I denne artikel ser vi på stretch-aktiverede tabeller, som man skal være opmærksom på, herunder nøglebegrænsninger
Stretch Database er en SQL Server funktion, der giver brugerne mulighed for at migrere kolde data sikkert og gennemsigtigt til Azure cloud. Brugere kan endda sætte disse migreringer på pause under forbindelsesfejl, hvilket hjælper med lettere overførsel af data.
Stretch Database er direkte rettet mod transaktionelle databaser, der indeholder en stor mængde kolde data, som normalt er gemt i flere tabeller i en database. Og disse tabeller kan indeholde data, der er langt mere end en milliard rækker.
Hvorfor bruges Stretch Database?
• Det giver brugerne mulighed for at gemme kolde data i en separat tabel eller en database til at migrere til Azure cloud.
• Brugere kan bruge sin filterfunktion til at adskille eller vælge kolde eller varme data i rækkerne, alt efter hvad de vil migrere.
Stretch Database er fantastisk SQL Server funktion, der giver brugerne mulighed for at migrere deres data sikkert og gennemsigtigt til Microsoft Azure, men det kommer også med nogle begrænsninger, som deaktiverer brugerne i at implementere eller aktivere stretch på deres databaser. Her er en liste over få af dens begrænsninger. Husk dem, mens du bruger stretch, hvis du vil migrere dine data til Azure skyen.
Begrænsninger for Stretch Database-aktiverede tabeller
Dette er nogle af de betingelser, der forhindrer Stretch Database i at blive aktiveret i dine tabeller. Sørg for at huske dem næste gang du arbejder med Stretch Database.
1. Begrænsninger
• Mens du bruger strækdatabase, håndhæves Unikhed ikke på PRIMÆRE NØGLE- og UNIKE begrænsninger i Microsoft Azure-tabeller, der indeholder nogen form for migrerede data.
2. DML-operationer
• I enhver Stretch-aktiveret tabel er bruger ikke tilladt at SLETTE eller OPDATERE nogen migrerede rækker eller rækker, der stadig er kvalificerede til migration.
• Brugere har heller ikke tilladelse til at indsætte rækker i nogen Stretch-aktiveret tabel fra en linket server.
3. Indekser
• Stretch-aktiverede tabeller tillader ikke brugere at oprette et indeks til visningen.
• Eventuelle filtre på indekser i SQL Server overføres ikke fra den Stretch-aktiverede tabel til den eksterne tabel.
4. Begrænsninger, der forhindrer brugere i at aktivere Stretch Database i en tabel
Brugere kan ikke aktivere Stretch Database for tabeller, der har eller er under følgende betingelser:
5. Tabelegenskaber
• Tabeller med mere end 998 indekser eller over 1,023 kolonner
• Alle filtabeller eller tabeller, der indeholder FILESTREAM-data
• Tabeller, der har en aktiv brug af Change Data Capture eller Change Tracking
• Eventuelle tabeller, der er optimeret til hukommelse
6. Datatyper
• Tekst, billede og ntekst
• tidsstempel
• sql_variant
• XML
• CLR-datatyper som geometri, hierarchyid, CLR eller brugerdefinerede geografityper.
7. Begrænsninger
• Kontroller begrænsninger sammen med standardbegrænsninger
• Eventuelle begrænsninger for udenlandske nøgler, der refererer til tabellen. Vi kan forklare dette ved hjælp af forholdet mellem forælder og barn, hvor (for eksempel Ordre (forælder) og Ordre_Detail (barn)), en bruger kan aktivere Stretch Database Table for tabellen for sit barn (Order_Detail), men kan ikke ændre indstillingen af overordnet tabel (rækkefølge).
8. Indekser
• Indekser med fulde tekster
• XML-indekser
• Rumlige indekser
• Eventuelle indekserede visninger, der refererer til tabellen
Mens stretch-databaser bør overvejes aktivt, skal virksomheder også investere i et værktøj, der kan gendanne sql serverdatabasefiler for at holde deres data sikre under uforudsete udgifter.
Forfatter Introduktion:
Victor Simon er ekspert i datagendannelse i DataNumen, Inc., som er verdens førende inden for datagendannelsesteknologier, herunder adgangsgendannelse og SQL-genopretningssoftwareprodukter. For mere information besøg www.datanumen.com