手动修改oracle scn号,SCN(系统改变号)

1. scn: system change number

用以标识数据库在某个确切时刻提交的版本.

数据库的内部逻辑时钟.

每个数据库都有一个全局的SCN生成器.

它会随着外部变化的加快而加快变化，在数据文件和控制文件里各存放一个SCN号，然后恢复(主要是介质恢复)的时候它们会进行比对，

一般情况下，这俩个文件里的SCN号是一致的；非正常情况下，要根据实时情况判断这俩个文件里的SCN号的大小

ORACLE通过SCN维护数据库的一致性,

以及实施至关重要的恢复机制.

SCN的获取

(1)select dbms_flashback.get_system_change_number from dual; 9i

(2)select current_scn from v$database; 10g

(3)select max(ktuxescnw*power(2,32)+ktuxescnb) from x$ktuxe; before 9i

(4)从内存中获取SCN

sys:

sql>oradebug setmypid

sql>oradebug DUMPvar SGA kcsgscn_

kcslf kcsgscn_ [20009104, 20009124) =

00000000 000704BD 000007D2 00000000 00000000 00000000 00000000 20008F10

sql>select to_number('704BD','xxxxxx') SCN from dual;

select to_number('1078F3','xxxxxx') SCN from dual;

观察scn变化速率

不繁忙时:

select current_scn from v$database;

繁忙时:

set serveroutput on

declare

a number;

begin

for i in 1..100 loop

select current_scn into a from v$database;

dbms_output.put_line(a);

end loop;

end;

/  **执行上面的PL/SQL语句

2. 转储control file和数据文件头信息

控制文件保存的信息:

DB名称,创建时间

所有数据文件和日志文件名称和路径

表空间信息

备份信息

检查点和SCN信息

归档信息

sqlplus sys/oracle as sysdba

SQL> show parameter user_dump_dest

/opt/oracle/admin/LH/udump

quit

cd /opt/oracle/admin/LH/udump

rm *.trc

sqlplus sys/oracle as sysdba

alter session set events

'immediate trace name controlf level 8';

quit

ll lh_ora_17702.trc

vi lh_ora_17702.trc

观察内容

转储数据文件头信息

cd /opt/oracle/admin/LH/udump

rm *.trc

sqlplus sys/oracle as sysdba

alter session set events

'immediate trace name file_hdrs level 10';

quit

vi .trc

每个数据文件头信息都会转储出来

观察内容

转储日志文件

cd /opt/oracle/admin/LH/udump/

rm *.trc

sqlplus sys/oracle as sysdba

alter system dump logfile '/opt/oracle/oradata/lh/redo01.log';

quit

vi  lh_ora_11346.trc

low scn

next scn

标识该日志文件包含这2个值之间的信息

CKPT:

工作:

(1)向DBWR布置写数据文件

(2)更新控制文件,数据文件头信息,记录检查点

触发:

(1)redolog切换

(2)alter system checkpoint;

(3)将tbs->offline,read only,backup

(4)初始化参数

log_checkpoint_interval

log_checkpoint_timeout

3.

v$database.checkpoint_change#      记录最后一次检查点发生控制文件的SCN

(the scn of ckpt in controlfile)

select checkpoint_change# from v$database;

v$datafile_header.checkpoint_change#   记录最后一次检查个个数据文件的SCN

(the scn of every datafile in every datafile)

select checkpoint_change# from v$datafile_header;

v$datafile.checkpoint_change#    记录最后一次检查个个控制文件的SCN

(the scn of every datafile in controlfile)

select checkpoint_change# from v$datafile;

v$datafile.last_change#     (select last_change# from v$datafile;)

每个数据文件的终止scn都存储在controlfile中

在正常的数据库操作过程中，

所有正处于联机读写模式下的数据文件的终止scn都为null.

用以标识数据库或数据文件是否正常关闭

[当数据库是read only open模式,

v$database.current_scn=0]

在安全关闭数据库的过程中，系统会执行一个检查点动作，

这时所有数据文件的终止scn,都会设置成数据文件头中

的那个checkpoint_change#的值。

在数据库重新启动的时候，需要校验

(1)数据文件头部的 checkpoint cnt 与

控制文件中的   checkpoint cnt

是否一致,如不一致,停止往下进行,

如一致,继续校验

(2)数据文件头的SCN对应控制文件的结束SCN是否一致

Oracle将v$datafile_header.checkpoint_change#与v$database.checkpoint_change#进行比较 (介质恢复)

(比较v$datafile_header和v$database的checkpoint_change#)

如果这两个值相互匹配，oracle接下来还要比较v$datafile_header.checkpoint_change#和v$datafile.last_change# (实例恢复)

(比较v$databasefile_header的checkpoint_change#和v$databasefile的last_change#)

**实例恢复是由SMON，自动恢复

*1.如果这两个值也一致，就意味着所有数据块都已经提交，所有对数据库的修改都没有

在关闭数据库的过程中丢失，因此这次启动数据库的过程也不需要任何恢复操作，此时数据库就可以打开了。

*2.当所有的数据文件都打开之后，存储在控制文件中的v$datafile.last_change#的值再次被

更改为null，这表示数据文件已经打开并能够正常使用了。

在数据文件打开过程中,

如果v$datafile_header.checkpoint_change#

与v$database.checkpoint_change#不同,需要介质恢复

如果v$datafile_header.checkpoint_change#

和v$datafile.last_change#不同,需要实例恢复

open:

select checkpoint_change# from v$database          622419

select checkpoint_change# from v$datafile          622419

select last_change# from v$datafile                null

select checkpoint_change# from v$datafile_header   622419

(1)正常关闭

ORACLE_SID=LH

sqlplus sys/oracle as sysdba

shutdown immediate              把所有数据文件的终止scn(null),都会设置成数据文件头中的那个checkpoint_change#的值

startup mount

select checkpoint_change# from v$database          623414

select checkpoint_change# from v$datafile          623414

select last_change# from v$datafile                623414

select checkpoint_change# from v$datafile_header   623414

alter database open;

比较v$datafile_header.checkpoint_change#与v$database.checkpoint_change#

比较v$datafile_header.checkpoint_change#和v$datafile.last_change#

select checkpoint_change# from v$database          623415

select checkpoint_change# from v$datafile          623415

select last_change# from v$datafile                null

select checkpoint_change# from v$datafile_header   623415

(2)非正常关闭

在ORACLE打开状态下,断电,直接关机

启动OS

ORACLE_SID=LH

sqlplus sys/oracle as sysdba

startup mount

select checkpoint_change# from v$database          623415

select checkpoint_change# from v$datafile          623415

select last_change# from v$datafile                null

select checkpoint_change# from v$datafile_header   623415

alter database open;

比较v$datafile_header.checkpoint_change#与v$database.checkpoint_change#

比较v$datafile_header.checkpoint_change#和v$datafile.last_change#不同,需要实例恢复

tail -f -n 300 alert_LH.log

SMON: enabling cache recovery

SMON: enabling tx recovery

select checkpoint_change# from v$database          645765

select checkpoint_change# from v$datafile          645765

select last_change# from v$datafile                null

select checkpoint_change# from v$datafile_header   645765

(3)介质恢复(DBA要介入)

open:

ORACLE_SID=LH

sqlplus sys/oracle as sysdba

alter database begin backup;

$ cp tbs16.dbf tbs16.dbf.bak

sqlplus sys/oracle as sysdba

select checkpoint_change# from v$database          517792

select checkpoint_change# from v$datafile          517962

select last_change# from v$datafile                null

select checkpoint_change# from v$datafile_header   517962

alter database end backup;

select checkpoint_change# from v$database          517792

select checkpoint_change# from v$datafile          517962

select last_change# from v$datafile                null

select checkpoint_change# from v$datafile_header   517962

shutdown immediate

$ mv  tbs16.dbf.bak  tbs16.dbf

startup mount

select checkpoint_change# from v$database          518771

select checkpoint_change# from v$datafile          518771

select file#,last_change# from v$datafile          518771

select file#,checkpoint_change# from v$datafile_header 518771   (7)  517962

alter database open;  比较v$datafile_header.checkpoint_change#与v$database.checkpoint_change#不同,需要介质恢复

ORA-01113: file 7 needs media recovery

recover database;

Media recovery complete.

select checkpoint_change# from v$database          518771

select checkpoint_change# from v$datafile          518771

select file#,last_change# from v$datafile          518771 (7) 518770

select file#,checkpoint_change# from v$datafile_header 518771   (7)  518770

alter database open;   比较v$datafile_header.checkpoint_change#和v$datafile.last_change# 不同,需要实例恢复

SMON: enabling cache recovery

SMON: enabling tx recovery

select checkpoint_change# from v$database          518772

select checkpoint_change# from v$datafile          518772

select file#,last_change# from v$datafile          null

select file#,checkpoint_change# from v$datafile_header 518772

sqlplus sys/oracle as sysdba

SQL> oradebug setmypid

sql> oradebug dump controlf 4

$ORACLE_BASE/admin/hj/udump/hj_ora_4198.trc

我们可以看到所有的数据文件Stop scn: 0xffff.ffffffff，这是一个极大的值，说明我们的数据库是打开的。我们知道，shutdown abort的时候，

没有checkpoint，控制文件也不会被更新，当数据库重新启动的时候，Oracle会发现这个SCN仍然是这个极大值，和数据库的Checkpoint SCN不一样，

此时数据库就会进行恢复，只有当这两个SCN一样，数据库才能OPEN。

redo: 已提交,datafile想要,但没有,需要应用redologfile里的redo sql

undo: 未提交,datafile不想要,但有了,需要应用undofile里的undo信息