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

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

 

在步入正题之前,先普及一下关于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

 


11 Comments on “关于SCN另外两个有趣的知识点”

  1. saup007 says:

    学习。。。

  2. ok0329 says:

    博客之前的老文章怎么都看不到了?今天上来查看些资料,发现很多文章都看不到了。

    • Cui Hua says:

      换过一次blog平台,重新整理过一遍,以前的好多文章都写得不好,所以就没再放上去

      • cc says:

        即使你认为不好的文章对于我们来讲,也很有价值。
        有些经典的文章也找不到了。
        毕竟人的精力是有限的,你不可能重写所有的文章啊。

  3. 随风 says:

    详细解析9i和10g的datafile header
    能否将这个文章发给我

    • 狼来了 says:

      能否将你之前的文章发给我拜读一下:
      之前已经写过:
      “详细解析9i和10g的datafile header”

      “详细解析LMT的datafile的物理结构”

      “详细解析datafile的status”

      万分感谢。

  4. wxjzqymtl says:

    给力,又学习了新的知识。。
    好希望能快点看到你自己出的书,关于sql优化方面的。。

  5. jyc says:

    上面提的是从11g创建dblink到10g,那从10g创建一个dblink到11g的结果呢?


Leave a Reply

Your email address will not be published. Required fields are marked *