故障介绍：
在日常的维护中我们经常会碰到数据库日志异常庞大的问题，这样会导致数据库读写非常缓慢。通常我们会采取数据库日志收缩功能来缩小日志的占用空间，这种方式可以处理一部分的故障。还有一部分是怎么收缩都是不起作用。
减小数据库日志大小的方法：
1.没有做数据库镜像的数据库，且恢复模式为完整的。可以将数据库的恢复模式改成简单，然后再去收缩日志。
(建议项目上没有做数据库镜像的都将恢复模式改成简单，这样可以让日志不增长成那么巨大)
2.如果做了上面的操作还是没有把数据库日志变小，执行语句查询log_reuse_wait_desc的状态，然后根据下面提供的表查看日志延迟截断的原因。一般出现最多的原因会是LOG_BACKUP或者REPLICATION。如果是LOG_BACKUP则是没有备份日志，可以将数据库的日志完整备份一次，再去做日志的收缩，这样就可以将日志缩小。如果报的是REPLICATION（这种情况经过很多的查询，说是sql2008的一个bug，在这次广州肿瘤医院的问题处理中就遇到这种）最后缩小的方法是在查询分析器里执行EXEC sp_removedbreplication dbname
这个存储过程，然后再执行日志收缩就解决了。
解决方案
查看日志信息
在查询分析器中执行如下代码来查看日志信息：
1 DBCC LOGINFO('数据库名称')
我们看到status=0的日志，代表已经备份到磁盘的日志文件；而status=2的日志还没有备份。当我们收缩日志文件时，收缩掉的空间其实就是status=0的空间，如果日志物理文件无法减小，这里一定能看到非常多status=2的记录。接下来分析为什么会有这么多status=2的记录
查看日志截断延迟原因
活跃(active)的日志无法通过收缩来截断，有各种原因会使日志截断延迟，具体表现就是事务日志的物理文件无法通过截断、收缩来减小，通过下面的代码可以看到实例上每个数据库的日志截断延迟原因：
USE [master]
SELECT [name] ,[database_id] ,[log_reuse_wait] ,[log_reuse_wait_desc] FROM [sys].[databases]
各种原因及解释如下：
log_reuse_wait_desc 值 说明
NOTHING 当前有一个或多个可重复使用的虚拟日志文件。
CHECKPOINT 自上次日志截断之后，尚未出现检查点，或者日志头部尚未跨一个虚拟日志文件移动（所有恢复模式）。
这是日志截断延迟的常见原因。有关详细信息，请参阅检查点和日志的活动部分。
LOG_BACKUP 需要日志备份，以将日志的头部前移（仅适用于完整恢复模式或大容量日志恢复模式）。
注意：
日志备份不会妨碍截断。
完成日志备份后，日志的头部将前移，一些日志空间可能变为可重复使用。
ACTIVE_BACKUP_OR_RESTORE 数据备份或还原正在进行（所有恢复模式）。
数据备份与活动事务的运行方式相同。数据备份在运行时，将阻止截断。有关详细信息，请参阅本主题后面的“数据备份操作与还原操作”部分。
ACTIVE_TRANSACTION 事务处于活动状态（所有恢复模式）。
一个长时间运行的事务可能存在于日志备份的开头。在这种情况下，可能需要进行另一个日志备份才能释放空间。有关详细信息，请参阅本主题后面的“长时间运行的活动事务”部分。
事务被延迟（仅适用于 SQL Server 2005 Enterprise Edition 及更高版本）。“延迟的事务 ”是有效的活动事务，因为某些资源不可用，其回滚受阻。有关导致事务延迟的原因以及如何使它们摆脱延迟状态的信息，请参阅延迟的事务。
DATABASE_MIRRORING 数据库镜像暂停，或者在高性能模式下，镜像数据库明显滞后于主体数据库（仅限于完整恢复模式）。
有关详细信息，请参阅本主题后面的“数据库镜像与事务日志”部分。
REPLICATION 在事务复制过程中，与发布相关的事务仍未传递到分发数据库（仅限于完整恢复模式）。
有关详细信息，请参阅本主题后面的“事务复制与事务日志”部分。
DATABASE_SNAPSHOT_CREATION 正在创建数据库快照（所有恢复模式）。
这是日志截断延迟的常见原因，通常也是主要原因。
LOG_SCAN 正在进行日志扫描（所有恢复模式）。
这是日志截断延迟的常见原因，通常也是主要原因。
综上所述，是处理遇到这类问题的一些解决方案。
痛定思痛在以后的项目实施中要注意的几点：
1.如果医院没有做数据库镜像的可以在初始库的时候将数据库恢复模式改成简单。这样就不要任何的维护日志都不会无限制增长。当然这样做的弊端是当数据库出现误操作或误删除后无法通过日志还原误操作前的数据，所以需要保证在日常操作的时候要小心。并且这种模式下维护计划每天至少要备份2次数据库。
2.如果医院做了数据库镜像或者其他原因需要将数据库模式固定为完整模式的时候，一定要做好数据库的维护计划，首先一周之内备份一次完整的数据库日志，然后再进行数据库日志的收缩计划。（做计划的时候一定要记得加上清除老备份的计划，日志保存1个月内的，bak备份保存至少5天的。）
这样做的目的是让数据库日志能够定期备份截断，不至于让日志文件变无限制增长。
其他相关故障和解决方案，欢迎大家整理交流！
评论区