I den här artikeln tittar vi på stretchaktiverade tabeller som man bör vara medveten om inklusive viktiga begränsningar
Stretch Database är en SQL Server funktion som tillåter användare att migrera kall data säkert och transparent till Azure moln. Användare kan till och med pausa dessa migreringar under anslutningsfel, vilket underlättar överföring av data.
Stretch Database riktar sig direkt mot transaktionsdatabaser som innehåller en stor mängd kalldata, som vanligtvis lagras i flera tabeller i en databas. Och dessa tabeller kan innehålla data som är långt mer än en miljard rader.
Varför används Stretch Database?
• Det gör det möjligt för användare att lagra kall data i en separat tabell eller en databas för att migrera till Azure-molnet.
• Användare kan använda sin filterfunktion för att separera eller välja kall eller het data, i raderna beroende på vad de vill migrera.
Stretch Database är fantastiskt SQL Server funktion som tillåter användare att migrera sina data säkert och öppet till Microsoft Azure, men det kommer också med vissa begränsningar, vilket gör att användarna inte kan implementera eller möjliggöra sträckning i sina databaser. Här är en lista över några av dess begränsningar. Tänk på dem när du använder stretch om du vill migrera dina data till Azure-molnet.
Begränsningar för Stretch Database-aktiverade tabeller
Det här är några av villkoren som förhindrar att Stretch Database aktiveras i dina tabeller, se till att ha dem i åtanke nästa gång du arbetar med Stretch Database.
1. Begränsningar
• När du använder stretch-databas tillämpas inte unika PRIMÄRA NYCKEL- och UNIKA begränsningar i Microsoft Azure-tabeller som innehåller någon form av migrerad data.
2. DML-operationer
• I någon Stretch-aktiverad tabell får användare inte ta bort eller UPPDATERA migrerade rader eller rader som fortfarande är kvalificerade för migrering.
• Användare får inte heller infoga rader i någon Stretch-aktiverad tabell från en länkad server.
3. Index
• Stretch-aktiverade tabeller tillåter inte användare att skapa ett index för vyn.
• Alla filter på index i SQL Server förökas inte från den Stretch-aktiverade tabellen till fjärrbordet.
4. Begränsningar som hindrar användare från att aktivera Stretch Database i en tabell
Användare kan inte aktivera Stretch Database för tabeller som har eller har kommit under följande villkor:
5. Tabellegenskaper
• Tabeller med mer än 998 index eller över 1,023 XNUMX kolumner
• Alla filtabeller eller tabeller som innehåller FILESTREAM-data
• Tabeller som har en aktiv användning av Change Data Capture eller Change Tracking
• Alla tabeller som var minnesoptimerade
6. Datatyper
• Text, bild och ntext
• tidsstämpel
• sql_variant
• XML
• CLR-datatyper som geometri, hierarchyid, CLR eller användardefinierade geografityper.
7. Begränsningar
• Kontrollera begränsningar tillsammans med standardbegränsningar
• Eventuella begränsningar för utländska nycklar som hänvisar till tabellen. Vi kan förklara detta med förhållandet mellan förälder och barn där (till exempel Order (parent) och Order_Detail (child)), en användare kan aktivera Stretch Database Table för tabellen för sitt barn (Order_Detail) men kan inte ändra inställningen för överordnad tabell (beställning).
8. Index
• Index med fulltexter
• XML-index
• Rumsliga index
• Eventuella indexerade vyer som ger en hänvisning till tabellen
Även om stretchdatabaser bör beaktas aktivt måste företag också investera i ett verktyg som kan återhämta sql serverdatabasfiler för att hålla deras data säkra under eventualiteter.
Författarintroduktion:
Victor Simon är en dataåterställningsexpert i DataNumen, Inc., som är världsledande inom teknik för återställning av data, inklusive åtkomståterställning och mjukvaruprodukter för SQL-återställning. För mer information besök www.datanumen.com