日志传送数据库的限制

Question

在SQL 2005中，您应该不对启用了日志传送的数据库执行哪些操作（并且在完全恢复模式下运行）？

我认为将其他事务日志备份安排到其他位置会破坏日志传送（因为完整的日志链不再到达辅助服务器）。

我还认为Truncate Table可以使用日志传送（自Sql 2000起）。

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

编辑：例如数据库收缩或日志收缩好吗？

Answer 1

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

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

据我了解，使用此可用性技术不会限制日志传送数据库的操作功能。

可能导致并发症的一些事情：

加密

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

装配

在日志传送的数据库中访问已签名的程序集可能会遇到困难，因为您无法启用可信赖的属性。

<强>权限

如果您打算提供对Log Shipped数据库的读取权限，则SQL Server登录需要与源服务器具有相同的SID，以便登录能够自动正确映射。

希望这会有所帮助。欢呼声。

Answer 2

数据库/日志增长/收缩很好，它们将被运送过来，备用数据库也会增长/缩小。我唯一知道的就是破坏事物：

使用TRUNCATE_ONLY备份日志

更改恢复模式

使主数据库脱机（不确定这个，从未尝试过）

其他一切都很好，但是大量的REINDEXES可以制作一些在大型数据库上难以处理的非常大的日志。