Oracle中DG備庫undo工作模式是什么

這篇文章主要講解了“Oracle中DG備庫undo工作模式是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Oracle中DG備庫undo工作模式是什么”吧！

一：修改主庫備庫undo表空間

1.在主庫創建undo表空間(會自動同步到備庫)

SYS@prod>create undo tablespace smallundo datafile '/u01/app/oracle/oradata/prod/smallundo.dbf' size 2M;

修改undo表空間

SYS@prod>alter system set undo_tablespace=smallundo;

2.在備庫修改undo表空間  //由于備庫處于redo only模式，無法在線修改undo_tablespace

SYS@stddb>shutdown immediate

[oracle@service2 dbs]$ cd $ORACLE_HOME/dbs

修改參數文件 *.undo_tablespace='smallundo'

SYS@stddb>create spfile from pfile

SYS@stddb>startup

主庫:

SYS@prod>show parameter undo;  

NAME                                     TYPE         VALUE

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

undo_management                      string         AUTO

undo_retention                             integer         900

undo_tablespace                      string         SMALLUNDO

備庫：

SYS@stddb>show parameter undo

NAME                                     TYPE         VALUE

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

undo_management                      string         AUTO

undo_retention                             integer         900

undo_tablespace                      string         smallundo

二 ：測試

1.在主庫創建test表：

SYS@prod>create table test (id number)；

SYS@prod>insert into test(id) values(1)；

SYS@prod>commit;

2.在備庫模擬長時間的查詢操作：

SYS@stddb>variable rfc refcursor

SYS@stddb>execute open :rfc for select * from test；

3.在主庫執行循環更新操作：

SYS@prod>

begin

  for i in 1..20000 loop

  update test set id = 3;

  commit;

  end loop;

end;

4.在備庫獲取查詢結果：

SYS@stddb>print :rfc

ERROR:

ORA-01555: snapshot too old: rollback segment number 13 with name"_SYSSMU13_2332596898$" too small

三：結論

在備庫執行查詢語句出現的ORA-01555與主庫出現的ORA-01555原因是沒區別的，主備的undo塊是實時同步的，

本次測試中，采用的非自動擴展的undo表空間,由于表空間無法自動擴展，會優先保留Active有可用空間，會將已經提交事務的undo data覆蓋掉，即使沒有滿足undo retention的保留時間，所以會出現ORA-01555錯誤

當長時間查詢的SQL語句，無法從undo中獲得前映像構造CR塊就會出現ORA-01555錯誤

例如：

A會話執行一條查詢語句，查詢數據行數為10億行，B會話執行一條delete語句，刪除1億行數據，然后進行提交，當B會話事務提交成功后，A數據才查詢到這1億行數據，此時需要undo data來構造一致性讀，如果此時undo date被覆蓋，那么就會出現Ora-01555錯誤。

備庫CR塊構造：

主備同步時，如果主庫進行一個事務，但是這個未提交，在備庫查詢，需要構造CR塊滿足查詢，結合當前塊和undo塊生成CR塊。

//與主庫構造CR模式相同，也可以理解為在備庫上查詢和在主庫上查詢使用的undo是沒區別的

測試:

SYS@prod>select * from test;

ID

----------

 3

SYS@stddb>select object_name,object_id from dba_objects where object_name='TEST' and owner='SYS';

//查詢test表的object_id

OBJECT_NAME              OBJECT_ID

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

TEST                          88641

在主庫進行一次修改操作：

SYS@prod>update test set id = 1;

1 row updated.

在主庫備庫查詢塊狀態：

SYS@prod>select obj,state from x$bh where state = 3 and obj=88641;

No rows selected.

SYS@stddb>select obj,state from x$bh where state = 3 and obj=88641;

No rows selected.

執行查詢操作：

SYS@stddb>select * from test;

ID

----------

 3

在主備庫查詢test表構造CR塊情況：

SYS@prod>select obj,state from x$bh where state = 3 and obj=88641;

       OBJ        STATE

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

     88641            3

     88641            3

SYS@stddb>select obj,state from x$bh where state = 3 and obj=88641;

       OBJ        STATE

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

     88641            3

     88641            3

3是CR模式

備庫的redo工作模式：

主庫的redo日志進行日志切換時，備庫的redo日志也會隨之切換，但是沒有任何意義，僅僅算是同步，也不記錄警告日志。

SYS@stddb>select group#,status from v$log;

    GROUP# STATUS

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

 1 CURRENT

 2 CLEARING

 3 CLEARING

備庫的redo只有current與clearing兩種狀態。

感謝各位的閱讀，以上就是“Oracle中DG備庫undo工作模式是什么”的內容了，經過本文的學習后，相信大家對Oracle中DG備庫undo工作模式是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！