zoukankan      html  css  js  c++  java
  • SQL 2008 R2数据库变为REPLICATION,日志不断增长并且不能截断和收缩的解决方式

    

    执行环境:windows server2003sql server2008 R2,数据库上布置CDC

     

    用户反应系统报错是日志已满,系统不能执行。

    查看日志文件时。发现日志文件已经达到15G,后来为了解决这个问题,干脆把数据库移到还有一个F盘,D盘专门放日志文件。空间有80G

    当时想这80G至少保证系统执行一周吧。谁知道系统刚执行两天。日志文件已爆涨到80GD盘空间仅剩余10MB。数据库做不论什么动作都不能够。

    重新为了应急把日志文件直接删除(先停掉服务,删除日所文件,再通过DBCC CheckDB()命令检查数据库一致性问题),系统恢复了正常。

    这时空间是有了,可是问题依然没有解决。可是日志文件依然猛涨。曾经用的截断和收缩日志方法全然不起作用?

     

    解决方法:

    步骤一:

    查看日志信息,在查询分析器中执行例如以下代码来查看日志信息:

    DBCC LOGINFO('数据库名称')

    能够看到status=0的日志,代表已经备份到磁盘的日志文件;而status=2的日志还没有备份。当收缩日志文件时,收缩掉的空间事实上就是 status=0的空间,假设日志物理文件无法减小,这里一定能看到许多status=2的记录。

     

    步骤二:

    查看日志不能截断原因

    活跃(active)的日志无法通过收缩来截断。有各种原因会使日志截断延迟,详细表现就是事务日志的物理文件无法通过截断、收缩来减小,通过以下的代码能够看到实例上每一个数据库的日志截断延迟原因:

    usemaster

    go

    select*from sys.databases

    发现当前数据库的log_reuse_wait_desc的值为REPLICATION,其它数据库的log_reuse_wait_desc值为LOG_BACKUPNOTHING…

     

     

    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

    正在进行日志扫描(全部恢复模式)。

    这是日志截断延迟的常见原因。通常也是主要原因。

     

    针对延迟日志截断原因的部分解决方式,

    LOG_BACKUP

    备份日志后再执行收缩就可以。

     

    REPLICATION

    这是我遇到的情况,但我根本没有启用过REPLICATION。是已离职同事原来创建一个复制数据库,后来没有删除干净而导致。还有还有一说法,这好像是SQLSERVER2008的一个BUG,解决方法是给标有“REPLICATION”的数据库随意一个表创建数据库事务复制(TRANSACTIONREPLICATION)。然后再删除,执行数据库与日志备份后,经常使用以下的日志收缩方法就能够完毕收缩:

    USE [master]
    GO
    ALTER DATABASE 数据库名 SET RECOVERY SIMPLE WITH NO_WAIT
    GO
    ALTER DATABASE 数据库名 SET RECOVERY SIMPLE --简单模式
    GO
    
    USE 数据库名
    GO
    DBCC SHRINKFILE (N'数据库名_Log' , 5, TRUNCATEONLY)   -->參数二(5)就是压缩到指定大小
    GO
    
    USE [master]
    GO
    ALTER DATABASE 数据库名 SET RECOVERY FULL WITH NO_WAIT
    GO
    ALTER DATABASE 数据库名 SET RECOVERY FULL --还原为全然模式
    GO


     

    附加:在创建数据库复制时,我也遇到了一个大麻烦,提示:在执行 xp_cmdshell 的过程中出错。调用 'CreateProcess' 失败,错误代码: '5'。使用了各种方法,均无效果。后来在网上找一个帖子说有可能是系统安装360的原因而导致,我就把把360先停掉,结果真的解决这个问题了。

     

     

  • 相关阅读:
    修改数据库的兼容级别
    如何写出安全的API接口
    最新IP地址数据库
    java 中的静态(static)代码块
    Java RTTI(类型信息)(.class 类对象)
    机器学习之决策树预测——泰坦尼克号乘客数据实例
    敏捷开发 —— TDD(测试驱动开发)
    Java 内存泄漏
    红顶商人 —— 胡雪岩
    各地特色美食与点菜的艺术
  • 原文地址:https://www.cnblogs.com/yjbjingcha/p/8400392.html
Copyright © 2011-2022 走看看