关于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
学习。。。
博客之前的老文章怎么都看不到了?今天上来查看些资料,发现很多文章都看不到了。
换过一次blog平台,重新整理过一遍,以前的好多文章都写得不好,所以就没再放上去
即使你认为不好的文章对于我们来讲,也很有价值。
有些经典的文章也找不到了。
毕竟人的精力是有限的,你不可能重写所有的文章啊。
谢谢这么看得起我!需要哪些文章你可以告诉我,我可以把那些文章发给你。
详细解析9i和10g的datafile header
能否将这个文章发给我
能否将你之前的文章发给我拜读一下:
之前已经写过:
“详细解析9i和10g的datafile header”
“详细解析LMT的datafile的物理结构”
“详细解析datafile的status”
万分感谢。
你换了blog,相关文章也没有了, 真可惜。。。。
给力,又学习了新的知识。。
好希望能快点看到你自己出的书,关于sql优化方面的。。
上面提的是从11g创建dblink到10g,那从10g创建一个dblink到11g的结果呢?
自己测试了,不论哪个方向创建,都按高scn同步。