Collega / scollega vs. backup / ripristina

Devo trasferire il database (nel suo insieme) su un altro server, per creare un database duplicato per configurare un altro ambiente di test.

Ho due scelte:

1. Effettuare un backup completo sul server di origine / ripristinare sul server di destinazione;
2. Scollega sul server di origine / collega al server di destinazione.

Quali sono i pro e i contro delle due soluzioni in base alle mie esigenze?

Sto usando SQL Server 2008 Enterprise.

Il backup / ripristino dovrebbe normalmente essere il tuo metodo di scelta. Sarà più veloce nella maggior parte delle situazioni.

Puoi usarlo in modo coerente, anche per testare la produzione.

Vedi anche questa domanda correlata, in cui è menzionato il backup / restore vs staccare / allegare:

Migrazione di SQL Server ripristina backup rispetto a copia dati e file di registro

Assicurarsi di aggiungere l' WITH COPY_ONLYopzione al backup in modo che non interrompa la catena di backup del piano di manutenzione esistente.

1. Il distacco del database lo porterà offline. Effettuare un backup se è necessario che il database rimanga online mentre lo si copia su un altro server.
2. Lo spostamento e il ripristino di un file di backup (.bak) potrebbe essere più semplice / più semplice rispetto allo spostamento e al collegamento di più file mdf / ldf (come se si staccasse il database).
3. Sulla carta, un distacco / collegamento di un database può essere tecnicamente più veloce, ma in pratica è probabile che un backup / ripristino sia più rapido e semplice. Quando si scollega un database, è innanzitutto necessario portare offline il database originale (scollegare tutti e tutto), quindi il database non è disponibile fino a quando non si ricollega. Devi anche tenere traccia di tutti i file, mentre con un backup tutti i file sono raggruppati.

Se si decide di eseguire il backup / ripristino, utilizzare l'opzione WITH COPY_ONLY durante il backup per assicurarsi che la catena di backup di qualsiasi piano di manutenzione esistente non venga interrotta.

Un file .bak si comprime bene, quindi se si decide di eseguire un backup, comprimerlo prima di spostarlo potrebbe risparmiare un po 'di tempo di trasferimento.

Vorrei fare il backup / ripristino in quanto lascia il database originale in uno stato operativo.

Soprattutto se stai eseguendo una conversione di "produzione da testare", è importante che il database di produzione rimanga online.

Il backup / ripristino è anche un'opzione più sicura : cosa succede se il file viene danneggiato da qualche parte tra l'inizio del distacco, la copia, l'allegato, ecc.? Almeno se si esegue un backup e il file viene danneggiato, è possibile ricominciare. Se ciò accade con un distacco, il database è sparito.

Inoltre, per me (sebbene sia più una sensazione che altro), il backup / ripristino è un "lavoro quotidiano" mentre il distacco / collegamento è qualcosa che fai in circostanze eccezionali. Non chiedermi dove ho avuto questa idea però ;-)

Ho sempre avuto problemi con la parte "ripristino" del backup / ripristino. Non posso citare dettagli in quanto alla fine ho rinunciato a questo e da allora ho smantellato / copiato / attaccato.

L'unica cosa che riguarda il distacco è che DEVI AVERE AVER assicurarti di assicurarti che anche il DBMS non eliminerà anche il database. Ho avuto questo accadere, e non è una bella vista.

Raccomando un copy_onlybackup utilizzando questo metodo da una shell DOS (in modo da non interrompere i registri delle transazioni) :

Esegui dalla C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\Backupdirectory:

backup.bat SQLDBNAME

Dove backup.batcontiene (interruzione di riga aggiunta per leggibilità) :

sqlcmd.exe -U username -P xxxxxxx -S SQL-SERVERNAME 
    -Q "BACKUP DATABASE %1 TO DISK = '%1_COPYONLY.BAK' WITH COPY_ONLY,INIT;"