Som tiden går, migrerer flere virksomheder til, eller i det mindste evaluerer, Azure SQL Database som et alternativ til de høje omkostninger ved at køre SQL Server på stedet.
Tjekker kompatibilitet
Et af de første aspekter ved at flytte din database til Azure SQL Database er at tjekke for kompatibilitet, og Microsoft giver dig adskillige måder at gøre dette på for Azure SQL Database V12 (herefter blot kaldet 'V12'). En af disse metoder er at bruge SQL Server Data Tools for Visual Studio (SSDT), som bruger de seneste kompatibilitetsregler til at opdage V12-inkompatibiliteter. I SSDT kan du importere dit databaseskema og bygge et projekt til en V12-implementering, og hvis der findes inkompatibiliteter, kan de rettes i SSDT og derefter synkroniseres tilbage til kildedatabasen.
Du kan også bruge et kommandolinjeværktøj kaldet SqlPackage, der kan generere en rapport om kompatibilitetsproblemer (og altid sikre dig, at du har den nyeste version). SQL Server Management Studio er en anden måde at gøre det på, ved at bruge funktionen Export Data-tier Application, som kan opdage og rapportere fejl til skærmen. Hvis der ikke opdages fejl, kan du migrere din database til V12. Hvis der opdages inkompatibiliteter, kan de rettes ved hjælp af SSMS før migrering.
Data Migration Assistant er et selvstændigt værktøj (som let kan forveksles med SQL Server Migration Assistant), der kan bruges til at reducere besværet med at opgradere, og erstatter SQL Server 2016 Upgrade Advisor Preview. DMA kan også anbefale forbedringer af ydeevne og pålidelighed. Et andet værktøj, SQL Azure Migration Wizard (SAMW), er et Codeplex-værktøj, der bruger Azure SQL Database V11-kompatibilitetsregler til at opdage V12-inkompatibiliteter. SAMW kan også fuldføre migreringen til V12 og løse nogle kompatibilitetsproblemer. Noget du skal være opmærksom på, når du bruger SAMW, er, at det kan registrere inkompatibiliteter, der ikke skal rettes.
Migrering af data
Når din database har bestået kompatibilitetskontrollen, skal du bestemme den bedste metode til at migrere. Nogle af de mere almindelige metoder omfatter brug af SSMS Migration Wizard, eksport til en BACPAC, brug af transaktionsreplikering eller manuel scripting af databaserne og indsættelse af dine data.
Brug af SSMS Migration Wizard er fantastisk til SQL Server 2005 og nyere databaser, der er små til mellemstore. Du kan aktivere denne guide i SSMS 2016 ved at højreklikke på en database, vælge Opgaver og derefter Deploy Database til Microsoft Azure SQL Database. I SSMS 2014 hedder det Deploy Database til Windows Azure SQL Database. Ved at bruge denne guide kan du angive den database, der skal migreres, oprette forbindelse til dit Azure-abonnement, vælge placeringen for .bacpac-filen, det nye databasenavn og hvilket niveau, der skal migreres til. Når du klikker på Afslut, vil guiden udtrække og validere skemaet og derefter eksportere dataene. Når dataene er eksporteret, vil de oprette en implementeringsplan og begynde at importere dataene til den nye V12-database.
Meget lig SSMS Migration Wizard er applikationen til eksport af data. For at vælge denne mulighed skal du højreklikke på databasen, vælge Opgaver og derefter Eksporter datalagsapplikation. I eksportindstillingerne angiver du, hvor du vil oprette .bacpac-filen. Du kan gemme dette lokalt eller gemme det direkte på din Azure-lagringskonto. Der er også en avanceret fane, hvor du kan vælge, hvilke tabeller der skal inkluderes. Dette er nyttigt, hvis din lokale database indeholder kopier af tabeller, som du ikke ønsker at migrere til V12. Når du vælger Udfør, eksporterer den dine data. Du kan derefter oprette forbindelse til din Azure-server via SSMS og vælge at importere datalagsapplikation. Du skal angive placeringen af filen, databasenavnet og niveauet for Azure SQL-databasen. Når du vælger finish, begynder databasen at importere. Denne metode giver dig lidt mere kontrol over processen, da den adskiller eksporten fra importen. Det giver dig også mulighed for at gemme .bacpac-filen på din Azure-lagringskonto, så den mere sårbare importproces ikke er afhængig af din internetforbindelse.
En mulighed, når du bruger enten SSMS Migration Wizard eller Export Data-tier Application, er at oprette en Azure VM med SQL Server og konfigurere logforsendelse. Dette vil forhåndsfase din database i Azure-skyen for at hjælpe med at minimere databasens importtid. Når det er tid til at foretage migreringen, gendanner du bare de sidste log-backups på den sekundære og fjerner derefter logforsendelse. For at bringe databasen online skal du udføre en gendannelse med gendannelse. Dette vil i det væsentlige eliminere den tid, det tager at kopiere din database fra dit datacenter til Azure-datacentret.
Transaktionel replikering er en anden metode til at reducere nedetiden ved migrering til V12. Det er den bedste mulighed, hvis du har et ekstremt lille vedligeholdelsesvindue til at skifte til V12, hvis databasen kan understøtte transaktionsreplikering. Opsætning af transaktionsreplikering kræver primære nøgler for hver offentliggjort tabel, hvilket kan være problematisk for mange databaser. Konfiguration af transaktionsreplikering kan også være kompliceret, da du skal konfigurere distributionsdatabasen, konfigurere udgiveren og abonnenten og overvåge jobs.
Du kan også migrere manuelt ved at bruge guiden Generer scripts og udskrive databaseskemaet og/eller dataene. Du kan derefter oprette en tom database i Azure og importere dit skema og/eller data ved at udføre scriptet. Jeg har hørt om nogle mennesker, der bruger denne metode til at oprette den tomme database og derefter manuelt indsætte deres data en tabel ad gangen ved hjælp af SSMS og en forbundet server. Denne metode kan fungere for dig, men den kan også være meget kompliceret, hvis du har en masse skemakonstruktioner som udenlandske nøglerelationer og identitetskolonner, i hvilket tilfælde de andre metoder ovenfor ville være mere pålidelige og effektive.
Andre overvejelser om migrering
Når man planlægger at migrere lokale databaser til V12, er størrelsen af databasen en stor faktor for, hvor lang tid migreringen vil tage. Eksporten af databasen, overførslen af dataene og importen vil alle stige i forhold til størrelsen af databasen.
En anden stor faktor i gendannelses-/importtiden, når du flytter dine databaser til V12, er det ydeevneniveau, du også gendanner. Gendannelses-/importprocessen kræver mange hestekræfter, så for at hjælpe med at fremskynde din migrering bør du overveje at gendanne til et højere ydeevneniveau. Når databasen er online, kan du nemt og hurtigt falde ned til et lavere niveau, der opfylder dine daglige præstationsbehov. At kunne ændre ydeevneniveauer med et par museklik er en af de store fordele ved Azure SQL Database.
Overvågning
En vigtig del af administrationen af enhver database er overvågning. Hvis du ikke overvåger noget, kan du ikke måle det. Hvis du ikke ved, hvad dine målinger er, når tingene fungerer normalt, hvordan vil du så vide, hvilke ting der er værre, når ydeevnen er forringet? Med lokale databaser har vi værktøjer, som vi er fortrolige med:SQL Server Management Studio, Performance Monitor, Task Manager, DMV'er og så videre. Når vi flytter vores databaser til V12, mister vi muligheden for at overvåge fra et OS-perspektiv, og andre koncepter ændrer sig også en smule. Vi har nu denne metric kaldet DTU at arbejde med, som står for Database Transaction Units. Tænk på det som en kombination af CPU, data og transaktionslog I/O og hukommelse. Azure Portal inkluderer et overvågningsdiagram, der som standard har DTU-procent markeret, og du kan redigere dette diagram, så det inkluderer yderligere metrics, såsom:
- Blokeret af firewall
- CPU %
- DTU-grænse
- DTU brugt
- Data I/O %
- Databasestørrelse %
- Deadlocks
- Mislykkede forbindelser
- OLTP-lager i hukommelsen %
(forhåndsvisning)
- Log I/O %
- Sessioner %
- Vellykkede forbindelser
- Samlet databasestørrelse
- Arbejdsprocent
Som minimum vil jeg tilføje CPU-procent, data-I/O-procent, deadlocks og databasestørrelsesprocent. I øjeblikket viser dette diagram den foregående time med ressourceudnyttelse.
Overvågning af DMV'er har ikke ændret sig meget, udover at have et par nye DMV'er relateret til individuelle databasemetrikker og hvordan databasestørrelsen beregnes. En af mine tidligere artikler her, Getting Started Tuning Performance in Azure SQL Database, dækker nogle af forskellene i de almindelige scripts, der bruges til at indsamle diskforsinkelser og ventestatistikker i forhold til Azure SQL Database.
Tredjepartsværktøjer er også begyndt at inkludere hooks i Azure SQL Database, såsom SentryOne med DB Sentry. DB Sentry giver dig mulighed for at overvåge ydeevne og administrere hændelser, der opstår i dit system. En cool funktion er Top SQL-funktionen, der giver dig mulighed for at se de forespørgsler, der har størst indflydelse på din overordnede ydeevne, så du kan justere/fikse eventuelle problemer med den forespørgsel. En anden er at kortlægge DTU over tid og visualisere det på et dashboard sammen med andre vigtige metrics.
 Top SQL i SentryOne-klienten |  DTU-brug på DB Sentry Dashboard |
Disse metrics er gemt i en dedikeret database, som giver dig mulighed for at baseline og trende over ydeevne over tid, hvilket er meget bedre end de begrænsede diagrammer, du i øjeblikket får i Azure Portal.
Oversigt
Der er mange fordele ved at migrere til Azure SQL Database V12, hvis din database er kompatibel, så drag fordel af et af de tilgængelige værktøjer til at kontrollere din kompatibilitet med V12. Hvis din database er kompatibel eller let kan ændres til at blive kompatibel, kan du nemt migrere til Azure SQL Database V12 og begynde at teste og benchmarke dine applikationer og arbejdsbelastninger.