Procedure consigliate per l'esecuzione di Data Migration Assistant
Importante
Data Migration Assistant (DMA) è deprecato. Per opzioni per la migrazione dei dati da SQL Server ad Azure SQL, vedere opzioni per la migrazione da SQL Server ad Azure SQL.
Questo articolo fornisce alcune informazioni sulle procedure consigliate per l'installazione, la valutazione e la migrazione.
Installazione
Non installare ed eseguire Data Migration Assistant direttamente nel computer host di SQL Server.
Valutazione
- Eseguire valutazioni nei database di produzione negli orari non di punta.
- Per ridurre la durata della valutazione, eseguire separatamente le valutazioni dei problemi di compatibilità e delle raccomandazioni sulle nuove funzionalità.
Migrazione
Eseguire la migrazione di un server durante gli orari non di punta.
Quando si esegue la migrazione di un database, fornire una singola posizione di condivisione accessibile dal server di origine e dal server di destinazione e, se possibile, evitare un'operazione di copia. Un'operazione di copia, a seconda delle dimensioni del file di backup, può causare un ritardo. L'operazione di copia aumenta anche le probabilità che una migrazione non riesca a causa di un passaggio aggiuntivo. Quando viene fornita una singola posizione, Data Migration Assistant ignora l'operazione di copia.
Inoltre, assicurarsi di fornire le autorizzazioni corrette per la cartella condivisa in modo da evitare errori di migrazione. Le autorizzazioni corrette sono specificate nello strumento. Se un'istanza di SQL Server viene eseguita con le credenziali del servizio di rete, assegnare le autorizzazioni corrette per la cartella condivisa all'account del computer per l'istanza di SQL Server.
Durante la connessione ai server di origine e di destinazione abilitare la connessione crittografata. L'utilizzo della crittografia TLS aumenta la protezione dei dati trasmessi attraverso le reti tra Data Migration Assistant e l'istanza di SQL Server, che risulta particolarmente utile in caso di migrazione degli account di accesso SQL. Se non si usa la crittografia TLS e la rete viene compromessa da un utente malintenzionato, gli account di accesso SQL di cui è in corso la migrazione potrebbero essere intercettati e/o modificati immediatamente dall'autore dell'attacco.
Tuttavia, se tutti accedono attraverso una configurazione di Intranet sicura, la crittografia potrebbe non essere necessaria. L'abilitazione della crittografia rallenta le prestazioni a causa del sovraccarico aggiuntivo necessario per crittografare e decrittografare i pacchetti. Per ulteriori informazioni, fare riferimento a Crittografia delle connessioni a SQL Server.
Verificare la presenza di vincoli non attendibili sia nel database di origine che nel database di destinazione prima di migrare i dati. Dopo la migrazione, analizzare di nuovo il database di destinazione per verificare se alcuni vincoli sono diventati non attendibili come parte dello spostamento dei dati. Correggere i vincoli non attendibili in base alle esigenze. Lasciare i vincoli non attendibili può comportare piani di esecuzione scadenti e può influire sulle prestazioni.