Beste Möglichkeit, eine Datenbank zu kopieren (SQL Server 2008)

Dumme Frage - Was ist der beste Weg, um Instanzen in einer Umgebung zu kopieren, in der ich einen Entwicklungsserver mit Instanzen von einem Produktionsserver aktualisieren möchte?

Ich habe Backup-Restore durchgeführt, aber ich habe Detach-Copy-Attach gehört und ein Typ hat mir sogar gesagt, er würde nur die Datendateien zwischen den Dateisystemen kopieren ...

Sind dies die drei (oder zwei, die letzte klingt irgendwie verdächtig) akzeptierten Methoden?

Nach meinem Verständnis ist die zweite Methode schneller, erfordert jedoch aufgrund des Ablöseaspekts Ausfallzeiten an der Quelle.

Was ist in dieser Situation (wenn Sie eine genaue Kopie der Produktion auf einem Entwicklungsserver wünschen) die akzeptierte Vorgehensweise zum Übertragen von Anmeldungen usw.? Sollte ich nur die Benutzerdatenbanken + master + msdb sichern und wiederherstellen?

Der schnellste Weg, eine Datenbank zu kopieren, ist die Methode zum Trennen, Kopieren und Anhängen. Die Produktionsbenutzer haben jedoch keinen Datenbankzugriff, während die Produktdatenbank getrennt ist. Sie können so etwas tun, wenn Ihre Produktions-DB beispielsweise ein Point-of-Sale-System ist, das nachts niemand verwendet.

Wenn Sie die Produktionsdatenbank nicht trennen können, sollten Sie Backup und Restore verwenden.

Sie müssen die Anmeldungen erstellen, wenn sie sich nicht in der neuen Instanz befinden. Ich empfehle Ihnen nicht, die Systemdatenbanken zu kopieren.

Mit SQL Server Management Studio können Sie die Skripts erstellen, mit denen die erforderlichen Anmeldungen erstellt werden. Klicken Sie mit der rechten Maustaste auf das Login, das Sie erstellen möchten, und wählen Sie Script Login As / Create.

Dadurch werden die verwaisten Benutzer aufgelistet:

EXEC sp_change_users_login 'Report'

Wenn Sie bereits eine Anmelde-ID und ein Kennwort für diesen Benutzer haben, beheben Sie diese wie folgt:

EXEC sp_change_users_login 'Auto_Fix', 'user'

Wenn Sie eine neue Anmelde-ID und ein neues Kennwort für diesen Benutzer erstellen möchten, beheben Sie dies wie folgt:

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

Der einfachste Weg ist eigentlich ein Skript.

Führen Sie dies in der Produktion aus:

USE MASTER;

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

Mit diesem einen Befehl wird eine vollständige Sicherungskopie der Datenbank in eine einzelne Datei erstellt, ohne die Verfügbarkeit der Produktion oder den Sicherungszeitplan usw. zu beeinträchtigen.

Führen Sie dies zum Wiederherstellen einfach auf Ihrem Entwickler aus oder testen Sie 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

Speichern Sie diese Skripte dann auf jedem Server. Ein-Klick-Komfort.

Bearbeiten:
Wenn beim Wiederherstellen eine Fehlermeldung angezeigt wird, dass die logischen Namen nicht übereinstimmen, können Sie sie wie folgt abrufen:

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

Wenn Sie SQL Server-Anmeldungen verwenden (keine Windows-Authentifizierung), können Sie dies nach jeder Wiederherstellung (auf dem Entwickler- / Testcomputer) ausführen:

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

UPDATE:
Mein Rat unten zeigt Ihnen, wie Sie eine Datenbank mit SQL Server Management Studio skripten, aber die Standardeinstellungen in SSMS lassen aus irgendeinem Grund alle wichtigen Teile einer Datenbank (wie Indizes und Trigger!) Aus. Daher habe ich mein eigenes Programm erstellt, um eine Datenbank ordnungsgemäß zu skripten, die nahezu alle Arten von DB-Objekten enthält, die Sie möglicherweise hinzugefügt haben. Ich empfehle stattdessen, dies zu verwenden. Es heißt SQL Server Scripter und ist hier zu finden:
https://bitbucket.org/jez9999/sqlserverscripter

Ich bin überrascht, dass dies niemand erwähnt hat, da es wirklich nützlich ist: Sie können eine Datenbank (deren Schema und Daten) mit SQL Server Management Studio in ein Skript ausgeben.

Klicken Sie mit der rechten Maustaste auf die Datenbank, wählen Sie "Aufgaben | Skripte generieren ..." und wählen Sie dann, um bestimmte Datenbankobjekte zu skripten. Wählen Sie diejenigen aus, die Sie in die neue Datenbank kopieren möchten (Sie möchten wahrscheinlich mindestens die Tabellen und Schemata auswählen). Klicken Sie dann im Bildschirm "Skriptoptionen festlegen" auf "Erweitert", scrollen Sie nach unten zu "Zu skriptende Datentypen" und wählen Sie "Schema und Daten". Klicken Sie auf OK und beenden Sie die Generierung des Skripts. Sie werden sehen, dass dies jetzt ein langes Skript für Sie generiert hat, das die Tabellen der Datenbank erstellt und die Daten in diese einfügt! Anschließend können Sie eine neue Datenbank erstellen und die USE [DbName]Anweisung oben im Skript so ändern , dass sie den Namen der neuen Datenbank widerspiegelt, in die Sie die alte kopieren möchten. Führen Sie das Skript und die alte Datenbank aus. '

Auf diese Weise können Sie das Ganze in SQL Server Management Studio ausführen, ohne das Dateisystem berühren zu müssen.

Im Folgenden wird beschrieben, wie ich eine Datenbank aus der Produktionsumgebung in meine lokale Umgebung kopiere:

1. Erstellen Sie eine leere Datenbank auf Ihrem lokalen SQL Server
2. Klicken Sie mit der rechten Maustaste auf die neue Datenbank -> Aufgaben -> Daten importieren
3. Wählen Sie im SQL Server-Import- und Export-Assistenten den Servernamen der Produktumgebung als Datenquelle aus. Und wählen Sie Ihre neue Datenbank als Zieldaten aus.

Es ist schwierig, Ihre Produktions-dB oder andere laufende dBs zu trennen und mit diesen Ausfallzeiten umzugehen, daher verwende ich fast immer eine Sicherungs- / Wiederherstellungsmethode.

Wenn Sie auch sicherstellen möchten, dass Ihre Anmeldungen synchron bleiben , lesen Sie den MS KB-Artikel über die Verwendung des gespeicherten proc sp_help_revlogin , um dies zu tun.

Die Methode zum Trennen / Kopieren / Anhängen entfernt die Datenbank. Das möchten Sie in der Produktion nicht.

Die Sicherung / Wiederherstellung funktioniert nur, wenn Sie über Schreibberechtigungen für den Produktionsserver verfügen. Ich arbeite mit Amazon RDS und ich nicht.

Die Import / Export-Methode funktioniert aufgrund von Fremdschlüsseln nicht wirklich - es sei denn, Sie erstellen Tabellen einzeln in der Reihenfolge, in der sie aufeinander verweisen. Sie können einen Import / Export in eine neue Datenbank durchführen. Dadurch werden alle Tabellen und Daten kopiert, jedoch nicht die Fremdschlüssel.

Dies klingt nach einer allgemeinen Operation, die mit der Datenbank durchgeführt werden muss. Warum geht SQL Server damit nicht richtig um? Jedes Mal, wenn ich das tun musste, war es frustrierend.

Abgesehen davon war die einzige schmerzlose Lösung, auf die ich gestoßen bin, das SQL Azure-Migrationstool, das von der Community verwaltet wird. Es funktioniert auch mit SQL Server.

Ich führe einen SP aus, um die Tabelle (n) zu löschen, und verwende dann ein DTS-Paket, um die neuesten Produktionstabellen in meine Entwicklungsbox zu importieren. Dann gehe ich nach Hause und komme am nächsten Morgen zurück. Es ist nicht elegant; aber es funktioniert bei mir.

Wenn Sie eine Kopie einer Live-Datenbank erstellen möchten, führen Sie die Sicherungs- / Wiederherstellungsmethode aus.

[In SQLS2000 nicht sicher über 2008:] Beachten Sie nur, dass die Benutzerkonten die Benutzerkonten sind, wenn Sie SQL Server-Konten in dieser Datenbank verwenden, im Gegensatz zu Windows-Konten, wenn die Master-Datenbank auf dem Entwicklungsserver anders oder nicht synchron ist wird nicht übersetzt, wenn Sie die Wiederherstellung durchführen. Ich habe von einem SP gehört, um sie neu zuzuordnen, aber ich kann mich nicht erinnern, welcher es war.