关于事务日志的一些疑问
事务日志是用来存放日常操作备份的。现在我这里有两个数据库服务器（A、B），数据库大小都是30G左右，两个服务器的访问量相当。

服务器A的事务日志增加得非常快，每天都增加10G左右，服务器B的就稳定在2G左右。看看设定，A和B都限定了Transaction   Log最大值20G，但是A不断增加，早就超过了这个数值。我现在不得不设定一个任务给A，每天清理这些增加的事务日志。

问题一：
如果让A的事务增加速度下降。我听说可以设定上限，然后到达上限就会自动reuse开头的数据空间，可是我不知道如何做。

问题二：
设定事务日志最大值无效，原因何在。

问题三：
sys.databases里面有log_reuse_wait这一列属性，请帮忙解释一下下列属性的用处。我看过了msdn，但是上面讲得也不是很清楚，有看不明白的地方。最好有点例子配合说明。

Reuse   of   transaction   log   space   is   currently   waiting   on   one   of   the   following:

0   =   Nothing

1   =   Checkpoint

2   =   Log   backup

3   =   Active   backup   or   restore

4   =   Active   transaction

5   =   Database   mirroring

6   =   Replication

7   =   Database   snapshot   creation

8   =   Log   Scan

9   =   Other   (transient)

===========================================
问题的关键在于如何合理使用事务日志。如何清理和备份日志不是问题所在，那个我已经排了工作，每周都会自动进行的。

------解决方案--------------------
恢复模式不一样吧？
------解决方案--------------------
1:是否设定事务日志文件的大小上限和日志文件空间的重用并没有直接关系。这里首先要区分日志文件物理大小和逻辑使用。每一个日志文件其创建以后，就已经有一定的物理大小了，例如物理大小是500M。但这个物理大小可以增长或者收缩,例如按照每次200M大小增加，直到2000MB。而逻辑使用则是：当前的物理文件是否已经被完全占满。你所问的问题实际上是：如何在日志文件物理大小一定的情况下，能够在逻辑上重复使用其中部分空间记录事务日志。这需要做的事情是：截断事务日志。

简单的说，事务日志分为活动部分和非活动部分，对于非活动部分可以截断，从而能够重复使用其占用的物理空间。但被截断的事务日志必须是非活动的，而且其必须在和活动的事务日志不同的虚拟日志文件里。虚拟日志文件是事务日志可以被重复使用的单位，SQL Server引擎自动将每个物理文件划分成一系列虚拟日志文件。当事务日志被截断后，虚拟日志文件中的空间就可以重复使用了。通常这种重复使用发生在：逻辑日志文件的最后达到了物理文件的末尾，此时新的事务日志开始从物理文件的开头被截断部分重新记录。

则现在的问题成为：如何截断事务日志？这取决你的数据库恢复模式。如果使用的是简单恢复模式，则一旦出现某个虚拟日志文件中的日志都成为非活动的情况下，其会自动截断。而如果使用的是完全恢复模式或者大容量恢复模式，则只有在备份数据库事务日志时才会截断事务日志。

（2）
某些情况下，可能发生截断事务日志延迟。例如：
（1）事务日志文件正在被扫描；
（2）正在进行事务日志备份过程中
（3）数据备份或还原正在进行
（4）数据库镜像相关的问题：如果镜像尚未完成则会阻止截断日志。
（5）正在创建数据库快照。
（6）自上次事务日志被截断后未出现检查点。只有出现检查点情况下，才可能发生事务日志截断。
（7）复制：复制过程中，如果有事务日志仍然未被传递到发布服务器，则会阻止截断事务日志。
导致截断事务日志延迟的原因可以在sys.databases视图中的log_reuse_wait看到。例如，如果该列值为Log Scan，则表明由于日志文件正在被扫描，导致无法截断事务日志。
------解决方案--------------------
1.如果你设置了日志文件的上限，它物理上是不应该超过这个上限的，如你所说，它会说“The transaction log for database '数据库名 ' is full”。
2.恢复模式不要随便改，要看你的数据关键性和更新频率，简单恢复模式会无法使用日志备份前滚到故障点，建议你根据数据关键性，查看联机帮助里面的“恢复模型”选择一种你需要的模型。
3.同样，日志也是不能随便手工截断，也是看数据关键性，因为日志截断后那些已提交的非活动事务将会压缩掉，同样无法在恢复数据库后做前滚。
4.数据库A/B的日志增长量差异大，先看看两个库的恢复模型是否一致？再看两个库的事务类型是不是相差较大，例如数据库A是不是update、delete居多或者常有大量数据导入导出？