恢复删除的数据文件案例《from&nbs…
2013-01-28 22:09
471 查看
【案例描述】
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
【案例警示】
分析整个灾难的形成过程，我们总结这次数据灾难给我们的警示是：
1.数据库需要全面的系统规划和监控
2.数据库的破坏性操作需要谨慎
3.数据环境运维必须遵守一定的安全守则
4.数据备份应进行必要的检查和确认
5.避免在疲劳或不清醒状态独自做出重要判断
6.在对故障做出清晰判断之前不要采取贸然措施
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
【案例警示】
分析整个灾难的形成过程，我们总结这次数据灾难给我们的警示是：
1.数据库需要全面的系统规划和监控
2.数据库的破坏性操作需要谨慎
3.数据环境运维必须遵守一定的安全守则
4.数据备份应进行必要的检查和确认
5.避免在疲劳或不清醒状态独自做出重要判断
6.在对故障做出清晰判断之前不要采取贸然措施
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 在线删除全部数据文件的恢复案例
- 误操作删除数据文件恢复案例讨论
- 误操作删除数据文件恢复案例
- UNIX文件系统下误删除的数据恢复经典案例--UFS删除恢复
- 人工误删除InnoDB ibdata数据文件如何恢复？（没试过）
- Oracle数据文件物理删除后的恢复
- 【转载】linux中误删除oracle数据文件的恢复操作
- 数据恢复误删除、误格式化文件恢复工具DiskGenius
- 物理删除oracle数据文件的恢复
- MySQL 删除ibdata1 文件后恢复数据
- [数据恢复答疑]删除了WINDOWS桌面上的文件，该如何恢复数据
- 文件系统管理 之 有关ext2文件系统下反删除（Undelete）操作恢复数据的文档
- Oracle案例：损坏数据文件的恢复方法
- mysql innodb引擎数据库，删除ibdata1文件恢复数据教程
- 如何彻底删除文件，让文件没办法恢复，保证数据安全？
- 为什么二进制文件与文本文件存入同样的数据，文件大小差异会这么大？（from <<Thinking in C++>>'s execise）
- MySQL ibdata损坏或丢失 通过frm&ibd文件恢复数据
- mysql&nbsp;数据恢复&nbsp;案例：&nbsp;“恢复/导入…
- 操作系统命令误删除数据库的数据文件并数据库没有备份的恢复
- 网上删除所有数据文件的恢复情况