SQL Server 数据库 Suspect 解决案例

  次阅读 作者:智能小宝 来源:互联网 2016-02-16 10:35 我要评论(0)

生产环境:

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层面downtime,在Ticket中录入大概发生时间,事件描述,最近有没有发生过任何变更事件。如果没有Ticket系统,请群发email给相关人员。电话IncidentManager管理所有的事件更新,这样做的好处:使惊慌失措的人们知道发生了什么,减少他们的压力。

整理一下自己

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

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

6:40 am查找到最初的错误,发生在成功的 Log backup以后的1分钟,错误信息显示:OS Error导致了LogWriter的logflush (写日志)失败。不能写日志会导致数据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(failedto 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' isnotavailable. Check the event log for related error messages. Resolve anyerrors andrestart 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 把数据库恢复到一致性上(consistentrecover)。如果 log有问题, 那么它 会重建 log ( 个人认为这就是repair allow data loss的意思) .对于一个100GB以上的数据库, rebuild log可能花费数小时,考虑到recovery time object (RTO)和 SLA (service levelagreement) , 都不允许数据库 downtime 很久 (事后的反思)。幸运的是不能alter database,错误信息直接指明了databaselog locked, 暗示了数据库 log可能没有 corrupt, 那么没有必要着急dbcc repair了。

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

第二次尝试 迁移日志文件

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

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

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

建立问题

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

本站文章信息来源于网络以及网友投稿,本站只负责对文章进行整理、排版、编辑,是出于传递更多信息之目的,并不意味着赞同其观点或证实其内容的真实性。如果您有什么意见或建议,请联系QQ28-1688-302!

人工智能实验室
相关文章相关文章
  • 无人驾驶汽车如何改变城市生活?听听他们怎么说

    无人驾驶汽车如何改变城市生活?听听他们怎么说

  • 韩春雨称已能重复实验结果 近期将有消息公布

    韩春雨称已能重复实验结果 近期将有消息公布

  • 英国研发“杀生”机器人 通过生命体获取能量

    英国研发“杀生”机器人 通过生命体获取能量

  • 未来两年人工智能要怎么走?看这篇就够了

    未来两年人工智能要怎么走?看这篇就够了

网友点评网友点评
阅读推荐阅读推荐

据国外媒体报道,在过去两年内,聊天机器人(chatbot)、人工智能以及机器学习的研发和采用取得了巨大进展。许多初创公司正利用人工智能和...

霍金 视觉中国 图 英国著名物理学家霍金(Stephen Hawking)再次就人工智能(AI)发声,他认为:对于人类来说,强大AI的出现可能是最美妙的...

文|郑娟娟 今年,人工智能(AI) 60岁了。在AI60岁的时候,笔者想要介绍一下AI100,一个刚刚2岁的研究项目,但它的预设寿命是100年,甚至更长...

AlphaGo与李世石的人机大战,为大众迅速普及了人工智能的概念。 但对谷歌而言,除了下围棋,现在的人工智能进展到哪一步了?未来,人工智能...