Sandbox SQL Server

J'essaie de mettre en place un bac à sable pour nos développeurs de rapports dans leur travail. Mon plan actuel est de "réinitialiser" la base de données tous les soirs, mais je ne sais pas comment procéder. Ce que je veux dire par réinitialisation, c'est que je veux essentiellement supprimer toutes les tables utilisateur, vues, procédures stockées, etc. de toutes les bases de données sauf une sur le serveur. Je suppose qu'une autre option serait de supprimer et de recréer la base de données également, mais je suis presque sûr que cela signifierait également un accès à tous les groupes / personnes AD appropriés.

Je ne sais vraiment pas quelle serait la meilleure façon de procéder, alors j'espère que certains d'entre vous seront en mesure de fournir de bonnes idées / suggestions. Merci.

Pour plus de clarté, nous voulons essentiellement le faire avec notre base de données: http://try.discourse.org/t/this-site-is-a-sandbox-it-is-reset-every-day/57 . La seule différence est que nous ne voulons pas recréer nos utilisateurs tous les jours.

Version: SQL Server 2008
Edition: Developer & Enterprise

sql-server sql-server-2008

— Kittoes0124
source

Réponses:

Une autre idée serait de simplement configurer un travail nocturne qui effectue une sauvegarde copy_only et la restaure sur le serveur de développement (ou sur le même serveur, si vous n'en avez qu'un, mais ce n'est peut-être pas une excellente idée). La bonne chose à ce sujet est que la restauration peut aller sur n'importe quel serveur (ou plusieurs serveurs) et peut être complètement découplée de toute activité sur la base de données principale.

Sur le serveur 1:

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

Sur le serveur 2:

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

Vous devrez peut-être également ajouter des MOVEcommandes si la disposition du disque entre les serveurs est différente (ou si vous placez la copie sur le même serveur).

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';

Si vous restaurez sur le même serveur, vous ne devriez pas avoir de problèmes avec les utilisateurs. Si vous effectuez une restauration sur un autre serveur, vos utilisateurs existeront mais les connexions au niveau du serveur ne le seront peut-être pas. Il existe des scripts pour résoudre ce problème et une nouvelle fonctionnalité dans SQL Server 2012 ( bases de données contenues ) qui élimine complètement le problème.

— Aaron Bertrand
source

Nous avons dev / prod mais dev est le seul serveur sur lequel cela se produirait. Prod est uniquement destiné aux processus prêts pour la production.

— Kittoes0124

C'est la solution que je choisirais, mais n'oubliez pas que dans la plupart des cas, vous ne voulez pas simplement copier la production dans un environnement de développement. Veuillez avoir une mesure (script?) En place, qui supprimera ou masquera, par exemple, les adresses e-mail des utilisateurs, leurs coordonnées, etc. Vous ne voulez pas que vos développeurs commencent accidentellement à envoyer des e-mails aux utilisateurs.

— zeroDivisible le

Étant donné que vous disposez d'une instance avec le moteur Enterprise Edition, j'utiliserais des instantanés de base de données .

Cela vous permettra d'annuler rapidement et facilement toutes les modifications apportées au cours de la journée, sans avoir à restaurer l'intégralité de la base de données.

Notez que si les développeurs prévoient d'effectuer des chargements de données volumineuses (on dirait qu'ils ne le sont pas?), Cela peut ne pas être approprié.

— Jon Seigel
source

Pourquoi ne serait-il pas approprié qu'ils effectuent des chargements de données volumineuses? La nôtre pourrait charger disons ... 8 millions de lignes de 100 colonnes de temps en temps (même si elles "ne devraient pas" l'être) mais nous ne voulons pas nécessairement les empêcher de le faire. Tout ce qui nous tient vraiment à cœur, c'est que tout finit par se nuk à la fin de la journée.

— Kittoes0124

@Kittoes car un instantané doit être conservé lorsque les données source changent. Il doit extraire les pages existantes de la source si la source change, afin de conserver la vue "avant". Il ne le fait que lorsque les données source changent (un instantané utilise un fichier fragmenté vide, à l'exception des deltas). Cette maintenance peut devenir assez coûteuse. Découvrez le fonctionnement des instantanés de base de données .

— Aaron Bertrand

@AaronBertrand Ok, donc si la base de données atteint 8 Go pendant une journée, alors quand l'instantané est restauré, toutes les nouvelles données seront supprimées mais la base de données aura toujours une taille de 8 Go? Ou ai-je un malentendu?

— Kittoes0124

@Kittoes un instantané est en lecture seule, vous ne pourrez donc charger que de nouvelles données dans la base de données source. Si vous ajoutez 8 Go pendant la journée, il ne sera pas visible pour l'instantané. Lorsque vous rétablissez / supprimez l'instantané, la base de données source contiendra toujours ces 8 Go de données et sera dimensionnée en conséquence. Si vous prenez ensuite un autre instantané, les nouvelles données seront visibles. Si vous supprimez 8 Go pendant la journée, il sera ajouté à l'instantané.

— Aaron Bertrand

@Kittoes si vous voulez dire que vous voulez annuler la charge de données de 8 Go en revenant au moment où l'instantané a été pris, oui, il devrait retourner vos fichiers de données à la taille qu'ils étaient (si vous voulez vraiment que les fichiers soient à nouveau petits afin vous pouvez simplement augmenter automatiquement lorsque vous chargez à nouveau 8 Go demain est un autre problème). Mais je n'ai pas testé ce scénario explicitement. Et comme l'article que j'ai lié aux mentions, ce n'est pas nécessairement infaillible, car il dépend également de la fiabilité du stockage sous-jacent. Une sauvegarde est un moyen plus sûr de le faire.

— Aaron Bertrand

Permettez-moi d'ajouter mes quelques cents pour voir si cela vous aide:

Dans ma société, nous avons la même situation que chaque soir, les développeurs veulent actualiser les bases de données qu'ils ont utilisées tout au long de la journée. Cela signifie que nous avons un ensemble de bases de données de Dev ne touchent pas - disons , un et un autre ensemble de bases de données qui sont la copie exacte A , mais ils font leurs trucs , mais veulent se rafraîchir tous les soirs - disons B . Cela se produit sur une seule instance de serveur.

Ce que j'ai mis en œuvre est un processus de restauration nocturne pour y parvenir. Voici comment cela fonctionne:

Créez une table de pilotes avec une liste de bases de données qui doivent être restaurées tous les soirs (comme vous l'avez mentionné).

Tableau: nightly_restore (OriginalDB, RestoreDB, backuplocation, enabled_YN, Results, PASS_FAIL)

Ensuite, vous pouvez écrire du TSQL qui parcourra la liste des bases de données du tableau ci-dessus, puis effectuer les restaurations et consigner tout succès ou échec dans les résultats et un bit 1 = réussite ou 0 = échec. Enabled_YN déterminera si cette base de données doit être restaurée ou non.

S'il y a plus de bases de données qui seront ajoutées à l'avenir, il vous suffit d'insérer celles-ci dans le tableau et de définir le bit enabled_YN sur Y (activé).

De cette façon, le processus sera plus flexible et plus facile à gérer.

Si vous voulez le SQL que j'ai écrit (je suis sûr, vous pourrez l'écrire :-)), envoyez-moi un ping ou ajoutez un commentaire et je le partagerai.

HTH

— Kin Shah
source