SQL大型事务日志备份与修复问题

核心提示： 如果您运行的是异步数据库镜像，则可能会存在尚未从主体数据库发送到镜像服务器的事务日志记录储备(称为数据库镜像 SEND 队列)，SQL大型事务日志备份与修复问题(4)，这些事务日志记录在成功发出之前无法被释放，如果生成了大量事务日志记录，因为它的着眼点不是挽救用户数据，“修复&

如果您运行的是异步数据库镜像，则可能会存在尚未从主体数据库发送到镜像服务器的事务日志记录储备(称为数据库镜像 SEND 队列)。这些事务日志记录在成功发出之前无法被释放。如果生成了大量事务日志记录，而网络带宽又受到限制(或出现其他硬件问题)，则储备可能会变得很大，导致事务日志不断增大。

最后，如果用户启动了一个显式事务(如使用 BEGIN TRAN 语句)，然后进行了某些形式的修改(如 DDL 语句或插入/更新/删除操作)，则所生成的事务日志记录在用户提交或回滚该事务前都需要进行保留。这意味着由其他事务生成的任何后继事务日志记录也无法被释放，因为事务日志无法选择性地进行释放。如果假设该用户当天没有结束该事务就下班回家了，则随着越来越多的事务日志记录被不断生成而又无法释放，事务日志就会越来越大。

要了解事务日志无法释放的原因，可以查询 sys.databases 系统目录视图并查看 log_reuse_wait_desc 列，类似于下面所示：

SELECT name AS [Database],
　log_reuse_wait_desc AS [Reason]
FROM master.sys.databases;

如果证明是由于某个活动事务所导致的，可使用 DBCC OPENTRAN 语句获取有关该事务的更多信息：

DBCC OPENTRAN ('dbname')

问：我听说在从损坏进行恢复时，不到万不得已不要使用 REPAIR_ALLOW_DATA_LOSS;而应先使用备份进行还原。您是否能解释一下为什么不应使用 SQL Server 2005 的修复功能，以及为什么在使用时要考虑“危险”程度?

答：首先，我确实编写过有关 SQL Server 2005 修复的文章。REPAIR_ALLOW_DATA_LOSS(以下简称为“修复”)的问题在于其工作方式不是很清晰。之所以这样命名此“修复”正是为了说明运行它可能会导致数据库中的数据丢失。此功能修复损坏的数据库结构的方式通常是先删除损坏的结构，然后修复数据库中的其他所有内容(引用已删除结构的或被已删除结构引用的)。在保持数据库结构一致性方面，“修复”的确是不到万不得已不推荐使用的方法，因为它的着眼点不是挽救用户数据。“修复”不会故意去删除用户数据，但它也不会主动去挽救用户数据。