Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1142299
  • 博文数量: 251
  • 博客积分: 8431
  • 博客等级: 中将
  • 技术积分: 2699
  • 用 户 组: 普通用户
  • 注册时间: 2007-07-22 16:24
文章分类

全部博文(251)

文章存档

2016年(2)

2015年(5)

2014年(4)

2013年(10)

2012年(8)

2011年(14)

2010年(20)

2009年(33)

2008年(51)

2007年(104)

分类: Oracle

2015-04-27 15:36:37

【案例描述】
    2011 年 12 月 30 日,某运营商客户,在遭受数据损失之后请求我们协助进行数据恢复。整个数据灾难的过程如下。

1.     凌晨,数据库归档日志写满磁盘,因而无法继续归档,数据库服务中断。

2.     在进行空间释放时,删除了一个认为不再需要的目录。

3.     删除目录之后,发现数据库服务受到影响。

4.     经确认,该目录包含 7 个 16GB 大小的在用数据文件。

5.     在试图通过备份来恢复时,发现之前的备份是不成功的。

6.     灾难形成。
  这是一个由删除引发的严重故障,如果数据不可恢复,灾难影响将是非常严重的。

【数据库环境描述】

OS:HP-UX

数据库版本:Oracle 11.2.0.1


【技术回放】

从告警日志看最初数据库出现的问题是归档日志无法写出,出现归档错误,归档停滞会导致数据库的所有DML事务无法进行,在线业务受到影响。

Fri Dec 30 03:34:33 2011

ARC0: Encountered disk I/O error 19502

ARC0: Closing local archive destination LOG_ARCHIVE_DEST_1:

      '/archlog/1_6578_765575017.dbf' (error 19502)(com1)

ARC0: I/O error 19502 archiving log 5 to'/archlog/1_6578_765575017.dbf'

ARCH: Archival stopped, error occurred. Will continue retrying

ORACLE Instance com1 - Archival Error

ORA-16038: log 5 sequence# 6578 cannot be archived

ORA-19502: write error on file "", block number  (block size=512)

ORA-00312: online log 5 thread 1: '/oradata2/redolog5_1.dbf'

ORA-00312: online log 5 thread 1: '/oradata3/redolog5_2.dbf'

ARCH: Archival stopped, error occurred. Will continue retrying

经过处理,在凌晨5点22分左右,归档得以继续,归档进程从失败中被释放出来,但是这位凌晨被吵醒的工程师草率的做出了错误的判断,删除了认为没用的目录,oradata4整个目录在操作系统上被删除,其中的所有数据文件荡然无存,以下是丢失的文件列表和状态,从v$datafile中可以查询得到这些信息

       TS#     FILE# NAME                                          BYTESSTATUS

---------- ---------- -------------------------------------------------- -------

         5        229 /oradata4/YDDY_DATA55.dbf                      0 ONLINE

        19        230 /oradata4/EFB01.dbf                             0 ONLINE

        18        231 /oradata4/undotbs203.dbf                       0 RECOVER

         9        232 /oradata4/SMS_DATA47.dbf                       0 ONLINE

         9        233 /oradata4/SMS_DATA48.dbf                       0 ONLINE

         9        234 /oradata4/SMS_DATA49.dbf                       0 ONLINE

         5        235 /oradata4/YDDY_DATA56.dbf                      0 ONLINE

而当用户尝试的从备份开始恢复时,发现备份无法还原出来,此前的几次备份都失败了,备份不可用,现在问题就相当严重了。


【恢复重现】

首先找到一个后台进程(如DBWR进程),通过其进程地址找到文件句柄(/proc//fd, fd - File Descriptors),以下就是数据库文件的句柄显示信息,通过拷贝这些文件就可以恢复那些被删除但是尚未消失的数据文件:

bash-2.05$ ps -ef|grep dbw|grep -v grep

oracle   762     1 0   Jun 10 ?       217:30 ora_dbw0_sxnms

bash-2.05$ ls  /proc/762/fd

0    12   256 260  264  268 272  276  280 284  288  292 296  3    303 307  311  315 319  323  327 331  335  339 343  347  61   13   257  261 265  269  273 277  281  285 289  293  297 300  304  308 312  316  320 324  328  332 336  340  344 348  710   14  258  262  266 270  274  278 282  286  290 294  298  301 305  309  313 317  321  325 329  333  337 341  345  4   811   2    259 263  267  271 275  279  283 287  291  295 299  302  306 310  314  318 322  326  330 334  338  342 346  5  9

db2% ls -l |grep oracle

-r--r--r--   1 oracle   dba      657920 Apr 26  2002 11

-rw-r-----   1 oracle   dba         923 Jun 10  2011 12

-rw-rw----   1 oracle   dba          24 Jun 10  2011 13

-rw-r-----   1 oracle   dba     1859584 Jan  5 16:42 256

-rw-r-----   1 oracle   dba     1859584 Jan  5 16:42 257

-rw-r-----   1 oracle   dba     1859584 Jan  5 16:42 258

-rw-r-----   1 oracle   dba     414195712 Jan  5 16:41 259

-rw-r-----   1 oracle   dba     6291464192 Jan  5 16:42 260

-rw-r-----   1 oracle   dba     161488896 Jan  5 16:18 261

-rw-r-----   1 oracle   dba     20979712 Jan  5 16:18 262

-rw-r-----   1 oracle   dba     26222592 Jan  5 16:18 263

-rw-r-----   1 oracle   dba     10493952 Jan  5 16:18 264

-rw-r-----   1 oracle   dba     473178112 Jan  5 16:18 265

-rw-r-----   1 oracle   dba     1048584192 Jan  5 16:40 266

-rw-r-----   1 oracle   dba     1048584192 Jan  5 16:18 267

-rw-r-----   1 oracle   dba     1048584192 Jan  5 16:40 268

-rw-r-----   1 oracle   dba     1048584192 Jan  5 16:40 269

-rw-r-----   1 oracle   dba     1048584192 Jan  5 16:41 270

-rw-r-----   1 oracle   dba     1048584192 Jan  5 16:42 271

-rw-r-----   1 oracle   dba     1384652800 Jan  5 16:18 272

在这个案例中,我们拷贝文件恢复之后,创建了一个新的目录(保留原来的目录结构未变动),随后通过offline,rename,recover,online四个步骤恢复这些文件,加载到数据库中。以下是简要的步骤记录。

首先复制文件到新分配的目录空间:

cp /proc/762/fd/266 /new_u02/oradata/cinms_user01.dbf

cp /proc/762/fd/267 /new_u02/oradata/cinms_user02.dbf

cp /proc/762/fd/268 /new_u02/oradata/cinms_user03.dbf

cp /proc/762/fd/269 /new_u02/oradata/cinms_user04.dbf

cp /proc/762/fd/285 /new_u02/oradata/cinms_user07.dbf

cp /proc/762/fd/286 /new_u02/oradata/cinms_user08.dbf

将相应的文件离线:

alter database datafile 8 offline;

alter database datafile 9 offline;

alter database datafile 10 offline;

alter database datafile 11 offline;

alter database datafile 27 offline;

alter database datafile 28 offline;

通过更名(RENAME)的方式对文件进行重定向:

alter database rename file

‘/u02/oradata/cinms_user01.dbf’to ‘/new_u02/oradata/cinms_user01.dbf’;

alter database rename file

‘/u02/oradata/cinms_user02.dbf’ to‘/new_u02/oradata/cinms_user02.dbf’;

alter database rename file

‘/u02/oradata/cinms_user03.dbf’ to‘/new_u02/oradata/cinms_user03.dbf’;

alter database rename file

‘/u02/oradata/cinms_user04.dbf’ to ‘/new_u02/oradata/cinms_user04.dbf’;

alter database rename file

‘/u02/oradata/cinms_user07.dbf’ to‘/new_u02/oradata/cinms_user07.dbf’;

alter database rename file

‘/u02/oradata/cinms_user08.dbf’ to‘/new_u02/oradata/cinms_user08.dbf’;

然后执行恢复:

recover datafile 8;

recover datafile 9;

recover datafile 10;

recover datafile 11;

recover datafile 27;

recover datafile 28;

最后将文件Online加载:

alter database datafile 8 online;

alter database datafile 9 online;

alter database datafile 10 online;

alter database datafile 11 online;

alter database datafile 27 online;

alter database datafile 28 online;

以下是日志中记录的操作日志信息:

Mon Dec 19 18:17:38 2011

alter database datafile 8 offline

Mon Dec 19 18:17:39 2011

Completed: alter database datafile 8 offline

Mon Dec 19 18:18:04 2011

alter database rename file '/u02/oradata/sxnms_user01.dbf'

                  to'/new_u02/oradata/sxnms_user01.dbf'

Mon Dec 19 18:18:20 2011

ALTER DATABASE RECOVER datafile 8  

Media Recovery Datafile: 8

Media Recovery Start

Starting datafile 8 recovery in thread 1 sequence 14295

Datafile 8: '/new_u02/oradata/sxnms_user01.dbf'

Media Recovery Log

Recovery of Online Redo Log: Thread 1 Group 1 Seq 14295 Readingmem 0

  Mem# 0 errs 0:/u01/oradata/sxnms/redo01.log

Media Recovery Complete

Completed: ALTER DATABASE RECOVER  datafile 8

Mon Dec 19 18:19:00 2011

alter database datafile 8 online

Completed: alter database datafile 8 online
阅读(2114) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~