使用append+nologging引起恢復故障實驗

 

Oracle的nologging屬性是非常容易被濫用的。在我們之前的文章中，探討過append+nologging對於Redo Log的影響。從文章的結論看：如果我們使用append配合nologging，的確是可以減少Redo Log的生成的。

但是，這樣做真的有好處嗎？

希望減少Redo Log生成的思路無非是：Redo Log生成量少了，這樣在LGWR寫入的量就少了，從而帶來的物理IO和日誌切換動作就少了。但是，隨著帶來的問題是：日誌少了真的沒有問題嗎？

Oracle Redo Log是資料庫的重要物件，原始提出Redo Log的目的在於“日誌在先，資料恢復”。從宏觀上看，Redo Log是保證資料庫事務一致性的手段。但更重要的是，Redo Log是資料庫內部一致性、資料庫完全恢復和高可用性元件（DG、OGG）的重要技術基礎。

Redo Log是描述資料塊變化的記錄資訊，其中包括邏輯變化和物理變化。本篇就透過實驗來確定Append+Nologging給備份還原帶來的問題。

 

1、環境準備和備份

 

我們選擇Oracle 11gR2進行測試。為了保證一致性，我們首先進行一次熱備份動作。

 

RMAN> backup database plus archivelog delete all input;

 

Starting backup at 10-DEC-13

current log archived

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=38 device type=DISK

（篇幅原因，有省略……）

 

Starting Control File and SPFILE Autobackup at 10-DEC-13

piece handle=/u01/flash_recovery_area/WILSON/autobackup/2013_12_10/o1_mf_s_833787521_9bdo43ol_.bkp comment=NONE

Finished Control File and SPFILE Autobackup at 10-DEC-13

 

此時，配合歸檔模式，我們是可以實現完全恢復的。

 

RMAN> list backup;

 

List of Backup Sets

===================

 

BS Key  Type LV Size       Device Type Elapsed Time Completion Time

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

130     Full    1.31G      DISK        00:01:55     10-DEC-13     

        BP Key: 130   Status: AVAILABLE  Compressed: NO  Tag: TAG20131210T073642

        Piece Name: /u01/flash_recovery_area/WILSON/backupset/2013_12_10/o1_mf_nnndf_TAG20131210T073642_9bdo0djj_.bkp

  List of Datafiles in backup set 130

（篇幅原因，有省略……）

  SPFILE Included: Modification time: 10-DEC-13

  SPFILE db_unique_name: WILSON

  Control File Included: Ckp SCN: 5260073      Ckp time: 10-DEC-13

 

 

2、一次append+nologging動作

 

我們建立一張資料表T，將其nologging屬性設定為Y。

 

SQL> create table t as select * from dba_objects where 1=0;

Table created

 

SQL> alter table t nologging;

Table altered

 

使用insert append插入資料。

 

SQL> insert /*+append*/ into t select * from dba_objects;

72768 rows inserted

 

SQL> commit;

Commit complete

 

 

3、啟動恢復過程

 

如果此時發生系統故障，資料丟失，需要進行資料恢復動作。試圖使用RMAN來進行完全恢復。

 

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

 

SQL> conn / as sysdba

Connected to an idle instance.

SQL> startup mount;

ORACLE instance started.

 

Total System Global Area  849530880 bytes

Fixed Size                  1339824 bytes

Variable Size             511708752 bytes

Database Buffers          331350016 bytes

Redo Buffers                5132288 bytes

Database mounted.

 

啟用RMAN恢復過程。

 

--Restore過程

RMAN> restore database;

 

Starting restore at 10-DEC-13

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=18 device type=DISK

 

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00001 to

（篇幅原因，有省略……）

channel ORA_DISK_1: piece handle=/u01/flash_recovery_area/WILSON/backupset/2013_12_10/o1_mf_nnndf_TAG20131210T073642_9bdo0djj_.bkp tag=TAG20131210T073642

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:07:05

Finished restore at 10-DEC-13

 

--Recover應用Redo Log

RMAN> recover database;

 

Starting recover at 10-DEC-13

using channel ORA_DISK_1

 

starting media recovery

media recovery complete, elapsed time: 00:00:12

 

Finished recover at 10-DEC-13

 

RMAN>

 

恢復過程沒有明顯的錯誤標誌，恢復似乎是成功了。之後開啟資料庫。

 

RMAN> alter database open;

database opened

 

 

4、壞塊出現

 

回到sqlplus環境，檢查資料表。

 

SQL> conn scott/tiger@wilson;

Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.1.0

Connected as scott

 

SQL> select count(*) from t;

 

select count(*) from t

 

ORA-01578: ORACLE 資料塊損壞 (檔案號 4, 塊號 3611)

ORA-01110: 資料檔案 4: '/u01/oradata/WILSON/datafile/o1_mf_users_805nxydh_.dbf'

ORA-26040: 資料塊是使用 NOLOGGING 選項載入的

 

 

報錯壞塊！

 

這個過程也是可以理解的。Redo Log是描述資料變化全過程的過程化資料。完全恢復是建立在重演Redo Log過程，以達到最終資料一致的目的。Nologging透過額外的手段減少了redo log的生成，必然有一部分重要的變化資料是缺失的。那麼，nologging部分還原出來之後，就難以保證資料一致性。

至此，我們可以看出nologging的問題，就是影響資料的恢復過程連續性。讓我們設想一種場景：如果在生產環境中使用nologging append方法之後，沒有發現後續的問題，也沒有進行全備份動作。一旦發生故障，需要進行資料恢復時就遇到麻煩。不僅僅是該資料表可能有問題，其他資料表引用的該資料表關係也會受到影響。

更進一步，如果我們配置了Data Guard、OGG這種嚴重依賴Redo Log Apply的技術元件，我們更可能會導致源資料庫正確、但是備份端出現壞塊。

 

5、處理方法

 

Nologging是一個綜合性的過程。在Oracle資料庫中，資料庫層面、表空間和資料表三個層次均有nologging配置屬性。三者之前的配置關係和作用是相互的。

下面我們透過資料庫層面的nologging，開啟強制日誌（force logging）功能，一定程度上可以避免由於nologging帶來的資料恢復問題。注意：由於條件的限制，筆者使用了另外的資料庫，但是不影響結果。

 

 

SQL> archive log list;

Database log mode              Archive Mode

Automatic archival             Enabled

Archive destination            USE_DB_RECOVERY_FILE_DEST

Oldest online log sequence     110

Next log sequence to archive   112

Current log sequence           112

SQL> alter database open;

 

Database altered.

 

SQL> alter database force logging;

Database altered.

 

 

SQL> select log_mode, force_logging from v$database;

 

LOG_MODE     FORCE_LOGGING

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

ARCHIVELOG   YES

 

 

備份資料過程省略，建立一個全新的全備份。之後建立資料表。

 

SQL> create table t nologging as select * from dba_objects where 1=0;

Table created

 

SQL> alter table t move tablespace users;

Table altered

 

 

SQL> select logging from dba_tables where owner='SYS' and table_name='T';

LOGGING

-------

NO

 

SQL> insert /*+append*/ into t select * from dba_objects;

75607 rows inserted

 

SQL> commit;

Commit complete

 

SQL> select count(*) from t;

  COUNT(*)

----------

     75607

 

啟動還原過程，從全備份開始，前推Redo Log進行完全恢復。

 

--start到mount狀態省略

RMAN> restore database;

 

Starting restore at 11-DEC-13

using channel ORA_DISK_1

 

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oradata/ORA11G/datafile/o1_mf_system_92t6zl2m_.dbf

channel ORA_DISK_1: restoring datafile 00002 to /u01/app/oradata/ORA11G/datafile/o1_mf_sysaux_92t6zl5k_.dbf

channel ORA_DISK_1: restoring datafile 00003 to /u01/app/oradata/ORA11G/datafile/o1_mf_undotbs1_92t6zl6d_.dbf

channel ORA_DISK_1: restoring datafile 00004 to /u01/app/oradata/ORA11G/datafile/o1_mf_users_92t6zl83_.dbf

channel ORA_DISK_1: restoring datafile 00005 to /u01/app/oradata/ORA11G/datafile/o1_mf_example_92t74b1f_.dbf

channel ORA_DISK_1: restoring datafile 00006 to /u01/app/oradata/ORA11G/datafile/o1_mf_trcatbl_96mlzz0j_.dbf

channel ORA_DISK_1: restoring datafile 00007 to /u01/app/oradata/ORA11G/datafile/o1_mf_test1_971dp6kb_.dbf

channel ORA_DISK_1: restoring datafile 00008 to /u01/app/oradata/ORA11G/datafile/o1_mf_test2_971dqkh0_.dbf

channel ORA_DISK_1: reading from backup piece /u01/app/fast_recovery_area/ORA11G/backupset/2013_12_11/o1_mf_nnndf_TAG20131211T091503_9bhh4qdp_.bkp

channel ORA_DISK_1: piece handle=/u01/app/fast_recovery_area/ORA11G/backupset/2013_12_11/o1_mf_nnndf_TAG20131211T091503_9bhh4qdp_.bkp tag=TAG20131211T091503

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:01:15

Finished restore at 11-DEC-13

 

RMAN> recover database;

 

Starting recover at 11-DEC-13

using channel ORA_DISK_1

 

starting media recovery

media recovery complete, elapsed time: 00:00:05

 

Finished recover at 11-DEC-13

 

RMAN> alter database open;

database opened

 

 

啟動資料庫之後，檢查資料表狀態。

 

 

SQL> select count(*) from t;

 

  COUNT(*)

----------

     75607

 

SQL> select logging from dba_tables where owner='SYS' and table_name='T';

 

LOGGING

-------

NO

 

 

從實驗結果可知，利用force logging，可以一定程度上避免由於資料表nologging引起的壞塊問題。

 

 

6、結論與反思

 

在這個案例中，我們看到了日常工作中常用nologging的潛在問題。在實際工作中，特別是大資料、資料倉儲系統應用，很多運維人員甚至開發人員都喜歡使用nologging來處理資料。這樣的現象是由於對Oracle Redo Log重要性沒有明確認識。一旦進行恢復，就容易大禍臨頭。

筆者認為：nologging的使用是有條件和場合的。如果我們是在準備資料階段，關閉歸檔、使用nologging都是允許的手段。一旦上線，切記要主要避免使用這樣的操作方式。也許在效能上有一些優勢，但是帶來的風險不是我們可以承擔的。