登录  /  注册

SQL Server数据库Suspect解决案例

php中文网
发布: 2016-06-07 15:05:58
原创
1210人浏览过

欢迎进入Windows社区论坛,与300万技术人员互动交流 >>进入 生产环境: SQL Server 2008 R2 Active/Passive Nodes,Windows Server 2008 R2 SP1 Cluster, vSphere 5.x 发生起始 6 am 接到Application Team报告 BiztalkMsgBoxDb进入suspect模式,不可以访问。

欢迎进入windows社区论坛,与300万技术人员互动交流 >>进入

  生产环境:

  SQL Server 2008 R2 Active/Passive Nodes,Windows Server 2008 R2 SP1 Cluster, vSphere 5.x

  发生起始

  6 am 接到Application Team报告 BiztalkMsgBoxDb进入suspect模式,不可以访问。

  报告事件,减少用户压力

  简单的和App Manager电话了下,了解他们Apps层面down time,在Ticket中录入大概发生时间,事件描述,最近有没有发生过任何变更事件。如果没有Ticket系统,请群发email给相关人员。电话Incident Manager管理所有的事件更新,这样做的好处:使惊慌失措的人们知道发生了什么,减少他们的压力。

  整理一下自己

  6:30 am很多人的电话总让自己神经紧张,简单的brainstorm一下suspect可能发生的原因:文件组(数据和日志)的损坏?磁盘爆满/SAN Disk出错?备份还在吧?

  察看Error Log,定位起始出错信息

  6:40 am查找到最初的错误,发生在成功的 Log backup以后的1分钟,错误信息显示:OS Error导致了LogWriter的log flush (写日志)失败。不能写日志会导致数据suspect.

  2014-03-17 03:15:56.05 spid5s      Error: 17053, Severity: 16, State: 1.

  2014-03-17 03:15:56.05 spid5s      LogWriter: Operating system error1117(failed to retrieve text for this error. Reason: 15105) encountered.

  2014-03-17 03:15:56.05 spid5s      Write error during log flush.

  2014-03-17 03:15:56.05 spid79      Error: 9001, Severity: 21, State: 4.

  2014-03-17 03:15:56.05 spid79      The log for database 'BizTalkMsgBoxDb' isnot available. Check the event log for related error messages. Resolve anyerrors and restart the database.

  2014-03-17 03:15:56.05 spid85      Error: 9001, Severity: 21, State: 4.

  分析错误:

  1117 OS错误,有关磁盘。日志文件还在,磁盘没有满。可以考虑对log file迁移。

  第一次尝试 DBCC Repair

  (任何尝试的基础都是要明白:你的动作,不会使情况变得更糟糕)

  命令 ALTER DATABASE [xxxxxx]SET EMERGENCY;

  命令出错, 数据库被锁,不能alter database ,直接放弃DBCC CHECKDB (N'xxxxxxx', REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS;修复。

  为什么要放弃: DBCC Repair 要求数据库在 emergency模式下,它会试图利用现有log 把数据库恢复到一致性上(consistent recover)。如果 log有问题, 那么它 会重建 log ( 个人认为这就是repair allow data loss的意思) .对于一个100 GB以上的数据库, rebuild log可能花费数小时,考虑到recovery time object (RTO)和 SLA (service level agreement) , 都不允许数据库  downtime  很久 (事后的反思)。幸运的是不能alter database,错误信息直接指明了database log locked, 暗示了数据库 log可能没有 corrupt, 那么没有必要着急dbcc repair了。

  事后反思,武断的认为log file corrupted 是错误的,dbcc  repair作为 methodology 的第一步也是不合时宜的,应为没有向用户确认是否可以丢失过去15分钟的active transaction (虽然客户还在睡觉) ( 每15 分钟的事务日志备份),更何况它还会让数据库  downtime更久,8点上班前未必恢复的了,可能都没有database backup restore快。作为methodology第一步应该首先确认是否file corrupted 并且联系server team是否有IO异常。

  第二次尝试 迁移日志文件

  遇到 resource lock 的问题,通常的 第一反应都是kill 或者 重启资源。这里限于自己技能不足或者没有建立正确的methodology,第一时间发现不了lock的资源,所以选择了重启资源

  应为是Windows Cluster,所以不用detach/attach数据库,直接failover到passive server,数据库在failover后等效的重起和实例恢复了。现在日志文件可写,数据库恢复到Active.

  暂时解决了问题,然后将数据库switch over到原来的 active服务器。没有出错,证明不是磁盘本身的问题。可能是磁盘接口问题。同时查看了event viewer除了log backup没有发现其他。Sp_who2也没有发现可疑的database lock排除了数据库进程锁住数据库或者logfile.

  建立问题

  7 am,让Server Team检查磁盘,怀疑EVA SAN出问题。 现在只知道起始错误和解决方法。作为一个问题,留给Problem Manager继续更进,用来避免以后发生同样的问题。

  总结:遇到 log file  导致的 数据库挂起,解决方法学首先是(1)确认磁盘问题,然后是(2 ) 确认数据库process lock,然后是(3)确认是否 corrupt,  这些 check up 做完后再针对(1) (2)(3) 提出解决方案。从(1) 到 (3)严重性也越高, 所以恢复后数据丢失的可能性也越高。要和客户确认在线修复的风险。最后的稻草自然是平时完备的数据备份方案和定期的数据库恢复执行计划。

SQL Server数据库Suspect解决案例

智能AI问答
PHP中文网智能助手能迅速回答你的编程问题,提供实时的代码和解决方案,帮助你解决各种难题。不仅如此,它还能提供编程资源和学习指导,帮助你快速提升编程技能。无论你是初学者还是专业人士,AI智能助手都能成为你的可靠助手,助力你在编程领域取得更大的成就。
来源:php中文网
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn
最新问题
关于CSS思维导图的课件在哪? 课件
凡人来自于2024-04-16 10:10:18
热门教程
更多>
最新下载
更多>
网站特效
网站源码
网站素材
前端模板
关于我们 免责申明 意见反馈 讲师合作 广告合作 最新更新
php中文网:公益在线php培训,帮助PHP学习者快速成长!
关注服务号 技术交流群
PHP中文网订阅号
每天精选资源文章推送
PHP中文网APP
随时随地碎片化学习
PHP中文网抖音号
发现有趣的

Copyright 2014-2024 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号