Con il passare del tempo, sempre più aziende migrano o almeno valutano il database SQL di Azure come alternativa al costo elevato dell'esecuzione di SQL Server in locale.
Verifica della compatibilità
Uno dei primi aspetti dello spostamento del database nel database SQL di Azure è verificare la compatibilità e Microsoft offre numerosi modi per eseguire questa operazione per il database SQL di Azure V12 (di seguito denominato solo "V12"). Uno di questi metodi utilizza SQL Server Data Tools per Visual Studio (SSDT) che usa le regole di compatibilità più recenti per rilevare le incompatibilità V12. In SSDT puoi importare lo schema del database e creare un progetto per una distribuzione V12 e, se vengono rilevate incompatibilità, possono essere corrette all'interno di SSDT e quindi sincronizzate di nuovo con il database di origine.
Puoi anche utilizzare uno strumento da riga di comando chiamato SqlPackage che può generare un rapporto sui problemi di compatibilità (e assicurarti sempre di avere la versione più recente). SQL Server Management Studio è un altro modo per farlo, usando la funzionalità Esporta applicazione livello dati, che può rilevare e segnalare errori sullo schermo. Se non vengono rilevati errori, è possibile migrare il database alla versione V12. Se vengono rilevate incompatibilità, è possibile correggerle utilizzando SSMS prima della migrazione.
Data Migration Assistant è uno strumento autonomo (facilmente confuso con SQL Server Migration Assistant) che può essere usato per ridurre lo sforzo di aggiornamento e sostituisce SQL Server 2016 Upgrade Advisor Preview. DMA può anche consigliare miglioramenti delle prestazioni e dell'affidabilità. Un altro strumento, SQL Azure Migration Wizard (SAMW), è uno strumento Codeplex che usa le regole di compatibilità del database SQL di Azure V11 per rilevare le incompatibilità V12. SAMW può anche completare la migrazione alla V12 e risolvere alcuni problemi di compatibilità. Qualcosa da tenere presente quando si utilizza SAMW è che è in grado di rilevare incompatibilità che non devono essere risolte.
Migrazione dei dati
Una volta che il tuo database ha superato il controllo di compatibilità, devi determinare il metodo migliore per migrare. Alcuni dei metodi più comuni includono l'utilizzo della Migrazione guidata SSMS, l'esportazione in un BACPAC, l'utilizzo della replica transazionale o lo script manuale dei database e l'inserimento dei dati.
L'utilizzo della Migrazione guidata SSMS è ottimo per SQL Server 2005 e versioni successive di database di piccole e medie dimensioni. È possibile attivare questa procedura guidata in SSMS 2016, facendo clic con il pulsante destro del mouse su un database, scegliere Attività e quindi Distribuisci database nel database SQL di Microsoft Azure. In SSMS 2014 si chiama Deploy Database to Windows Azure SQL Database. L'uso di questa procedura guidata consente di specificare il database di cui eseguire la migrazione, connettersi alla sottoscrizione di Azure, scegliere il percorso per il file .bacpac, il nuovo nome del database e il livello in cui eseguire la migrazione. Quando si fa clic su Fine, la procedura guidata estrarrà e convaliderà lo schema, quindi esporterà i dati. Una volta esportati i dati, creerà un piano di distribuzione e inizierà a importare i dati nel nuovo database V12.
Molto simile alla Migrazione guidata SSMS è l'applicazione del livello dati di esportazione. Per selezionare questa opzione, fare clic con il pulsante destro del mouse sul database, scegliere Attività, quindi Esporta applicazione livello dati. Nelle impostazioni di esportazione specifichi dove desideri creare il file .bacpac. Puoi salvarlo in locale o salvarlo direttamente nel tuo account di archiviazione di Azure. C'è anche una scheda avanzata in cui puoi selezionare quali tabelle includere. Ciò è utile se il database locale contiene copie di tabelle di cui non si desidera migrare alla V12. Quando hai scelto Fine, esporterà i tuoi dati. È quindi possibile connettersi al server di Azure tramite SSMS e scegliere di importare l'applicazione di livello dati. Specificare il percorso del file, il nome del database e il livello del database SQL di Azure. Quando hai scelto Fine, il database inizierà l'importazione. Questo metodo ti offre un controllo leggermente maggiore sul processo poiché separa l'esportazione dall'importazione. Ti dà anche la possibilità di archiviare il file .bacpac nel tuo account di archiviazione di Azure in modo che il processo di importazione più vulnerabile non dipenda dalla tua connessione Internet.
Un'opzione quando si usa la migrazione guidata SSMS o l'applicazione del livello dati di esportazione consiste nel creare una macchina virtuale di Azure con SQL Server e configurare il log shipping. Ciò premetterà il database nel cloud di Azure per ridurre al minimo il tempo di importazione del database. Quando arriva il momento di eseguire la migrazione, è sufficiente ripristinare i backup dei log finali sul secondario e quindi rimuovere il log shipping. Per portare il database online, eseguire un ripristino con ripristino. Ciò eliminerà essenzialmente il tempo necessario per copiare il database dal data center nel data center di Azure.
La replica transazionale è un altro metodo per ridurre i tempi di inattività della migrazione alla V12. È l'opzione migliore se hai una finestra di manutenzione estremamente ridotta per passare alla V12, se il database può supportare la replica transazionale. La configurazione della replica transazionale richiede chiavi primarie per ogni tabella pubblicata, il che può essere problematico per molti database. Anche la configurazione della replica transazionale può essere complicata, poiché devi configurare il database di distribuzione, configurare l'editore e l'abbonato e monitorare i lavori.
Puoi anche migrare manualmente utilizzando la procedura guidata Genera script ed eseguendo lo script dello schema e/o dei dati del database. È quindi possibile creare un database vuoto in Azure e importare lo schema e/o i dati eseguendo lo script. Ho sentito di alcune persone che usano questo metodo per creare il database vuoto e quindi inserire manualmente i propri dati una tabella alla volta utilizzando SSMS e un server collegato. Questo metodo può funzionare per te, ma può anche essere molto complicato se hai molti costrutti di schema come relazioni di chiavi esterne e colonne di identità, nel qual caso gli altri metodi sopra sarebbero più affidabili ed efficienti.
Altre considerazioni sulla migrazione
Quando si pianifica la migrazione dei database locali alla versione V12, la dimensione del database è un fattore determinante per quanto tempo impiegherà la migrazione. L'esportazione del database, il trasferimento dei dati e l'importazione aumenteranno in proporzione alle dimensioni del database.
Un altro fattore importante nel tempo di ripristino/importazione quando si spostano i database su V12 è anche il livello di prestazioni che si sta ripristinando. Il processo di ripristino/importazione richiede molta potenza, quindi per accelerare la migrazione, dovresti prendere in considerazione il ripristino a un livello di prestazioni più elevato. Quando il database è online, puoi passare facilmente e rapidamente a un livello inferiore che soddisfa le tue esigenze di prestazioni quotidiane. La possibilità di modificare i livelli di prestazioni con pochi clic del mouse è uno dei grandi vantaggi del database SQL di Azure.
Monitoraggio
Una parte importante dell'amministrazione di qualsiasi database è il monitoraggio. Se non stai monitorando qualcosa, non puoi misurarlo. Se non sai quali sono le tue metriche quando le cose funzionano normalmente, come farai a sapere quali sono le cose peggiori quando le prestazioni peggiorano? Con i database locali, disponiamo di strumenti che conosciamo:SQL Server Management Studio, Performance Monitor, Task Manager, DMV e così via. Quando spostiamo i nostri database alla versione V12, perdiamo la capacità di monitorare dal punto di vista del sistema operativo e anche altri concetti cambiano leggermente. Ora abbiamo questa metrica chiamata DTU con cui lavorare, che sta per Database Transaction Units. Pensalo come una combinazione di CPU, dati e I/O del registro delle transazioni e memoria. Il portale di Azure include un grafico di monitoraggio in cui per impostazione predefinita viene controllata la percentuale DTU ed è possibile modificare questo grafico per includere metriche aggiuntive, ad esempio:
- Bloccato da Firewall
- % CPU
- Limite DTU
- DTU utilizzato
- % I/O dati
- Dimensione del database %
- Blocchi di stallo
- Connessioni non riuscite
- % di spazio di archiviazione OLTP in memoria
(anteprima)
- % I/O log
- % sessioni
- Connessioni riuscite
- Dimensione totale del database
- % di lavoratori
Come minimo, aggiungerei percentuale di CPU, percentuale di I/O dati, deadlock e percentuale di dimensione del database. Attualmente, questo grafico mostra l'ora precedente di utilizzo delle risorse.
Il monitoraggio da parte delle DMV non è cambiato molto, a parte la presenza di alcune nuove DMV relative alle singole metriche del database e al modo in cui calcolare le dimensioni del database. Uno dei miei precedenti articoli qui, Guida introduttiva all'ottimizzazione delle prestazioni nel database SQL di Azure, illustra alcune delle differenze negli script comuni usati per raccogliere le latenze del disco e le statistiche di attesa in relazione al database SQL di Azure.
Anche gli strumenti di terze parti hanno iniziato a includere hook nel database SQL di Azure, ad esempio SentryOne con DB Sentry. DB Sentry ti dà la possibilità di monitorare le prestazioni e gestire gli eventi che si verificano nel tuo sistema. Una caratteristica interessante è la funzione Top SQL che ti consente di vedere le query che hanno il maggiore impatto sulle prestazioni complessive in modo da poter ottimizzare/risolvere eventuali problemi con quella query. Un altro è tracciare la DTU nel tempo e visualizzarla su una dashboard insieme ad altre metriche importanti.
 Top SQL nel client SentryOne |  Utilizzo DTU nel dashboard di DB Sentry |
Queste metriche sono archiviate in un database dedicato, offrendoti la possibilità di baseline e trend nel tempo delle prestazioni, che è molto migliore rispetto ai grafici limitati attualmente disponibili nel portale di Azure.
Riepilogo
La migrazione al database SQL di Azure V12 offre numerosi vantaggi, se il database è compatibile, quindi approfitta di uno degli strumenti disponibili per verificare la compatibilità con V12. Se il database è compatibile o può essere facilmente modificato per renderlo compatibile, è possibile migrare facilmente al database SQL di Azure V12 e iniziare a testare e confrontare le applicazioni e i carichi di lavoro.
