Allteftersom tiden går migrerar fler företag till, eller åtminstone utvärderar, Azure SQL Database som ett alternativ till den höga kostnaden för att köra SQL Server på plats.
Kontrollera kompatibilitet
En av de första aspekterna av att flytta din databas till Azure SQL Database är att kontrollera kompatibilitet och Microsoft ger dig många sätt att göra detta för Azure SQL Database V12 (hädanefter kallad "V12"). En av dessa metoder är att använda SQL Server Data Tools for Visual Studio (SSDT) som använder de senaste kompatibilitetsreglerna för att upptäcka V12-inkompatibiliteter. I SSDT kan du importera ditt databasschema och bygga ett projekt för en V12-distribution, och om några inkompatibiliteter hittas kan de korrigeras inom SSDT och sedan synkroniseras tillbaka till källdatabasen.
Du kan också använda ett kommandoradsverktyg som heter SqlPackage som kan generera en rapport om kompatibilitetsproblem (och alltid se till att du har den senaste versionen). SQL Server Management Studio är ett annat sätt att göra det, med hjälp av funktionen Export Data-tier Application, som kan upptäcka och rapportera fel till skärmen. Om inga fel upptäcks kan du migrera din databas till V12. Om inkompatibiliteter upptäcks kan de korrigeras med SSMS före migrering.
Data Migration Assistant är ett fristående verktyg (lätt att förväxla med SQL Server Migration Assistant) som kan användas för att minska ansträngningen att uppgradera och ersätter SQL Server 2016 Upgrade Advisor Preview. DMA kan också rekommendera prestanda- och tillförlitlighetsförbättringar. Ett annat verktyg, SQL Azure Migration Wizard (SAMW), är ett Codeplex-verktyg som använder Azure SQL Database V11-kompatibilitetsregler för att upptäcka V12-inkompatibiliteter. SAMW kan också slutföra migreringen till V12 och åtgärda vissa kompatibilitetsproblem. Något att vara medveten om när du använder SAMW är att det kan upptäcka inkompatibiliteter som inte behöver åtgärdas.
Migrera data
När din databas har klarat kompatibilitetskontrollen måste du bestämma den bästa metoden att migrera. Några av de vanligaste metoderna inkluderar att använda SSMS-migreringsguiden, exportera till en BACPAC, använda transaktionsreplikering eller manuellt skripta databaserna och infoga dina data.
Att använda SSMS Migration Wizard är bra för SQL Server 2005 och uppåt-databaser som är små till medelstora. Du kan aktivera den här guiden i SSMS 2016 genom att högerklicka på en databas, välja Uppgifter och sedan Distribuera databas till Microsoft Azure SQL Database. I SSMS 2014 kallas det Deploy Database to Windows Azure SQL Database. Med hjälp av den här guiden kan du ange databasen som ska migreras, ansluta till din Azure-prenumeration, välja platsen för .bacpac-filen, det nya databasnamnet och vilken nivå som ska migreras till. När du klickar på slutför extraherar och validerar guiden schemat och exporterar sedan data. När data har exporterats kommer den att skapa en distributionsplan och börja importera data till den nya V12-databasen.
Mycket lik SSMS-migreringsguiden är applikationen för export av data. För att välja det här alternativet, högerklicka på databasen, välj Uppgifter och sedan Exportera datalagsprogram. I exportinställningarna anger du var du vill skapa .bacpac-filen. Du kan spara detta lokalt eller spara det direkt på ditt Azure Storage-konto. Det finns även en avancerad flik där du kan välja vilka tabeller som ska inkluderas. Detta är användbart om din lokala databas innehåller kopior av tabeller som du inte vill migrera till V12. När du väljer Slutför kommer den att exportera dina data. Du kan sedan ansluta till din Azure-server via SSMS och välja att importera datanivåapplikation. Du kommer att ange platsen för filen, databasnamnet och nivån för Azure SQL Database. När du väljer slutför börjar databasen importeras. Denna metod ger dig lite mer kontroll över processen eftersom den skiljer exporten från importen. Det ger dig också möjlighet att lagra .bacpac-filen i ditt Azure Storage-konto så att den mer sårbara importprocessen inte kommer att vara beroende av din internetanslutning.
Ett alternativ när du använder antingen SSMS Migration Wizard eller Export Data-tier Application är att skapa en Azure VM med SQL Server och ställa in loggsändning. Detta kommer att försteg din databas i Azure-molnet för att minimera importtiden för databasen. När det är dags att göra migreringen återställer du bara de sista loggbackuperna på den sekundära och tar sedan bort loggleveransen. För att få databasen online, utför en återställning med återställning. Detta kommer i princip att eliminera den tid det tar att kopiera din databas från ditt datacenter till Azure datacenter.
Transaktionsreplikering är en annan metod för att minska stilleståndstiden vid migrering till V12. Det är det bästa alternativet om du har ett extremt litet underhållsfönster för att byta över till V12, om databasen kan stödja transaktionsreplikering. Att ställa in transaktionsreplikering kräver primärnycklar för varje publicerad tabell, vilket kan vara problematiskt för många databaser. Konfigurering av transaktionsreplikering kan också vara komplicerat, eftersom du måste ställa in distributionsdatabasen, konfigurera utgivaren och abonnenten och övervaka jobb.
Du kan också migrera manuellt genom att använda guiden Generera skript och skripta ut databasschemat och/eller data. Du kan sedan skapa en tom databas i Azure och importera ditt schema och/eller data genom att köra skriptet. Jag har hört talas om att vissa personer använder den här metoden för att skapa den tomma databasen och sedan manuellt infoga sina data en tabell i taget med hjälp av SSMS och en länkad server. Den här metoden kan fungera för dig, men den kan också vara mycket komplicerad om du har många schemakonstruktioner som främmande nyckelrelationer och identitetskolumner, i vilket fall de andra metoderna ovan skulle vara mer tillförlitliga och effektiva.
Andra migreringsöverväganden
När man planerar att migrera lokala databaser till V12 är databasens storlek en stor faktor för hur lång tid migreringen kommer att ta. Exporten av databasen, överföringen av data och importen kommer alla att öka i proportion till databasens storlek.
En annan stor faktor i återställnings-/importtiden när du flyttar dina databaser till V12 är prestandanivån du också återställer. Återställning/importprocessen kräver mycket hästkrafter, så för att påskynda din migrering bör du överväga att återställa till en högre prestandanivå. När databasen är online kan du enkelt och snabbt gå ner till en lägre nivå som uppfyller dina dagliga prestationsbehov. Att kunna ändra prestandanivåer med några få musklick är en av de stora fördelarna med Azure SQL Database.
Övervakning
En viktig del av att administrera en databas är övervakning. Om du inte övervakar något kan du inte mäta det. Om du inte vet vad dina mätvärden är när saker fungerar normalt, hur vet du vilka saker som är sämre när prestanda försämras? Med lokala databaser har vi verktyg som vi är bekanta med:SQL Server Management Studio, Performance Monitor, Task Manager, DMV, och så vidare. När vi flyttar våra databaser till V12 tappar vi möjligheten att övervaka ur ett OS-perspektiv, och andra koncept förändras också lite. Vi har nu detta mått som heter DTU att arbeta med, som står för Database Transaction Units. Se det som en kombination av CPU, data och transaktionslogg I/O och minne. Azure Portal innehåller ett övervakningsdiagram som som standard har DTU-procenten markerad, och du kan redigera detta diagram för att inkludera ytterligare mätvärden, till exempel:
- Blockerad av brandvägg
- CPU %
- DTU-gräns
- DTU används
- Data I/O %
- Databasstorlek %
- Dödläge
- Misslyckade anslutningar
- OLTP-lagring i minnet %
(förhandsgranskning)
- Logga I/O %
- Sessioner %
- Lyckade anslutningar
- Total databasstorlek
- Arbetare %
Som ett minimum skulle jag lägga till CPU-procent, data I/O-procent, dödläge och databasstorlek. För närvarande visar detta diagram föregående timmes resursanvändning.
Övervakning av DMV:er har inte förändrats mycket, förutom att ha några nya DMV:er relaterade till individuella databasmått och hur man beräknar databasstorlek. En av mina tidigare artiklar här, Komma igång Justera prestanda i Azure SQL Database, täcker några av skillnaderna i de vanliga skript som används för att samla in disklatenser och väntestatistik i förhållande till Azure SQL Database.
Tredjepartsverktyg har också börjat inkludera krokar i Azure SQL Database, som SentryOne med DB Sentry. DB Sentry ger dig möjlighet att övervaka prestanda och hantera händelser som inträffar i ditt system. En cool funktion är Top SQL-funktionen som låter dig se de frågor som har störst inverkan på din övergripande prestanda så att du kan finjustera/fixa eventuella problem med den frågan. En annan är att kartlägga DTU över tid och visualisera det på en instrumentpanel tillsammans med andra viktiga mätvärden.
 Top SQL i SentryOne-klienten |  DTU-användning på DB Sentry Dashboard |
Dessa mätvärden lagras i en dedikerad databas, vilket ger dig möjligheten att basera och utveckla prestanda över tid, vilket är mycket bättre än de begränsade diagram som du för närvarande får i Azure Portal.
Sammanfattning
Det finns många fördelar med att migrera till Azure SQL Database V12, om din databas är kompatibel, så dra nytta av ett av de tillgängliga verktygen för att kontrollera din kompatibilitet med V12. Om din databas är kompatibel, eller lätt kan modifieras för att bli kompatibel, kan du enkelt migrera till Azure SQL Database V12 och börja testa och benchmarka dina applikationer och arbetsbelastningar.