Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2880523
  • 博文数量: 599
  • 博客积分: 16398
  • 博客等级: 上将
  • 技术积分: 6875
  • 用 户 组: 普通用户
  • 注册时间: 2009-11-30 12:04
个人简介

WINDOWS下的程序员出身,偶尔也写一些linux平台下小程序, 后转行数据库行业,专注于ORACLE和DB2的运维和优化。 同时也是ios移动开发者。欢迎志同道合的朋友一起研究技术。 数据库技术交流群:58308065,23618606

文章分类

全部博文(599)

文章存档

2014年(12)

2013年(56)

2012年(199)

2011年(105)

2010年(128)

2009年(99)

分类: Oracle

2012-04-27 15:48:37


 
从崔大师网站上看到的关于SCN的相关知识:
 

1SCN会随着dblink从高向低扩散;

2、过大的SCN可能会导致Oracle数据库打不开;

 

第一点倒是知道,第二点还真不清楚。

 

 

 

在步入正题之前,先普及一下关于OracleSCN的基本知识点:

1OracleSCN在每秒16384commit的情况下可以维持534年,每秒16384commitOracle早先认为的任何系统的极限commit强度;

2OracleSCN的起点是198811

3_minimum_giga_scn=n的含义是把SCN往前推进到nG,但请注意,只有在SCN小于nG的时候才会用到这个隐含参数,反之则Oracle会置这个隐含参数于不顾。

 

好了,我们进入正题,这篇文章里要阐述的两个关于SCN的有趣的知识点如下:

1SCN会随着dblink从高向低扩散;

2、过大的SCN可能会导致Oracle数据库打不开;

 

好了,我们来看两个证明上述观点的实例:

一、SCN会随着dblink从高向低扩散:

先连到名为cuihua10.2.0.1的库:

SQL> conn sys/oracle@cuihua as sysdba;

Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.1.0

Connected as SYS

 

可以看到系统目前的SCN

SQL> select dbms_flashback.get_system_change_number() from dual;

 

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

                    1073742134

 

当然,这个SCN会随着时间的推移而增长:

SQL> select dbms_flashback.get_system_change_number() from dual;

 

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

                    1073742140

 

这个库目前的对象数为51831

SQL> select count(*) from dba_objects;

 

  COUNT(*)

———-

     51831

 

再另起一个session,连到名为cuihua11211.2.0.1的库:

SQL> conn sys/oracle@cuihua112 as sysdba;

Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.1.0

Connected as SYS

 

cuihua112中创建一个到上述10.2.0.1的库cuihuadblink

SQL> create public database link cuihua connect to scott identified by tiger using ‘cuihua’;

 

Database link created

 

可以看到在cuihua112中,系统目前的SCN仅为2100672

SQL> select dbms_flashback.get_system_change_number() from dual;

 

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

                       2100672

 

当然,这个SCN会随着时间的推移而增长,但是增长的幅度有限(因为这个库很闲,我什么事情也没做):

SQL> select dbms_flashback.get_system_change_number() from dual;

 

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

                       2100673

 

接着,我通过刚建的dblink去查一下cuihua中的对象数,结果是51831,和之前的查询结果一致:

SQL> select count(*) from dba_objects@cuihua;

 

  COUNT(*)

———-

     51831

 

接着我们马上再次查询系统的SCN,发现结果已经从之前的2100673猛增到1073742966,这个实际上已经足以证明SCN会随着dblink从高向低扩散

SQL> select dbms_flashback.get_system_change_number() from dual;

 

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

                    1073742966

 

 

好了,我们再来看第二个实例:

二、过大的SCN可能会导致Oracle数据库打不开(我只测试了10.2.0.1

现在这个名为10.2.0.1的库cuihua是可以正常打开的:

SQL> startup pfile=’D:\oracle\oradata\cuihua\initcuihua.ora’

ORACLE 例程已经启动。

 

Total System Global Area  608174080 bytes

Fixed Size                  1250404 bytes

Variable Size             209718172 bytes

Database Buffers          390070272 bytes

Redo Buffers                7135232 bytes

数据库装载完毕。

数据库已经打开。

 

今天是2012324

SQL> select sysdate from dual;

 

SYSDATE

——————————

2012-3-24 22:04:17

 

2012324距离198811290.741935月:

SQL> select months_between (to_date(’20120324′,’YYYYMMDD’),to_date(’19880101′,’YYYYMMDD’) ) “MONTHS” from dual;

 

    MONTHS

———-

290.741935

 

在每秒16384的极限commit强度下,要超过当前时间(即要超过290.741935月,我这里选用了300),只需要将_minimum_giga_scn递增到12260即可:

SQL> select 16384*60*60*24*31*300/(1024*1024*1024) SCN from dual;

 

       SCN

———-

12260.7421

 

Shutdown上述库:

SQL> shutdown immediate;

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

 

修改initcuihua.ora文件,添加*._minimum_giga_scn=12260

*.undo_management=’AUTO’

*.undo_retention=3600

*.undo_tablespace=’UNDOTBS1′

*.user_dump_dest=’D:\oracle\admin\cuihua\udump’

*._minimum_giga_scn=12260

 

改完后再启库的时候发现已经启动不了了,但这里Oracle报的错误是莫名其妙的:

SQL> startup pfile=’D:\oracle\oradata\cuihua\initcuihua.ora’

ORACLE 例程已经启动。

 

Total System Global Area  608174080 bytes

Fixed Size                  1250404 bytes

Variable Size             209718172 bytes

Database Buffers          390070272 bytes

Redo Buffers                7135232 bytes

数据库装载完毕。

ORA-01052: 未指定所需的目标 LOG_ARCHIVE_DUPLEX_DEST

 

SQL> select status from v$instance;

 

STATUS

————

MOUNTED

 

SQL> shutdown immediate;

ORA-01109: 数据库未打开

 

 

已经卸载数据库。

ORACLE 例程已经关闭。

 

再在cuihua112中计算一下,不超过当前时间(即不超过290.741935月,我这里选用了280)的_minimum_giga_scn的值应该是11443

SQL> select 16384*60*60*24*31*280/(1024*1024*1024) SCN from dual;

 

       SCN

———-

11443.3593

 

修改initcuihua.ora文件,将_minimum_giga_scn的值改为11443

*.undo_management=’AUTO’

*.undo_retention=3600

*.undo_tablespace=’UNDOTBS1′

*.user_dump_dest=’D:\oracle\admin\cuihua\udump’

*._minimum_giga_scn=11443

 

改完后上述库又可以成功启动了:

SQL> startup pfile=’D:\oracle\oradata\cuihua\initcuihua.ora’

ORACLE 例程已经启动。

 

Total System Global Area  608174080 bytes

Fixed Size                  1250404 bytes

Variable Size             209718172 bytes

Database Buffers          390070272 bytes

Redo Buffers                7135232 bytes

数据库装载完毕。

数据库已经打开。

 

SQL> select dbms_flashback.get_system_change_number() from dual;

 

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

                12286827692577

 

从结果里可以看到,SCN确实被我们推进到了我们想要推进的值:

SQL> select dbms_flashback.get_system_change_number()/(1024*1024*1024) from dual;

 

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

              11443.0000005225

 



原文地址:

阅读(1261) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~