Spostamento del database SQL Server su un nuovo disco mentre è online

Ho un database SQL Server da 1,4 TB che sta lottando enormemente con l'I / O del disco. Abbiamo installato un nuovo array SSD nel server che risolverà tutti i nostri problemi, stiamo solo discutendo il modo migliore per spostare il database. Idealmente, se possiamo farlo senza tempi di inattività, è meglio. Ma se la scelta è tra due giorni di scarso rendimento (ad es. Durante la copia dei dati) rispetto a due ore di inattività, quest'ultimo potrebbe essere preferibile.

Finora, le soluzioni che abbiamo trovato sono:

• Semplice copia. Porta offline il DB, copia i file, modifica le posizioni in SQL Server e riportalo online. I dati approssimativi stimano che ci vorranno fino a cinque ore, il che non è davvero accettabile, ma è la soluzione più semplice.

• Copia a livello di blocco. Usando un'utilità simile a rsync, copiamo i file in background mentre il DB è attivo. Quando siamo pronti per la migrazione, portiamo il DB offline, eseguiamo una copia differenziale attraverso questa utility, quindi puntiamo il server SQL verso i nuovi file e lo portiamo online. Il tempismo qui non è noto. Non sappiamo quanto tempo ci vorrà per fare un'analisi differenziale di 1,4 TB e copiarla. La nostra altra preoccupazione è che la copia a livello di blocco lascerà i file in alcuni stati illeggibili da SQL Server e avremo tempo perso.

• Migrazione SQL. Crea un nuovo file di dati SQL da 1,4 TB sul nuovo disco e disabilita la crescita automatica su tutti gli altri file. Quindi eseguire DBBC SHRINKFILE (-file_name-, EMPTYFILE) su tutti gli altri file di dati a turno. Una volta che tutti i dati sono stati trasferiti, ad un certo punto prenderò una finestra pianificata per spostare il file MDF sull'SSD e rimuovere gli altri file non utilizzati. Mi piace perché riduce al minimo i tempi di fermo. Ma non ho idea di quanto tempo ci vorrà e se causerà un degrado delle prestazioni mentre sta accadendo.

Non abbiamo alcun tipo di ambiente di carico e prestazioni per testarlo. Posso verificare che le strategie funzioneranno nel nostro ambiente di gestione temporanea, ma non l'impatto e non le prestazioni.

Un metodo per spostare l'intero database è con BACKUPe RESTORE. Il database non sarà disponibile durante lo switch finale ma i tempi di inattività dovrebbero essere minimi con la pianificazione. Questa procedura presuppone il modello di recupero FULLo BULK_LOGGED:

1) Eseguire un backup COMPLETO (o utilizzare quello esistente).

2) Ripristinare l'ultimo backup completo su un nome di database diverso, specificando l' WITH MOVEopzione per riposizionare i file sull'archivio SSD come desiderato e l' NORECOVERYopzione in modo da poter ripristinare i successivi backup differenziali e di registro.

3) Applicare modifiche incrementali al nuovo database fino al momento del cut-over finale con i backup del registro delle transazioni e RESTORE...WITH NORECOVERY. Ciò ridurrà al minimo i tempi di inattività per il passaggio finale al nuovo database.

4) Per passare al nuovo database, portare offline l'applicazione, eseguire un backup del registro delle transazioni finale e applicare al nuovo database WITH RECOVERY. Infine, rinominare il database originale con un nome diverso e rinominare il database trasferito con il nome originale. Rilascia il vecchio database a tuo piacimento.

Nel modello di recupero SEMPLICE, è possibile utilizzare un processo simile ma senza il backup / ripristino del registro delle transazioni del passaggio 3. Utilizzare invece un backup / ripristino del database differenziale nel passaggio finale. Ciò potrebbe richiedere più tempi di inattività, a seconda della quantità di modifiche dal FULLbackup iniziale .

Good approach is to use SQL REPLICATION between two server
once all data replicated on SSD server then take current server offline 
and switch to SSD server.