none
Full 模式下日志自动截断 RRS feed

  • 问题

  • sql2008R2,还原模型为:Full

    每天日志增长约7G左右,但是日志文件居然自动截断了 是为什么,在这期间我没有备份日志,也没有将还原模型改成简单。

    现象:

    我的数据库会在每天晚上跑一些JOB来接收大量的数据(将其它系统的数据插入到我的数据库中),每晚的日志增长大约是7G,但是早上我看日志使用率居然只有百分之零点几,

    我想知道为什么日志会被截断了呢?我想看日志截断记录应该查哪些系统对象呢?

    2012年11月13日 3:37

答案

  • 有查 sql server 的日志么?

    无论是更改数据库恢复模型,还是备份,在日志中有记录的,看看最近一段时间的日志确认一下

    • 已标记为答案 xx0605 2012年11月13日 7:23
    2012年11月13日 5:54

全部回复

  • Did you ever backup db? If not yet, sql will treat it as simple recovery mode.
    2012年11月13日 3:44
  • 有过数据库备份的,最近一次数据库备份是11-02号.

    2012年11月13日 4:49
  • 非常奇怪,关注一下

    给我写信: QQ我:点击这里给我发消息

    2012年11月13日 5:25
  • SELECT * FROM fn_dblog(null,null)

    你可以晚上将数据放入一张表然后第二天再查询一下看看最早的日志还在不在。

    另外你可以查一下MSDB LOG备份记录,SQL Server在FULL 模式下只有日志备份才可以截断LOG

    2012年11月13日 5:41
  • SELECT * FROM fn_dblog(null,null)

    你可以晚上将数据放入一张表然后第二天再查询一下看看最早的日志还在不在。

    另外你可以查一下MSDB LOG备份记录,SQL Server在FULL 模式下只有日志备份才可以截断LOG

    我查过 msdb.dbo.backupset 了的,里面的日志备份记录我都看过了,最近一次日志备份是11-05号

    近几天内没有日志备份的。

    2012年11月13日 5:50
  • 有查 sql server 的日志么?

    无论是更改数据库恢复模型,还是备份,在日志中有记录的,看看最近一段时间的日志确认一下

    • 已标记为答案 xx0605 2012年11月13日 7:23
    2012年11月13日 5:54
  • 我总结一下

    SELECT [End Time] FROM [sys].[fn_dblog](NULL,NULL)  看一下那个时间,最后一个事务的结束时间

    SELECT [database_name],[backup_finish_date],[recovery_model] FROM [msdb].[dbo].[backupset]  ORDER BY [database_name] DESC 每个数据库的最后备份时间

    看sql errorlog


    给我写信: QQ我:点击这里给我发消息

    2012年11月13日 6:06
  • 有查 sql server 的日志么?

    无论是更改数据库恢复模型,还是备份,在日志中有记录的,看看最近一段时间的日志确认一下

    邹老大,在这里看到你倍感亲切呀。。。。

    我看了sql server   的日志,里面没有这些记录,不过很奇怪,我查13号的居然从0点到9点之间没有任何记录在sqlserver 的日志里.

    而我们的作业都是从2点到8点之间运行的,白天不运行。

    2012年11月13日 6:12
  • 12号,11号都一样,在0点到9点之间有没日志记录

     我查看的是:Management-->Sql Server Logs -->Current-2012-11-09 17:23:00

    2012年11月13日 6:15
  • 估计job里面有task截断了日志。不过截断日志sql server的log好像有记录的。

    想不想时已是想,不如不想都不想。

    2012年11月13日 6:32
    版主
  • 日志自动被截断是从6号开始发生的,

    我查了下5号日志,里面有一条如下:

    Date  2012-11-5 9:43:33
    Log  SQL Server (Current - 2012-11-13 12:04:00)

    Source  Backup

    Message
    BACKUP failed to complete the command BACKUP DATABASE CC_1. Check the backup application log for detailed messages.

    跟这个有关么?

    5号当时备份日志的时候并没有提示出错的。

    因为从这之后我就没有备份过日志了

    从backupSet里查出来 5号的记录如下:

    CC_1-Transaction Log  Backup ZhL 2012-11-05 09:43:40.000 FULL 393 445A7826-44A6-42C1-839E-A9439190170C 388 1 1 1 1 1 1 1 NULL 4608 CC_1-Transaction Log  Backup NULL ZhL10 50 1600 32 0 1572264000052388100001 1572961000000028600001 1572961000000020300048 1572264000052386700001 2011-12-23 17:26:11.000 2012-11-05 09:43:40.000 2012-11-05 10:04:35.000 L 0 0 90 661 49217857536 NS 75 512 2052 196609 Chinese_PRC_CI_AS 0 FULL 0 0 0 0 0 0 0 0 0 0 CA98D040-143B-4F9F-93C1-82BA047F94D0 CA98D040-143B-4F9F-93C1-82BA047F94D0 NULL 939FB228-D7B2-4702-AD1A-AC0D007CFB5F FEC66C66-5968-43AA-A30A-E14B4FEFBE44 NULL NULL 49217857536


    • 已编辑 xx0605 2012年11月13日 6:38
    2012年11月13日 6:36
  • 哦,查到了,在5号有人把模式转换成简单,然后又立即转换成FULL了

    Date  2012-11-5 10:19:16
    Log  SQL Server (Current - 2012-11-13 12:04:00)

    Source  spid63

    Message
    Setting database option RECOVERY to SIMPLE for database CC_1

    Date  2012-11-5 10:19:24
    Log  SQL Server (Current - 2012-11-13 12:04:00)

    Source  spid63

    Message
    Setting database option RECOVERY to FULL for database CC_1

    而从这之后就没有全备过数据库了,所以才会自动截断。。。。

    阿弥陀佛.....

    2012年11月13日 6:42
  • 呵呵, 可以去抓人结案了
    2012年11月13日 6:46
  • 想查查这两条记录是谁操作的该怎么查呢?

    2012年11月13日 6:50
  • 好像是查不了,所有的蛛丝马迹都在sql errorlog 里了

    2012-11-12 21:16:47.36 登录          Login succeeded for user 'XXX'. Connection: trusted. [客户端: <local machine>]


    给我写信: QQ我:点击这里给我发消息

    2012年11月13日 7:08
  • 感谢各位的帮忙,问题解决,虽然不知道是谁干的,但至少我可以交差了哈。。。。。

    阿弥陀佛。。。。

    2012年11月13日 7:24
  • 善哉善哉

    给我写信: QQ我:点击这里给我发消息

    2012年11月13日 8:40