oracle创建dblinks出现scn,关于oracle dblink 使scn 增加

关于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会置这个隐含参数于不顾。

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

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

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

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

先连到名为orcl的10.2.0.1的库：

SQL> connsys/oracle@orcl93as sysdba;

Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.1.0

Connected as SYS

可以看到系统目前的SCN：

SQL> select current_scn from v$database;

CURRENT_SCN

-----------

1073742097

这个库scott.emp的有14行记录：

SQL> select count(*) from scott.emp;

COUNT(*)

----------

14

再另起一个session，连到名为orcl112的11.2.0.1的库：

SQL> connsys/oracle@orcl93as sysdba;

Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.1.0

Connected as SYS

从orcl94中创建一个到上述10.2.0.1的库orcl93的dblink：

SQL> create public database link orcl93 connect to scott identified by tiger using 'ORCL93';

Database link created.

可以看到在orcl112中，系统目前的SCN仅为178492：

SQL> select current_scn from v$database;

CURRENT_SCN

-----------

178492

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

SQL> select count(*) fromemp@orcl93;

COUNT(*)

----------

14

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

SQL> select current_scn from v$database;

CURRENT_SCN

-----------

1073742731

我们再来看第二个实例：

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

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

SQL> startup pfile='D:\oracle\oradata\orcl\initorcl.ora'

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;

修改initorcl.ora文件，添加*._minimum_giga_scn=12260：

*.undo_management='AUTO'

*.undo_retention=3600

*.undo_tablespace='UNDOTBS1'

*.user_dump_dest='D:\oracle\admin\orcl\udump'

*._minimum_giga_scn=12260

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

SQL> startup pfile='D:\oracle\oradata\orcl\initorcl.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;

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

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

SCN

----------

11443.3593

修改initorcl.ora文件，将_minimum_giga_scn的值改为11443：

*._minimum_giga_scn=11443

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

SQL> startup pfile='D:\oracle\oradata\orcl\initorcl.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