SQL Server沙箱


9

我正试图为我们的报表开发人员设置一个沙盒,以供他们使用。我目前的计划是每天晚上“重置”数据库,但我不确定该怎么做。重置是指我实际上要从服务器上除一个数据库之外的所有数据库中删除任何用户表,视图,存储过程等。我想另一个选择是也删除并重新创建数据库,但是我很确定这也意味着要重新访问所有适当的AD组/人员。

我真的不知道这样做的最佳方式是什么,所以我希望你们中的一些人能够提供一些好的想法/建议。谢谢。

为了清楚起见,我们本质上希望使用我们的数据库来做到这一点:http : //try.discourse.org/t/this-site-is-a-sandbox-it-is-reset-every-day/57。唯一的不同是我们不想每天重新创建用户。

版本: SQL Server 2008
版本:开发人员和企业

Answers:


8

另一个想法是简单地设置一个每晚工作,该工作只执行copy_only备份,然后将其还原到开发服务器上(或者如果只有一个,则在同一台服务器上,但这可能不是一个好主意)。这样做的好处是,还原可以转到任何服务器(或多个服务器),并且可以与主数据库上的任何活动完全分离。

在服务器1上:

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

在服务器2上:

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

MOVE如果服务器之间的磁盘布局不同(或者将副本放置在同一服务器上),则可能还需要添加命令。

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

如果要在同一服务器上还原,则用户应该不会有任何问题。如果还原到其他服务器,则您的用户将存在,但服务器级别的登录名可能不存在。有一些脚本可以解决此问题,并且SQL Server 2012(包含的数据库)中有一项新功能可以完全消除该问题。


我们拥有dev / prod,但是dev是唯一会在其中发生这种情况的服务器。产品仅适用于准备产品的过程。
Kittoes0124 2013年

这是我会选择的解决方案,请记住,在大多数情况下,您不想简单地将生产复制到开发环境中。请采取适当的措施(脚本?),例如,该措施将删除或掩盖用户的电子邮件地址,联系方式等。您不希望您的开发人员意外地开始向用户发送电子邮件。
zeroDiverse

5

由于您具有Enterprise Edition Engine的实例,因此我将使用数据库快照

这样,您便可以快速轻松地回滚一天中所做的任何更改,而不必还原整个数据库。

请注意,如果开发人员计划进行大数据加载(听起来不是吗?),那么这可能不合适。


如果他们正在进行大数据加载,那为什么不合适呢?我们的加载可能会说...。不时地加载800万行100列(即使它们“不应该”),但我们不一定要阻止它们这样做。我们真正关心的是,一切都在一天结束时被取消。
Kittoes0124 2013年

2
@Kittoes,因为当源数据更改时必须维护快照。如果源发生更改,它需要从源中拉出现有页面,以便保持“之前”视图。直到源数据更改(快照使用的稀疏文件(增量除外)为空)后,它才会执行此操作。这种维护可能变得非常昂贵。查看数据库快照如何工作
亚伦·伯特兰

@AaronBertrand好吧,如果数据库在一天之内增长到8GB,那么在恢复快照时,所有新数据都将被删除,但数据库大小仍为8GB?还是我误会了?
Kittoes0124 2013年

@Kittoes快照是只读的,因此您只能将新数据加载到源数据库中。如果白天增加8GB,则快照将看不到它。还原/删除快照时,源数据库仍将具有该8GB的数据,并会相应调整大小。如果您随后拍摄另一个快照,新数据将可见。如果白天删除8GB,它将被添加到快照中。
亚伦·伯特兰

1
@Kittoes如果您想通过还原到拍摄快照的时间点来撤消8GB的数据负载,是的,它应该将数据文件恢复为原来的大小(是否确实要再次减小文件大小,因此您明天再加载8GB时可以自动增长更多,这是另一个问题)。但是我还没有明确测试这种情况。正如我所链接提及的文章所述,这不一定是万无一失的,因为它还取决于基础存储的可靠性。备份是一种更安全的方法。
亚伦·伯特兰

0

让我加点钱,看看它是否对您有帮助:

在我的公司中,我们遇到的情况是,开发人员每天晚上都想刷新他们整天一直在使用的数据库。这意味着,我们有一组数据库是Dev的不碰- 可以说,一个和另一组的数据库,这是完全相同的副本,但他们做自己的东西,但要每天晚上得到刷新- 可以说乙。这在1个单服务器实例上发生。

我实现的是一个实现此目的的夜间恢复过程。下面是它的工作方式:

创建一个驱动程序表,其中包含需要在每个晚上恢复的数据库列表(如前所述)。

表:nightly_restore(原始数据库,还原数据库,备份位置,enabled_YN,结果,PASS_FAIL)

然后,您可以编写一些TSQL,该TSQL将遍历上表中的数据库列表,然后执行恢复并在结果中记录任何成功或失败,以及1 = Pass或0 = Fail。Enabled_YN将确定是否需要还原该数据库。

如果将来有更多数据库要添加,则只需将它们插入表中,然后将enabled_YN位设置为Y(启用)。

这样,过程将更加灵活和易于管理。

如果您想要我编写的SQL(我敢肯定,您可以编写它:-)),只需ping我或添加注释,我将与您分享。

高温超导

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.