SQL Server Sandbox

Ich versuche, eine Sandbox für unsere Berichtsentwickler einzurichten, in der sie arbeiten können. Mein aktueller Plan ist es, die Datenbank jeden Abend zurückzusetzen, aber ich bin mir nicht sicher, wie ich das machen soll. Mit Zurücksetzen meine ich, dass ich im Wesentlichen alle Benutzertabellen, Ansichten, gespeicherten Prozeduren usw. aus allen außer einer Datenbank auf dem Server löschen möchte. Ich nehme an, eine andere Option wäre, die Datenbank ebenfalls zu löschen und neu zu erstellen, aber ich bin mir ziemlich sicher, dass dies bedeuten würde, den Zugriff auf alle geeigneten AD-Gruppen / Personen erneut zu bereichern.

Ich weiß wirklich nicht, wie ich das am besten machen könnte, also hoffe ich, dass einige von Ihnen in der Lage sind, einige gute Ideen / Vorschläge zu machen. Vielen Dank.

Aus Gründen der Übersichtlichkeit möchten wir dies im Wesentlichen mit unserer Datenbank tun: http://try.discourse.org/t/this-site-is-a-sandbox-it-is-reset-every-day/57 . Der einzige Unterschied besteht darin, dass wir unsere Benutzer nicht jeden Tag neu erstellen möchten.

Version: SQL Server 2008
Edition: Entwickler und Unternehmen

sql-server sql-server-2008

— Kittoes0124
quelle

Antworten:

Eine andere Idee wäre, einfach einen nächtlichen Job einzurichten, der eine copy_only-Sicherung durchführt und auf dem Entwicklungsserver wiederherstellt (oder auf demselben Server, wenn Sie nur einen haben, aber das ist möglicherweise keine gute Idee). Das Schöne daran ist, dass die Wiederherstellung auf jeden Server (oder auf mehrere Server) erfolgen und vollständig von allen Aktivitäten in der Primärdatenbank entkoppelt werden kann.

Auf Server 1:

BACKUP DATABASE db TO DISK = '\\someshare\file.bak' 
  WITH COPY_ONLY, INIT, COMPRESSION;

Auf Server 2:

RESTORE DATABASE db_dev FROM DISK = '\\someshare\file.bak'
  WITH REPLACE, RECOVERY;

Möglicherweise müssen Sie auch MOVEBefehle hinzufügen , wenn das Festplattenlayout zwischen den Servern unterschiedlich ist (oder wenn Sie die Kopie auf demselben Server ablegen).

RESTORE DATABASE db_dev FROM DISK = '\\someshare\file.bak'
  WITH REPLACE, RECOVERY,
  MOVE 'data_file_name' TO 'D:\somepath\somefile.mdf',
  MOVE 'log_file_name'  TO 'E:\somepath\somefile.ldf';

Wenn Sie auf demselben Server wiederherstellen, sollten Sie keine Probleme mit Benutzern haben. Wenn Sie auf einem anderen Server wiederherstellen, sind Ihre Benutzer vorhanden, die Anmeldungen auf Serverebene jedoch möglicherweise nicht. Es gibt Skripte, um dies zu beheben , und eine neue Funktion in SQL Server 2012 ( Enthaltene Datenbanken ), mit der das Problem vollständig behoben wird.

— Aaron Bertrand
quelle

Wir haben dev / prod, aber dev ist der einzige Server, auf dem dies geschehen würde. Prod ist nur für prod-fähige Prozesse vorgesehen.

— Kittoes0124

Dies ist die Lösung, die ich wählen würde. Denken Sie jedoch daran, dass Sie in den meisten Fällen die Produktion nicht einfach in die Entwicklungsumgebung kopieren möchten. Bitte haben Sie eine Maßnahme (Skript?), Mit der beispielsweise E-Mail-Adressen, Kontaktdaten usw. von Benutzern entfernt oder verdeckt werden. Sie möchten nicht, dass Ihre Entwickler versehentlich E-Mails an Benutzer senden.

— zeroDivisible

Da Sie eine Instanz mit der Enterprise Edition-Engine haben, würde ich Datenbank-Snapshots verwenden .

Auf diese Weise können Sie alle während des Tages vorgenommenen Änderungen schnell und einfach rückgängig machen, ohne die gesamte Datenbank wiederherstellen zu müssen.

Beachten Sie, dass dies möglicherweise nicht angemessen ist, wenn die Entwickler große Datenmengen laden möchten (klingt so, als wären sie es nicht?).

— Jon Seigel
quelle

Warum wäre es nicht angemessen, wenn sie große Datenmengen laden würden? Unsere könnten ab und zu 8 Millionen Zeilen mit 100 Spalten laden (auch wenn sie "nicht" sein sollten), aber wir wollen sie nicht unbedingt daran hindern. Alles, was uns wirklich wichtig ist, ist, dass am Ende des Tages alles kaputt geht.

— Kittoes0124

@Kittoes, da ein Snapshot gepflegt werden muss, wenn sich die Quelldaten ändern. Wenn sich die Quelle ändert, müssen vorhandene Seiten aus der Quelle abgerufen werden, damit die Vorher-Ansicht beibehalten wird. Dies geschieht erst, wenn sich die Quelldaten ändern (ein Snapshot verwendet eine Datei mit geringer Dichte, die bis auf Deltas leer ist). Diese Wartung kann sehr teuer werden. Sehen Sie, wie Datenbank-Snapshots funktionieren .

— Aaron Bertrand

@AaronBertrand Ok, wenn die Datenbank an einem Tag auf 8 GB wächst, werden dann bei der Wiederherstellung des Snapshots alle neuen Daten entfernt, aber die Datenbank hat immer noch eine Größe von 8 GB? Oder verstehe ich falsch?

— Kittoes0124

@Kittoes Ein Snapshot ist schreibgeschützt, sodass Sie nur neue Daten in die Quellendatenbank laden können. Wenn Sie tagsüber 8 GB hinzufügen, ist dies für den Schnappschuss nicht sichtbar. Wenn Sie den Snapshot zurücksetzen / löschen, verfügt die Quellendatenbank weiterhin über diese 8 GB Daten und wird entsprechend dimensioniert. Wenn Sie dann einen weiteren Schnappschuss machen, werden die neuen Daten angezeigt. Wenn Sie tagsüber 8 GB entfernen, wird dies dem Snapshot hinzugefügt .

— Aaron Bertrand

@Kittoes Wenn Sie damit meinen, dass Sie das Laden von 8 GB Daten rückgängig machen möchten, indem Sie zu dem Zeitpunkt zurückkehren, zu dem der Snapshot erstellt wurde, sollten Ihre Datendateien auf die Größe zurückgesetzt werden, die sie hatten (ob Sie die Dateien wirklich wieder klein haben möchten, also Sie können einfach mehr automatisch wachsen, wenn Sie morgen wieder 8 GB laden. Dies ist ein weiteres Problem. Aber ich habe dieses Szenario nicht explizit getestet. Und wie der Artikel, auf den ich verwiesen habe, erwähnt, ist dies nicht unbedingt narrensicher, da es auch von der Zuverlässigkeit des zugrunde liegenden Speichers abhängt. Ein Backup ist ein sicherer Weg, dies zu tun.

— Aaron Bertrand

Lassen Sie mich meine paar Cent hinzufügen, um zu sehen, ob es Ihnen hilft:

In meinem Unternehmen haben wir die gleiche Situation, dass die Entwickler jede Nacht die Datenbanken aktualisieren möchten, die sie den ganzen Tag über verwendet haben. Dies bedeutet , dass wir eine Reihe von Datenbanken haben , dass Devs nicht berühren - sagen wir mal A und ein anderer Satz von Datenbanken , die exakte Kopie A sind , aber sie haben ihre Sachen aber wollen jede Nacht aktualisiert bekommen - sagen wir mal B . Dies geschieht auf einer einzelnen Serverinstanz.

Was ich implementiert habe, ist ein NIGHTLY RESTORE-PROZESS, um dies zu erreichen. Unten ist, wie es funktioniert:

Erstellen Sie eine Treibertabelle mit einer Liste von Datenbanken, die jeden Abend wiederhergestellt werden müssen (wie bereits erwähnt).

Tabelle: nightly_restore (OriginalDB, RestoreDB, Backuplocation, enabled_YN, Ergebnisse, PASS_FAIL)

Dann können Sie eine TSQL schreiben, die die Liste der Datenbanken aus der obigen Tabelle durchläuft, dann die Wiederherstellungen durchführt und alle Erfolge oder Fehler in den Ergebnissen protokolliert und ein Bit 1 = Bestanden oder 0 = Nicht bestanden. Enabled_YN bestimmt, ob diese Datenbank wiederhergestellt werden muss oder nicht.

Wenn in Zukunft weitere Datenbanken hinzugefügt werden, müssen Sie diese nur in die Tabelle einfügen und das Bit enabled_YN auf Y (enabled) setzen.

Auf diese Weise wird der Prozess flexibler und überschaubarer.

Wenn Sie das SQL möchten, das ich geschrieben habe (ich bin sicher, Sie können es schreiben :-)), pingen Sie mich einfach an oder fügen Sie einen Kommentar hinzu, und ich werde es teilen.

HTH

— Kin Shah
quelle