日志发送数据库的限制

Question

在SQL 2005中，您应该对启用了日志传送(并且在完整恢复模型下运行)的数据库进行而不是所做的事情？

我认为，将额外的事务日志备份调度到不同的位置会中断日志传送(因为完整的日志链不再到达辅助服务器)。

我还收集到截断表可以用于日志传送(自Sql 2000以来)。

是否还有其他应该避免的活动/命令？

编辑:例如，是数据库收缩还是日志收缩？

Answer 1

你是对的。您不应该在日志传送配置之外定义任何其他事务日志备份，以确保维护自然日志序列。

但是，如果您希望执行Ad事务日志备份，天堂将禁止执行，因为您正在对生产数据库执行一些实时维护--例如，您可以调用日志传送用于执行事务日志备份的SQL Server作业。它通常被称为LS_Backup。这将维持LSN。

据我所知，使用这种可用性技术并不会限制日志提供的数据库的操作特性。

有些事情会引起并发症：

加密

如果您正在将日志传送到另一台服务器，并且正在使用SQL server本机加密，则除非Server使用相同的服务主密钥，否则您将无法访问日志发送数据库中的加密数据。

程序集

由于无法启用可信任的属性，您可能在访问日志附带的数据库中的签名程序集时遇到困难。

权限

如果您打算提供对日志附带的数据库的读取访问，那么Server登录将需要具有与来自源服务器的相同的SID，这样登录才能自动正确地映射。

希望这能有所帮助。干杯。

Answer 2

数据库/日志增长/收缩很好，它们会被运送过来，待机状态也会增加/缩小。我唯一知道的就是：

用TRUNCATE_ONLY备份日志

改变恢复模式

使主数据库脱机(不确定此数据库，从未尝试过)

其他一切都很好，但是做大量REINDEXES可以生成一些很大的日志，而这些日志在大型数据库上很难处理。