注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

yinaje

龙游当空,方显神色 _ 尹燕杰

 
 
 

日志

 
 
关于我

【简介】 尹燕杰 《产品五部曲》著作者,产品经理体系-创始人。 职场:国美、思源、百度、用友...。 【过往】出生在边陲煤城鹤岗的矿工子弟, *年携古子共筹氏族文学437社友, *年因合江事件离别社友. *年创办_氏族社在线 06年创办产品经理体系 14年更新CPJLTX.COM 现工作于北京 Email:yinaje@163.com

网易考拉推荐

应用SQL Server 数据库的大型企业项目,遭遇灾难性恢复的解决方案  

2008-01-21 17:26:58|  分类: 【数据库】 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

应用SQL Server 数据库维护的大型企业项目,遭遇的灾难性恢复的解决方案

 

        [修复MSSQL m_SizeRec > 0 && m_SizeRec <= MAXDATAROW 错误]

                           Date : 2008-1-21    [Write By yinaje]

                                       

---前言:

写作此文的原因是和自己从事的职业有关吧, 前些日子在工作中遇到了个平时少为接触的数据修复问题。

在一个国内某大型公司的企业流通软件平台运行中,支持该项目的数据库出现了一些相关的错误,致使该平台的相关的运行流程不能走通,症结分析是数据库的误操作;该公司的计算机中心负责维护的程序员,将数据库备份后发到软件供应商[也就是我公司的研发部]。在此这个维护人员为恢复此项目,作对了两点:

一、在此项目应用的数据库出现错误时,及时的查出错误症状且备份数据库

二、在此未对数据库主观的处理,及时上报和对备份文件转交相关部门处理

为此要感谢该维护数据库的程序员的正确处理,而不是网上所说的不主动处理或是其他消极待工的话,为期解释的话语是如果出现误操作的情况,将对应用程序上的数据产生不可想象的后果。

 

---说明:

当时为了处理该问题,自己的一些处理办法与过程就简单的介绍一下[1,自己测试 2SQL帮助 3,上网需求同类异常],并尽量对数据库中真实数据得以还原; 在网上的相关文章中除了用友公司将给处理办法做了简要的处理过程的处理并详细说明外,其他的很少问津甚至在长篇大论过后,也得不到相应的解决办法[多为非‘对症下药’]

为此在事隔数月后,在给朋友的讲解中将以下案列及处理具体细节程上以供他祥。

 

{案例详尽接剖}

 

---前期

项目维护数据库的程序人员,当发现相关数据的无法解决后,在select *  from 某表执行后在消息中显示错误时判断为数据问题,且超出本人能够和应处理的日常数据库范围后

需在进行:

1,  数据库的备份及相关程序;

2,  及时与公司内程序使用人员和相关领导沟通解决办法;

3,  在超出维护范围后,联系软件供应商,和软件供应商的应用研发人员,并将相关的故障及说明附以文档形式一并转交,或在各种通讯工具中及时通讯互通有无。

 

---分析

当得到维护人员发来的数据库备份文件后,相关的操作在这里不加详细的介绍[高级程序员都有自己的一套解决办法,详细步骤后反而会被我此时的无用功所累]

 

 

首先,将应用的程序是否OK与使用方得到确认,是否为使用者的程序出现BUG

      或是数据库是否有过误操作,日志文件是否健全等。

其次,分析错误原因,测试和得到客户认可的修复或是更改操作的允许范围。

最后,将备份文件,还原在本地数据库,保存数据库备份[不要删掉,以备重复操作]

 

---测错:

//按相关的方式测试错误原因:

按例错误分析,主要症状为对业务数据处理的商品货位表查询出错,只能显示部分数据,有关的数据因被强行的写入[或是在索引范围之外的,等原因]出现的数据槽偏移[日志出错]

等不可挽回的数据错误,必须加以修复[单表级别的修复]

<查询分析器中对相关症状的表,进行分析>

    Select  *  from  tab_hwspbiao

 

<执行语句后的报错__消息现象>

服务器:   消息  3***,级别   20,状态   1,行   2 

     

  Location:   e:\.........\storeng\drs\include\record.inl:1447  

  Expression:   m_SizeRec   >   0   &&   m_SizeRec   <=   MAXDATAROW  

  SPID:   52  

  Process   ID:   -8234     

  连接中断

 

---诊断:

     出现此报错信息,可以进行定位。由以上案例报错信息可知,为单表级错误。

<执行测试语句 [验证语句 ] 使用 DBCC 结果集输出>

 

首先运行DBCC修复DBCC CHECKTABLE(' tab_hwspbiao')

 

输出的结果最后一行有:repair_allow_data_loss 是最低的修复级别(对于由 DBCC CHECKTABLE ( tab_hwspbiao ) 发现的错误而言)

 

---处理:

此时我们针对,该案例子进行分析,服务器[肯定是多用户多线成的,此时不要计较我的说法]必须改成单机进行才能进行操作,顾而本人前期对在尽可能少的破坏数据的前提下进行如下的操作:[说明:此为真实且部分被简略处理文档]

 

----操作步骤

---1,为了安全起见,请首先备份数据库

---2,执行脚本,将以下语句在查询分析器上执行

---<·1  :请将data_name 更改为现用数据库名 如"ddmm">

alter database data_name set single_user with rollback immediate

dbcc checktable('hwsp',repair_allow_data_loss)

---<·2  :请将data_name 更改为现用数据库名 如" ddmm ">

alter database data_name set multi_user with rollback immediate

---3如有任何问题请回复此邮箱[yinaje@163.com以便即时处理]

---收到邮件后请及时回复电话1391****** :尹 * *    

    "[执行],消息显示返回以下结果如下:[ 后面的两个错误只是一般性索引错误,已在修复序列中,属于正常的修复范围之内;回滚信息部分省略]

 

正在回滚不合法事务。估计回滚已完成: 100%

服务器: 消息 8928,级别 16,状态 1,行 3

对象 ID 293628139,索引 ID 0: 未能处理页 (1:33332)。详细信息请参阅其它错误。

服务器: 消息 8944,级别 16,状态 1,行 3

表错误: 对象 ID 293628139,索引 ID 0,页 (1:33332),行 41。测试(columnOffsets->offTbl [varColumnNumber] <= (nextRec - pRec))失败。值为 2048 143

服务器: 消息 8978,级别 16,状态 1,行 3

表错误: 对象 ID 293628139,索引 ID 1。页 (1:30463) 缺少上一页 (1:33332) 对它的引用。可能是因为链的链接有问题。

服务器: 消息 8976,级别 16,状态 1,行 3

'table' DBCC 结果。

        该错误已修复。

        该错误已修复。

        该错误已修复。

修复: (1:33332) 已从对象 ID 293628139,索引 ID 0 处释放。

成功地还原了数据库 'dbname' 中对象 'dbo.table' Clustered 索引。

对象 'table' 163394 行,这些行位于 5089 页中。

CHECKTABLE 发现了 0 个分配错误和 4 个一致性错误(在表 'table' 中,该表的对象 ID 293628139)。

CHECKTABLE 修复了 0 个分配错误和 4 个一致性错误(在表 'table' 中,该表的对象 ID 293628139)。 "

 

---释意:

< : data_name处为正在使用的数据库名称 >

alter database data_name set single_user with rollback immediate

//-----此语句将数据库转到单用户模式下进行操作;

dbcc checktable('hwsp',repair_allow_data_loss)

// repair_allow_data_loss 是最低的修复级别,在处理时回滚不合法事物并修复

alter database data_name set multi_user with rollback immediate

//-----此语句使数据库返回到正常操作状态;

 

---后言:

    在此次的数据修复中,其操作实际极为简单,但是其中涉及的数据较为重要.案例的修复原理,也是我们应该在日常数据安全修复中应该继续学习的。

 对于此文涉及的案例在一些大型的项目修复中也常有发生,但对于修复并不是任何报错案例都适用的。希望更多的错误能在程序开发,和日常维护中尽量的屏蔽掉‘它’的发生,毕竟不是谁都希望毁掉一些数据;

 

    [在写此文中,因使用的是SQL Server 2005数据库,对于部分消息及报错来源于百度搜索;文中避免不了稍许的错误,有些时候是习惯了,在此希望博友斧正]

                                                                                              

 

 

 

  评论这张
 
阅读(108754)| 评论(18)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018