在SQL 2005中，您应该不对启用了日志传送的数据库执行哪些操作（并且在完全恢复模式下运行）？
我认为将其他事务日志备份安排到其他位置会破坏日志传送（因为完整的日志链不再到达辅助服务器）。
我还认为Truncate Table可以使用日志传送（自Sql 2000起）。
是否还有其他应该避免的活动/命令？
编辑：例如数据库收缩或日志收缩好吗？
答案 0 :(得分：6)
你是对的。您不应在日志传送配置之外定义任何其他事务日志备份，以确保维护自然日志序列。
如果您希望执行Ad-Hoc事务日志备份，天堂禁止，因为您正在对生产数据库执行一些实时维护，然后您可以调用日志传送用于执行事务日志的SQL Server作业备份。它通常称为LS_Backup。这将维持LSN。
据我了解，使用此可用性技术不会限制日志传送数据库的操作功能。
可能导致并发症的一些事情：
加密
如果您将日志传送到另一台服务器并使用SQL Server本机加密，那么除非SQL Server使用相同的服务主密钥，否则您将无法访问日志传送数据库中的加密数据。
装配
在日志传送的数据库中访问已签名的程序集可能会遇到困难，因为您无法启用可信赖的属性。
<强>权限
如果您打算提供对Log Shipped数据库的读取权限，则SQL Server登录需要与源服务器具有相同的SID，以便登录能够自动正确映射。
希望这会有所帮助。欢呼声。
答案 1 :(得分：2)
数据库/日志增长/收缩很好，它们将被运送过来，备用数据库也会增长/缩小。我唯一知道的就是破坏事物：
使用TRUNCATE_ONLY备份日志
更改恢复模式
使主数据库脱机（不确定这个，从未尝试过）
其他一切都很好，但是大量的REINDEXES可以制作一些在大型数据库上难以处理的非常大的日志。