Migrate SQL Server to Azure SQL Virtual Machine with DMS Online

Ambiente di test utilizzato

Per questa guida ho configurato un ambiente di test in Azure che rispecchia uno scenario abbastanza realistico, simile a quello che mi capita spesso di vedere anche dai clienti.

L’obiettivo è simulare una migrazione da un SQL Server “classico” verso una SQL Server su Azure Virtual Machine, utilizzando Azure DMS in modalità online.

Nel mio lab ho utilizzato:

  • una VM sorgente con SQL Server (on-premises simulato)
  • una VM di destinazione su Azure con SQL Server installato
  • uno Storage Account Azure per i backup
  • Azure Database Migration Service per orchestrare la migrazione

I database utilizzati sono due database di test, ma la logica è esattamente la stessa anche su ambienti più grandi.

Una cosa importante che tengo sempre a sottolineare è che, anche in ambienti di produzione, conviene sempre replicare questo tipo di configurazione in un ambiente di test prima di fare la migrazione vera. Questo permette di validare:

  • i tempi di backup e restore
  • la configurazione dello storage
  • il comportamento dei log durante la sincronizzazione
  • eventuali problemi di permessi o networking

Nel mio caso ho utilizzato un resource group dedicato al lab, in modo da tenere tutte le risorse isolate e facilmente gestibili.

Step 1 — Verifica e configurazione del Recovery Model

Prima di iniziare la migrazione, ci sono alcuni requisiti fondamentali da verificare. Saltare anche solo uno di questi punti può portare a errori durante il processo.

Il primo requisito, ed è anche quello più importante per la modalità online, è che tutti i database devono essere configurati con Recovery Model FULL. Senza questo requisito non è possibile utilizzare i backup dei log e quindi la sincronizzazione continua non funzionerà.

Per prima cosa possiamo verificare il Recovery Model dei database presenti sull’istanza SQL Server.

SELECT 
    name AS NomeDatabase,
    recovery_model_desc AS RecoveryModel
FROM sys.databases
WHERE database_id > 4
ORDER BY name;

Questa query mostra tutti i database utente, escludendo i database di sistema, e permette di controllare rapidamente quali database sono già in modalità FULL e quali invece sono ancora in SIMPLE.

Se uno o più database risultano in SIMPLE, è possibile portarli in FULL con il comando seguente

ALTER DATABASE [NomeDatabase] SET RECOVERY FULL;

Naturalmente va sostituito NomeDatabase con il nome reale del database da migrare.

Nel caso ci siano più database da impostare, è possibile usare anche uno script dinamico che modifica automaticamente tutti i database utente attualmente configurati in SIMPLE:

DECLARE @DBName NVARCHAR(256);
DECLARE @SQL NVARCHAR(MAX);

DECLARE db_cursor CURSOR FOR
SELECT name
FROM sys.databases
WHERE recovery_model_desc = 'SIMPLE'
  AND database_id > 4
  AND state_desc = 'ONLINE';

OPEN db_cursor;
FETCH NEXT FROM db_cursor INTO @DBName;

WHILE @@FETCH_STATUS = 0
BEGIN
    SET @SQL = N'ALTER DATABASE ' 
             + QUOTENAME(@DBName) 
             + N' SET RECOVERY FULL;';

    PRINT @SQL;
    EXEC sp_executesql @SQL;

    FETCH NEXT FROM db_cursor INTO @DBName;
END;

CLOSE db_cursor;
DEALLOCATE db_cursor;

Dopo aver modificato il Recovery Model è importante eseguire subito un backup FULL del database, perché il cambio da SIMPLE a FULL da solo non avvia realmente la catena dei backup di log.

Questa è una cosa da non sottovalutare: se non viene eseguito un backup FULL dopo la modifica, i successivi backup dei log potrebbero non essere disponibili o non essere utilizzabili correttamente durante la migrazione.