oracle切换scn,在ORACLE中增进SCN及案例介绍

在oracle数据库中我们可以利用oracle的内部事件调整SCN。增进SCN通常有两种常用方法:

1.alter session set events 'IMMEDIATE trace name ADJUST_SCN level x';

--需要数据库OPEN

2.通过10015事件

alter session set events '10015 trace name adjust_scn level x';

--在数据库无法打开，mount状态下。

注:level 1为增进SCN 10亿 (1 billion) (1024*1024*1024=1073741824)

测试：

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER

------------------------

571904

SQL> alter session set events 'IMMEDIATE trace name ADJUST_SCN level 1';

Session altered

--10g的告警日志会报这样的错：

Tue Mar 31 17:01:00 2009

Errors in file c:\oracle\product\10.2.0\admin\orasjh\udump\orasjh_ora_2208.trc:

ORA-01031: 权限不足

查看trace文件，有这样的报错：

...

Clearing ORA-1031 thrown by trace 'ADJUST_SCN'

----- Dump for trace 'ADJUST_SCN': -----

*** 2009-03-31 17:01:00.828

ksedmp: internal or fatal error

ORA-01031: 权限不足

Current SQL statement for this session:

...

我在9i测试是没问题的。

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER

------------------------

1073766630

在测试一下在数据库关闭的情况下SCN的增进。

SQL> shutdown immediate;

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

SQL>

SQL> startup mount

ORACLE 例程已经启动。

Total System Global Area  147921840 bytes

Fixed Size                   453552 bytes

Variable Size             121634816 bytes

Database Buffers           25165824 bytes

Redo Buffers                 667648 bytes

数据库装载完毕。

SQL> alter session set events '10015 trace name adjust_scn level 10';

会话已更改。

SQL> alter database open;

数据库已更改。

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER

------------------------

1.0737E+10

SQL>

增进SCN的意义？

在解决ORA-00600: internal error code, arguments: [2662]错误的时候会用到。

这里转载一个案例：

参考地址：

客户那边数据库突然出现一个current日志文件坏了，导致数据库crash了，然后现场工程师使用_ALLOW_RESETLOGS_CORRUPTION = TRUE这个隐含参数，做了不完全恢复后强行将数据库打开。可是打开数据库后发现只能用internal用户连接进去，别的用户连接都报错，错误信息如下：

ORA-00600: internal error code, arguments: [2662], [0], [431267936], [0], [431273216], [0], [], []

查询不了任何应用的表，应用也没法使用，于是想尝试全库的exp出来然后重新imp进去建库，结果发现exp数据也不成功，也是报同样的ORA-600的错误，用户当时数据没有任何的备份过，只能想办法尽量打开数据库，导出数据了。

处理过程：

先检查了600错误产生的trace文件：

*** SESSION ID:(7.15) 2004.11.23.23.28.16.824

ksedmp: internal or fatal error

ORA-00600: internal error code, arguments: [2662], [0], [431267754], [0], [431272752], [0], [], []

Current SQL statement for this session:

SELECT * FROM "WHSB"."SB_BSBF"得到的信息有限，只能看到是严重内部错误，剩下的都是内存堆栈的一堆信息，于是查找了一下这个错误的具体相关信息。

ORA-600 [2662] "Block SCN is ahead of Current SCN"，说明当前数据库的数据块的SCN早于当前的SCN，主要是和存储在UGA变量中的dependent SCN进行比较，如果当前的SCN小于它，数据库就会产生这个ORA-600 [2662]的错误了。这个错误一共有五个参数，分别代表不同的含义，

ORA-600 [2662] [a] [b] [c] [d] [e]

Arg [a] Current SCN WRAP

Arg [b] Current SCN BASE

Arg [c] dependent SCN WRAP

Arg [d] dependent SCN BASE

Arg [e] Where present this is the DBA where the dependent SCN came from.

我们分析错误中的提示，它的参数b=431267754,d=431272752,表明当前的SCN确实是小于dependent SCN，所以产生了这个600的错误。通过查阅文档，发现这个错误的产生原因主要有以下几条：

1.使用隐含参数_ALLOW_RESETLOGS_CORRUPTION后resetlogs打开数据库

2.硬件错误引起数据库没法写控制文件和重做日志文件

3.错误的部分恢复数据库

4.恢复了控制文件但是没有使用recover database using backup controlfile进行恢复

5.数据库crash后设置了_DISABLE_LOGGING隐含参数

6.在并行服务器环境中DLM存在问题

仔细对比了一下，发现问题可能是由于第一条产生的，由于设置了_ALLOW_RESETLOGS_CORRUPTION这个隐含参数后，虽然强制性的打开数据库，但是数据库本身存在了corruption，仍然存在严重的问题。于是想到使用ADJUST_SCN事件来调整当前的SCN，使其大于dependent SCN，然后保证数据库可以全库的导出，然后重建数据库导入数据。用internal用户登陆数据库后，连接别的用户，还是失败报错，执行：

alter session set events 'IMMEDIATE trace name ADJUST_SCN level 1';

然后尝试连接别的用户，连接成功。最后exp整个数据库，重建数据库后导入数据，整个数据库恢复成功！

通过这个实例，我们可以看到，尽量的不要去使用那些隐含参数，这些参数是oracle所不推荐使用的，也不是万能的！如果使用了可能会存在一些遗留的问题，如果非要使用，建议使用后一定要exp/imp重建建立数据库。