在关系数据库系统中，我们需要数据库可靠，所谓的可靠就是当遇见如下两种情况之一时保证数据库的一致性:在系统崩溃/故障等情况下，保证数据库的一致性

数据不能在多个DML语句同时修改数据的情况下，导致不一致或数据损坏

实际上，上述第二种情况就是并发性所需要解决的问题，传统关系数据库中，我们用锁来解决这个问题，而对于内存数据库或带有乐观并发控制的数据库系统，通过多版本并发控制(MVCC)来解决这个问题。因为本篇文章的主旨是讨论日志而不是并发，因此对于上述第二种情况不会详细解释。

我们上面还多次提到了一致性(Consistence)，在开始了解日志如何维持一致性之前，我们首先要明白什么是一致性。一致性在数据库系统中所指的内容比较广，一致性不仅仅需要数据库中的数据满足各种约束，比如说唯一约束，主键约束等，还需要满足数据库设计者心中的隐式约束，简单的业务约束比如说性别这列只允许男或女，这类隐式约束通常使用触发器或约束来实现，或是在数据库所服务的应用程序中进行约束。

下面我们把一致性的范围缩减到事务一致性，事务一致性的概念学术上的解释为：如果事务执行期间没有出现系统错误或其他事务错误，并且数据库在事务开始期间是数据一致的，那么在该事务结束时，我们认为数据库仍然保证了一致性。

因此，引申出来事务必须满足原子性，也就是事务不允许部分执行。事务的部分执行等同于将数据库置于不一致的境地之下。此外多事务并发执行也可能导致数据库不一致，除非数据库系统对并发进行控制。

关于上面的显式约束，由数据库系统来实现，比如说违反了一致性约束的语句会导致数据库系统报错并拒绝执行。但一些隐式的事务约束，比如说写语句的开发人员对系统设计者所设计的规则并不了解，导致了违反业务规则的数据修改，这种情况在数据库端很难探查。但是这种问题通常可以规则到权限控制的领域，我们认为授予某个用户修改特定数据的权限，就认为这个用户应该了解数据库中隐式和显式的规则。

除去这些业务上的数据不一致之外，我们需要在系统崩溃等情况下保证数据的一致性，而可能导致这类数据不一致的情况包括但不限于下面这些情况：存储系统损坏，比如说磁盘上字节级别的损坏，这类问题通常可以通过磁盘上的奇偶校验发现，另外还有一些大一些的问题，比如说整个存储系统崩溃。这类问题的修复手段取决于前期工作，比如说备份策略，高可用性架构，SAN Replication等技术。

机房整体损坏，这类问题比较极端，只有异地机房容灾可以解决。

系统故障，修改数据的进程都需要事务作为上下文，和其他概念一样，事务也是有状态的。而事务状态通常存储在易丢失的主存中，因此，当出现系统故障、进程崩溃等系统失败时，可能导致事务状态的丢失，此时，我们就无法得知事务中的哪部分已经执行而哪部分还未执行，重新运行事务并不会解决这类问题，因为有可能导致事务中某部分的重复执行。因此解决这类问题的方式就是将事务的状态以及对数据库修改的详细步骤与内存中的数据分开存放，并存储于磁盘等稳定的介质中，当系统故障等情况下，我们可以通过这些记录来将系统恢复到一致性的状态之下，我们对这类存储，称之为日志。

---------------------------------回答正文-------------------------------

SQL Server中日志主要用于下面三个部分：事务回滚(Rollback)

事务前滚(Roll Forward)

帮助数据冗余(利用事务日志进行备份，搭建冗余系统，在SQL Server中指的是镜像、事务日志传送、复制、AlwaysOn等技术，或者其他第三方利用SQL Server日志同步数据的技术)

SQL Server还提供了两种恢复模式：简单模式和完整模式

简单模式指的是日志被不在被当前未结束事务需要后，就可以回收重复利用。

完整模式指的是日志被不在被当前未结束事务需要后，就可以留着等待将这部分日志归档(日志备份)

而楼主使用的是简单恢复模式，不存在忘记备份日志导致日志越来越大的问题。因此可能造成日志越来越大的原因主要是：

1.当前存在活动日志，这个可以使用DBCC OPENTRAN命令查看是否有当前活动日志导致日志无法截断。

2.当前库用于复制，因为日志需要被复制的Log Reader进程读取，在读取之前日志是无法被清理掉的，原因可以通过sys.databases的log_resue_wait列查看到原因。

3.日志之前曾经因为大的操作暴涨，忘记收缩，尝试直接收缩一下日志。

---------------------------------------------------------------

CheckPoint通常没用，因为SQL Server会定期CheckPoint，而楼主貌似问题存在一段时间了。

另外，删了日志再附加会有风险，假如数据库当前没有活动事务时，你删了文件，这就是所谓的clean shutdown，不会有问题，但加入当前有事务产生的数据需要被rollback或roll forward,那么日志文件的缺失会导致SQL Server无法做数据库的recovery,因此数据库会质疑，如果数据库比较重要，那么存在风险。