【案例描述】
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/<proc_id>/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.在對故障做出清晰判斷之前不要採取貿然措施