简单恢复模式下，日志文件的增长

 

     最近公司要把两个sql sever 2005 数据库合并成一个数据库，一个数据库26G，一个数据库31G。这只是mdf文件，不是ldf文件。在合并之前就考虑到了日志文件会很大，但是没有想到这么大 。

      把数据库设置成简单恢复模式，日志文件照样非常大。简单恢复模式并不等于没有或者很少的日志量。

      当我使用默认的设置即日志文件的设置（初始大小1M，自动增长为10％，增长没有限制），数据文件的设置（初始大小2G，自动增长为1M，没有限制），因 为我合并的数据库比较大，数据量也较大，当用这种设置的时候，日志文件就很大，我为日志文件留下了100G的空间，还是不够用，因为我跑数据是在晚上跑 的，当我第二天来看的时候，日志文件已经还原到了504K，奇怪怎么日志文件会自动恢复到原始大小，当日志文件占用了整个磁盘的时候。当我查看sql 的日志记录，或者是系统日志的时候有记录。说磁盘空间不足，日志恢复到0。

这是我在sql server 2005 中的截图

 

 

 

错错误编号: 5144级别:10
数据库 '%3!' 中文件 '%1!' 的自动增长 在 %5! 毫秒后已取消或出现超时。使用 ALTER DATABASE 设置更小的 FILEGROWTH 或设置新的大小。2052

这个问题说明要求数据库 立即分配 xx MB 的存储空间用于满足你的处理需求,但数据库 在 xx 毫秒无法完成这个分配.难道这个错误

     分析：当我使用默认的文件设置的时候，mdf文件每次增加1M，初始文件2G。如果我把初始值改为20G 。这样就避免了数据处理时候频繁分配空间。也节省了时间。预先为它分配足够的空间。日志文件也是分配。

     测试结果：日志文件没有突破100G，90G。看来这样的设置是比较有用的。

     这个设置只是针对频繁导入大量数据，在短时间内。

    checkpoint 的理解：

通 常数据库在提交(commit) 完成之前先要保证日志都要写到日志文件中去，而脏数据保存到数据缓存中，然后在分批写入数据文件中（也就是磁盘中）。日志的写入和提交是同步的，数据的写 入和提交不是同步的。当数据库崩溃时候，或者是一些其他原因使得数据库停止工作，可能有些数据还在缓存中，没有提交到数据库文件。为了保证数据的一致性， 需要把数据恢复到崩溃之前的状态。

   在这个恢复的过程中，并不是所有的数据都需要恢复的，为了定位恢复的切入点，这就要用到checkpoint 这个概念。通过它来确定那些日志需要重新做恢复。