【案例描述】
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.在对故障做出清晰判断之前不要采取贸然措施
阅读(2216) | 评论(0) | 转发(0) |
