Spostavo i database quasi costantemente, a causa della riconfigurazione e delle migrazioni della SAN.
Supponendo che tu stia spostando un intero server alla volta, andrei con qualcosa come il tuo percorso n. 2. (Se si sposta un database alla volta e alla fine si esegue ogni database su un server, ciò sarebbe più problematico poiché sarebbe necessario modificare i percorsi dei file.)
Nota che "single_user" non significa necessariamente TU. Potresti andare a DBCC CHECKDB un database e non essere in grado di entrare perché qualcuno è già lì. Prepara uno script che puoi eseguire per avviare "tutti tranne te" da un database e tenerlo in un posto comodo. Si noti che SQL 2000 non ha le stesse funzionalità di "tenere fuori tutti" delle versioni più moderne.
Un vecchio trucco è mettere in pausa il servizio SQL Server. Ciò impedirà i nuovi accessi, ma chiunque sia già connesso può continuare come al solito. Quindi: connettiti tramite una finestra SSMS in modo da poter svolgere il lavoro, quindi metti in pausa il servizio, quindi avvia le connessioni indesiderate, fai le tue cose tramite la finestra di comando SSMS (non la GUI, crea e interrompe molte connessioni) e quindi interrompi la pausa il servizio. Avvertenza: non sono sicuro di come andrebbe a finire su un cluster. Potrebbe voler eseguire il failover.
È utile avere un modo per tenere tutti gli utenti delle app fuori da un server fino a quando non hai finito il tuo lavoro. Altrimenti, le connessioni possono iniziare a spuntare mentre si sta tentando di fare cose, il che può portare alla contesa delle risorse e / o alla lentezza. In passato ho utilizzato i seguenti modi, a seconda della situazione esatta: Disattivazione dei server delle applicazioni Uso di ALTER DATABASE .. SET RESTRICTED_USER (Se gli account delle app sono membri di ruoli db_owner, sysadmin o dbcreator, questo è un problema. ) Dire agli utenti che il sistema sarà offline in un determinato momento, come una domenica mattina. (Questo non funzionerà in un ambiente "reale" 24x7). Scollegare la scheda NIC che si trova di fronte ai server delle app o agli utenti. (In questo caso, potrei accedere tramite un'altra scheda di rete connessa a una rete di soli amministratori o tramite ILO.)
Staccare un gran numero di database e ricollegarli può richiedere molto lavoro. Se lo fai, assicurati di avere il tuo script "attach" scritto in anticipo.
Ho avuto molto successo nell'arresto di SQL Server, nella copia di tutto, nella modifica delle lettere di unità e nell'avvio di SQL Server. Nessun distacco / collegamento. Fintanto che SQL Server è spento e si stanno copiando file (non SPOSTANDO), non è possibile creare troppi problemi, anche se si spostano i database di sistema. Poiché i percorsi sono gli stessi, SQL Server non si accorgerà che nulla è cambiato mentre il servizio era spento. Assicurati solo di riportare le lettere di unità ai volumi corretti o che le cose vadano male per te.
Il mio problema più frequente non era correggere gli ACL nelle directory dei file. Le versioni più moderne di SQL Server sono più efficaci nell'impostare solo le autorizzazioni necessarie per l'account del servizio, mentre le versioni precedenti sembrano meno esigenti. Se si dimentica di impostare gli ACL e l'account del servizio non è un amministratore locale (non che lo consiglierei a me), uno o più database potrebbero non aprirsi all'avvio dell'istanza. Non fatevi prendere dal panico, basta cambiare gli ACL e collegare il database.
In genere uso ROBOCOPY per fare questo tipo di lavoro. C'è un'opzione della riga di comando per preservare gli ACL.
L'uso di un calcolo / verifica CRC non è una cattiva idea, ma non l'ho mai fatto. Quando i database tornano indietro, eseguo CHECKDB () su tutti. Di solito preparerò uno script per questo in anticipo, piuttosto che fare affidamento sul dare il via manualmente a un lavoro di manutenzione. In questo modo, posso controllare un paio di database più piccoli prima di controllare un database di grandi dimensioni che potrebbe richiedere molti minuti o ore per l'esecuzione. Dubito che un controllo CRC (o uno strumento di confronto dei dati di Redgate) troverebbe qualcosa che CHECKDB () mancherebbe, e se lo facesse SQL Server non sarebbe in grado di risolverlo.
Dopo aver copiato i file, ma prima di riavviare l'istanza, andrò a modificare leggermente il percorso del file delle cartelle OLD rinominando una delle cartelle. Questo è un ulteriore controllo rispetto al problema "Spiacenti, il server punta ancora ai vecchi file".
Non avere fretta di eliminare i vecchi file e recuperare spazio sul vecchio archivio e assicurati che i backup completi siano stati eseguiti correttamente. Prova a ripristinare un paio di quei backup da qualche altra parte. Una volta che hai una buona esecuzione di checkdb () e buoni backup completi, puoi pensare di abbandonare quel vecchio spazio di archiviazione e chiudere la mano sinistra.
I peggiori problemi che ho avuto con queste migrazioni si sono verificati dopo aver pensato di aver finito. Sarebbe l'amministratore della SAN a dirmi che era successo qualcosa e che i miei file system erano confusi. (Riparato, riformattato, copiato di nuovo.)
Un altro problema divertente è che la SAN è lenta senza una ragione apparente. Se pensi che ci vorranno 10 ore per copiare i tuoi dati e sei copiato al 30% all'ora numero 9, hai un problema. Guarda i tempi di trasferimento (robocopy mostra% copiato e fornisce stime dei tempi, oppure puoi usare Perfmon) e avere un piano di fallback se qualcosa va storto.
Inoltre, non sono sicuro se i tuoi volumi saranno partizionati per te, ma potresti voler essere sicuro che stiano usando un offset di 1 MB. Su Windows Server 2008 e versioni successive, questo non dovrebbe essere un problema. Sul vecchio sistema operativo, lo è. Ci sono un sacco di cose su Google su questo, e i tuoi ragazzi di archiviazione dovrebbero saperlo, ma lo chiederei.