一.概述

  当数据库发生损坏,数据库的每个文件都能打开,只是其中的一些页面坏了,这种情况可以借助DBCC
CHECKDB进行数据库检查修复。如果要保证数据库不丢失,或修复不好,管理员只能做数据库完整恢复,为了少数页面恢复整个数据库,代价是比较高的,sql
server引入了页面还原功能,可以指定还原若干页面,从而能够大大节省数据库恢复时间。
  页面还原用于修复隔离的损坏页面,还原恢复时间比文件更快,减少了还原过程中处于离线的数据量,当某个文件的大量页面都出现损坏,可以直接还原该文件(需要有文件备份)。要进行还原的页面是在访问该页面,遇到错误而标记为”可疑”,可以试试去找msdb.dbo.suspect_pages表。在页面还原后,也需要恢复所有的日志文件备份
  1.1 还原的限制,不能还原的页
    (1)事务日志不能还原。
    (2)分配页面:全局分配映射GAM页面,共享全局分配映射SGAM页面和可用空间PFS页面,这些系统页面损坏,页面还原无法恢复。
    (3)所有数据文件的页面0 的(文件启动页面)。
    (4)页面1:9的(数据库启动页面)。
  1.2 还原条件
    (1) 必需使用完整恢复模式。
    (2) 只读文件组中的页面无法还原。
    (3) 还原顺序必须是从完整备份,文件备份中恢复页面开始。
    (4) 页面还原需要截止到当前日志文件的连续日志备份
    (5) 数据库备份和页面还原不能同时进行。

当数据库出现页损坏或校验和出错时如何处理

说明:灾难恢复系列的文章是由 Robert Davis写的,发布在SQLSoldier,
个人认为挺不错的,所以根据自己的理解,边测试边整理,并非直接翻译,如有不准确,欢迎指正。

二.还原步骤      

  (1) 获取要还原的损坏页面的页ID,当sql
server遇到校验或残缺写错误时,会返回页面编号。可以通过查询msdb数据库里的suspect_pages表,或者监视事件和errorlog文件里记录的错误信息,查找到损坏的页面ID。
  (2)
从包含页的完整数据库备份,文件备份或文件组备份开始进行页面还原。在restore
database 语句中,使用page子句列出所有要还原的页ID。
  (3) 应用最近的差异备份。
  (4) 应用后续的日志备份。
  (5) 创建新的数据库尾日志备份。
  (6) 还原新的尾日志备份,应用这个新的日志备份后,就完成了页面还原。

作者:nzperfect / perfectaction
日期:2009.09.27

本篇进入数据库灾难恢复第五篇,从本篇开始,主要深入讲述一些数据page损坏的问题,先从容易修复的非聚集索引开始。

三. 备份

  为了演示损坏的数据页面,新建一个PageTest表,初始化三个PAGE页,后面人为的破坏一个数据页面。

use BackupPageTest
-- 创建表
create table PageTest
(
    ID int,
    name varchar(8000)
)
-- 产生
insert into PageTest
select 1, REPLICATE('a',8000)
insert into PageTest
select 1, REPLICATE('b',8000)
insert into PageTest
select 1, REPLICATE('c',8000)

 sys.system_internals_allocation_units 查看分配页情况

 图片 1

/* 
第1个参数:库名
第2个参数:表名
第3个参数:-1: 显示所有IAM、数据分页、及指定对象上全部索引的索引分页
PageFID: 文件ID
PageType=1 指数据页面
PageType=10 IAM页面
*/ 
-- 未公开的命令,语法如下:
DBCC IND(dbname,tablename,-1)

最近一直在进一步学习数据库故障的处理方面的知识,做为一个数据库维护人员,我即期望遇到所有的数据库出错的案例,以增加自己的经验,但同时又担心遇到这样或那样无法处理的数据库故障而导致数据丢失。

通常,处理数据损坏的情况按三个步骤进行:

  图片 2

use master
-- 完整备份
backup database  BackupPageTest to BackupTestDevice

前几天看到一个文章,是说一个网站管理员在招聘DBA时,提出一个问题:“如果在sql
server
日志里发现一个页损坏或是校验和错误应该如何处理?”网站管理员描述,大概有90%的应聘者都会采用一个方案,用DBCC
CHECKDB加上其中的一个修复选项,但其中也基本没有人能具体解释DBCC
CHECKDB修复的过程或是工作原理及能修复到什么程度。

1.确定损坏(使用DBCC CHECKDB)
2.确定损坏的对象及对象类型(如索引页、分配页等)
3.确定适合的修复方法

四 模拟页面损坏

  使用PagePID为89的数据页面进行演示,通过dbcc
page查看该页面,知道该页数据是存储的第三条数据。

dbcc traceon (3604)
dbcc page('BackupPageTest',1,89,1)

  图片 3

  使用 dbcc wirtepage来模拟该面损坏:

-- 未公开的命令语法为如下
dbcc writepage ({ dbid, 'dbname' }, fileid, pageid, offset, length, data)

-- 模拟页面损坏
dbcc writepage(BackupPageTest,1,89,96,10,0x65656565656565656565)

图片 4

-- 查询该表时,第三条数据显示NULL
select * from PageTest

借助联机文档以及个人的一些理解和经历,解释一下如何面对这个问题:”当数据库出现页损坏或校验和出错时如何处理?”

确定损坏
当我们在做一些例行完整性检查或者收到一些其它的错误或警告,如果有一个page损坏的信息,不要直接就去处理这个页面,应该先对数据库运行DBCC
CHECCKDB做一下全面检查,以确定是不是其它页面造成的。

  图片 5

--更新第三条数据,结果报错
update PageTest set  id=2  where ID is null

  图片 6

-- 插入第4条是成功的
insert into PageTest
select 4, REPLICATE('d',8000)

  图片 7

首先,需要先了解DBCC CHECKDB,联机文档url:

使用DBCC
CHECKDB可让看到哪些page损坏,我们通过使用No_InfoMsgs选项过滤不需要的信息,同时使用All_ErrorMsgs确保返回所有错误,为了可读性,我们用TableResults
选项将其结果格式化成表,如:

五. 获取要修复的数据页面 

-- 使用checkdb检查
DBCC CHECKDB(BackupPageTest)

  通过校验,提示无法处理面(1:89)如下图

  图片 8

通过联机文档,可以得知有REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST |
REPAIR_REBUILD三个修复选项,而提供实际功能的只有REPAIR_ALLOW_DATA_LOSS和REPAIR_REBUILD两个,其
中REPAIR_ALLOW_DATA_LOSS
尝试修复报告的所有错误,这些修复可能会导致一些数据丢失;而且REPAIR_REBUILD执行不会丢失数据的修复,包括快速修复(如修复非聚集索引中
缺少的行)以及更耗时的修复(如重新生成索引);可见REPAIR_REBUILD是我们期望的图片 9
当你从sql server log里或是在程序查询数据库或是定期通过DBCC
CHECKDB为数据库做体检的时候,出现了页损坏或校验和出错信息时,如:

DBCC CheckDB(AdventureWorksDW2012)
    With No_InfoMsgs, All_ErrorMsgs, TableResults;

六. 还原

use master
--从完整数据库备份,开始还原,指定要还原的PAGE页
restore database BackupPageTest page='1:89' from BackupTestDevice with file=39,  norecovery
--创建新的尾日志备份
backup log BackupPageTest to BackupTestDevice

 
 此时访问数据表PageTest将会发错,如下图所示,表明在还原过程中数据是不可访问的。

 图片 10

图片 11

--最后还原新的尾日志备份
restore log BackupPageTest from BackupTestDevice with file=40,  recovery

   数据修复过来了,如下图:

  图片 12

  再次CHECKDB 检查表状态

  图片 13


从结果可以看到返回了一些错误,有些是相同的,需要我们自己找出哪些是真的错误,然后通过具体的错误信息找出对象id,索引id,分区id,分配单元id,文件及页面(object
ID, index ID, partition ID, allocation unit ID, file, and page.)。
图片 14
图片 15

M8928sg , Level 16, State 1, Line 1
Object ID 2088535921, index ID 0, partition ID 72345201021503994, alloc unit ID 72345201051571606 (type In-row data): Page (1:94299) could not be processed.  See other errors for details.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 2088535921, index ID 0, partition ID 72345201021503994, alloc unit ID 72345201051571606 (type In-row data), page (1:94299). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed.
CHECKDB found 0 allocation errors and 2 consistency errors in table ‘yourtable’ (object ID 2088535921).
CHECKDB found 0 allocation errors and 2 consistency errors in database ‘yourdb’.

确定损坏的对象及对象类型
在执行DBCC
CHECKDB之后,我们也可以通过msdb的suspect_pages去确定损坏信息,这个表每一行记录一个损坏的page,不过这个表没有对象id和索引id,只有数据库id、文件号、数据页id,如果需要更详细信息,需要用DBCC
PAGE去查看了。在这里我们不用这个方法,因为之前的DBCC
CHECKDB中已经有这些信息。

发表评论

电子邮件地址不会被公开。 必填项已用*标注