WINDOWS下的程序员出身,偶尔也写一些linux平台下小程序, 后转行数据库行业,专注于ORACLE和DB2的运维和优化。 同时也是ios移动开发者。欢迎志同道合的朋友一起研究技术。 数据库技术交流群:58308065,23618606
全部博文(599)
分类: Oracle
2012-04-27 15:48:37
1、SCN会随着dblink从高向低扩散;
2、过大的SCN可能会导致Oracle数据库打不开;
第一点倒是知道,第二点还真不清楚。
在步入正题之前,先普及一下关于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
原文地址: