Sea*_*ong 9 sql-server sql-server-2008-r2
我正在 SQL Server 2008 R2 SP1 上设置生产数据库的开发副本。目前,两个开发人员很少使用实时数据库进行只读查询,但新数据库也会对其进行更新。
由于数据库是 2.1TB,总共需要 3 天时间来恢复和更新到我们测试所需的最新版本,我最初的计划是创建一组新的备份文件,然后从这些文件中恢复。这将允许我在同一 SQL 实例和机器上创建数据库的开发副本,而不必使当前数据库脱机。
但是,为了节省这几天的时间,我认为只复制物理数据库文件并附加数据库的新副本可能是个好主意。不幸的是,当我尝试复制时,我收到一个错误,指的是 SQL Server 对这些文件的锁定。
由于除了传输日志文件之外我无法将数据库脱机(我可以在人们早上进入之前完成此操作),有什么方法可以复制实时数据库文件而不将数据库置于脱机状态?还是应该等到人们回家后再做?
Aar*_*and 11
为什么备份/恢复 2.1 TB 的数据库需要 3 天?如果只是关于移动备份,我怀疑复制 MDF/LDF 文件实际上会更慢,因为至少可以压缩备份。如果它只是关于恢复,那么写入文件的副本应该不会比恢复过程本身更快 - 确保您启用了即时文件初始化。或者在辅助系统上获得更快的 I/O。
无论如何,不,您不能在数据库联机时复制 MDF/LDF 文件,您必须使其脱机才能这样做。这是复制数据库的绝对最不安全的方法。如果文件在分离/脱机时发生任何事情,您现在的数据库副本为零。
我建议寻找使备份/恢复更快的方法 - 无论是确保您以最佳方式压缩备份和传输文件,使用最好的可用 I/O 子系统,获得更好的 I/O,使确保已启用 IFI 等。
另一个要考虑的选择是循环日志传送 - 假设生产处于完全恢复状态并且您正在定期进行日志备份,您可以在开发人员处理另一个数据库时将日志传送到一个数据库,并且当您达到稳定点时,通过恢复进行恢复并让开发人员切换,并随身携带他们最近的更改。现在在他们刚刚停止工作的副本上重新初始化日志传送,并且将在下一次“稳定”切换时为他们准备好,无需等待。
| 归档时间: |
|
| 查看次数: |
25423 次 |
| 最近记录: |