Tilbage i august 2015 skrev jeg en artikel, der introducerede den nye Stretch Database-funktion i SQL Server 2016. I den artikel diskuterede jeg, hvordan man kommer i gang med Stretch Database i SQL Server 2016 Community Technology Preview 2 (CTP2). SQL Server 2016 blev udgivet den 1. juni 2016, og der har været adskillige opdateringer til produktet. Metoden til opsætning af Stretch Database er ændret en smule såvel som nogle af funktionerne.
Fra og med SQL Server 2016 fik vi muligheden for at gemme dele af en database i en Azure SQL-database. I tidligere forhåndsvisninger, når du aktiverede Stretch for en database, var du nødt til at migrere hele tabellen, med RTM-udgivelsen af SQL Server 2016, kan du nu vælge en del af en tabel. Når du aktiverer stræk for en tabel, migrerer den lydløst dine data. Hvis du ikke er bekendt med Stretch Database, udnytter den processorkraften i Azure til at køre forespørgsler mod fjerndataene ved at omskrive forespørgslen. Du behøver ikke at omskrive nogen forespørgsler fra din side. Du vil se dette som en "fjernforespørgsel"-operatør i forespørgselsplanen.
En nem måde at identificere databaser og tabeller, der er kvalificerede til at blive Stretch-aktiveret, er at downloade og køre SQL Server 2016 Upgrade Advisor og køre Stretch Database Advisor. Aaron Bertrand (@AaronBertrand) skrev om dette for et stykke tid tilbage. Opgraderingsrådgiveren har ændret sig lidt siden Aarons indlæg, men processen er for det meste den samme:
- Identificer kandidattabeller til SQL Server 2016 Stretch-databaser
Begrænsninger for Stretch-database
Ikke alle borde vil være kvalificerede til at være Stretch-aktiverede. Visse tabelegenskaber, data- og kolonnetyper, begrænsninger og indekser understøttes ikke, såsom:
- Hukommelsesoptimerede og replikerede tabeller
- Tabeller, der indeholder FILESTREAM-data, bruger Change Tracking eller Change Data Capture
- Datatyper såsom tidsstempel, sql_variant, XML eller geografi
- Tjek eller standardbegrænsninger
- Fremmednøglebegrænsninger, der refererer til tabellen
- XML-, fuldtekst-, rumlige eller klyngede kolonnelagerindekser
- Indekserede visninger, der refererer til tabellen
- Du kan ikke køre UPDATE- eller DELETE-sætninger eller køre CREATE INDEX- eller ALTER INDEX-operationer på en Stretch-aktiveret tabel
For en komplet liste over begrænsninger kan du besøge:Krav og begrænsninger for Stretch Database.
Opsætning af Stretch-database
At komme i gang med RTM-udgivelsen er en smule anderledes end de tidligere forhåndsvisninger. Du skal bruge en Azure-konto, og derefter skal du aktivere Stretch Database på den lokale instans.
For at aktivere Stretch Database på en instans skal du køre:
EXEC sys.sp_configure N'remote data archive', '1'; RECONFIGURE; GO
Til denne demo vil jeg bruge en prøvedatabase, som jeg har oprettet kaldet STRETCH. Jeg startede med at højreklikke på databasen, vælge Opgaver, Stræk, og derefter vælge Aktiver. Dette brugte SQL Server 2016 Management Studio.
Den næste skærm viser dig, hvilke borde du gerne vil aktivere for Stretch:
Jeg valgte SALES2 tabellen. Guiden er som standard "Hele tabellen", men du kan også ændre denne mulighed for at migrere en undergruppe af rækker.
Hvis du vælger efter rækker, skal du vælge et navn til dine kriterier, og så kan du vælge hvilken kolonne du vil bruge i din where-sætning, samt betingelse og værdi. I dette skærmbillede valgte jeg rækker før 2016. At kunne vælge en del af en tabel er en kæmpe forbedring i forhold til de tidligere forhåndsvisninger, som kun tillod dig at strække hele tabellen. For nemheds skyld vil jeg i denne demo migrere hele tabellen, så jeg klikkede på Annuller og derefter på Næste.
Når du har valgt dine tabeller og betingelser, skal du vælge hvilket Azure-abonnement du vil bruge, dit Azure-område og dine serveroplysninger.
Når du har indtastet de nødvendige oplysninger, skal du klikke på Næste.
En ny forbedring bruger databasens hovednøgle til at beskytte Azure-legitimationsoplysningerne for at oprette forbindelse til Azure. Hvis du ikke allerede har en hovednøgle, bliver du bedt om at oprette en, hvis du allerede har en, skal du angive adgangskoden. Klik på Næste.
Du skal oprette en firewall-regel for din server, eller du kan indtaste et IP-område for undernet. Foretag dit valg, og klik på Næste.
Det er her, tingene virkelig har ændret sig, og det vil få mig til at genoverveje at bruge denne funktion. Microsoft har skabt en Database Stretch Unit (DSU), så du kan skalere op eller ned det ydeevne, du har brug for til Stretch-data. Fra juni 2016 faktureres den nuværende prissætning for både computer og lagring, som du ser repræsenteret på billedet ovenfor. For mit 15 MB-bord, der blev migreret, ville jeg blive opkrævet $61 USD pr. måned for opbevaring, såvel som minimums DSU-niveau (100) til $912,50 pr. måned. DSU-niveauer spænder fra:
| DSU-niveau | Pris pr. time | Maks. månedlig pris (måneder med 31 dage) |
|---|---|---|
| 100 | 1,25 USD | 930 USD |
| 200 | 2,50 USD | $1.860 |
| 300 | 3,75 USD | 2.790 USD |
| 400 | 5,00 USD | 3.720 USD |
| 500 | 6,25 USD | 4.650 USD |
| 600 | 7,50 USD | 5.580 USD |
| 1000 | 12,50 USD | 9.300 USD |
| 1200 | 15,00 USD | 11.160 USD |
| 1500 | 18,75 USD | 13.950 USD |
| 2000 | 25,00 USD | 18.600 USD |
Hvorfor fortalte guiden mig kun $912,50, når prisarket angiver, at det burde være $900 for juni (eller forholdsmæssigt baseret på, hvor mange dage der er tilbage i juni)? Dit gæt er lige så godt som mit; Jeg har prøvet forskellige matematiske ting og kom op blank. Du kan lære mere om prismodellerne her:
- SQL Server Stretch Database Pricing
Inden jeg lærte om denne nye faktureringsmetode for DSU, kunne jeg argumentere for, at brug af Stretch Database ville være en meget omkostningseffektiv metode til at gemme kolde data (ubrugte data) i skyen. Ved at strække disse data ind i Azure kan du migrere en stor del af ældre data, hvilket ville reducere størrelsen (og dermed omkostningerne) af dine lokale sikkerhedskopier. I tilfælde af at du skulle gendanne en database, skulle du blot oprette forbindelsen til Azure for de strakte data, og dermed eliminere behovet for at gendanne dem. Men med de minimale omkostninger på næsten 1.000 USD om måneden for den lave DSU-skala, vil mange organisationer opleve, at det er meget billigere at opbevare dataene på et billigere lager i deres datacenter og finde andre metoder til HA som f.eks. spejling, logforsendelse eller tilgængelighedsgrupper.
Klik på Udfør for at starte migreringen.
Tillykke, jeg har nu migreret SALES2-tabellen til en Azure SQL-database
Deaktiver et strækbord
I de tidlige forhåndsvisninger af Stretch Database, hvis du ville deaktivere en Stretch-tabel, skulle du oprette en ny tabel og indsætte stretch-dataene i den. Når alle data var kopieret, skulle du enten manuelt skifte tabellerne ud ved at omdøbe dem eller manuelt flette de strakte data tilbage til produktionstabellen. Med RTM-udgivelsen kan du stadig håndtere migreringen manuelt, vælge at forlade dataene i Azure eller vælge en mulighed for at bringe data tilbage fra Azure.
Uanset hvilken metode du bruger til at bringe dataene tilbage, pålægges du dataoverførselsgebyrer.
Sikkerhedskopiering og gendannelse af en Stretch-database
Når du migrerer data til en Stretch-database, håndterer Azure sikkerhedskopieringen af Stretch-dataene. Sikkerhedskopier sker med et øjebliksbillede taget hver 8. time, og snapshots opbevares i 7 dage. Dette giver dig op til 21 point-in-time i løbet af de foregående 7 dage at gendanne.
Du behøver ikke at foretage ændringer i dine nuværende lokale backuprutiner. Eventuelle lokale sikkerhedskopier vil indeholde alle lokale data og kvalificerede data, som endnu ikke er blevet migreret. Dette omtales som en overfladisk sikkerhedskopi og indeholder ingen data, der allerede er migreret til Azure.
DBCC CHECKDB
Du kan heller ikke køre CHECKDB mod data, der er blevet migreret til Azure.
Da jeg kørte DBCC CHECKDB på min STRETCH-database før migreringen, fik jeg følgende resultater for SALES2-tabellen:
DBCC-resultater for 'SALES2'.Der er 45860 rækker på 1901 sider for objektet "SALES2".
Efter migreringen modtog jeg følgende output til SALES2-tabellen (min fremhævelse):
DBCC-resultater for 'SALES2'.Der er 0 rækker på 1901 sider for objektet "SALES2".
Du kan køre DBCC CHECKDB mod Azure SQL Database, men på grund af ikke at kunne oprette forbindelse direkte til den strakte Azure SQL Database, kan du i øjeblikket ikke manuelt køre DBCC CHECKDB mod de strakte data specifikt. Jeg kan ikke finde nogen dokumentation, der angiver, at Azure udfører nogen konsistenstjek mod disse databaser.
Dette medfører en betydelig risiko efter min mening.
Oversigt
Stretch Database er en nem måde at migrere arkivdata til Microsoft Azure, hvis din database understøtter det. I øjeblikket i SQL Server 2016 RTM er der mange begrænsninger med tabel-, data- og kolonneegenskaber, data og kolonnetyper, begrænsninger og indekser. Hvis du ikke er begrænset af disse begrænsninger, så er Stretch Database en enkel måde at migrere historiske data til Azure SQL Database for at frigøre lokal lagring og reducere gendannelsestider for disse databaser, hvis omkostningerne gør det umagen værd. Du skal også være komfortabel, i det mindste for nu, med ikke at være i stand til at køre DBCC CHECKDB mod nogen migreret data. Håndtering af gendannelser vil også være en smule vanskeligere med at skulle genoprette forbindelsen mellem SQL Server-databasen og den eksterne Azure-database.