Naarmate de tijd verstrijkt, migreren meer bedrijven naar, of evalueren ze op zijn minst, Azure SQL Database als alternatief voor de hoge kosten van het on-premises uitvoeren van SQL Server.
Compatibiliteit controleren
Een van de eerste aspecten van het verplaatsen van uw database naar Azure SQL Database is controleren op compatibiliteit en Microsoft geeft u tal van manieren om dit te doen voor Azure SQL Database V12 (hierna alleen 'V12' genoemd). Een van deze methoden is het gebruik van SQL Server Data Tools for Visual Studio (SSDT), die de meest recente compatibiliteitsregels gebruikt om V12-incompatibiliteiten te detecteren. In SSDT kunt u uw databaseschema importeren en een project bouwen voor een V12-implementatie, en als er onverenigbaarheden worden gevonden, kunnen deze binnen SSDT worden gecorrigeerd en vervolgens weer worden gesynchroniseerd met de brondatabase.
U kunt ook een opdrachtregelprogramma gebruiken met de naam SqlPackage dat een rapport van compatibiliteitsproblemen kan genereren (en er altijd voor zorgt dat u over de nieuwste versie beschikt). SQL Server Management Studio is een andere manier om dit te doen, met behulp van de functie Export Data-tier Application, die fouten kan detecteren en rapporteren op het scherm. Als er geen fouten worden gedetecteerd, kunt u uw database migreren naar V12. Als er onverenigbaarheden worden gedetecteerd, kunnen deze vóór de migratie worden gecorrigeerd met SSMS.
Data Migration Assistant is een stand-alone tool (gemakkelijk te verwarren met de SQL Server Migration Assistant) die kan worden gebruikt om de upgrade-inspanning te verminderen, en vervangt de SQL Server 2016 Upgrade Advisor Preview. DMA kan ook prestatie- en betrouwbaarheidsverbeteringen aanbevelen. Een ander hulpprogramma, SQL Azure Migration Wizard (SAMW), is een Codeplex-hulpprogramma dat gebruikmaakt van Azure SQL Database V11-compatibiliteitsregels om V12-incompatibiliteiten te detecteren. SAMW kan ook de migratie naar V12 voltooien en enkele compatibiliteitsproblemen oplossen. Iets om op te letten bij het gebruik van SAMW is dat het incompatibiliteiten kan detecteren die niet verholpen hoeven te worden.
Gegevens migreren
Zodra uw database de compatibiliteitscontrole heeft doorstaan, moet u bepalen wat de beste methode is om te migreren. Enkele van de meest voorkomende methoden zijn het gebruik van de SSMS-migratiewizard, exporteren naar een BACPAC, het gebruik van transactionele replicatie of het handmatig scripten van de databases en het invoegen van uw gegevens.
Het gebruik van de SSMS-migratiewizard is geweldig voor SQL Server 2005 en hoger, databases die klein tot middelgroot zijn. U kunt deze wizard in SSMS 2016 activeren door met de rechtermuisknop op een database te klikken, Taken te kiezen en vervolgens Database implementeren in Microsoft Azure SQL Database. In SSMS 2014 heet het Deploy Database to Windows Azure SQL Database. Met deze wizard kunt u de database opgeven die u wilt migreren, verbinding maken met uw Azure-abonnement, de locatie voor het .bacpac-bestand, de nieuwe databasenaam en naar welke laag u wilt migreren kiezen. Wanneer u op Voltooien klikt, zal de wizard het schema extraheren en valideren en vervolgens de gegevens exporteren. Zodra de gegevens zijn geëxporteerd, wordt een implementatieplan gemaakt en wordt begonnen met het importeren van de gegevens in de nieuwe V12-database.
Zeer vergelijkbaar met de SSMS Migration Wizard is de Export Data-tier Application. Om deze optie te selecteren, klikt u met de rechtermuisknop op de database, kiest u Taken en vervolgens Export Data-tier Application. In de exportinstellingen geeft u op waar u het .bacpac-bestand wilt maken. U kunt dit lokaal opslaan of rechtstreeks in uw Azure-opslagaccount opslaan. Er is ook een geavanceerd tabblad waar u kunt selecteren welke tabellen u wilt opnemen. Dit is handig als uw lokale database kopieën bevat van tabellen die u niet naar V12 wilt migreren. Als u Voltooien kiest, worden uw gegevens geëxporteerd. U kunt vervolgens via SSMS verbinding maken met uw Azure-server en ervoor kiezen om de gegevenslaagtoepassing te importeren. U geeft de locatie van het bestand, de databasenaam en de laag van de Azure SQL Database op. Als u Voltooien hebt gekozen, begint de database met importeren. Deze methode geeft je iets meer controle over het proces, omdat het de export van de import scheidt. Het geeft je ook de mogelijkheid om het .bacpac-bestand op te slaan in je Azure-opslagaccount, zodat het kwetsbaardere importproces niet afhankelijk is van je internetverbinding.
Een optie bij het gebruik van de SSMS-migratiewizard of de toepassing Gegevenslaag exporteren, is om een Azure-VM te maken met SQL Server en logboekverzending in te stellen. Hiermee wordt uw database vooraf gefaseerd in de Azure-cloud om de importtijd van de database te minimaliseren. Wanneer het tijd is om de migratie uit te voeren, herstelt u gewoon de laatste logboekback-ups op de secundaire en verwijdert u vervolgens de verzending van logboeken. Voer een herstel met herstel uit om de database online te brengen. Dit elimineert in wezen de tijd die nodig is om uw database van uw datacenter naar het Azure-datacenter te kopiëren.
Transactionele replicatie is een andere methode om de downtime van de migratie naar V12 te verminderen. Het is de beste optie als je een extreem kleine onderhoudsperiode hebt om over te schakelen naar V12, als de database transactionele replicatie kan ondersteunen. Het instellen van transactionele replicatie vereist primaire sleutels voor elke gepubliceerde tabel, wat voor veel databases problematisch kan zijn. Het configureren van transactionele replicatie kan ook ingewikkeld zijn, omdat u de distributiedatabase moet opzetten, de uitgever en abonnee moet instellen en taken moet controleren.
U kunt ook handmatig migreren door de wizard Scripts genereren te gebruiken en het databaseschema en/of de gegevens uit te scripten. U kunt vervolgens een lege database maken in Azure en uw schema en/of gegevens importeren door het script uit te voeren. Ik heb gehoord dat sommige mensen deze methode gebruiken om de lege database te maken en vervolgens handmatig hun gegevens tabel voor tabel invoegen met behulp van SSMS en een gekoppelde server. Deze methode kan voor u werken, maar het kan ook erg ingewikkeld zijn als u veel schemaconstructies hebt, zoals externe-sleutelrelaties en identiteitskolommen, in welk geval de andere bovenstaande methoden betrouwbaarder en efficiënter zouden zijn.
Andere migratieoverwegingen
Wanneer u van plan bent om on-premises databases naar V12 te migreren, is de grootte van de database een enorme factor in hoe lang de migratie duurt. De export van de database, de overdracht van de gegevens en de import zullen allemaal toenemen in verhouding tot de grootte van de database.
Een andere grote factor in de herstel-/importtijd bij het verplaatsen van uw databases naar V12 is de prestatielaag die u ook herstelt. Het herstel-/importproces vereist veel pk's, dus om uw migratie te versnellen, kunt u overwegen terug te zetten naar een hoger prestatieniveau. Wanneer de database online is, kunt u gemakkelijk en snel naar een lager niveau gaan dat voldoet aan uw dagelijkse prestatiebehoeften. Het kunnen wijzigen van prestatieniveaus met een paar muisklikken is een van de grote voordelen van Azure SQL Database.
Bewaking
Een belangrijk onderdeel van het beheer van een database is monitoring. Als je iets niet meet, kun je het ook niet meten. Als u niet weet wat uw statistieken zijn als de dingen normaal werken, hoe weet u dan welke dingen slechter zijn als de prestaties afnemen? Met on-premises databases hebben we tools waarmee we vertrouwd zijn:SQL Server Management Studio, Performance Monitor, Task Manager, DMV's, enzovoort. Wanneer we onze databases naar V12 verplaatsen, verliezen we de mogelijkheid om vanuit een OS-perspectief te monitoren, en andere concepten veranderen ook een beetje. We hebben nu deze statistiek genaamd DTU om mee te werken, wat staat voor Database Transaction Units. Zie het als een combinatie van CPU, data en transactielog I/O en geheugen. De Azure Portal bevat een bewakingsgrafiek waarbij het DTU-percentage standaard wordt gecontroleerd, en u kunt deze grafiek bewerken om aanvullende metrische gegevens op te nemen, zoals:
- Geblokkeerd door firewall
- CPU %
- DTU-limiet
- DTU gebruikt
- Gegevens I/O %
- Databasegrootte %
- Vastgelopen
- Mislukte verbindingen
- In-Memory OLTP-opslag %
(preview)
- Log I/O %
- Sessies %
- Succesvolle verbindingen
- Totale databasegrootte
- Werknemers %
Ik zou op zijn minst het CPU-percentage, het gegevens-I/O-percentage, deadlocks en het percentage databasegrootte toevoegen. Momenteel geeft deze grafiek het vorige uur van resourcegebruik weer.
Monitoring door DMV's is niet veel veranderd, behalve dat er een paar nieuwe DMV's zijn die verband houden met individuele databasestatistieken en het berekenen van de databasegrootte. Een van mijn eerdere artikelen hier, Aan de slag met het afstemmen van prestaties in Azure SQL Database, behandelt enkele van de verschillen in de algemene scripts die worden gebruikt voor het verzamelen van schijflatenties en wachtstatistieken met betrekking tot Azure SQL Database.
Hulpprogramma's van derden zijn ook begonnen met het opnemen van hooks in Azure SQL Database, zoals SentryOne met DB Sentry. DB Sentry biedt u de mogelijkheid om de prestaties te bewaken en gebeurtenissen te beheren die zich in uw systeem voordoen. Een leuke functie is de Top SQL-functie waarmee u de query's kunt zien die de meeste invloed hebben op uw algehele prestaties, zodat u eventuele problemen met die query kunt afstemmen / oplossen. Een ander voorbeeld is het in kaart brengen van DTU in de loop van de tijd en het visualiseren van dat op een dashboard naast andere belangrijke statistieken.
 Top SQL in de SentryOne-client |  DTU-gebruik op het DB Sentry-dashboard |
Deze metrische gegevens worden opgeslagen in een speciale database, zodat u de prestaties in de loop van de tijd kunt bepalen en trends kunt bepalen, wat veel beter is dan de beperkte grafieken die u momenteel in de Azure Portal krijgt.
Samenvatting
Er zijn veel voordelen aan het migreren naar Azure SQL Database V12, als uw database compatibel is, dus profiteer van een van de beschikbare hulpprogramma's om uw compatibiliteit met V12 te controleren. Als uw database compatibel is of eenvoudig kan worden aangepast om compatibel te worden, kunt u eenvoudig migreren naar Azure SQL Database V12 en beginnen met het testen en benchmarken van uw toepassingen en workloads.