ITPub博客

首页 > 数据库 > Oracle > Oracle 探索DG备库undo工作模式

Oracle 探索DG备库undo工作模式

原创 Oracle 作者:DBhanG 时间:2020-06-24 14:21:09 0 删除 编辑

模拟备库出现 ORA-01555 分析备库 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两种状态。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/69975956/viewspace-2700466/,如需转载,请注明出处,否则将追究法律责任。

上一篇: Oracle 单实例补丁
请登录后发表评论 登录
全部评论

注册时间:2020-05-28

  • 博文量
    59
  • 访问量
    42172