In augustus 2015 schreef ik een artikel waarin ik de nieuwe Stretch Database-functie in SQL Server 2016 introduceerde. In dat artikel besprak ik hoe je aan de slag kunt gaan met Stretch Database in SQL Server 2016 Community Technology Preview 2 (CTP2). SQL Server 2016 is uitgebracht op 1 juni 2016 en er zijn talloze updates voor het product geweest. De methode voor het opzetten van Stretch Database is lichtjes gewijzigd, evenals enkele functies.
Vanaf SQL Server 2016 kregen we de mogelijkheid om delen van een database op te slaan in een Azure SQL Database. In eerdere previews toen je Stretch voor een database inschakelde, moest je de hele tabel migreren, met de RTM-release van SQL Server 2016 kun je nu een deel van een tabel kiezen. Zodra u stretch voor een tabel inschakelt, worden uw gegevens geruisloos gemigreerd. Als u niet bekend bent met Stretch Database, maakt het gebruik van de verwerkingskracht in Azure om query's uit te voeren op de externe gegevens door de query te herschrijven. U hoeft aan uw kant geen query's te herschrijven. U zult dit zien als een "remote query"-operator in het queryplan.
Een gemakkelijke manier om databases en tabellen te identificeren die in aanmerking komen voor Stretch-enabled is door de SQL Server 2016 Upgrade Advisor te downloaden en uit te voeren en de Stretch Database Advisor uit te voeren. Aaron Bertrand (@AaronBertrand) schreef hier een tijdje terug over. De upgrade-adviseur is enigszins veranderd sinds Aarons post, maar het proces is grotendeels hetzelfde:
- Kandidaatstabellen identificeren voor SQL Server 2016 Stretch-databases
Beperkingen voor Stretch-database
Niet alle tafels komen in aanmerking voor Stretch-enabled. Bepaalde tabeleigenschappen, gegevens- en kolomtypen, beperkingen en indexen worden niet ondersteund, zoals:
- Voor geheugen geoptimaliseerde en gerepliceerde tabellen
- Tabellen die FILESTREAM-gegevens bevatten, gebruiken Change Tracking of Change Data Capture
- Gegevenstypen zoals tijdstempel, sql_variant, XML of geografie
- Controleer of standaardbeperkingen
- Buitenlandse sleutelbeperkingen die verwijzen naar de tabel
- XML, full-text, ruimtelijke of geclusterde columnstore-indexen
- Geïndexeerde weergaven die verwijzen naar de tabel
- U kunt geen UPDATE- of DELETE-instructies uitvoeren of CREATE INDEX- of ALTER INDEX-bewerkingen uitvoeren op een tabel met Stretch-functionaliteit
Voor een volledige lijst van beperkingen kunt u terecht op:Vereisten en beperkingen voor Stretch Database.
Stretch Database instellen
Aan de slag met de RTM-release is een beetje anders dan de eerdere previews. U hebt een Azure-account nodig en vervolgens moet u Stretch Database inschakelen op het lokale exemplaar.
Om Stretch Database op een instantie in te schakelen, voert u het volgende uit:
EXEC sys.sp_configure N'remote data archive', '1'; RECONFIGURE; GO
Voor deze demo ga ik een voorbeelddatabase gebruiken die ik heb gemaakt, genaamd STRETCH. Ik begon door met de rechtermuisknop op de database te klikken, Taken, Uitrekken te kiezen en vervolgens Inschakelen te kiezen. Dit was met behulp van SQL Server 2016 Management Studio.
In het volgende scherm ziet u welke tabellen u voor Stretch wilt inschakelen:
Ik koos de SALES2-tabel. De wizard is standaard ingesteld op 'Volledige tabel', maar u kunt die optie ook wijzigen om een subset van rijen te migreren.
Als u kiest voor rijen, moet u een naam voor uw criteria selecteren en vervolgens kunt u kiezen welke kolom u wilt gebruiken in uw waar-instructie, evenals de voorwaarde en waarde. In deze schermafbeelding heb ik rijen van vóór 2016 gekozen. Het is een enorme verbetering om een deel van een tafel te kunnen kiezen ten opzichte van de eerdere voorbeelden, waarbij je alleen de hele tafel kon uitrekken. Voor de eenvoud ga ik in deze demo de hele tabel migreren, dus ik klikte op Annuleren en vervolgens op Volgende.
Zodra u uw tabellen en voorwaarden hebt geselecteerd, moet u kiezen welk Azure-abonnement u gaat gebruiken, uw Azure-regio en uw servergegevens.
Nadat u de vereiste informatie heeft ingevoerd, klikt u op Volgende.
Een nieuwe verbetering is het gebruik van de hoofdsleutel van de database om de Azure-referenties te beschermen om verbinding te maken met Azure. Als u nog geen hoofdsleutel heeft, wordt u gevraagd er een te maken. Als u er al een heeft, moet u het wachtwoord opgeven. Klik op Volgende.
U moet een firewallregel voor uw server maken, of u kunt een subnet-IP-bereik invoeren. Maak uw keuze en klik op Volgende.
Dit is waar de dingen echt zijn veranderd en zal me ertoe aanzetten deze functie te heroverwegen. Microsoft heeft een Database Stretch Unit (DSU) gemaakt, zodat u het prestatieniveau dat u nodig hebt voor Stretch-gegevens kunt verhogen of verlagen. Vanaf juni 2016 worden de huidige prijzen gefactureerd voor zowel rekenkracht als opslag, die u in de bovenstaande afbeelding ziet. Voor mijn tafel van 15 MB die was gemigreerd, zou ik $ 61 USD per maand voor opslag in rekening worden gebracht, evenals het minimale DSU-niveau (100) van $ 912,50 per maand. DSU-niveaus variëren van:
| DSU-niveau | Uurkosten | Maximale maandelijkse kosten (maanden met 31 dagen) |
|---|---|---|
| 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 |
Waarom vertelde de wizard me slechts $ 912,50, terwijl het prijsoverzicht aangeeft dat het $ 900 zou moeten zijn voor juni (of naar rato op basis van hoeveel dagen er nog over zijn in juni)? Jouw gok is even goed als die van mij; Ik heb verschillende wiskundige dingen geprobeerd en kwam blanco uit. U kunt hier meer te weten komen over de prijsmodellen:
- SQL Server Stretch Database-prijzen
Voordat ik deze nieuwe factureringsmethode voor DSU leerde kennen, zou ik het argument kunnen aanvoeren dat het gebruik van Stretch Database een zeer kosteneffectieve methode zou zijn voor het opslaan van koude gegevens (ongebruikte gegevens) in de cloud. Door deze gegevens uit te breiden naar Azure, kunt u een groot deel van de oudere gegevens migreren, waardoor de omvang (en dus de kosten) van uw lokale back-ups zou afnemen. Als u een database zou moeten herstellen, hoeft u alleen maar de verbinding met Azure tot stand te brengen voor de uitgerekte gegevens, zodat u deze niet meer hoeft te herstellen. Met de minimale kosten van bijna $ 1.000 per maand voor de low-end DSU-schaal, zullen veel organisaties merken dat het veel goedkoper is om de gegevens op een goedkopere opslaglaag in hun datacenter te bewaren en andere methoden voor HA te vinden, zoals spiegelen, verzending loggen of beschikbaarheidsgroepen.
Klik op Voltooien om de migratie te starten.
Gefeliciteerd, ik heb nu de SALES2-tabel gemigreerd naar een Azure SQL Database
Een Stretch-tabel uitschakelen
Als u in de vroege voorvertoningen van Stretch Database een Stretch-tabel wilde uitschakelen, moest u een nieuwe tabel maken en de stretchgegevens daarin invoegen. Nadat alle gegevens zijn gekopieerd, moet u de tabellen handmatig uitschakelen door ze een andere naam te geven, of de uitgerekte gegevens handmatig weer samenvoegen in de productietabel. Met de RTM-release kunt u de migratie nog steeds handmatig afhandelen, ervoor kiezen om de gegevens in Azure te laten of een optie kiezen om gegevens terug te halen uit Azure.
Ongeacht welke methode u gebruikt om de gegevens terug te brengen, er worden kosten in rekening gebracht voor gegevensoverdracht.
Back-up en herstel van een Stretch-database
Zodra u gegevens naar een Stretch-database migreert, zorgt Azure voor de back-up van de Stretch-gegevens. Er worden back-ups gemaakt waarbij elke 8 uur een momentopname wordt gemaakt en de momentopnamen worden 7 dagen bewaard. Dit geeft je tot 21 punten in de tijd in de afgelopen 7 dagen om te herstellen.
U hoeft geen wijzigingen aan te brengen in uw huidige lokale back-uproutines. Alle lokale back-ups die worden gemaakt, bevatten alle lokale gegevens en in aanmerking komende gegevens die nog niet zijn gemigreerd. Dit wordt een ondiepe back-up genoemd en bevat geen gegevens die al naar Azure zijn gemigreerd.
DBCC CHECKDB
U kunt CHECKDB ook niet uitvoeren op gegevens die naar Azure zijn gemigreerd.
Toen ik vóór de migratie DBCC CHECKDB op mijn STRETCH-database uitvoerde, kreeg ik de volgende resultaten voor de SALES2-tabel:
DBCC-resultaten voor 'SALES2'.Er zijn 45860 rijen in 1901 pagina's voor object 'SALES2'.
Na de migratie ontving ik de volgende uitvoer voor de SALES2-tabel (nadruk van mij):
DBCC-resultaten voor 'SALES2'.Er zijn 0 rijen in 1901 pagina's voor object "SALES2".
U kunt DBCC CHECKDB uitvoeren op Azure SQL Database, maar omdat u niet rechtstreeks verbinding kunt maken met de uitgerekte Azure SQL Database, kunt u DBCC CHECKDB momenteel niet handmatig uitvoeren op de uitgerekte gegevens. Ik kan geen documentatie vinden waarin staat dat Azure consistentiecontroles uitvoert op deze databases.
Dit brengt naar mijn mening een aanzienlijk risico met zich mee.
Samenvatting
Stretch Database is een gemakkelijke manier om archiefgegevens te migreren naar Microsoft Azure, als uw database dit ondersteunt. Momenteel zijn er in SQL Server 2016 RTM veel beperkingen met betrekking tot tabel-, gegevens- en kolomeigenschappen, gegevens- en kolomtypen, beperkingen en indexen. Als u niet door die beperkingen wordt beperkt, is Stretch Database een eenvoudige manier om historische gegevens naar Azure SQL Database te migreren om lokale opslag vrij te maken en de hersteltijden van die databases te verkorten als de kosten het de moeite waard maken. U moet zich, althans voorlopig, ook op uw gemak voelen met het niet kunnen uitvoeren van DBCC CHECKDB tegen gemigreerde gegevens. Het beheren van herstelbewerkingen zal ook wat lastiger zijn omdat de verbinding tussen de SQL Server-database en de externe Azure-database moet worden hersteld.