Usare il Log Replay Service (LRS) per eseguire migrazione
Il Log Replay Service (LRS) è uno strumento che consente migrazioni personalizzate di database da SQL Server on-premises a SQL Managed Instance nel cloud. Usa la tecnologia di log shipping ed è utile nei casi in cui è necessario un maggiore controllo, quando è necessaria poca tolleranza per i tempi di inattività o quando non è possibile usare Servizio Migrazione dati di Azure.
L'archiviazione con ridondanza locale può essere usata direttamente con PowerShell, i cmdlet dell'interfaccia della riga di comando o l'API per compilare e orchestrare manualmente le migrazioni di database a Istanza gestita di SQL. Alcuni dei motivi per cui prendere in considerazione l'uso dell'archiviazione con ridondanza locale includono:
- Maggiore controllo sul progetto di migrazione del database
- Poca tolleranza per il tempo di inattività durante la fase di transizione della migrazione
- Impossibilità di installare l'eseguibile DMS nell'ambiente
- Mancanza di accesso ai file di backup del database
- Impossibilità di aprire porte di rete dall'ambiente ad Azure
Informazioni sui tipi di migrazione
Sono disponibili due modalità di migrazione per LRS.
| Modalità | Descrizione | Consigliati per | Disponibilità della catena di backup |
|---|---|---|---|
| completamento automatico | Termina automaticamente la migrazione quando viene ripristinato l'ultimo file di backup | Carichi di lavoro passivi | L'intera catena di backup deve essere disponibile in anticipo |
| Continuo | Analizza continuamente i nuovi file di backup e li ripristina, consentendo il recupero dei dati | Carichi di lavoro attivi | È possibile aggiungere la catena di backup durante la migrazione |
Indipendentemente dalla modalità, pianifica di completare la migrazione entro 30 giorni, poiché il lavoro LRS verrà annullato automaticamente dopo questo periodo.
Proteggere il processo di migrazione
Per eseguire LRS, è necessario avere uno dei seguenti ruoli di controllo degli accessi basati su ruolo di Azure: Proprietario della sottoscrizione, Contributor SQL Managed Instance, o un ruolo personalizzato con l'autorizzazione Microsoft.Sql/managedInstances/databases/*.
Un account di archiviazione BLOB di Azure è obbligatorio e funziona come risorsa di archiviazione intermedia per i file di backup tra l'istanza di SQL Server e l'istanza gestita di SQL. Per usare l'archiviazione BLOB di Azure con un firewall, è necessaria un'altra configurazione. È necessario aggiungere la subnet di Istanza gestita di SQL alle regole del firewall di rete virtuale dell'account di archiviazione usando la delega della subnet MI e l'endpoint del servizio di archiviazione. È anche possibile usare un token di firma di accesso condiviso o un'identità gestita per accedere all'account di archiviazione BLOB di Azure, ma non entrambi.
Migliorare le prestazioni di backup e ripristino
È possibile suddividere i backup completi e differenziali in più file, anziché usare un singolo file, per migliorare le prestazioni di backup e ripristino. Ciò è dovuto al fatto che più file possono essere letti o scritti in parallelo, riducendo il tempo necessario per completare l'operazione di backup o ripristino.
Inoltre, l'abilitazione della compressione dei backup può contribuire a migliorare la velocità di trasferimento di rete. I backup compressi sono di dimensioni inferiori, il che significa che richiedono meno tempo per il trasferimento in rete. Ciò può essere particolarmente utile quando si trasferiscono backup di grandi dimensioni da o verso Azure.
È consigliabile abilitare CHECKSUM per i backup, anche se non è obbligatorio. SQL Managed Instance esegue un controllo di integrità sui backup senza CHECKSUM, il che può aumentare il tempo necessario per ripristinare il database. Abilitando CHECKSUMè possibile velocizzare le operazioni di ripristino.