Server选项/事务日志

Question

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

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

是时候把这个转变成一个“生产”环境了。由于空间关系，我们需要把这些原木保持得很小。

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

我们使用了大量的SQL，几乎每天都会进行模式更改。我相信您已经看到了一种场景，您在白板上添加了“让我们使用prod1和prod2，我们将开发和推出更改”，但是最终prod1作为dev结束了，没有人使用其他两个！

所以我的问题..。

三个服务器一个小组。Prod1，Prod2和dev。最好的博士策略是什么？

在保持良好的数据质量而又不牺牲敏捷性方面，应该有哪些过程/流程来做好工作呢？

任何关于这个主题的链接都会很有帮助。

谢谢!

*更新*

谢谢你的回应！大问题…。

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

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

这些数据并不是说我们需要一个负载均衡器，它几乎没有负载。主要问题和最高优先级是数据完整性。我们的系统有一个从未中断过的主数据中心。永远也不会！(开玩笑)

在发生数据中心/服务器中断的情况下，我只想得到以下保证：

·我将手动更新OBDC数据源以指向备份。然后前端将作为新的“prod”来对抗另一个数据库。我会处理那些在电话上有问题的用户。事实上，他们可能不会费心打电话，他们会再试一次。

·这需要工作，直到我找出出了什么问题，然后把它指向第一个备份和运行后，并再次同步。

·顺便提一句，会出现“停机”的最大原因是VM是否存在问题。

1. 我能提供多少数据(就时间而言)？如果它在写的过程中崩溃了，那也没什么大不了的。我可以手动清理。
2. 有多少数据在变化，以什么速度变化？每小时由3-4个用户进行几次更改.但我有庞大的审计表，这样我们就可以知道谁在什么时候改变了什么。这就是90%的存储来自于表中的地方，日志就是烦人的。我可以手动获得数据与表，而没有日志。
3. 如果需要恢复，我能负担多少停机时间？几个小时。如果有一个真正的数据中心停机，这个系统不是每个人都会担心的。
4. 如果由于不备份而丢失数据，那么复制数据有多困难？我可以手动恢复它，但不期待它！
5. 我可以花多少钱来满足这些要求？拉链。只是我的时间。

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

·暂停运行prod1的VM

·将ODCB数据源指向prod2

·对prod 2做几处改动

·取消VM暂停，重新同步2个数据库

·将ODBC数据源指向prod 1。

如果我能做到这一点，我觉得我已经通过了非常出色的要求。

谢谢!

Answer 1

有几种DR策略。有些处理HA (高可用性)，另一些处理严格的博士每晚备份和每小时记录备份是一个相当不错的DR策略，这取决于您的数据更改的频率。

这里有一些很好的链接

SQL AlwaysOn

SQL事务复制

如何处理不同的环境。如果我有两个防弹盒的话。我可能会把它们都放在负载平衡器后面。取决于它们的功能；如果它们或多或少是只读数据库，那么可能是事务复制。如果他们做了大量的写作，那么我将确保我们有某种与AlwaysOn相结合的会话粘性功能来保持这两个系统的同步。

要从"Dev“环境中部署数据库，我将确保部署前的proc和schema更改会创建某种更改脚本。使用类似于ORM的实体框架或nHibernate将使您能够通过数据库迁移来做到这一点。如果您所处的环境不使用类似的工具，那么Redgate的一些东西可能会起作用，比如：DLM自动化套房

Answer 2

如果日志文件处于“失控”状态，最常见的原因是数据库处于完整或批量日志恢复模式，而不执行常规日志备份。日志备份过程的一部分是截断日志。您多久做一次日志备份？如果不进行日志备份，则应该考虑执行这些备份，或者将数据库更改为简单的恢复模型。

在开发环境中，日志备份可能不是什么大问题，但是在生产中您应该有一个允许正确恢复数据的备份策略。确切地说，什么是“最佳”DR策略取决于您的环境和应用程序。首先，你需要回答的问题是: 1.我有多少数据可以松散(就时间而言)？2.有多少数据在变化，以什么速度变化? 3.如果需要恢复，我能负担多少停机时间? 4.如果数据因不备份而丢失，复制数据有多难? 5.我能花多少钱来满足这些要求？

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

顺便说一句，镜像不是备份的替代品，它解决了另一个问题。如果有人意外地丢弃了一个表，镜像将很高兴地将该放置镜像到备用服务器。镜像可以防止许多硬件故障，但不能防止操作错误或用户错误。你最好还是准备好备份。