V srpnu 2015 jsem napsal článek představující novou funkci Stretch Database v SQL Server 2016. V tomto článku jsem diskutoval o tom, jak začít s Stretch Database v SQL Server 2016 Community Technology Preview 2 (CTP2). SQL Server 2016 byl vydán 1. června 2016 a došlo k mnoha aktualizacím produktu. Způsob nastavení Stretch Database se mírně změnil, stejně jako některé funkce.
Počínaje SQL Serverem 2016 jsme získali možnost ukládat části databáze do Azure SQL Database. V dřívějších náhledech, když jste povolili Stretch pro databázi, museli jste migrovat celou tabulku, s vydáním RTM SQL Server 2016 si nyní můžete vybrat část tabulky. Jakmile povolíte roztažení pro tabulku, bude tiše migrovat vaše data. Pokud neznáte Stretch Database, využívá výpočetní výkon v Azure ke spouštění dotazů na vzdálená data přepsáním dotazu. Na své straně nemusíte přepisovat žádné dotazy. V plánu dotazů to uvidíte jako operátor „vzdáleného dotazu“.
Snadný způsob, jak identifikovat databáze a tabulky, které jsou způsobilé pro aktivaci Stretch, je stáhnout a spustit SQL Server 2016 Upgrade Advisor a spustit Stretch Database Advisor. Aaron Bertrand (@AaronBertrand) o tom psal před chvílí. Poradce pro upgrade se od Aaronova příspěvku mírně změnil, ale proces je většinou stejný:
- Identifikujte tabulky kandidátů pro SQL Server 2016 Stretch Database
Omezení pro databázi Stretch
Ne všechny tabulky budou způsobilé pro aktivaci Stretch. Některé vlastnosti tabulek, typy dat a sloupců, omezení a indexy nejsou podporovány, například:
- Paměťově optimalizované a replikované tabulky
- Tabulky, které obsahují data FILESTREAM, používají sledování změn nebo zachycování dat změn
- Datové typy, jako je časové razítko, sql_variant, XML nebo geografie
- Zkontrolujte nebo výchozí omezení
- Omezení cizího klíče, která odkazují na tabulku
- XML, fulltextové, prostorové nebo seskupené indexy columnstore
- Indexovaná zobrazení, která odkazují na tabulku
- Nemůžete spouštět příkazy UPDATE nebo DELETE ani spouštět operace CREATE INDEX nebo ALTER INDEX v tabulce s povolenou funkcí Stretch
Úplný seznam omezení najdete na:Požadavky a omezení pro Stretch Database.
Nastavení databáze Stretch Database
Začínáme s vydáním RTM je trochu jiné než předchozí náhledy. Budete potřebovat účet Azure a potom musíte povolit Stretch Database v místní instanci.
Chcete-li povolit Stretch Database na instanci, spusťte:
EXEC sys.sp_configure N'remote data archive', '1'; RECONFIGURE; GO
Pro toto demo použiji ukázkovou databázi, kterou jsem vytvořil, nazvanou STRETCH. Začal jsem kliknutím pravým tlačítkem na databázi, výběrem Úkoly, Roztáhnout a poté Povolit. To bylo pomocí SQL Server 2016 Management Studio.
Další obrazovka vám nabídne, které tabulky chcete povolit pro Stretch:
Vybral jsem si stůl SALES2. Výchozí nastavení průvodce je „Celá tabulka“, ale tuto možnost můžete také změnit a migrovat podmnožinu řádků.
Pokud vybíráte podle řádků, musíte pro svá kritéria vybrat název a poté si můžete vybrat, který sloupec chcete použít ve svém příkazu where, a také podmínku a hodnotu. Na tomto snímku obrazovky jsem vybral řádky před rokem 2016. Možnost vybrat si část tabulky je obrovským zlepšením oproti dřívějším náhledům, které vám umožňovaly pouze roztáhnout celou tabulku. Pro zjednodušení v této ukázce budu migrovat celou tabulku, takže jsem kliknul na Storno a poté na Další.
Jakmile budete mít vybrané tabulky a podmínky, musíte si vybrat, které předplatné Azure budete používat, vaši oblast Azure a informace o vašem serveru.
Jakmile zadáte požadované informace, klikněte na Další.
Nové vylepšení využívá hlavní klíč databáze k ochraně přihlašovacích údajů Azure pro připojení k Azure. Pokud ještě nemáte hlavní klíč, budete vyzváni k jeho vytvoření, pokud jej již máte, budete muset zadat heslo. Klikněte na Další.
Budete muset vytvořit pravidlo brány firewall pro váš server nebo můžete zadat rozsah IP podsítě. Proveďte výběr a klikněte na Další.
Tady se věci opravdu změnily a přiměje mě to znovu zvážit použití této funkce. Společnost Microsoft vytvořila jednotku Database Stretch Unit (DSU), abyste mohli zvýšit nebo snížit úroveň výkonu, kterou potřebujete pro data Stretch. Od června 2016 jsou aktuální ceny účtovány za výpočetní výkon i úložiště, což vidíte na obrázku výše. Za mou 15MB tabulku, která byla migrována, by mi bylo účtováno 61 USD měsíčně za úložiště a také minimální úroveň DSU (100) na 912,50 USD měsíčně. Úrovně DSU se pohybují od:
| Úroveň DSU | Hodinové náklady | Maximální měsíční náklady (měsíce s 31 dny) |
|---|---|---|
| 100 | 1,25 $ | 930 $ |
| 200 | 2,50 $ | 1 860 $ |
| 300 | 3,75 $ | 2 790 $ |
| 400 | 5,00 $ | 3 720 $ |
| 500 | 6,25 $ | 4 650 $ |
| 600 | 7,50 $ | 5 580 $ |
| 1000 | 12,50 $ | 9 300 $ |
| 1200 | 15,00 $ | 11 160 $ |
| 1500 | 18,75 $ | 13 950 $ |
| 2000 | 25,00 $ | 18 600 $ |
Proč mi průvodce řekl pouze 912,50 $, když ceník uvádí, že by to mělo být 900 $ za červen (nebo poměrné podle toho, kolik dní do června zbývá)? Tvůj odhad je stejně dobrý, jako můj; Zkoušel jsem různé matematické věci a přišel jsem prázdný. Více o cenových modelech se můžete dozvědět zde:
- Cena SQL Server Stretch Database
Než jsem se dozvěděl o této nové metodě účtování pro DSU, mohl bych argumentovat, že použití Stretch Database by bylo velmi nákladově efektivní metodou pro ukládání studených dat (nepoužitých dat) do cloudu. Natažením těchto dat do Azure byste mohli migrovat velkou část starších dat, což by snížilo velikost (a tím i náklady) vašich místních záloh. V případě, že byste museli obnovit databázi, museli byste jednoduše vytvořit připojení k Azure pro roztažená data, čímž odpadá nutnost je obnovovat. Nicméně, s minimálními náklady téměř 1 000 $ měsíčně za nízkou úroveň DSU, mnoho organizací zjistí, že je mnohem levnější uchovávat data na levnější vrstvě úložiště v rámci jejich datového centra a najít jiné metody pro HA, jako je např. zrcadlení, odeslání protokolu nebo skupiny dostupnosti.
Klepnutím na tlačítko Dokončit zahájíte migraci.
Gratulujeme, nyní jsem migroval tabulku SALES2 do Azure SQL Database
Zakázat tabulku roztažení
Pokud jste v prvních náhledech Stretch Database chtěli deaktivovat tabulku Stretch, museli byste vytvořit novou tabulku a vložit do ní data stretch. Jakmile budou všechna data zkopírována, budete muset tabulky buď ručně vypnout přejmenováním, nebo ručně sloučit roztažená data zpět do produkční tabulky. S vydáním RTM můžete migraci stále zpracovávat ručně, můžete zvolit ponechání dat v Azure nebo zvolit možnost přenést data zpět z Azure.
Bez ohledu na to, jakou metodu přivedete data zpět, vám budou účtovány poplatky za přenos dat.
Zálohování a obnova databáze Stretch
Jakmile migrujete data do databáze Stretch, Azure zpracuje zálohu dat Stretch. Zálohování probíhá se snímkem pořízeným každých 8 hodin a snímky se uchovávají po dobu 7 dnů. Získáte tak až 21 bodů v čase za předchozích 7 dní k obnovení.
Ve svých aktuálních místních zálohovacích rutinách nemusíte provádět žádné změny. Všechny provedené místní zálohy budou obsahovat všechna místní data a vhodná data, která ještě nebyla migrována. Toto se nazývá mělká záloha a neobsahuje žádná data již migrovaná do Azure.
DBCC CHECKDB
CHECKDB také nemůžete spustit pro data, která byla migrována do Azure.
Když jsem před migrací spustil DBCC CHECKDB na mé databázi STRETCH, dostal jsem následující výsledky pro tabulku SALES2:
Výsledky DBCC pro 'PRODEJ2'.Objekt "PRODEJ2" obsahuje 45860 řádků na 1901 stránkách.
Po migraci jsem obdržel následující výstup pro tabulku SALES2 (důraz):
Výsledky DBCC pro 'SALES2'.Existuje 0 řádků na 1901 stranách pro objekt "PRODEJ2".
DBCC CHECKDB můžete spustit proti Azure SQL Database, ale protože se nemůžete připojit přímo k natažené Azure SQL Database, aktuálně nemůžete ručně spustit DBCC CHECKDB konkrétně pro natažená data. Nemohu najít žádnou dokumentaci, která uvádí, že Azure provádí nějaké kontroly konzistence proti těmto databázím.
To podle mého názoru přináší značné riziko.
Shrnutí
Stretch Database je snadný způsob migrace archivních dat do Microsoft Azure, pokud to vaše databáze podporuje. V současné době v SQL Server 2016 RTM existuje mnoho omezení s vlastnostmi tabulek, dat a sloupců, typy dat a sloupců, omezení a indexy. Pokud vás tato omezení neomezují, pak je Stretch Database jednoduchý způsob, jak migrovat historická data do Azure SQL Database, abyste uvolnili místní úložiště a zkrátili dobu obnovy těchto databází, pokud se to náklady vyplatí. Musíte se také alespoň prozatím spokojit s tím, že nebudete moci spustit DBCC CHECKDB proti jakýmkoli migrovaným datům. Správa obnovení bude také trochu složitější, protože bude nutné obnovit spojení mezi databází SQL Server a vzdálenou databází Azure.