关于SCN另外两个有趣的知识点

Posted: March 24, 2012 | Author: Cui Hua | Filed under: Oracle | 11 Comments »

首先声明一下，这篇文章的结论来源于我昨天在机场接姗姗妈的时候跟大熊的讨论，并不是我的原创。

 

在步入正题之前，先普及一下关于Oracle里SCN的基本知识点：

1、Oracle的SCN在每秒16384次commit的情况下可以维持534年，每秒16384次commit是Oracle早先认为的任何系统的极限commit强度；

2、Oracle里SCN的起点是1988年1月1日；

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

 

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

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

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

 

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

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

先连到名为cuihua的10.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，连到名为cuihua112的11.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的库cuihua的dblink：

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

数据库装载完毕。

数据库已经打开。

 

今天是2012年3月24日：

SQL> select sysdate from dual;

 

SYSDATE

——————————

2012-3-24 22:04:17

 

2012年3月24日距离1988年1月1日有290.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

 

---