挽救DG中主庫的nologging操作的塊

沃趣科技發表於2018-05-15
原文網址 : http://blog.itpub.net/28218939/viewspace-2154509/


眾所周知我們的Data Guard資料同步是基於日誌流的。所以在主庫執行nologging操作是不被允許的。這也就是為什麼我們需要在配置Data Guard階段需要使用Force Logging。但是這也會帶來很多問題（SQL執行效率），例如：當我們使用資料泵進行遷移時我們希望最少停機時間完成，這時候我們就可能會考慮到以最小日誌匯入的方式以加快匯入速度，然後重新同步備庫。

在一些場景中，我們會去使用nologging操作去節省大量資料插入的時間，而這種操作所帶來的問題就是，如果該庫在有備庫的情況下，因為主庫的nologging插入操作不會生成redo，所以不會在備庫上傳輸和應用，這會導致備庫的資料出現問題。

在Oracle 11g，如果遇到這樣的問題，可以透過在備庫恢復有問題的資料檔案來解決問題，示例如下：

在一個具有主備關係的主庫上將force_logging設定為nologging模式，隨後建立一張表，設定為nologging模式

點選(此處)摺疊或開啟

  1. SQL> alter database no force logging;
  2. SQL> create table DEMO tablespace users pctfree 99 as select rownum n from xmltable('1 to 1000');
  3. SQL> alter table DEMO nologging;

之後使用/* +append*/插入資料並提交

點選(此處)摺疊或開啟

  1. SQL> insert /*+ append */ into DEMO select rownum n from xmltable('1 to 100000');
  2. SQL> commit

這時候在備庫對該表進行查詢會看到如下報錯資訊

點選(此處)摺疊或開啟

  1. SQL>select count(1) from demo;
  2. select count(1) from demo
  3.                  *
  4. ERROR at line 1:
  5. ORA-01578: ORACLE data block corrupted (file # 4, block # 819)
  6. ORA-01110: data file 4: '/data/data1/ORCL2/datafile/o1_mf_users_3ft1e9qb_.dbf'
  7. ORA-26040: Data block was loaded using the NOLOGGING option


而要修復這個問題，需要將包含缺少的資料的資料檔案從主庫複製到物理備庫。

步驟一

1、查詢主庫

點選(此處)摺疊或開啟

  1. SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE;
  2. NAME UNRECOVERABLE_CHANGE#
  3. --------------------------------------------------------------------------- ---------------------
  4. +DATADG/orcl/datafile/system.270.972381717 0
  5. +DATADG/orcl/datafile/sysaux.265.972381717 0
  6. +DATADG/orcl/datafile/undotbs1.261.972381717 0
  7. +DATADG/orcl/datafile/users.259.972381717 6252054
  8. +DATADG/orcl/datafile/example.264.972381807 0
  9. +DATADG/orcl/datafile/undotbs2.258.972381927 0
  10. +DATADG/orcl/datafile/example.266.972400297 0
  11. +DATADG/orcl/datafile/ax.268.973612569 0


2、查詢備庫

點選(此處)摺疊或開啟

  1. sys@ORCL>SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE;
  2. NAME UNRECOVERABLE_CHANGE#
  3. --------------------------------------------------------------------------- ---------------------
  4. /data/data1/ORCL2/datafile/o1_mf_system_3dt1e9op_.dbf 0
  5. /data/data1/ORCL2/datafile/o1_mf_sysaux_3ct1e9nb_.dbf 0
  6. /data/data1/ORCL2/datafile/o1_mf_undotbs1_3gt1e9qq_.dbf 0
  7. /data/data1/ORCL2/datafile/o1_mf_users_3ft1e9qb_.dbf 5383754
  8. /data/data1/ORCL2/datafile/o1_mf_example_3et1e9ps_.dbf 0
  9. /data/data1/ORCL2/datafile/o1_mf_undotbs2_3ht1e9r1_.dbf 0
  10. /data/data1/ORCL2/datafile/o1_mf_example_3at1e9nb_.dbf 0
  11. /data/data1/ORCL2/datafile/o1_mf_ax_3bt1e9nb_.dbf 0


3、比較主資料庫和備用資料庫的查詢結果

在兩個查詢結果中比較UNRECOVERABLE_CHANGE#列的值。如果主庫中UNRECOVERABLE_CHANGE＃列的值大於備庫中的同一列，則需要將這些資料檔案在備庫恢復。

步驟二 

將主庫對應的資料檔案複製至備庫


點選(此處)摺疊或開啟

  1. SQL> alter tablespace users begin backup
  2. SQL> exit
  3. ASMCMD>cp +DATADG/orcl/datafile/users.259.972381717 /tmp
  4. $ scp /tmp/users.259.972381717 10.10.60.123:/data/data1/ORCL2/datafile/
  5. SQL> alter tablespace users end backup


步驟三 

備庫將舊的資料檔案rename至新的資料檔案

點選(此處)摺疊或開啟

  1. SQL> alter database recover managed standby database cancel;
  2. SQL> alter system set standby_file_management=manual; #在備庫執行rename操作時，需要此引數為manual
  3. SQL> alter database rename file '/data/data1/ORCL2/datafile/o1_mf_users_3ft1e9qb_.dbf' to '/data/data1/ORCL2/datafile/users.259.972381717';
  4. SQL> alter system set standby_file_management=auto;
  5. SQL> alter database recover managed standby database using current logfile disconnect from session;


之後就可以在備庫查詢到例項表DEMO

點選(此處)摺疊或開啟

  1. SQL> select count(1) from demo;
  2.   COUNT(1)
  3. ----------
  4.     101000


對於這種情況，在12.1版本中，RMAN提供了一種便捷的方式讓我們不需要在主庫上進行資料檔案的備份傳輸而可以在備庫使用 restore database (or datafile ) from service去從主庫進行恢復。

當然，Oracle的RMAN是足夠聰明的：如果資料檔案是正常的狀態，RMAN可以根據它們的資料檔案頭進行跳躍恢復。如果，由於nologging操作導致某些塊被標記為損壞的，那麼這部分資料檔案就是需要恢復的，然後怎麼辦？在恢復命令中有FORCE選項。但我們可能並不需要它。因為有些時候資料檔案是同步的，實時日誌應用程式還是在執行的。這個時候，為了恢復，我們需要停止應用。 

一旦我們停止了應用，那麼我們就不需要執行RESOTORE DATABASE FORCE操作，因為現在資料檔案的狀態是過舊的，就算你不加FORCE選項RMAN也是不會跳過這些資料檔案的。

步驟一 

備庫關掉實時日誌應用，並開啟至mount狀態。

點選(此處)摺疊或開啟

  1. SQL> alter database recover managed standby database cancel;
  2. SQL> shutdown immediate
  3. Database closed.
  4. Database dismounted.
  5. ORACLE instance shut down.
  6. SQL> startup mount
  7. ORACLE instance started


步驟二 

備庫登陸RMAN,使用restore database (or datafile ) from service進行恢復

點選(此處)摺疊或開啟

  1. RMAN> restore database from service 'primary_db'; #這裡的primary_db,為備庫至主庫的tns連線串的別名
  2. Starting restore at 2018-05-03 17:00:35
  3. using target database control file instead of recovery catalog
  4. allocated channel: ORA_DISK_1
  5. channel ORA_DISK_1: SID=29 device type=DISK
  6. channel ORA_DISK_1: starting datafile backup set restore
  7. channel ORA_DISK_1: using network backup set from service primary_db
  8. channel ORA_DISK_1: specifying datafile(s) to restore from backup set
  9. channel ORA_DISK_1: restoring datafile 00001 to /data/data1/ORCL2/datafile/o1_mf_system_02t1t9ck_.dbf
  10. channel ORA_DISK_1: restore complete, elapsed time: 00:00:25
  11. channel ORA_DISK_1: starting datafile backup set restore
  12. channel ORA_DISK_1: using network backup set from service primary_db
  13. channel ORA_DISK_1: specifying datafile(s) to restore from backup set
  14. channel ORA_DISK_1: restoring datafile 00003 to /data/data1/ORCL2/datafile/o1_mf_sysaux_03t1t9d3_.dbf
  15. channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
  16. channel ORA_DISK_1: starting datafile backup set restore
  17. channel ORA_DISK_1: using network backup set from service primary_db
  18. channel ORA_DISK_1: specifying datafile(s) to restore from backup set
  19. channel ORA_DISK_1: restoring datafile 00004 to /data/data1/ORCL2/datafile/o1_mf_undotbs1_04t1t9di_.dbf
  20. channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
  21. channel ORA_DISK_1: starting datafile backup set restore
  22. channel ORA_DISK_1: using network backup set from service primary_db
  23. channel ORA_DISK_1: specifying datafile(s) to restore from backup set
  24. channel ORA_DISK_1: restoring datafile 00006 to /data/data1/ORCL2/datafile/o1_mf_users_05t1t9dm_.dbf
  25. channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
  26. Finished restore at 2018-05-03 17:01:34


當然要記得去起庫並開啟實時日誌應用程式！

而在12.2中，Oracle提供了一種更方便的方式去進行恢復主庫會將未記錄的塊的列表傳送至備庫，並記錄在備庫控制檔案中，我們可以從備庫的v$nonlogged_block這個檢視檢視到相關資訊。不需要傳送主庫的整個資料檔案，而是在RMAN執行一個簡單的命令來恢復它們：

RECOVER DATABASE NONLOGGED BLOCK

步驟一 

停止備庫實時日誌應用

點選(此處)摺疊或開啟

  1. SQL> alter database recover managed standby database cancel;


步驟二 

備庫登陸RMAN執行

RECOVER DATABASE NONLOGGED BLOCK 

注意：執行此步驟前請確認主備庫的log_archive_config引數已經設定

點選(此處)摺疊或開啟

  1. RMAN> recover database nonlogged block;
  2. Starting recover at 2018-05-03 14:54:22
  3. using target database control file instead of recovery catalog
  4. allocated channel: ORA_DISK_1
  5. channel ORA_DISK_1: SID=56 device type=DISK
  6. starting recovery of nonlogged blocks
  7. List of Datafiles
  8. =================
  9. File Status Nonlogged Blocks Blocks Examined Blocks Skipped
  10. ---- ------ ---------------- --------------- --------------
  11. 1 OK 0 0 107519
  12. 3 OK 0 0 262399
  13. 4 OK 0 0 149759
  14. 5 OK 0 0 31999
  15. 6 OK 0 0 42239
  16. 7 OK 0 16707 21532
  17. 8 OK 0 0 12799
  18. 9 OK 0 0 76799
  19. 18 OK 0 0 33279
  20. 19 OK 0 0 57599
  21. 20 OK 0 0 24959
  22. 21 OK 0 0 33279
  23. 22 OK 0 0 51199
  24. 23 OK 0 0 12799
  25. 29 OK 0 0 1310719
  26. 30 OK 0 0 12799
  27. 31 OK 0 0 33279
  28. 32 OK 0 0 52479
  29. 33 OK 0 0 923519
  30. 34 OK 0 16822 8777
  31. 35 OK 0 0 12799
  32. 37 OK 0 0 24959
  33. Details of nonlogged blocks can be queried from v$nonlogged_block view
  34. recovery of nonlogged blocks complete, elapsed time: 00:00:08
  35. Finished recover at 2018-05-03 14:54:32

最後別忘了開啟實時日誌應用程式。

綜上來看，12.2中這個特性在資料倉儲等一些場景是可以嘗試的。以往我們開啟force logging造成大量的redo日誌並且影響一部分dml語句的執行效率。在12.2我們可以嘗試使用nonlogging操作去節省大量資料插入的時間，然後在系統空閒時間進行備庫恢復操作。但是注意這種操作也存在弊端，這樣你的備庫的可用性就大大降低了。凡事總有取捨！


|  作者簡介

陳康，沃趣科技資料庫技術專家

主要參與公司產品實施、測試、維護以及最佳化。


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/28218939/viewspace-2154509/，如需轉載，請註明出處，否則將追究法律責任。

相關文章