11g中關於控制檔案自動備份的改進(r6筆記第22天)
在之前做一個測試演示的時候,使用的是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
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'
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的基礎上還是做了很多的改進和優化,很多功能的細節之中都加入了更多的考量,從這一點上來說,控制檔案的延時自動備份還是合理的。 我們在分析這個問題的時候,還是需要細心,自己主動去發現問題,自己先去求證,再檢視官方的解釋,沒準就會有意外的收穫。