Il modo migliore per copiare un database (SQL Server 2008)

Question

Domanda stupida - qual è il modo migliore per copiare istanze in un ambiente in cui si desidera aggiornare un server di sviluppo con istanze da un server di produzione?

Ho fatto il backup-restore, ma ho sentito distacco-copia-attach e un ragazzo mi ha persino detto che avrebbe basta copiare i file di dati tra i file system ....

Sono queste le tre (o due, l'ultimo suona come sospetto) metodi accettati?

La mia comprensione è che il secondo metodo è più veloce ma richiede tempi di inattività sulla sorgente a causa dell'aspetto di distacco.

Inoltre, in questa situazione (volendo una copia esatta della produzione su un server di sviluppo) qual è la prassi accettata per il trasferimento degli accessi, ecc.? Devo solo eseguire il backup e ripristinare i database utente + master + msdb?

Answer 1

Il modo più veloce per copiare un database è il metodo detach-copy-attach, ma gli utenti di produzione non avranno accesso al database mentre il db prod è scollegato. Puoi fare qualcosa del genere se il tuo DB di produzione è ad esempio un sistema Point of Sale che nessuno usa durante la notte.

Se non è possibile staccare il db di produzione, è necessario utilizzare il backup e il ripristino.

È necessario creare gli accessi se non si trovano nella nuova istanza. Non ti consiglio di copiare i database di sistema.

È possibile utilizzare SQL Server Management Studio per creare gli script che creano gli accessi necessari. Fare clic con il tasto destro del mouse sul login che è necessario creare e selezionare Script Login come/Crea.

Questa volontà elenca gli utenti orfani:

EXEC sp_change_users_login 'Report' 

Se si dispone già di un ID di accesso e una password per l'utente, risolvere il problema facendo:

EXEC sp_change_users_login 'Auto_Fix', 'user' 

Se si desidera creare un nuovo login ID e la password per questo utente, risolvere il problema facendo:

EXEC sp_change_users_login 'Auto_Fix', 'user', 'login', 'password' 

Answer 2

È difficile staccare il dB di produzione o altri dB in esecuzione e gestire il tempo di inattività, quindi quasi sempre utilizzo un metodo di backup/ripristino.

Se anche voi volete fare in modo di mantenere il vostro di accesso in sincronia controllare il MS KB article sull'uso del proc memorizzato sp_help_revlogin per fare questo.

Answer 3

Se si desidera acquisire una copia di un database attivo, eseguire il metodo di backup/ripristino.

[In SQLS2000, non sono sicuro del 2008:] Basta tenere presente che se si utilizzano account SQL Server in questo database, a differenza degli account Windows, se il DB master è diverso o non sincronizzato sul server di sviluppo , gli account utente non verranno tradotti quando si esegue il ripristino. Ho sentito parlare di un SP per rimapparli, ma non riesco a ricordare quale fosse.

Answer 4

corro un SP per eliminare la tabella (s) e quindi utilizzare un pacchetto DTS per importare le tabelle di produzione più recenti nella mia casella di sviluppo. Poi vado a casa e torno la mattina seguente. Non è elegante; ma funziona per me.

Answer 5

UPDATE:
Il mio consiglio di seguito spiega come lo script di un DB tramite SQL Server Management Studio, ma le impostazioni di default in SSMS perdere tutti i tipi di parti cruciali di una banca dati per (come gli indici e trigger!) qualche ragione. Così, ho creato il mio programma per scrivere correttamente un database, includendo praticamente ogni tipo di oggetto DB che potresti aver aggiunto. Raccomando invece di usare questo. Si chiama SQL Server Scripter e può essere trovato qui:
https://bitbucket.org/jez9999/sqlserverscripter

---

Mi sorprende che nessuno ha parlato di questo, perché è davvero utile: è possibile scaricare un database (il suo schema e dati) a uno script, utilizzando SQL Server Management Studio.

Fare clic con il pulsante destro del mouse sul database, selezionare "Attività | Genera script ...", quindi selezionare per eseguire lo script di oggetti di database specifici. Seleziona quelli che vuoi copiare nel nuovo DB (probabilmente vorrai selezionare almeno le tabelle e gli schemi). Quindi, per la schermata "Imposta opzioni di script", fare clic su "Avanzate", scorrere fino a "Tipi di dati da script" e selezionare "Schema e dati". Fare clic su OK e terminare la generazione dello script. Vedrai che questo ora ha generato un lungo script per te che crea le tabelle del database e inserisce i dati in essi! È quindi possibile creare un nuovo database e modificare l'istruzione USE [DbName] nella parte superiore dello script per riflettere il nome del nuovo database su cui si desidera copiare quello precedente. Esegui lo script e lo schema del vecchio database e i dati saranno copiati in quello nuovo!

Ciò consente di eseguire l'intera operazione all'interno dello studio di gestione SQL Server e non è necessario toccare il file system.

Answer 6

Il metodo di scollegamento/copia/collegamento interromperà il database. Non è qualcosa che vorresti nella produzione.

Il backup/ripristino funziona solo se si dispone delle autorizzazioni di scrittura sul server di produzione. Lavoro con Amazon RDS e non lo faccio.

Il metodo di importazione/esportazione non funziona realmente a causa delle chiavi esterne, a meno che non si facciano le tabelle una per una nell'ordine in cui fanno riferimento l'una all'altra. È possibile eseguire un'importazione/esportazione in un nuovo database. Questo copierà tutte le tabelle e i dati, ma non le chiavi esterne.

Questo suona come un'operazione comune che si ha a che fare con il database. Perché SQL Server non lo gestisce correttamente? Ogni volta che dovevo farlo era frustrante.

Detto questo, l'unica soluzione indolore che ho incontrato era Sql Azure Migration Tool che viene gestita dalla comunità. Funziona anche con SQL Server.

Answer 7

Il modo più semplice è in realtà una sceneggiatura.

Esegui questo sulla produzione:

USE MASTER; 

BACKUP DATABASE [MyDatabase] 
TO DISK = 'C:\temp\MyDatabase1.bak' -- some writeable folder. 
WITH COPY_ONLY 

Questo comando crea una copia di backup completa del database su un unico file, senza interferire con la disponibilità di produzione o di pianificazione del backup, ecc

Per ripristinare, basta eseguire questo sul vostro dev o il test di SQL Server:

USE MASTER; 

RESTORE DATABASE [MyDatabase] 
FROM DISK = 'C:\temp\MyDatabase1.bak' 
WITH 
MOVE 'MyDatabase' TO 'C:\Sql\MyDatabase.mdf', -- or wherever these live on target 
MOVE 'MyDatabase_log' TO 'C:\Sql\MyDatabase_log.ldf', 
REPLACE, RECOVERY 

quindi salvare questi script su ciascun server. Convenienza con un clic.

Edit:
se si ottiene un errore durante il ripristino che i nomi logici non corrispondono, è possibile ottenere in questo modo:

RESTORE FILELISTONLY 
FROM disk = 'C:\temp\MyDatabaseName1.bak' 

Se si utilizzano gli account di accesso di SQL Server (non Windows di autenticazione) è possibile eseguire questo dopo il ripristino di volta in volta (sulla macchina dev/test):

use MyDatabaseName; 
sp_change_users_login 'Auto_Fix', 'userloginname', null, 'userpassword'; 

Answer 8

ho usato EMS SQL Backup ed ha il compito di trasporto di database che può essere facilmente in programma. Devi specificare la cartella di rete condivisa. La copia viene eseguita anche tramite backup/copia/ripristino, ma può essere impostata rapidamente. Sembra che non ci sia la possibilità di gestire gli accessi nel programma e dovrai farlo manualmente.

Answer 9

Qui di seguito è quello che faccio per copiare un database da env produzione al mio ENV locale:

1. creare un database vuoto nel server SQL locale
2. Fare clic destro sul nuovo database -> attività -> dati di importazione
3. Nell'Importazione/Esportazione guidata di SQL Server, selezionare il nomeserver di env del prodotto come origine dati. E seleziona il tuo nuovo database come dati di destinazione.