ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 【听海日志】之SCN与Oracle

【听海日志】之SCN与Oracle

原创 Linux操作系统 作者:听海★蓝心梦 时间:2012-04-12 19:45:26 0 删除 编辑

一、SCN基础

1、什么是SCN

Concepts中是这样描述SCN的:

A system change number (SCN) is a logical, internal timestamp used by Oracle Database. SCNs order events that occur within the database, which is necessary to satisfy the ACID properties of a transaction. Oracle Database uses SCNs to mark the SCN before which all changes are known to be on disk so that recovery avoids applying unnecessary redo. The database also uses SCNs to mark the point at which no redo exists for a set of data so that recovery can stop.

怎么理解这个“SCN(系统变更号)是供Oracle数据库使用的一个逻辑的、内部的时间戳”呢?要理解这个先需要理解Oracle中的事务(Transaction)和数据一致性(Data Consistency)的概念。

先说说数据一致性的概念。数据一致性指的是数据的可用性。比如说管理一个财务的系统,需要从A账户将100元转入到B账户,正常的操作是从A账户减去100元,然后给B账户加上100元,如果这两步操作都正常完成了,那我们可以说完成转账操作之后的数据是一致可用的;但是如果在操作的过程中出了问题,A账户的100元给减掉了,但是B账户却没有加上100元,这样的情况下产生的结果数据就有问题了,因为部分操作的失败导致了数据的不一致而不可用,在实际中肯定是要避免这种让数据不一致的情况发生的。在Oracle数据库中,保证数据一致性的方法就是事务。

事务是一个逻辑的、原子性的作业单元,通常由一个或者是多个SQL组成,一个事务里面的所有SQL操作要么全部失败回滚(Rollback),要么就是全部成功提交(Commit)。就像上面转账的例子,为保证数据的一致性,就需要将转账的两步操作放在一个事务里面,这样不管哪个操作失败了,都需要将所有已进行的操作回滚,以保证数据的可用性。进行事务管理是数据库区别于别的文件系统的一个最主要的特征,在数据库中事务最主要的作用就是保证了数据的一致性,每次事务的提交都是将数据库从一种一致性的状态带入到另外一种一致性的状态中,SCN就是用来对数据库的每个一致状态进行标记的,每当数据库进入到一个新的一致的状态,SCN就会加1,也就是每个提交操作之后,SCN都会增加。也许你会想为什么不直接记录事务提交时候的时间戳呢?这里面主要是涉及了两个问题,一个是时间戳记录的精度有限,再一个就是在分布式系统中记录时间戳会存在系统时钟同步的问题,详细的讨论可以查看Ordering Events in Oracle

SCN在数据库中是一个单一的不断的随着数据库一致性状态的改变而自增的序列。正如一个时间戳代表着时间里面的某一个固定的时刻点一样,每一个SCN值也代表着数据库在运行当中的一个一致性的点,大的SCN值所对应的事务总是比小SCN值的事务发生的更晚。因此把SCN说成是Oracle数据库的逻辑时间戳是很恰当的。

2SCN概述

SCN是当Oracle数据库更新后,由DBMS去自动维护累积递增的一个数字。通常看文章的时候能看到各种类型的SCN,但是严格来说SCN是没有分类的,之所以会有不同类型的SCN并不是说这些SCN的概念不一样,而是说不同分类的SCN代表的意义不一样,不管什么时候SCN所指代的都是数据库的某个一致性的状态。就像我们给一天中的某个时间点定义上班时间、另外的某个时间点定义成下班时间一样,数据库Checkpoint发生点的SCN被称为Checkpoint SCN,仅此而已。Oracle数据库中一共有4SCN分别为:

•系统检查点SCN (System Checkpoint SCN)

•文件检查点SCN (Datafile Checkpoint SCN)

•结束SCN (Stop SCN)

•数据文件头SCN (Start SCN)

其中前面3SCN存在于控制文件中,最后一种则存在于数据文件的文件头中,在Oracle中用来标识数据库的每一次改动,及其先后顺序,SCN的最大值是0xffff.ffffffff。在控制文件中,System Checkpoint SCN是针对整个数据库全局的,因而只存在一个,而Datafile Checkpoint SCNStop SCN是针对每个数据文件的,因而一个数据文件就对应在控制文件中存在一份Datafile Checkpoint SCNStop SCN。在数据库正常运行期间,Stop SCN(通过视图v$datafile的字段last_change#可以查询)是一个无穷大的数字或者NULL

1、系统检查点SCN

系统检查点SCN位于控制文件中,当检查点进程启动时(ckpt)Oracle就把系统检查点的SCN存储到控制文件中。该SCN是全局范围的,当发生文件级别的SCN时,例如将表空间置于只读状态,则不会更新系统检查点SCN。查询系统检查点SCN的命令如下:

sys@ORCL> select CHECKPOINT_CHANGE# from v$database;

CHECKPOINT_CHANGE#

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

        21655892

2、文件SCN

ckpt进程启动时,包括全局范围的(比如日志切换)以及文件级别的检查点(将表空间置为只读、begin backup或将某个数据文件设置为offline等),这时会在控制文件中记录的SCN。查询数据文件SCN的命令如下:

sys@ORCL> alter tablespace users read only;

Tablespace altered.

sys@ORCL> select file#,checkpoint_change# from v$datafile;

     FILE# CHECKPOINT_CHANGE#

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

       1        21655892

       2        21655892

       3        21655892

       4        21657577

       5        21657577

       6        21655892

 

6 rows selected.

sys@ORCL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

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

        21655892

可以看到45号文件也就是users表空间所属的文件SCN值和其他文件不一致,且比系统检查点的SCN要大(因为这两个数据文件最后被操作,其他数据文件没有变动)

3、结束SCN

每个数据文件都有一个结束SCN,在数据库的正常运行中,只要数据文件在线且是可读写的,结束SCNNULL。否则则存在具体的SCN值。结束SCN也记录在控制文件中。

sys@ORCL> select TABLESPACE_NAME,STATUS from dba_tablespaces;

TABLESPACE_NAME              STATUS

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

SYSTEM                         ONLINE

SYSAUX                         ONLINE

UNDOTBS1                    ONLINE

TEMP                        ONLINE

USERS                            READ ONLY

sys@ORCL> select file#,LAST_CHANGE# from v$datafile;        

     FILE# LAST_CHANGE#

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

       1

       2

       3

       4     21657577

       5     21657577

       6

 

6 rows selected.

可以看到除了users表空间的结束SCN不为空,其他数据文件的结束SCN为空。将数据库至于mount状态,由于该状态下所有的数据文件都不可写,故mount状态下所有的数据文件都具有结束SCN

sys@ORCL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

sys@ORCL> startup mount

ORACLE instance started.

 

Total System Global Area  263049216 bytes

Fixed Size              2212448 bytes

Variable Size               230690208 bytes

Database Buffers         25165824 bytes

Redo Buffers                4980736 bytes

Database mounted.

sys@ORCL> select file#,last_change# from v$datafile;

 

     FILE# LAST_CHANGE#

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

       1     21657939

       2     21657939

       3     21657939

       4     21657577

       5     21657577

       6     21657939

 

6 rows selected.

4、数据文件头SCN

不同于上述的SCN数据文件开始SCN记录在每个数据文件中。当发生系统及文件级别的检查点后,不仅将这时的SCN号记录在控制文件中,同样也记录在数据文件中。查询数据文件头SCN的命令如下:

sys@ORCL> select file#,CHECKPOINT_CHANGE# from v$datafile_header;

 

FILE# CHECKPOINT_CHANGE#

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

       1        21657939

       2        21657939

       3        21657939

       4        21657577

       5        21657577

       6        21657939

 

6 rows selected.

3SCN相关概念

1Redo log中的high SCNlow SCN

OracleRedo log会顺序纪录数据库的各个变化。一组redo log文件写满后,会自动切换到下一组redo log文件。则上一组redo loghigh SCN就是下一组redo loglow SCN。在current loghigh SCN为无穷大。可通过查询v$log_history查看 low SCN high SCN

sys@ORCL> select recid,sequence#,first_change#,next_change# from v$log_history;

     RECID SEQUENCE# FIRST_CHANGE#      NEXT_CHANGE#

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

       1      2      21,069,995        21,085,568

       2      1      21,085,569        21,105,418

       3      2      21,105,418        21,132,018

       4      3      21,132,018        21,163,953

       5      4      21,163,953        21,191,900

       6      5      21,191,900        21,209,347

       7      6      21,209,347        21,223,812

       8      7      21,223,812       21,232,963

       9      8      21,232,963        21,263,223

      10      9      21,263,223        21,288,586

      11     10      21,288,586        21,301,971

      12      1      21,300,115        21,324,025

      13      2      21,324,025        21,344,131

      14      3      21,344,131        21,347,920

      15      4      21,347,920        21,369,784

      16      5      21,369,784        21,374,509

      17      6      21,374,509        21,374,914

      18      7      21,374,914        21,375,336

      19      8      21,375,336        21,384,136

      20      9      21,384,136        21,409,089

      21     10      21,409,089        21,446,217

      22     11      21,446,217        21,496,982

      23     12      21,496,982        21,509,283

      24     13      21,509,283        21,545,787

      25     14      21,545,787        21,564,418

      26     15      21,564,418        21,581,068

      27     16      21,581,068        21,582,611

      28     17      21,582,611        21,582,860

      29     18      21,582,860        21,583,942

      30     19      21,583,942        21,609,862

      31     20      21,609,862        21,630,988

      32     21      21,630,988        21,655,891

 

32 rows selected.

2、查看currnet redolog中的high SCN

sys@ORCL> select vf.member,v.status,v.first_change# from v$logfile vf,v$log v where vf.group#=v.group# and v.status='CURRENT';

MEMBER                                 STATUS         FIRST_CHANGE#

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

/opt/oracle/oradata/orcl/redo01.log              CURRENT        21,655,891

sys@ORCL> alter system dump logfile '/opt/oracle/oradata/orcl/redo01.log';

System altered.

sys@ORCL> show parameter user_dump

NAME                      TYPE  VALUE

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

user_dump_dest          string /opt/oracle/diag/rdbms/orcl/orcl/trace

打开转储出来的文件,可以看到:

DUMP OF REDO FROM FILE '/opt/oracle/oradata/orcl/redo01.log'

 Opcodes *.*

 RBAs: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff

 SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff

 Times: creation thru eternity

 FILE HEADER:

      Compatibility Vsn = 186646528=0xb200000

      Db ID=1284637334=0x4c920296, Db Name='ORCL'

      Activation ID=1296530476=0x4d477c2c

      Control Seq=19392=0x4bc0, File size=102400=0x19000

      File Number=1, Blksiz=512, File Type=2 LOG

 descrip:"Thread 0001, Seq# 0000000022, SCN 0x0000014a7153-0xffffffffffff"

 thread: 1 nab: 0xffffffff seq: 0x00000016 hws: 0x5 eot: 1 dis: 0

 resetlogs count: 0x2dd248e0 scn: 0x0000.01450393 (21300115)

 prev resetlogs count: 0x2dce6ef7 scn: 0x0000.0141bd81 (21085569)

 Low  scn: 0x0000.014a7153 (21655891) 03/20/2012 09:18:56

 Next scn: 0xffff.ffffffff 01/01/1988 00:00:00

 Enabled scn: 0x0000.01450393 (21300115) 12/01/2011 15:18:56

 Thread closed scn: 0x0000.014a7953 (21657939) 03/20/2012 09:43:56

 Disk cksum: 0x202e Calc cksum: 0x202e

 Terminal recovery stop scn: 0x0000.00000000

 Terminal recovery  01/01/1988 00:00:00

 Most recent redo scn: 0x0000.00000000

 Largest LWN: 0 blocks

 End-of-redo stream : No

 Unprotected mode

 Miscellaneous flags: 0x800000

 Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000

redo log中当前系统的SCN记录当前最新的数据库SCN值可通过如下命令查看:

sys@ORCL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER

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

             21658581

如果需要进行实例恢复,则需恢复的记录为2165589121658581redo log中的记录。

3、日志切换或者checkpoint

当日志切换或发生checkpoint时,从Low SCNNext SCN之间的所有redo记录的数据就被DBWn进程写入数据文件中,而CKPT进程则将所有数据文件(无论redo log中的数据是否影响到该数据文件)的文件头上记录的Start SCN(通过视图v$datafile_header的字段checkpoint_change#可以查询)更新为Next SCN,同时将控制文件中的System Checkpoint SCN(通过视图v$database的字段checkpoint_change#可以查询)、每个数据文件对应的Datafile Checkpoint(通过视图v$datafile的字段checkpoint_change#可以查询)也更新为Next SCN。但是,如果该数据文件所在的表空间被设置为read-only时,数据文件的Start SCN和控制文件中Datafile Checkpoint SCN都不会被更新。

4、心跳

Oracle中有一个事件叫Heartbeat,这个词在很多地方被提及,并且有着不同的含义(比如RAC),我们这里要讨论的是CKPTHeartbeat机制。Oracle通过CKPT进程每3秒将Heartbeat写入控制文件,以减少故障时的恢复时间。

5、数据库正常关闭启动

数据库正常关闭时,系统会执行一个完全检查点动作,并用该检查点时的SCN号更新上述4SCN号,这时所有数据文件的终止SCN号会设置为数据文件头的那个启动SCN(除了离线和只读的数据文件)。

数据库重新启动时,Oracle将数据文件头中的启动SCN与数据文件检查点SCN比较,如果这两个值匹配,Oracle接下来再比较数据文件头中的SCN和控制文件中数据文件的终止SCN,如果这个值也匹配,就意味着所有数据块已经提交,因此数据库不需要进行恢复,此时数据库直接打开。当所有的数据文件都打开之后,在线且可读写的数据文件终止SCN再次被设置为NULL,表示数据文件已经打开并能够正常使用了。有些表空间是只读的,这时控制文件中的系统检查点SCN号会不断增长,而数据文件SCN号和文件头中的启动SCN(会停止更新直到表空间又设置为可读写),显然这时系统检查点SCN号会大于数据文件SCN和文件头启动SCN

6、数据库非正常关闭

数据库非正常关闭(或称为实例崩溃)时,终止SCN不会被设置,依然为NULL,这可以通过把数据库启动至mount状态查询出来。这样重新启动时,SMON进程会执行实例恢复工作,即先执行前滚,再把数据库打开,最后执行回滚操作。

7、数据文件介质故障

出现介质故障时,数据文件检查点SCN及系统检查点SCN比文件头启动SCN大。系统发生介质故障时,数据文件被以前的备份代替,控制文件中的数据文件检查点SCN肯定比文件头中的启动SCN要大,这样Oracle就知道要对这个文件进行介质恢复。

8、控制文件介质故障

系统检查点SCN及数据文件SCN比数据文件头启动SCN小:

在数据库恢复时,控制文件可能不是最新的,即把一个较早的控制文件还原为当前的控制文件,然后再执行恢复操作,这时控制文件中的系统检查点SCN和数据文件SCN可能比文件头的启动SCN小。这时恢复数据库要用下面命令:recover database using Backup Controlfile或其他的恢复语句。

9、备份时的实例崩溃

当执行begin backup时实例崩溃:控制文件中的数据文件检查点SCN号和数据文件头部检查点SCN号相同,但是每个可读写的在线数据文件之间检查点SCN号不同,那么要求介质恢复,例如发出begin backup命令后就会出现这种情况,需要通过end backup命令好才可以打开数据库。

4SCN查看与转换

1、查看系统当前的SCN

Oracle数据库提供了两种直接查看系统当前SCN的方法,一个是V$DATABASE中的CURRENT_SCN列,另外一个就是通过dbms_flashback.get_system_change_number得到。

sys@ORCL> col SCN for 9999999999999

sys@ORCL> SELECT current_SCN SCN FROM v$database;

         SCN

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

      21660463

sys@ORCL> SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER SCN FROM DUAL;

         SCN

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

      21660479

如果你好奇心足够的话也许会执行下面的语句,然后发现一个“惊讶”的结果:

sys@ORCL> col SCN for 9999999999999

sys@ORCL> col SCN2 for 9999999999999

sys@ORCL> SELECT current_SCN SCN,DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER SCN2 FROM v$database;

         SCN              SCN2

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

      21660533           21660534

不过请不要惊讶,这个很正常,毕竟语句的执行时需要时间的,虽然很短,不过还是能发生很多的事情。

2SCN与时间的相互转换

一个SCN值总是发生在某一个特定的时刻的,只不过由于粒度的不一样,通常会存在多个SCN对应同一个时间戳。Oracle中提供了两个函数以供我们进行SCN和时间的互换:

SCN_TO_TIMESTAMP(SCN_number) SCN转换成时间戳。

TIMESTAMP_TO_SCN(timestamp) 将时间戳转换成SCN

下面就举几个例子来说明:

SCN转换成时间戳

sys@ORCL> SELECT SCN_TO_TIMESTAMP(21660534) timestamp FROM DUAL;

TIMESTAMP

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

20-3 -12 10.38.32.000000000 上午   -- 将时间戳转换成

sys@ORCL> SELECT TIMESTAMP_TO_SCN(TO_TIMESTAMP('20-3-12 10.38.32.000000000','DD-Mon-RR HH:MI:SS.FF A.M.')) SCN FROM DUAL;

         SCN

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

      2 1660533

很明显的能看到同样的时间戳,转换出来的SCN就是不一样,其根本原因就是粒度问题了。

3ORA_ROWSCN伪列

10g开始,Oracle提供了一个名为ORA_ROWSCN的伪列来让我们更近距离的接触SCN这个东西,利用这个伪列能很清楚的观察提交(Commit)操作对于表中SCN的影响。

我们先来建立以下测试的数据表和数据(例子延伸自《Oracle9i & 10g编程艺术》一书),下面的例子进行两次,两次唯一的不同在于建表时参数不一样,我们通过这个来观察SCN记录的一些行为。

试验一:

建立表

test@ORCL> CREATE TABLE t (x INT);

Table created.

插入数据

test@ORCL> BEGIN FOR i IN 1 .. 5 LOOP

INSERT INTO t VALUES(i );

COMMIT;

END LOOP;

END;

/

查看结果

SYS@ORCL> SELECT x, ORA_ROWSCN SCN,DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) BLOCKNO FROM t ORDER BY 2;

       X        SCN    BLOCKNO

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

       1   21661219     146911

       2   21661219     146911

       5   21661219     146911

       4   21661219     146911

       3   21661219     146911

试验二:

建立表

test@ORCL> CREATE TABLE t (x INT) ROWDEPENDENCIES;

Table created.

插入数据

test@ORCL> BEGIN FOR i in 1 .. 5 LOOP

INSERT INTO t VALUES (i);

COMMIT;

END LOOP;

END;

/

查看结果

test@ORCL> SELECT x, ORA_ROWSCN SCN, DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) blockno FROM t ORDER BY 2;

       X        SCN    BLOCKNO

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

       1   21661327     146919

       2   21661329     146919

       3   21661330     146919

       4   21661332     146919

       5   21661334     146919

试验一中每行数据的SCN数据都是一样的,如果根据我们现在对SCN的理解的话每次提交之后SCN应该变化才对的,那问题出在哪里呢?问题就出在默认情况下Oracle数据库记录SCN是以数据库为单位记录的,因为在数据库读取数据的时候都是以数据块单位,而不是以行为单位的。

要想达到按行记录SCN就必须在创建表的时候使用ROWDEPENDENCIES参数,ROWDEPENDENCIES用于打开一个数据表的行级的追踪,在行级维护SCN记录,使得我们能清楚的看到每次提交操作对于SCN的影响。试验二就是使用表的ROWDEPENDENCIES特性之后的结果。

注:ROWDEPENDENCIES有个重要的作用是用来实现乐观锁定(Optimistic Locking),这个在《Oracle9i & 10g编程艺术》一书中有详细的描述。

5SCN的作用

SCN描述的是数据一致性的状态,自然的它就会在各种涉及数据一致性的场合中起到重要作用的,下面列举的就是其中的一部分:

 •读数据的一致性

 •数据库恢复

 •Flashback

 •Stream

 •等等其他的

说这个的原因就是想说SCNOracle中的应用无处不在,理解SCN是理解数据库许多其他功能工作原理的基础。

在数据库启动过程中,当System Checkpoint SCN、Datafile Checkpoint SCN和Start SCN号都相同时,数据库可以正常启动,不需要做media recovery。三者当中有一个不同时,则需要做media recovery。

如果在启动的过程中,End SCN号为NULL,则需要做instance recovery。这种情况一般是数据库不正常关闭导致。ORACLE在启动过程中首先检查是否需要media recovery,然后再检查是否需要instance recovery。

二、SCN机制解析

1、事务中的SCN

SCNSystem Chang Number)作为oracle中的一个重要机制,在数据恢复、Data GuardStreams复制、RAC节点间的同步等各个功能中起着重要作用。理解SCN的运作机制,可以帮助你更加深入地了解上述功能。在理解SCN之前,我们先看下oracle事务中的数据变化是如何写入数据文件的:

1、事务开始;

2、在buffer cache中找到需要的数据块,否则,从数据文件中载入buffer cache中;

3、事务修改buffer cache的数据块,该数据被标识为“脏数据”,并被写入log buffer中;

4、事务提交,LGWR进程将log buffer中的“脏数据”写入redo log file中;

5、当发生checkpointCKPT进程更新所有数据文件的文件头中的信息,DBWn进程则负责将Buffer Cache中的脏数据写入到数据文件中。

经过上述5个步骤,事务中的数据变化最终被写入到数据文件中。但是,一旦在上述中间环节时,数据库意外宕机了,在重新启动时如何知道哪些数据已经写入数据文件、哪些没有写呢(同样,在DGstreams中也存在类似疑问:redo log中哪些是上一次同步已经复制过的数据、哪些没有)?SCN机制就能比较完善的解决上述问题。SCN是一个数字,确切的说是一个只会增加、不会减少的数字。正是它这种只会增加的特性确保了Oracle知道哪些应该被恢复、哪些应该被复制。

在一个事务提交后(上述第四个步骤),会在redo log中存在一条redo记录,同时,系统为其提供一个最新的SCN(通过函数dbms_flashback.get_system_change_number可以知道当前的最新SCN),记录在该条记录中。如果该条记录是在redo log被清空(日志满做切换时或发生checkpoint时,所有变化日志已经被写入数据文件中),则其SCN被记录为redo loglow SCN。以后在日志再次被清空前写入的redo记录中SCN则成为Next SCN

当日志切换或发生checkpoint(上述第五个步骤)时,从Low SCNNext SCN之间的所有redo记录的数据就被DBWn进程写入数据文件中,而CKPT进程则将所有数据文件(无论redo log中的数据是否影响到该数据文件)的文件头上记录的Start SCN(通过视图v$datafile_header的字段checkpoint_change#可以查询)更新为Next SCN,同时将控制文件中的System Checkpoint SCN(通过视图v$database的字段checkpoint_change#可以查询)、每个数据文件对应的Datafile Checkpoint(通过视图v$datafile的字段checkpoint_change#可以查询)也更新为Next SCN。但是,如果该数据文件所在的表空间被设置为read-only时,数据文件的Start SCN和控制文件中Datafile Checkpoint SCN都不会被更新。

2、产生最新的SCN

实际上,这个数字是由当时的timestamp转换过来的。每当需要产生一个最新的SCNredo记录时,系统获取当时的timestamp,将其转换为数字作为SCN。我们可以通过函数SCN_TO_TIMESTAMP10g以后)将其转换回timestamp

test@ORCL> select dbms_flashback.get_system_change_number get_scn, SCN_TO_TIMESTAMP(dbms_flashback.get_system_change_number) scn_to_timestamp from dual;

   GET_SCN SCN_TO_TIMESTAMP

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

  21662602 20-3 -12 11.21.47.000000000 上午

也可以用函数timestamp_to_scn将一个timestamp转换为SCN

test@ORCL> select timestamp_to_scn(SYSTIMESTAMP) as SCN from dual;

         SCN

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

      21662618

最后,SCN除了作为反映事务数据变化并保持同步外,它还起到系统的“心跳”作用——每隔3秒左右系统会刷新一次系统SCN

3SCN在数据库恢复中的作用

数据库在正常关闭(shutdown immediate/normal)时,会先做一次checkpoint,将log file中的数据写入数据文件中,将控制文件、数据文件中的SCN(包括控制文件中的Stop SCN)都更新为最新的SCN

数据库异常/意外关闭不会或者只更新部分Stop SCN

当数据库启动时,Oracle先检查控制文件中的每个Datafile Checkpoint SCN和数据文件中的Start SCN是否相同,再检查每个Datafile Checkpoint SCNStop SCN是否相同。如果发现有不同,就从Redo Log中找到丢失的SCN,重新写入数据文件中进行恢复。

SCN作为Oracle中的一个重要机制,在多个重要功能中起着“控制器”的作用。了解SCN的产生和实现方式,帮助DBA理解和处理恢复、DGStreams复制的问题。

利用SCN机制,在Oracle10g11g中又增加了一些很实用的功能——数据库闪回、数据库负载重现等。

1、使用using backup controlfile

1)使用备份控制文件。

2)重建resetlogs控制文件,如果重建noresetlogs不必要使用using backup controlfile

2alter database open resetlog

指定RESETLOGS将重设当前LOG sequence number1,抛弃所有日志信息。以下条件需要使用resetlog

1)在不完全恢复(介质恢复)。

2)使用备份控制文件。

使用resetlogs打开数据库后务必完整地备份一次数据库。

3create controlfile resetlogs/noresetlogs

1)用Noresetlogs重建控制文件时,控制文件中datafile Checkpoint来自Online logs中的Current log头。

2)用Resetlogs重建控制文件时,控制文件中datafile Checkpoint来自各数据文件头。

system SCN,datafile SCN,start SCN不全相等,需要介质恢复,如果stopSCN NULL需要实例恢复resetlogs抛弃所有在上一次恢复没有用到的日志信息,确保不被重新用与恢复。

4、各种异常情况需要的恢复

系统正常关闭:

system SCN=datafile SCN=start SCN=stop SCN

1) system SCN=datafile SCN=start SCN,不需要介质恢复。

2) stopSCN not NULL,不需要实例恢复。

系统异常关闭:

system SCN=datafile SCN=start SCNstop SCN NULL

1) system SCN=datafile SCN=start SCN,不需要介质恢复

2) stopSCN NULL,需要实例恢复

旧数据文件:

system SCN=datafile SCN>start SCNstop SCN NULL/notNULL

1) system SCN=datafile SCN>start SCN,需要介质恢复成system SCN=datafile SCN=start SCN

2) stopSCN NULL,需要实例恢复,not NULL不需要实例恢复。

备份控制文件:

system SCN=datafile SCN<=start SCN(当数据文件为旧的相等)stop SCN notNULL/NULL

1) system SCN=datafile SCN<=start SCN,需要使用using backup controlfile介质恢复成system SCN=datafile SCN=start SCN=current log SCN(当前日志最大SCN)

2) 为保证上一次恢复没有用到log日志不被使用,必须resetlogs

重建noresetlogs控制文件:

控制文件中 datafile Checkpoint来自Online logs中的Current log头。

current log SCN=system SCN=datafile SCN>=start SCN,stop SCN not NULL/NULL

1) current log SCN=system SCN=datafile SCN>=start SCN,需要介质恢复成system SCN=datafile SCN=start SCN=redolog SCN(当前日志最大SCN),stop SCN not NULL

2) stopSCN not NULL 不需要实例恢复。

重建resetlogs控制文件:

控制文件中datafile Checkpoint来自各数据文件头。

system SCN>=datafile SCN=start SCN,stop SCN not NULL/NULL

1) system SCN>=datafile SCN=start SCN,需要使用using backup controlfile介质恢复成system SCN=datafile SCN=start SCN(当前日志最大SCN),stop SCN not NULL

2) stop notNULL,因为SCN已经为redolog SCNlog已经不能使用,必须resetlogs

三、Oracle SCN研究

1SCN的管理方式

OracleSCN的管理,分为单节点和RAC两种方式。

1、单节点的instance

单节点的instance中,SCN值存在SGA区,由system commit number latch保护。任何进程要得到当前的SCN值,都要先得到这个latch

2RAC/OPS环境中

Oracle通过排队机制(Enqueue)实现SCN在各并行节点之间的顺序增长。具体有两种方法:

Lamport算法:又称面包房算法,先来先服务算法。跟很多银行采用的排队机制一样。客户到了银行,先领取一个服务号。一旦某个窗口出现空闲,拥有最小服务号的客户就可以去空闲窗口办理业务。

Commit广播算法:一有commit完成,最新的SCN就广播到所有节点中。

上述两种算法可以通过调整初始化参数max_commit_propagation_delay来切换。在多数系统(除了Compaq Tur64 Unix)中,该参数的默认值都是700厘秒(centisecond),采用Lamport算法。如果该值小于100厘秒,Oracle就采用广播算法,并且记录在alert.log文件中。

2、几种重要的SCN

1Commit SCN

当用户提交commit命令后,系统将当前SCN赋给该transaction。这些信息都反映在redo buffer中,并马上更新到redo log文件里。

2Offline SCN

除了System tablespace以外的任何表空间,当我们执行alter tablespaceoffline normal;命令时,就会触发一个checkpoint,将内存中的dirty buffer写入磁盘文件中。Checkpoint完成后,数据文件头会更新checkpoint SCNoffline normal SCN值。其中数据库文件头的checkpoint SCN值可通过查询列x$kccfe.fecps得到。

如果执行alter tablespaceoffline命令时采用temporaryimmediate选项,而不用normal选项时,offline normal SCN会被设成0。这样当数据库重启后通过resetlog方式打开时,该表空间就无法再改回在线状态。

3Checkpoint SCN

当数据库内存的脏数据块(dirty blocks)写到各数据文件中时,就发生一次checkpoint。数据库的当前checkpoint SCN值存在x$kccdi.diSCN中。Checkpoint SCN在数据库恢复中起着至关重要的作用。无论你用何种办法恢复数据库,只有当各个数据库文件的checkpoint SCN都相同时,数据库才能打开。

虽然参数“_allow_resetlogs_corruption”可以在checkpoint SCN不一致时强制打开数据库,但是这样的数据库在open后必须马上作全库的export,然后重建数据库并import数据。

4Resetlog SCN

数据库不完全恢复时,在指定时间点后的SCN都无法再应用到数据库中。Resetlog时的SCN就被设成当前数据库SCNredo log也会被重新设置。

5Stop SCN

Stop SCN记录在数据文件头上。当数据库处在打开状态时,stop SCN被设成最大值0xffff.ffffffff。在数据库正常关闭过程中,stop SCN被设置成当前系统的最大SCN值。在数据库打开过程中,Oracle会比较各文件的stop SCNcheckpoint SCN,如果值不一致,表明数据库先前没有正常关闭,需要做恢复。

6High and Low SCN

OracleRedo log会顺序纪录数据库的各个变化。一组redo log文件写满后,会自动切换到下一组redo log文件。则上一组redo loghigh SCN就是下一组redo loglow SCN

在视图v$log_history中,sequence#代表redo log的序列号,first_change#表示当前redo loglow SCN,列next_change#表示当前redo loghigh SCN

test@ORCL> col recid format 9999

test@ORCL> col requence# format 9999

test@ORCL> col first_change# format 9,999,999,999,999

test@ORCL> col next_change# format 9,999,999,999,999

test@ORCL> select recid,sequence#,first_change#,next_change# from v$log_history where rownum<6;

RECID SEQUENCE#      FIRST_CHANGE#  NEXT_CHANGE#

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

    1         2      21,069,995      21,085,568

    2         1      21,085,569      21,105,418

    3         2      21,105,418      21,132,018

    4         3      21,132,018      21,163,953

    5         4      21,163,953      21,191,900

3SCNoracle数据库恢复的关系

SCN号与oracle数据库恢复过程有着密切的关系,只有很好地理解了这层关系,才能深刻地理解恢复的原理,从而才能很好地解决这方面的问题。

CKPT进程在checkpoint发生时,将当时的SCN号写入数据文件头和控制文件,同时通知DBWR进程将数据块写到数据文件。CKPT进程也会在控制文件中记录RBA(redo byte address),以标志Recovery需要从日志中哪个地方开始。

1SCN不连续原因

1) 当发生日志组切换的时候。

2) 当符合LOG_CHECKPOINT_TIMEOUTLOG_CHECKPOINT_INTERVALfast_start_io_target,fast_start_mttr_target参数设置的时候。

3) 当运行ALTER SYSTEM SWITCH LOGFILE的时候。

4) 当运行ALTER SYSTEM CHECKPOINT的时候。

5) 当运行alter tablespace XXX begin backupend backup的时候。

6) 当运行alter tablespace ,datafile offline的时候。

2SCN与数据库启动

在数据库启动过程中,当System Checkpoint SCNDatafile Checkpoint SCNStart SCN号都相同时,数据库可以正常启动,不需要做media recovery.三者当中有一个不同时,则需要做media recovery。如果在启动的过程中,End SCN号为NULL,则需要做instance recoveryORACLE在启动过程中首先检查是否需要media recovery,然后再检查是否需要instance recovery

3SCN与数据库关闭

如果数据库的正常关闭的话,将会触发一个checkpoint,同时将数据文件的END SCN号设置为相应数据文件的Start SCN号。当数据库启动时,发现它们是一致的,则不需要做instance recovery。在数据库正常启动后,ORACLE会将END SCN号设置为NULL。如果数据库异常关闭的话,则END SCN号将为NULL

为什么需要System checkpoint SCN号与Datafile Checkpoint SCN号?为什么ORACLE会在控制文件中记录System checkpoint SCN号的同时,还需要为每个数据文件记录Datafile Checkpoint SCN号?

原因有二:

1) 对只读表空间,其数据文件的Datafile Checkpoint SCNStart SCNEND SCN号均相同。这三个SCN在表空间处于只读期间都将被冻结。

2) 如果控制文件不是当前的控制文件,则System checkpoint会小于Start SCNEND SCN号。记录这些SCN号,可以区分控制文件是否是当前的控制文件。

4Recovery database using backup controlfile

当有一个Start SCN号超过了System Checkpoit SCN号时,则说明控制文件不是当前的控制文件,因此在做recovery时需要采用using backup controlfile。这是为什么需要记录SystemCheckpoint SCN的原因之一。

这里需要一提的是,当重建控制文件的时候,System Checkpoint SCN0Datafile Checkpoint SCN的数据来自于Start SCN。根据上述的描述,此时需要采用using backup controlfilerecovery

重建控制文件方式分两种(resetlogsnoresetlogs):

1) 使用resetlogs选项时,System Checkpoint SCN为被归为0,而其中记录的各个数据文件的Datafile Checkpoint SCN则来自于Start SCN(也就是说可能会从冷备份的数据文件的数据文件头中获取)。根据上述的描述,此时需要采用using backup controlfilerecovery.因此情况是System Checkpoint SCN=0 < Start SCN = Datafile Checkpoint SCN

2) 使用noresetlogs选项时,有一个前提就是:一定要有online redo log的存在。否则就要使用resetlogs选项。这个时候控制文件重建好时,其system checkpoint SCN=Datafile Checkpoint SCN=Lastest Checkpoint SCN in online redo log,我们可以看到Datafile Checkpoint SCN并没有从Start SCN中读取。而是读取了最新的日志文件中的SCN作为自己的数据。此时重建的控制文件在恢复中的作用跟最新的控制文件类似,System Checkpoint SCN(已经读取最新的redo logcheckpoint SCN信息)可能会>Start SCN(因为数据文件可能会从冷备份中恢复),恢复时就不需要加using backup controlfile子句了。

关于backup controlfile的补充:

backup controlfile只有备份时刻的archive log信息,并没有DB crash时刻的archive log信息,所以并不会自动应用online redo log,而是提示找不到序号为Lastest Archive log sequence + 1archive log。尽管你可以手动指定online redo log来实现完全恢复,但因为一旦使用了using backup controlfile子句,Oracle就视为不完全恢复,必须open resetlogs。实际上,假如你有旧的控制文件又不想resetlogs,那很简单,使用旧的控制文件mount然后backup to trace,然后手工创建控制文件,使用reuse database ... noresetlogs这样就可以recover database自动恢复并open database而不用resetlogs(切记:必须有所有的online redo logs才可以这样!)。备份的控制文件不能自动进行完全恢复,可以手工apply日志进行完全恢复。

5、重建自动进行完全恢复示例

背景:

Oracle 11.2.0.1.0

Linux Enterprise RedHat 5

采用rman做热备,在备份期间,做不少事务,同时做alter system checkpoint

[oracle@localhost software]$ rman target /

Recovery Manager: Release 11.2.0.1.0 - Production on 星期二 3 20 15:15:38 2012

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

connected to target database: ORCL (DBID=1284637334)

RMAN> run {

2> allocate channel c1 type disk;

3> backup database filesperset 3 format '/software/full_%p_%t.bak';

4> release channel c1;

5> }

allocated channel: c1

channel c1: SID=35 device type=DISK

 

Starting backup at 20-3 -12

channel c1: starting compressed full datafile backup set

channel c1: specifying datafile(s) in backup set

input datafile file number=00005 name=/home/oracle/oradata/users02.dbf

input datafile file number=00001 name=/opt/oracle/oradata/orcl/system01.dbf

input datafile file number=00003 name=/opt/oracle/oradata/orcl/undotbs01.dbf

channel c1: starting piece 1 at 20-3 -12

channel c1: finished piece 1 at 20-3 -12

piece handle=/software/full_1_778432785.bak tag=TAG20120320T151945 comment=NONE

channel c1: backup set complete, elapsed time: 00:02:57

channel c1: starting compressed full datafile backup set

channel c1: specifying datafile(s) in backup set

input datafile file number=00004 name=/home/oracle/oradata/users01.dbf

input datafile file number=00002 name=/home/oracle/oradata/sysaux01.dbf

input datafile file number=00006 name=/home/oracle/oradata/undotbs02.dbf

channel c1: starting piece 1 at 20-3 -12

channel c1: finished piece 1 at 20-3 -12

piece handle=/software/full_1_778432963.bak tag=TAG20120320T151945 comment=NONE

channel c1: backup set complete, elapsed time: 00:01:45

Finished backup at 20-3 -12

 

Starting Control File and SPFILE Autobackup at 20-3 -12

piece handle=/home/oracle/dbbackup/ctl_20120320_c-1284637334-20120320-02 comment=NONE

Finished Control File and SPFILE Autobackup at 20-3 -12

 

released channel: c1

注:在这个备份角本里面我们加了filesperset 3。这样将整个数据库分成两个备份集。这样还原出来的数据文件其checkpoint_change#将不一样。否则由于数据库数据文件不多,都将包含在一个备份集中,这样即使在备份中做insert操作和alter system checkpoint也不会产生不同的checkpoint_change#。因为rman备份是将一个备份集中的文件同时备份的。而checkpoint_change#是存放在数据文件头部的,这样备份这些数据文件的头部的时间将是很快的。

然后模拟还原数据库:

sys@ORCL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

sys@ORCL> startup mount;

ORACLE instance started.

Total System Global Area  263049216 bytes

Fixed Size              2212448 bytes

Variable Size               234884512 bytes

Database Buffers         20971520 bytes

Redo Buffers                4980736 bytes

Database mounted.

RMAN> run {

2> allocate channel c1 type disk;

3> restore database;

4> release channel c1;

5> }

using target database control file instead of recovery catalog

allocated channel: c1

channel c1: SID=21 device type=DISK

 

Starting restore at 20-3 -12

 

channel c1: starting datafile backup set restore

channel c1: specifying datafile(s) to restore from backup set

channel c1: restoring datafile 00001 to /opt/oracle/oradata/orcl/system01.dbf

channel c1: restoring datafile 00003 to /opt/oracle/oradata/orcl/undotbs01.dbf

channel c1: restoring datafile 00005 to /home/oracle/oradata/users02.dbf

channel c1: reading from backup piece /software/full_1_778432785.bak

channel c1: piece handle=/software/full_1_778432785.bak tag=TAG20120320T151945

channel c1: restored backup piece 1

channel c1: restore complete, elapsed time: 00:02:27

channel c1: starting datafile backup set restore

channel c1: specifying datafile(s) to restore from backup set

channel c1: restoring datafile 00002 to /home/oracle/oradata/sysaux01.dbf

channel c1: restoring datafile 00004 to /home/oracle/oradata/users01.dbf

channel c1: restoring datafile 00006 to /home/oracle/oradata/undotbs02.dbf

channel c1: reading from backup piece /software/full_1_778432963.bak

channel c1: piece handle=/software/full_1_778432963.bak tag=TAG20120320T151945

channel c1: restored backup piece 1

channel c1: restore complete, elapsed time: 00:01:55

Finished restore at 20-3 -12

 

released channel: c1

sys@ORCL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

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

        21674485

sys@ORCL> select file#,checkpoint_change# from v$datafile;

  FILE#   CHECKPOINT_CHANGE#

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

       1        21674485

       2        21674485

       3        21674485

       4        21674485

       5        21674485

       6        21674485

6 rows selected.

sys@ORCL> select file#,checkpoint_change# from v$datafile_header;

     FILE# CHECKPOINT_CHANGE#

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

       1        21673534

       2        21673648

       3        21673534

       4        21673648

       5        21673534

       6        21673648

6 rows selected.

从这里可以看出,显然是需要做media recovery的。正常情况下,还需要做instance recovery。当然由于没有在线日志,所以只能做resetlogs

1) 有归档日志存

若有归档日志在,则只需要做一个recover database until cancel;然后即可alter database open resetlogs;

sys@ORCL> recover database until cancel;

ORA-00279: 更改 21673534 ( 03/20/2012 15:19:46 生成) 对于线程 1 是必需的

ORA-00289: 建议: /opt/oracle/flash_recovery_area/ORCL/archivelog/2012_03_20/o1_mf_1_22_7pjh1ss0_.arc

ORA-00280: 更改 21673534 (用于线程 1) 在序列 #22

Specify log: {=suggested | filename | AUTO | CANCEL}

auto

ORA-00279: 更改 21674803 ( 03/20/2012 16:13:45 生成) 对于线程 1 是必需的

ORA-00289: 建议: /opt/oracle/flash_recovery_area/ORCL/archivelog/2012_03_20/o1_mf_1_23_7pjh1vz3_.arc

ORA-00280: 更改 21674803 (用于线程 1) 在序列 #23

ORA-00278: 此恢复不再需要日志文件 '/opt/oracle/flash_recovery_area/ORCL/archivelog/2012_03_20/o1_mf_1_22_7pjh1ss0_.arc'

ORA-00279: 更改 21674806 ( 03/20/2012 16:13:47 生成) 对于线程 1 是必需的

ORA-00289: 建议: /opt/oracle/flash_recovery_area/ORCL/archivelog/2012_03_20/o1_mf_1_24_7pjh1z5h_.arc

ORA-00280: 更改 21674806 (用于线程 1) 在序列 #24

ORA-00278: 此恢复不再需要日志文件 '/opt/oracle/flash_recovery_area/ORCL/archivelog/2012_03_20/o1_mf_1_23_7pjh1vz3_.arc'

ORA-00279: 更改 21674809 ( 03/20/2012 16:13:51 生成) 对于线程 1 是必需的

ORA-00289: 建议: /opt/oracle/flash_recovery_area/ORCL/archivelog/2012_03_20/o1_mf_1_25_%u_.arc

ORA-00280: 更改 21674809 (用于线程 1) 在序列 #25

ORA-00278: 此恢复不再需要日志文件 '/opt/oracle/flash_recovery_area/ORCL/archivelog/2012_03_20/o1_mf_1_24_7pjh1z5h_.arc'

ORA-00308: 无法打开归档日志 '/opt/oracle/flash_recovery_area/ORCL/archivelog/2012_03_20/o1_mf_1_25_%u_.arc'

ORA-27037: 无法获得文件状态

Linux-x86_64 Error: 2: No such file or directory

Additional information: 3

sys@ORCL> alter database open resetlogs;

Database altered.

2) 无归档日志

如果没有归档日志,由于restore出来是没有在线日志的。如果v$datafile_headercheckpoint_change#是相同的,此时由于控制文件中checkpoint_change#比数据文件头中要高,所以数据库还是需要做media recovery

此时重建控制文件还是一样的,因为重建控制文件后,在控制文件中checkpoint_change#0,与文件头的checkpoint_change#还是不一样,还需要media recovery。且由于控制文件中checkpoint_change#比文件头中要高,所以做recover时还需要加上using backup controlfile

注:这时由于没有在线日志,所以重建控制文件需要将RESETLOGS改成RESETLOGS才可以创建成功,否则会报以下错误:

ORA-01565: error in identifying file 'D:ORACLE8IORADATAORA8IREDO01.LOG'

ORA-27041: unable to open file

此时SCN号信息如下:

sys@ORCL> select CHECKPOINT_CHANGE#,CONTROLFILE_CHANGE# from v$database;

CHECKPOINT_CHANGE#  CONTROLFILE_CHANGE#

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

  0                          0

此时由于没有归档日志和在线日志,无法做recovery。所以也就无法做alter database open Resetlogs了。此时可以加上_allow_resetlogs_corruption隐含参数,然后就可以alter database open resetlogs将数据库打开了。

当然如果v$datafile_headercheckpoint_change#是不相同的,那么此时就没有什么常归有效的办法能将数据库打开了。如果相差不多,加上隐含参数_allow_resetlogs_corruption,然后alter database open resetlogs还是有可能可以打开的。这个参数oracle是不建议加的,且加上这个参数也只是有可能可以打开。这个参数是以最oldestSCN将数据库打开,所以最好system数据文件的SCN号是最oldest的,否则容易产生大量的600号错误。

四、测试用例

1、查看正常关闭/启动过程

数据库正常关闭,在数据库启动过程中:当System Checkpoint SCN、Datafile Checkpoint SCN和Start SCN号都相同时,数据库可以正常启动

sys@ORCL> shutdown normal

Database closed.

Database dismounted.

ORACLE instance shut down.

sys@ORCL> startup mount

ORACLE instance started.

 

Total System Global Area  263049216 bytes

Fixed Size              2212448 bytes

Variable Size               234884512 bytes

Database Buffers         20971520 bytes

Redo Buffers                4980736 bytes

Database mounted.

sys@ORCL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

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

21677208

sys@ORCL> select checkpoint_change# from v$datafile;

CHECKPOINT_CHANGE#

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

        21677208

        21677208

        21677208

        21677208

        21677208

        21677208

6 rows selected.

SYS@ORCL> select checkpoint_change#,last_change# from v$datafile;

CHECKPOINT_CHANGE# LAST_CHANGE#

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

        21677208     21677208

        21677208     21677208

        21677208     21677208

        21677208     21677208

        21677208     21677208

        21677208     21677208

6 rows selected.

SYS@ORCL> select checkpoint_change# from v$datafile_header;

CHECKPOINT_CHANGE#

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

        21677208

        21677208

        21677208

        21677208

        21677208

        21677208

6 rows selected.

SYS@ORCL> alter database open;

Database altered.

看此时database的日志文件

Tue Mar 20 17:07:10 2012

ALTER DATABASE   MOUNT

Successful mount of redo thread 1, with mount id 1306217406

Allocated 3981120 bytes in shared pool for flashback generation buffer

Starting background process RVWR

Tue Mar 20 17:07:14 2012

RVWR started with pid=20, OS id=23412

Database mounted in Exclusive Mode

Lost write protection disabled

Completed: ALTER DATABASE   MOUNT

Tue Mar 20 17:11:27 2012

alter database open

Tue Mar 20 17:11:27 2012

LGWR: STARTING ARCH PROCESSES

Tue Mar 20 17:11:28 2012

ARC0 started with pid=21, OS id=23559

ARC0: Archival started

LGWR: STARTING ARCH PROCESSES COMPLETE

ARC0: STARTING ARCH PROCESSES

Tue Mar 20 17:11:29 2012

ARC1 started with pid=22, OS id=23561

Thread 1 opened at log sequence 1

  Current log# 1 seq# 1 mem# 0: /opt/oracle/oradata/orcl/redo01.log

Successful open of redo thread 1

MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set

Tue Mar 20 17:11:29 2012

SMON: enabling cache recovery

Tue Mar 20 17:11:29 2012

ARC2 started with pid=23, OS id=23563

ARC1: Archival started

ARC2: Archival started

ARC1: Becoming the 'no FAL' ARCH

ARC1: Becoming the 'no SRL' ARCH

Tue Mar 20 17:11:29 2012

ARC3 started with pid=24, OS id=23565

ARC2: Becoming the heartbeat ARCH

Successfully onlined Undo Tablespace 2.

Verifying file header compatibility for 11g tablespace encryption..

Verifying 11g file header compatibility for tablespace encryption completed

SMON: enabling tx recovery

Database Characterset is ZHS16GBK

No Resource Manager plan active

replication_dependency_tracking turned off (no async multimaster replication found)

ARC3: Archival started

ARC0: STARTING ARCH PROCESSES COMPLETE

Starting background process QMNC

Tue Mar 20 17:11:32 2012

QMNC started with pid=25, OS id=23567

Completed: alter database open

可以看到数据库正常启动没有做任何instance recovery,和media recovery

2END SCNNULL

如果在启动的过程中,End SCN号为NULL,则需要做instance recovery. 这种情况一般是数据库不正常关闭导致  测试如下:

SYS@ORCL> shutdown abort

ORACLE instance shut down.

SYS@ORCL> startup mount

­ORACLE instance started.

Total System Global Area  263049216 bytes

Fixed Size              2212448 bytes

Variable Size               234884512 bytes

Database Buffers         20971520 bytes

Redo Buffers                4980736 bytes

Database mounted.

SYS@ORCL> select checkpoint_change# from v$datafile_header;

CHECKPOINT_CHANGE#

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

        21677211

        21677211

        21677211

        21677211

        21677211

        21677211

6 rows selected.

SYS@ORCL> select checkpoint_change#,last_change# from v$datafile;

CHECKPOINT_CHANGE# LAST_CHANGE#

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

        21677211

        21677211

        21677211

        21677211

        21677211

        21677211        ----可以看到last_change# 下面的内容为NULL

6 rows selected.

SYS@ORCL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

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

      21677211

SYS@ORCL> alter database open;  -------在这个过程中做了实例恢复

Database altered.

此时日志文件中记录如下:

Tue Mar 20 17:15:03 2012

Shutting down instance (abort)

License high water mark = 3

USER (ospid: 23413): terminating the instance

Instance terminated by USER, pid = 23413

Tue Mar 20 17:15:04 2012

Instance shutdown complete

Tue Mar 20 17:15:32 2012

Starting ORACLE instance (normal)

LICENSE_MAX_SESSION = 0

LICENSE_SESSIONS_WARNING = 0

Picked latch-free SCN scheme 3

Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST

Autotune of undo retention is turned on.

IMODE=BR

ILAT =27

LICENSE_MAX_USERS = 0

SYS auditing is disabled

Starting up:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options.

Using parameter settings in server-side spfile /opt/oracle/product/db_1/dbs/spfileorcl.ora

System parameters with non-default values:

  processes                = 150

  sga_max_size             = 252M

  sga_target               = 152M

  control_files            = "/opt/oracle/oradata/orcl/control01.ctl"

  control_files            = "/opt/oracle/flash_recovery_area/orcl/control02.ctl"

  db_block_size            = 8192

  compatible               = "11.2.0.0.0"

  db_recovery_file_dest    = "/opt/oracle/flash_recovery_area"

  db_recovery_file_dest_size= 3882M

  db_flashback_retention_target= 30

  undo_tablespace          = "UNDOTBS1"

  remote_login_passwordfile= "EXCLUSIVE"

  db_domain                = ""

  dispatchers              = "(PROTOCOL=TCP) (SERVICE=orclXDB)"

  job_queue_processes      = 1000

  audit_file_dest          = "/opt/oracle/admin/orcl/adump"

  audit_trail              = "DB_EXTENDED"

  db_name                  = "orcl"

  open_cursors             = 300

  pga_aggregate_target     = 96M

  diagnostic_dest          = "/opt/oracle"

Tue Mar 20 17:15:33 2012

PMON started with pid=2, OS id=23761

Tue Mar 20 17:15:33 2012

VKTM started with pid=3, OS id=23763 at elevated priority

VKTM running at (10)millisec precision with DBRM quantum (100)ms

Tue Mar 20 17:15:33 2012

GEN0 started with pid=4, OS id=23767

Tue Mar 20 17:15:33 2012

DIAG started with pid=5, OS id=23769

Tue Mar 20 17:15:33 2012

DBRM started with pid=6, OS id=23771

Tue Mar 20 17:15:33 2012

PSP0 started with pid=7, OS id=23773

Tue Mar 20 17:15:33 2012

DIA0 started with pid=8, OS id=23775

Tue Mar 20 17:15:33 2012

MMAN started with pid=9, OS id=23777

Tue Mar 20 17:15:33 2012

DBW0 started with pid=10, OS id=23779

Tue Mar 20 17:15:33 2012

LGWR started with pid=11, OS id=23781

Tue Mar 20 17:15:33 2012

CKPT started with pid=12, OS id=23783

Tue Mar 20 17:15:33 2012

SMON started with pid=13, OS id=23785

Tue Mar 20 17:15:33 2012

RECO started with pid=14, OS id=23787

Tue Mar 20 17:15:33 2012

MMON started with pid=15, OS id=23789

Tue Mar 20 17:15:33 2012

MMNL started with pid=16, OS id=23791

starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...

starting up 1 shared server(s) ...

ORACLE_BASE from environment = /opt/oracle

Tue Mar 20 17:15:33 2012

ALTER DATABASE   MOUNT

Successful mount of redo thread 1, with mount id 1306255541

Allocated 3981120 bytes in shared pool for flashback generation buffer

Starting background process RVWR

Tue Mar 20 17:15:37 2012

RVWR started with pid=20, OS id=23802

Database mounted in Exclusive Mode

Lost write protection disabled

Completed: ALTER DATABASE   MOUNT

Tue Mar 20 17:24:26 2012

alter database open

Beginning crash recovery of 1 threads

Started redo scan

Completed redo scan

 read 68 KB redo, 47 data blocks need recovery

Started redo application at

 Thread 1: logseq 1, block 6600

Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0  --当前日志文件做实例恢复instance recovery

  Mem# 0: /opt/oracle/oradata/orcl/redo01.log

Completed redo application of 0.04MB

Completed crash recovery at

 Thread 1: logseq 1, block 6737, scn 21697600

 47 data blocks read, 47 data blocks written, 68 redo k-bytes read

Tue Mar 20 17:24:27 2012

LGWR: STARTING ARCH PROCESSES

Tue Mar 20 17:24:27 2012

ARC0 started with pid=21, OS id=24121

ARC0: Archival started

LGWR: STARTING ARCH PROCESSES COMPLETE

ARC0: STARTING ARCH PROCESSES

Tue Mar 20 17:24:28 2012

ARC1 started with pid=22, OS id=24123

Tue Mar 20 17:24:28 2012

ARC2 started with pid=23, OS id=24125

Thread 1 advanced to log sequence 2 (thread open)

ARC1: Archival started

ARC2: Archival started

ARC1: Becoming the 'no FAL' ARCH

ARC1: Becoming the 'no SRL' ARCH

ARC2: Becoming the heartbeat ARCH

Tue Mar 20 17:24:28 2012

ARC3 started with pid=24, OS id=24127

Thread 1 opened at log sequence 2

  Current log# 2 seq# 2 mem# 0: /opt/oracle/oradata/orcl/redo02.log

Successful open of redo thread 1

MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set

Successfully onlined Undo Tablespace 2.

Verifying file header compatibility for 11g tablespace encryption..

Verifying 11g file header compatibility for tablespace encryption completed

Tue Mar 20 17:24:28 2012

SMON: enabling cache recovery

SMON: enabling tx recovery

Database Characterset is ZHS16GBK

No Resource Manager plan active

replication_dependency_tracking turned off (no async multimaster replication found)

Starting background process QMNC

Tue Mar 20 17:24:29 2012

QMNC started with pid=25, OS id=24129

Completed: alter database open.

3SCN不同时恢复

oracle在启动过程中三者当中有一个不同时,则需要做media recovery,步骤是:首先检查是否需要media recovery,然后再检查是否需要instance recovery.测试如下;

SYS@ORCL> alter tablespace tools begin backup;

Tablespace altered.

此时拷贝tools01.dbf 到别处

SYS@ORCL> create table tools (id number) tablespace tools;

Table created.

SYS@ORCL> alter tablespace tools end backup;

Tablespace altered.

SYS@ORCL> create table tools (id number) tablespace tools;

Table created.

SYS@ORCL> insert into tools values(10);

1 row created.

SYS@ORCL> commit;

Commit complete.

SYS@ORCL> shutdown abort;

ORACLE instance shut down.

拷贝 tools01.dbf 回来

SYS@ORCL> startup mount;

ORACLE instance started.

Total System Global Area  101785252 bytes

Fixed Size                   454308 bytes

Variable Size              75497472 bytes

Database Buffers           25165824 bytes

Redo Buffers                 667648 bytes

Database mounted.

SYS@ORCL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

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

     251084

SYS@ORCL> select checkpoint_change#,last_change# from v$datafile;

CHECKPOINT_CHANGE# LAST_CHANGE#

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

            251084

            251084

            251084

            251084

            251084

SYS@ORCL> select checkpoint_change# from v$datafile_header;

CHECKPOINT_CHANGE#

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

            251084

            251084

            251084

           250867

            251084

可以看到 数据文件头的SCN250867,小于数据文件SCN 251084,和系统检查好SCN 251084

SYS@ORCL> alter database open;    --提示做介质恢复

alter database open

*

ERROR at line 1:

ORA-01113: file 4 needs media recovery

ORA-01110: data file 4: 'D:\ORACLE\ORADATA\PUBTEST\TOOLS01.DBF'

SYS@ORCL> recover datafile 4;

Media recovery complete.

SYS@ORCL> alter database open;

Database altered.

此时日志文件中内容如下:

ALTER DATABASE RECOVER  datafile 4

Media Recovery Datafile: 4

Media Recovery Start

Starting datafile 4 recovery in thread 1 sequence 16

Datafile 4: 'D:\ORACLE\ORADATA\PUBTEST\TOOLS01.DBF'

Media Recovery Log

Recovery of Online Redo Log: Thread 1 Group 1 Seq 16 Reading mem 0

Mem# 0 errs 0: D:\ORACLE\ORADATA\PUBTEST\REDO01.LOG

Recovery of Online Redo Log: Thread 1 Group 2 Seq 17 Reading mem 0

Mem# 0 errs 0: D:\ORACLE\ORADATA\PUBTEST\REDO02.LOG

Media Recovery Complete

Completed: ALTER DATABASE RECOVER  datafile 4

Tue Mar 18 09:48:50 2008

alter database open

Tue Mar 18 09:48:50 2008

 Beginning crash recovery of 1 threads

Tue Mar 18 09:48:50 2008

Started first pass scan

Tue Mar 18 09:48:52 2008

Completed first pass scan

 83 redo blocks read, 50 data blocks need recovery

Tue Mar 18 09:48:52 2008

Started recovery at

Thread 1: logseq 17, block 29, SCN 0.0

Recovery of Online Redo Log: Thread 1 Group 2 Seq 17 Reading mem 0

  Mem# 0 errs 0: D:\ORACLE\ORADATA\PUBTEST\REDO02.LOG

Tue Mar 18 09:48:52 2008

Completed redo application

Tue Mar 18 09:48:52 2008

Ended recovery at

Thread 1: logseq 17, block 112, SCN 0.271189

 50 data blocks read, 50 data blocks written, 83 redo blocks read

Crash recovery completed successfully

Tue Mar 18 09:48:53 2008

LGWR: Primary database is in CLUSTER CONSISTENT mode

Thread 1 advanced to log sequence 18

Thread 1 opened at log sequence 18

  Current log# 3 seq# 18 mem# 0: D:\ORACLE\ORADATA\PUBTEST\REDO03.LOG

Successful open of redo thread 1.

Tue Mar 18 09:48:54 2008

SMON: enabling cache recovery

Tue Mar 18 09:48:54 2008

ARC0: Evaluating archive   log 2 thread 1 sequence 17

ARC0: Beginning to archive log 2 thread 1 sequence 17

Creating archive destination LOG_ARCHIVE_DEST_1: 'D:\ORACLE\ORA92\RDBMS\ARC00017.001'

ARC0: Completed archiving  log 2 thread 1 sequence 17

Tue Mar 18 09:48:54 2008

Undo Segment 1 Onlined

Undo Segment 2 Onlined

Undo Segment 3 Onlined

Undo Segment 4 Onlined

Undo Segment 5 Onlined

Undo Segment 6 Onlined

Undo Segment 7 Onlined

Undo Segment 8 Onlined

Undo Segment 9 Onlined

Undo Segment 10 Onlined

Successfully onlined Undo Tablespace 1.

Tue Mar 18 09:48:54 2008

SMON: enabling tx recovery

Tue Mar 18 09:48:54 2008

Database Characterset is ZHS16GBK

replication_dependency_tracking turned off (no async multimaster replication found)

Completed: alter database open

五、深入分析checkpoint_change#

1、系统检查点(记录在控制文件中)

SYS@ORCL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

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

        21728618

2、数据文件检查点(记录在控制文件中)

SYS@ORCL> select file#,checkpoint_change#,last_change# from v$datafile;

     FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

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

       1        21728618

       2        21728618

       3        21728618

       4        21728618

       5        21728618

       6        21728618

6 rows selected.

3、数据文件头检查点(记录在数据文件中)

SYS@ORCL> select file#,checkpoint_change# from v$datafile_header;

     FILE# CHECKPOINT_CHANGE#

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

       1        21728618

       2        21728618

       3        21728618

       4        21728618

       5        21728618

       6        21728618

6 rows selected.

以上三个checkpoint_change#要一致(只读、脱机表空间除外),数据库才能正常打开。否则会需要进行一步的处理。正常关库时,会生成新的检查点,写入上述三个checkpoint_change#,同时数据文件中的last_change#也会记录下该检查点,也就是说三个checkpoint_change#last_change#记录着同一个值。通过以下SQL可以证明:

SYS@ORCL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SYS@ORCL> startup mount

ORACLE instance started.

Total System Global Area  263049216 bytes

Fixed Size              2212448 bytes

Variable Size               230690208 bytes

Database Buffers         25165824 bytes

Redo Buffers                4980736 bytes

Database mounted.

SYS@ORCL> select file#,checkpoint_change#,last_change# from v$datafile;

     FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

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

       1        21732562    21732562

       2        21732562    21732562

       3        21732562    21732562

       4        21732562    21732562

       5        21732562    21732562

       6        21732562    21732562

6 rows selected.

SYS@ORCL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

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

        21732562

SYS@ORCL> select file#,checkpoint_change# from v$datafile_header;

     FILE# CHECKPOINT_CHANGE#

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

       1        21732562

       2        21732562

       3        21732562

       4        21732562

       5        21732562

       6        21732562

6 rows selected.

数据库成功打开后,数据文件中的last_change#会被清空。正常关库时,再重新下最后的检查点。shutdown abort关库,这个值是空的(感兴趣可自行验证),此时数据库需要进行实例恢复(不需要用户干预),恢复后数据库才正常打开。checkpoint_change#last_change#实际上全部来自于SCN,可以通过下面的语句验证:

sys@ORCL> alter database open;

Database altered.

SYS@ORCL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER

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

             21732835

使用查询系统SCN号的函数,可以发现checkpoint_change#与之是接近的。SCN有很多触发的条件,可能不会特别接近。下面举几个全备后恢复的例子,以及相关场景下checkpoint_change#的情况。

问题1:数据文件损坏的恢复

此时控制文件中记录的checkpoint_change#比数据文件头中记录的要大,数据库需要介质或者实例恢复。

SYS@ORCL> startup

Database mounted.

ORA-01113: file 1 needs media recovery

ORA-01110: data file 1: '/u02/oradata/orcl/system01.dbf'

恢复一下,数据库就可以打开了。

SYS@ORCL> recover database;

ORA-00279: change 539624 generated at 10/18/2011 08:27:31 needed for thread 1

ORA-00289: suggestion : /u02/oradata/orcl/arc/1_5_764840495.dbf

ORA-00280: change 539624 for thread 1 is in sequence #5

 

 

Specify log: {=suggested | filename | AUTO | CANCEL}

auto

ORA-00279: change 540768 generated at 10/18/2011 12:17:11 needed for thread 1

ORA-00289: suggestion : /u02/oradata/orcl/arc/1_6_764840495.dbf

ORA-00280: change 540768 for thread 1 is in sequence #6

ORA-00278: log file '/u02/oradata/orcl/arc/1_5_764840495.dbf' no longer needed for this recovery

Log applied.

Media recovery complete.

SYS@ORCL> alter database open;

Database altered.

问题2:控制文件损坏的恢复

如果控制文件损坏,使用备份的控制文件是无法直接打开数据库的。

SYS@ORCL> startup

Database mounted.

ORA-01122: database file 1 failed verification check

ORA-01110: data file 1: '/u02/oradata/orcl/system01.dbf'

ORA-01207: file is more recent than controlfile - old controlfile

会提示数据文件与控制文件新,实际上就是控制文件中记录的checkpoint_change#比数据文件头中的checkpoint_change#要小,这种情况是不能打开数据库的。但数据可以启动到mount状态,此时可以用命令:

SYS@ORCL> alter database backup controlfile to trace;

生成一个控制文件的脚本,在udump目录中。使用该脚本可以重建控制文件,进行实例恢复后或打开数据库。如果没有备份的控制文件,数据库只能打开的nomount状态,不能获取重建控制文件的脚本。如果数据库不太复杂,可以手写一个。

问题3:数据文件、控制文件全部损坏

当然都有备份,日志是好的。恢复数据文件、控制文件后,数据库仍然是无法打开的。

SYS@ORCL> startup

Database mounted.

ORA-00314: log 1 of thread 1, expected sequence#  doesn't match

ORA-00312: online log 1 thread 1: '/u02/oradata/orcl/redo01.log'

提示的意思也就是日志中的检查点比较控制文件中记录的大。

SYS@ORCL> select checkpoint_change# from v$datafile;

CHECKPOINT_CHANGE#

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

            539624

            539624

            539624

            539624

            539624

SYS@ORCL> select checkpoint_change# from v$datafile_header;

CHECKPOINT_CHANGE#

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

            539624

            539624

            539624

            539624

            539624

SYS@ORCL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

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

            539624

SYS@ORCL> select * from v$log;

GROUP#  THREAD#  SEQUENCE#  BYTES  MEMBERS  ARC  STATUS FIRST_CHANGE#  FIRST_TIM

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

1          1          5   10485760          1 NO  CURRENT                 539571 18-OCT-11

2          1          4   10485760          1 YES INACTIVE                539116 18-OCT-11

3          1          3   10485760          1 YES INACTIVE                537456 18-OCT-11

此时可以使用下面的命令恢复数据库:

SYS@ORCL> recover database using backup controlfile;

恢复成功后,v$database中记录的checkpoint_change#并未发生变化。

SYS@ORCL> select checkpoint_change# from v$datafile;

CHECKPOINT_CHANGE#

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

            602574

            602574

            602574

            602574

            602574

SYS@ORCL> select checkpoint_change# from v$datafile_header;

CHECKPOINT_CHANGE#

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

            602574

            602574

            602574

            602574

            602574

SYS@ORCL>  select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

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

            539624

因为不一致,所以数据库仍然打不开:

SYS@ORCL> alter database open;

alter database open

*

ERROR at line 1:

ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

SYS@ORCL> alter database open resetlogs;

alter database open resetlogs

*

ERROR at line 1:

ORA-01113: file 1 needs media recovery

ORA-01110: data file 1: '/u02/oradata/orcl/system01.dbf'

此时的情况类似于问题2,解决办法也相同。shutdown abort,startup nomount,重建控制文件,recover database,alter database open;

问题4、冷备过后新建的数据文件损坏,且无备份

这种情况的处理办法:

SYS@ORCL> restore’备份的数据文件’;

SYS@ORCL> startup;

会提示无法定位数据文件,数据库无法打开,alter database create datafile提示无法定位的数据文件名称;此时查看checkpoint_change#,会发现新建的与其它的不相同。

SYS@ORCL> set autorecovery on

SYS@ORCL> recover database;

SYS@ORCL> alter database open;

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/751371/viewspace-721036/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2009-02-18

  • 博文量
    256
  • 访问量
    1188725