Tillbaka i augusti 2015 skrev jag en artikel som introducerade den nya Stretch Database-funktionen i SQL Server 2016. I den artikeln diskuterade jag hur man kommer igång med Stretch Database i SQL Server 2016 Community Technology Preview 2 (CTP2). SQL Server 2016 släpptes den 1 juni 2016 och det har gjorts många uppdateringar av produkten. Metoden för att ställa in Stretch Database har ändrats något, liksom några av funktionerna.
Från och med SQL Server 2016 fick vi möjligheten att lagra delar av en databas i en Azure SQL-databas. I tidigare förhandsvisningar när du aktiverade Stretch för en databas var du tvungen att migrera hela tabellen, med RTM-versionen av SQL Server 2016 kan du nu välja en del av en tabell. När du har aktiverat stretch för en tabell migreras dina data tyst. Om du inte är bekant med Stretch Database, utnyttjar den processorkraften i Azure för att köra frågor mot fjärrdata genom att skriva om frågan. Du behöver inte skriva om några frågor på din sida. Du kommer att se detta som en "fjärrfråga"-operatör i frågeplanen.
Ett enkelt sätt att identifiera databaser och tabeller som är kvalificerade för Stretch-aktiverade är att ladda ner och köra SQL Server 2016 Upgrade Advisor och köra Stretch Database Advisor. Aaron Bertrand (@AaronBertrand) skrev om detta för ett tag sedan. Uppgraderingsrådgivaren har ändrats något sedan Aarons inlägg, men processen är för det mesta densamma:
- Identifiera kandidattabeller för SQL Server 2016 Stretch-databaser
Begränsningar för Stretch Database
Alla bord kommer inte att vara kvalificerade för Stretch-aktiverade. Vissa tabellegenskaper, data och kolumntyper, begränsningar och index stöds inte, till exempel:
- Minnesoptimerade och replikerade tabeller
- Tabeller som innehåller FILESTREAM-data, använder ändringsspårning eller ändringsdatainsamling
- Datatyper som tidsstämpel, sql_variant, XML eller geografi
- Kontrollera eller standardbegränsningar
- Främmande nyckelbegränsningar som refererar till tabellen
- XML, fulltext, rumsliga eller klustrade kolumnlagerindex
- Indexerade vyer som refererar till tabellen
- Du kan inte köra UPDATE- eller DELETE-satser, eller köra CREATE INDEX- eller ALTER INDEX-operationer på en Stretch-aktiverad tabell
För en fullständig lista över begränsningar kan du besöka:Krav och begränsningar för Stretch Database.
Konfigurera Stretch Database
Att komma igång med RTM-versionen är lite annorlunda än de tidigare förhandsvisningarna. Du behöver ett Azure-konto och sedan måste du aktivera Stretch Database på den lokala instansen.
För att aktivera Stretch Database på en instans, kör:
EXEC sys.sp_configure N'remote data archive', '1'; RECONFIGURE; GO
För denna demo kommer jag att använda en exempeldatabas som jag har skapat som heter STRETCH. Jag började med att högerklicka på databasen, välja Tasks, Stretch och sedan välja Aktivera. Detta använde SQL Server 2016 Management Studio.
Nästa skärm visar dig vilka tabeller du vill aktivera för Stretch:
Jag valde SALES2-tabellen. Guiden har som standard "Hela tabellen", men du kan också ändra det alternativet för att migrera en delmängd av rader.
Om du väljer efter rader måste du välja ett namn för dina kriterier, och sedan kan du välja vilken kolumn du ska använda i din where-sats, samt villkor och värde. I den här skärmdumpen valde jag rader före 2016. Att kunna välja en del av en tabell är en enorm förbättring jämfört med tidigare förhandsvisningar, som bara tillät dig att sträcka ut hela tabellen. För enkelhetens skull kommer jag i den här demon att migrera hela tabellen, så jag klickade på Avbryt och sedan på Nästa.
När du har valt dina tabeller och villkor måste du välja vilken Azure-prenumeration du ska använda, din Azure-region och din serverinformation.
När du har angett nödvändig information klickar du på Nästa.
En ny förbättring använder databasens huvudnyckel för att skydda Azure-referenserna för att ansluta till Azure. Om du inte redan har en huvudnyckel kommer du att bli ombedd att skapa en, om du redan har en måste du ange lösenordet. Klicka på Nästa.
Du måste skapa en brandväggsregel för din server, eller så kan du ange ett subnäts IP-intervall. Gör ditt val och klicka på Nästa.
Det är här saker och ting verkligen har förändrats och kommer få mig att ompröva att använda den här funktionen. Microsoft har skapat en Databas Stretch Unit (DSU) så att du kan skala upp eller ner prestandanivån du behöver för Stretch-data. Från och med juni 2016 faktureras nuvarande prissättning för både dator och lagring, vilket du ser representerat i bilden ovan. För mitt 15MB-bord som migrerades skulle jag debiteras 61 USD per månad för lagring, samt den lägsta DSU-nivån (100) på 912,50 USD per månad. DSU-nivåerna sträcker sig från:
| DSU-nivå | Timkostnad | Max månadskostnad (månader med 31 dagar) |
|---|---|---|
| 100 | 1,25 USD | 930 USD |
| 200 | 2,50 USD | 1 860 USD |
| 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 |
Varför sa guiden till mig bara 912,50 $, när prisbladet anger att det borde vara 900 $ för juni (eller proportionellt baserat på hur många dagar som är kvar i juni)? Din gissning är lika bra som min; Jag har provat olika matematiska saker och kom upp tom. Du kan lära dig mer om prismodellerna här:
- SQL Server Stretch Database-prissättning
Innan jag lärde mig om denna nya faktureringsmetod för DSU, skulle jag kunna argumentera för att användning av Stretch Database skulle vara en mycket kostnadseffektiv metod för att lagra kall data (oanvänd data) i molnet. Genom att sträcka ut dessa data till Azure kan du migrera en stor del av äldre data, vilket skulle minska storleken (och därmed kostnaden) för dina lokala säkerhetskopior. I händelse av att du var tvungen att återställa en databas måste du helt enkelt upprätta anslutningen till Azure för den utsträckta data, vilket eliminerar behovet av att återställa den. Men med den minimala kostnaden på nästan 1 000 USD per månad för den låga DSU-skalan, kommer många organisationer att upptäcka att det är mycket billigare att behålla data på en billigare lagernivå i sitt datacenter och hitta andra metoder för HA som t.ex. spegling, loggsändning eller tillgänglighetsgrupper.
Klicka på Slutför för att påbörja migreringen.
Grattis, jag har nu migrerat SALES2-tabellen till en Azure SQL-databas
Inaktivera ett stretchbord
I de tidiga förhandsvisningarna av Stretch Database, om du ville inaktivera en Stretch-tabell, måste du skapa en ny tabell och infoga sträckdata i den. När all data väl har kopierats måste du antingen manuellt byta ut tabellerna genom att byta namn på dem eller manuellt slå ihop de utsträckta data tillbaka till produktionstabellen. Med RTM-versionen kan du fortfarande hantera migreringen manuellt, välja att lämna data i Azure eller välja ett alternativ för att ta tillbaka data från Azure.
Oavsett vilken metod du använder för att återföra data, debiteras du avgifter för dataöverföring.
Säkerhetskopiering och återställning av en Stretch-databas
När du migrerar data till en Stretch-databas hanterar Azure säkerhetskopieringen av Stretch-data. Säkerhetskopiering sker med en ögonblicksbild tagen var 8:e timme och ögonblicksbilderna bevaras i 7 dagar. Detta ger dig upp till 21 poäng i tid under de senaste 7 dagarna att återställa.
Du behöver inte göra några ändringar i dina nuvarande lokala säkerhetskopieringsrutiner. Alla lokala säkerhetskopior som tas kommer att innehålla all lokal data och kvalificerad data som ännu inte har migrerats. Detta kallas en ytlig säkerhetskopia och innehåller inga data som redan har migrerats till Azure.
DBCC CHECKDB
Du kan inte heller köra CHECKDB mot data som har migrerats till Azure.
När jag körde DBCC CHECKDB på min STRETCH-databas före migreringen fick jag följande resultat för SALES2-tabellen:
DBCC-resultat för 'SALES2'.Det finns 45860 rader på 1901 sidor för objektet "SALES2".
Efter migreringen fick jag följande utdata för SALES2-tabellen (min betoning):
DBCC-resultat för 'SALES2'.Det finns 0 rader på 1901 sidor för objektet "SALES2".
Du kan köra DBCC CHECKDB mot Azure SQL Database, men på grund av att du inte kan ansluta direkt till den sträckta Azure SQL-databasen kan du för närvarande inte köra DBCC CHECKDB manuellt mot den utsträckta data specifikt. Jag kan inte hitta någon dokumentation som säger att Azure utför några konsistenskontroller mot dessa databaser.
Detta medför en betydande risk enligt min åsikt.
Sammanfattning
Stretch Database är ett enkelt sätt att migrera arkivdata till Microsoft Azure, om din databas stöder det. För närvarande i SQL Server 2016 RTM finns det många begränsningar med tabell-, data- och kolumnegenskaper, data och kolumntyper, begränsningar och index. Om du inte är begränsad av dessa begränsningar är Stretch Database ett enkelt sätt att migrera historisk data till Azure SQL Database för att frigöra lokal lagring och minska återställningstider för dessa databaser om kostnaden gör det värt besväret. Du måste också vara bekväm, åtminstone för nu, med att inte kunna köra DBCC CHECKDB mot någon migrerad data. Att hantera återställningar kommer att vara lite svårare också med att behöva återställa anslutningen mellan SQL Server-databasen och den fjärranslutna Azure-databasen.