在之前做一個測試演示的時候，使用的是11gR2的庫，在說rman的備份配置的時候有一個功能時控制檔案的自動備份，
CONFIGURE CONTROLFILE AUTOBACKUP ON/OFF;
然後自己簡單介紹了下，說controlfile autobackup功能還是蠻實用的，一般還是建議開啟。之前自己在10g的環境中也測試過，印象中資料庫級的一些操作，比如建立表空間，刪除資料檔案等等，都會重新生成對應的控制檔案，然而在演示的時候，竟然還是掉了鏈子。
我們建立了一個表空間，沒有自動備份控制檔案，然後我們又建立了一個表空間，還是沒有生成備份控制檔案，在短時間內做了幾個操作，都沒有生成控制檔案的備份，自己都有點懷疑資料庫是不是故意不配合啊。如果這樣，rman裡面配置控制檔案的自動備份感覺就沒有什麼實際意義了。
回來後，自己找了套10gR2的庫，做了同樣的操作，這個時候autobackup的功能又好使了。
我們短時間內建立了一個表空間，然後刪除，然後再建立。
SQL> create tablespace data3 datafile '/u02/oracle/oradata/TEST10G/data03.dbf' size 5M;1

Tablespace created.

SQL> drop tablespace data3;

Tablespace dropped.

SQL> create tablespace data3 datafile '/u02/oracle/oradata/TEST10G/data03.dbf' size 5M reuse;

Tablespace created.

檢視控制檔案的備份路徑，發現生成了3個對應的控制檔案備份。儘管大小都一樣。
-rw-r----- 1 oracle dba 14745600 Aug 8 23:16 ctl_c-1135735312-20150808-0d
-rw-r----- 1 oracle dba 14745600 Aug 8 23:17 ctl_c-1135735312-20150808-0e
-rw-r----- 1 oracle dba 14745600 Aug 8 23:17 ctl_c-1135735312-20150808-0f
這個時候就有些疑惑，倒底在演示的環境和自己之後測試環境有哪些不同之處，翻來覆去找差別，也做了一些測試，發現原來還是資料庫版本的不同。
在10g的版本中，開啟控制檔案的自動備份，這個時候發生了建立表空間，資料檔案變更的操作時，會立即生成控制檔案的備份。
當然在11g裡面也不是不生成控制檔案，在一定的時候之後，檢視備份目錄還是會生成一個備份控制檔案。所以控制檔案自動備份功能還是起作用的，但是似乎還是有一定的延遲。
對於這個問題，沒有立刻就檢視官方文件求證，自己從一些trace日誌裡面挖掘挖掘，看看有什麼發現。
結果我把延時建立的控制檔案的時間戳和關鍵字在trace檔案裡搜了一圈，發現有一個檔案中剛好有我需要找的內容。
less TEST_m000_6627.trc
Starting control autobackup
*** 2015-08-01 21:11:08.014
Control autobackup written to DISK device
handle '/u02/ora11g/flash_recovery_area/TEST/ctl_c-2182319634-20150801-10'
透過日誌就能夠看到，後臺是開始做了一個autobackup的操作，
這個時候檢視了metalink，找到一篇相關的文章。
RMAN CONTROLFILE AUTOBACKUP NOT CREATED DURING DB STRUCTURE CHANGE (文件 ID 1068182.1)
在這篇文章中解釋了這個延時的原因，還是基於效能的考慮。避免因為大量的資料庫級變更產生了大量的控制檔案備份。‘
官方的解釋還是比較詳細的。會在後臺觸發MMON去做控制檔案的自動備份。

FIX

Beginning with Oracle Database Release 11g Release 2, Controlfile Autobackup Deferral feature has been implemented、
In order to increase performance the controlfile autobackup creation after structural changes, has been deferred.
In previous releases, one controlfile autobackup is created with each DDL command that makes structural changes in the database and we can see in the alert.log a message about controlfile autobackup creation after each DDL command executed. This can provoke serious performance problems when multiple structural changes are made together.

From Oracle Database Release 11g Release 2, RMAN takes only one control file autobackup when multiple structural changes contained in a script have been applied (for example, adding tablespaces, altering the state of a tablespace or datafile, adding a new online redo log, renaming a file, and so on ) .

In this release, the controlfile autobackups are created by MMON slaves after few minutes of the structural changes, which increases performance.

So, It's the expected behaviour to get the controlfile autobackup several minutes after the structural change on the database and it's also expected that no message about controlfile autobackup creation will appear in the alert.log.
There will be generated one MMON slave trace file with the controlfile creation information, that will be a file named:
SID__m000_<OS_PID>.trc

當然我們可以更近一步，比如我們知道控制檔案備份是一個延時的過程，那麼這個延時的預設值是多少呢，是5分鐘。
1 select a.ksppinm name, b.ksppstvl value, a.ksppdesc description
2    from x$ksppi a, x$ksppcv b
3* where a.indx = b.indx and a.ksppinm like '%control%delay%'
NAME                           VALUE                DESCRIPTION
------------------------------ -------------------- --------------------------------------------------------------------------------
_controlfile_autobackup_delay 300                  time delay (in seconds) for performing controlfile autobackups

所以透過這個案例我們可以發現很多時候在10g的基礎上還是做了很多的改進和最佳化，很多功能的細節之中都加入了更多的考量，從這一點上來說，控制檔案的延時自動備份還是合理的。
我們在分析這個問題的時候，還是需要細心，自己主動去發現問題，自己先去求證，再檢視官方的解釋，沒準就會有意外的收穫。

11g中關於控制檔案自動備份的改進

FIX

相關文章