Sql server SQL Server灾难恢复选项/事务日志

我在开发环境中的MDF文件上有一个大约10 Gig大小的数据库。日志文件失控，有时我运行此代码只是为了每天减少空间

 DBCC SHRINKDATABASE(FIX, TRUNCATEONLY);
 DBCC SHRINKFILE(FIX, 100);

是时候将其转移到“生产”环境中了。由于空间的关系，我们需要把这些日志保存得很小

我有两个prod服务器和一个dev服务器。在不知道任何事情的情况下，我认为最好在prod1到prod2上进行同步数据库镜像，而不知道如何在dev上更新数据库

我们使用了大量的SQLCLR，几乎每天都对模式进行更改。我相信您已经看到过这样一个场景：您在白板上显示“让我们使用prod1和prod2，我们将在开发和卷展更改上进行开发”，但最终prod1最终成为开发人员，没有人使用其他两个

所以我的问题

三台服务器，一个小团队。Prod1、Prod2和dev。最佳灾难恢复策略是什么

应该制定哪些程序/流程，以便在保持健全性、高数据质量的同时又不牺牲灵活性

关于这个主题的任何链接都会非常有用

谢谢

***********更新***********

谢谢你的回复！好问题

为了清楚起见，我应该补充这一点。我有一个访问前端，它在数据中心作为远程应用程序运行，前端使用ODBC数据源进行连接。东海岸办公室和西海岸办公室的3-4名用户使用此前端，并每小时更新数据库数次。我们的技术不太高，但数据很重要

我们正在使用企业版。延迟不是一个大问题。数据中心位于东海岸/西海岸。我不确定如果我们使用同步策略，更新数据库中的一行会拖多长时间。半秒钟就可以了。10秒不好。我用的是完整的模型。对不起，我输入了一个错误，我在其他数据库中使用了上面的代码，但是到目前为止，在这个数据库中还没有缩小日志。从未做过日志备份。在“做某事”之前，我想我应该知道“计划是什么”，所以这就是为什么我在这里问关于选项的问题

数据不是我们需要的负载平衡器，它几乎没有负载。主要问题和最高优先级是数据完整性。我们的系统有一个从未关闭过的主数据中心。永远不会！（开玩笑）

在数据中心/服务器停机的情况下，我只想确保以下几点：

•我将手动更新OBDC数据源以指向备份。然后前端将作为新的“prod”与另一个数据库协同工作。我会处理在电话中遇到问题的用户。事实上，他们可能甚至都不会打电话，他们会稍后再试

•这需要工作，直到我找出哪里出了问题，然后在备份和运行后将其指向第一个，并再次同步

•作为旁注，出现“停机”的最大原因是虚拟机出现问题

我可以释放多少数据（就时间而言）？ 如果它在写的中间崩溃，那就没什么大不了的。我可以手动清理

有多少数据在变化，变化速度如何？ 3-4个用户每小时会发生几次更改。但我有巨大的审计表，所以我们可以知道谁在什么时候改变了什么。这就是90%的存储来自表中，而日志只是令人讨厌的地方。我可以通过表格手动获取正确的数据，而无需日志

如果需要恢复，我能承受多少停机时间？ 几个小时。如果数据中心真的出现故障，那么这个系统并不是每个人都会担心的

如果数据因未备份而丢失，则复制数据有多困难？ 我可以手动恢复，但并不期待

我能花多少钱来满足这些要求？ 拉链。只是我的时间

一般来说，作为“证明”，我们已经做对了，我想运行以下测试：

•暂停运行prod1的虚拟机

•将ODCB数据源指向prod2

•在prod 2中进行一些更改

•解除虚拟机暂停，重新同步2个数据库

•将ODBC数据源指向prod 1

---

如果我能做到这一点，我觉得我已经顺利通过了要求

谢谢

如果日志文件处于“失控”状态，最常见的原因是数据库处于完整或大容量日志恢复模式，而没有进行常规日志备份。日志备份过程的一部分是截断日志。您多长时间做一次日志备份？如果不执行日志备份，则应考虑执行这些操作，或者将数据库更改为简单恢复模式。p> 在开发环境中，日志备份可能不是一个大问题，但在生产环境中，您应该有一个备份策略，允许正确恢复数据。确切的“最佳”灾难恢复策略取决于您的环境和应用程序。首先，您需要回答以下问题： 1.我可以释放多少数据（就时间而言）？ 2.有多少数据在变化，变化速度如何？ 3.如果需要恢复，我能承受多少停机时间？ 4.如果数据因未备份而丢失，则复制数据有多困难？ 5.我能花多少钱来满足这些要求

根据您的回答，您可以制定一个能够满足您需求的备份策略。如果问题1的答案接近于零，并且您的数据无法复制，那么不进行日志备份就进行夜间备份是没有好处的。另一方面，具有易于重新创建的数据的数据库可能是具有夜间备份的简单恢复模型的良好候选者

顺便说一句，镜像不是备份的替代品，它解决了另一个问题。如果有人不小心掉了一张桌子，镜像会很高兴地镜像d