深入浅出oracle阅读,深入浅出Oracle学习笔记（1）

第一章 数据库的启动和关闭

一、数据库启动

1、启动数据库到nomount状态：

Oracle首先寻找参数文件(pfile/spfile)，然后根据参数文件中的设置，创建实例，分配内存，启动后台进程。

Alert_.log中可以看到这一阶段的启动过程，读取参数文件，应用参数启动实例，所有在参数文件中定义的非缺省参数都会记录在警报日志文件中，然后后天进程依次启动。

在参数文件中，通常需要最少的参数是db_name，设置了这个参数之后，数据库实例就可以启动。

2、启动数据库到mount状态：

启动到nomount状态以后，Oracle就可以从参数文件中获得控制文件的位置信息，在mount数据库的过程中，Oracle需要找到控制文件并锁定控制文件。

启动到mount状态，数据库必须具备的另一个重要文件是口令文件，该文件位于$ORACLE_HOME/dbs目录下，缺省的名称为orapw。

口令文件中存放sysdba/sysoper用户的用户名和口令。在数据库没有启动之前，数据库内建用户是无法通过数据库本身来验证身份的，通过口令文件，Oracle可以实现对用户的身份认证，在数据库未启动之前登陆，进而启动数据库。

如果丢失了口令文件，在mount阶段就会出现错误。

3、启动数据库到open阶段：

Oracle主要进行的检查包括以下两项：

--检查数据文件头中的检查点计数(Checkpoint Cnt)是否和控制文件中的检查点计数一致。此步骤检查用以确认数据文件是来自同一版本，而不是从备份中恢复而来(因为Checkpoint Cnt不会被冻结，会一直被修改)。

执行Begin Backup之后，Checkpoint Cnt增加1，对表空间Begin Backup会触发一次表空间检查点，故检查点计数随之增加；

在表空间热备份模式下，手工执行检查点后，Checkpoint Cnt增加，但是SCN不再改变，这是因为表空间处于热备份模式，数据文件检查点被冻结。

End Backup后，数据文件头的冻结被取消，SCN开始变化。

--如果检查点计数检查通过，则数据库进行第二次检查：数据文件头的开始SCN和控制文件中记录的该文件的结束SCN是否一致，如果控制文件中记录的结束SCN等于数据文件头的开始SCN，则不需要对那个文件进行恢复。

对每个数据文件都完成检查后，打开数据库，锁定数据文件，同时将每个数据文件的结束SCN设置为无穷大。

二、SCN

SCN(System Change Number)系统改变号，用以标识数据库在某个确切时刻提交的版本。在事务提交时，它被赋予一个唯一的标识事务的SCN。

SCN是Oracle内部的时钟机制，Oracle通过SCN来维护数据库的一致性，并通过SCN实施Oracle至关重要的恢复机制。

SCN在数据库中是无处不在的，常见的事务表、控制文件、数据文件头、日志文件、数据块头等都记录有SCN值。

可以通过如下两种方式获得数据库的当前或近似SCN：

从Oracle 9i开始，可以使用dbms_flashback.get_system_change_number来获得：

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER

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

5111496

Oracle 9i前，可以通过查询x$ktuxe获得系统最接近当前值的SCN：

SQL> select max(ktuxescnw*power(2,32)+ktuxescnb) from x$ktuxe;

MAX(KTUXESCNW*POWER(2,32)+KTUXESCNB)

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

5112238

系统当前的SCN并不是在任何的数据库操作发生时都会改变，SCN通常在事务提交或回滚时改变。在控制文件、数据文件头、数据块、日志文件头、日志文件change vector中都有SCN，但其作用各不相同。

1、数据文件头中包含了该数据文件的Checkpoint SCN，表示该数据文件最近一次执行检查点操作时的SCN。

从控制文件的dump文件中，可以得到以下内容：

SQL> alter session set events 'immediate trace name CONTROLF level 10';

会话已更改。

DATA FILE #1:

(name #8) D:\ORACLE\ORADATA\GVORA\SYSTEM01.DBF

creation size=0 block size=8192 status=0xe head=8 tail=8 dup=1

tablespace 0, index=6 krfil=1 prev_file=0

unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00

Checkpoint cnt:293 scn: 0x0000.004d2eb9 04/26/2009 12:35:55 Stop scn: 0xffff.ffffffff 04/26/2009 01:20:25

……………..

对于每一个数据文件都包含一个这样的条目，记录该文件的检查点SCN的值以及检查点发生的时间。

可以通过命令转储数据文件头，观察其具体信息及检查点记录：

SQL> alter session set events 'immediate trace name file_hdrs level 10';

会话已更改。

2、日志文件头中包含了Low SCN和Next SCN

Low SCN和Next SCN这两个SCN表示了该日志文件包含有介于Low SCN到Next SCN的重做信息，对于Current的日志文件(当前正在被使用的Redo Logfile)，其最终SCN不可知，所以Next SCN被置为无穷大，也就是ffffffff。

SQL> select * from v$log;

GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS

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

FIRST_CHANGE# FIRST_TIME

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

1          1        116  104857600          1 NO  INACTIVE

5005169 25-4月 -09

2          1        117  104857600          1 NO  CURRENT

5058232 26-4月 -09

3          1        115  104857600          1 NO  INACTIVE

4861140 25-4月 -09

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER

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

5117682

SQL> select * from v$log;

GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS

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

FIRST_CHANGE# FIRST_TIME

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

1          1        116  104857600          1 NO  INACTIVE

5005169 25-4月 -09

2          1        117  104857600          1 NO  ACTIVE

5058232 26-4月 -09

3          1        118  104857600          1 NO  CURRENT

5118009 26-4月 -09

SQL> alter session set events 'immediate trace name CONTROLF level 10';

会话已更改。

可以看到，SCN 5117682显然位于Log Group#为2的日志文件中，该日志文件包含了SCN自5058232至5118009的Redo信息。Oracle在进行恢复时就需要根据低SCN和高SCN来确定需要的恢复信息位于哪一个日志或归档文件中。

通过控制文件转储，可以在控制文件中找到关于日志文件的信息：

LOG FILE #1:

(name #3) D:\ORACLE\ORADATA\GVORA\REDO01.LOG

Thread 1 redo log links: forward: 2 backward: 0

siz: 0x32000 seq: 0x00000074 hws: 0x5 bsz: 512 nab: 0x5913 flg: 0x0 dup: 1

Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.004a2cd4

Low scn: 0x0000.004c5f71 04/25/2009 22:36:21

Next scn: 0x0000.004d2eb8 04/26/2009 12:35:55LOG FILE #2:

(name #2) D:\ORACLE\ORADATA\GVORA\REDO02.LOG

Thread 1 redo log links: forward: 3 backward: 1

siz: 0x32000 seq: 0x00000075 hws: 0x2 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 1

Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.004c5f71

Low scn: 0x0000.004d2eb8 04/26/2009 12:35:55

Next scn: 0xffff.ffffffff 01/01/1988 00:00:00LOG FILE #3:

(name #1) D:\ORACLE\ORADATA\GVORA\REDO03.LOG

Thread 1 redo log links: forward: 0 backward: 2

siz: 0x32000 seq: 0x00000073 hws: 0x6 bsz: 512 nab: 0x148fb flg: 0x0 dup: 1

Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.004942e9

Low scn: 0x0000.004a2cd4 04/25/2009 11:52:43

Next scn: 0x0000.004c5f71 04/25/2009 22:36:21可以注意到，Log File2是当前的日志文件，该文件拥有的Next SCN为无穷大。

同样，可以通过直接dump日志文件的方式来进行转储：

SQL> select * from v$logfile;

GROUP# STATUS  TYPE    MEMBER

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

3         ONLINE  D:\ORACLE\ORADATA\GVORA\REDO03.LOG

2         ONLINE  D:\ORACLE\ORADATA\GVORA\REDO02.LOG

1         ONLINE  D:\ORACLE\ORADATA\GVORA\REDO01.LOG

SQL> alter system dump logfile 'D:\ORACLE\ORADATA\GVORA\REDO03.LOG';

系统已更改。

三、检查点1、检查点的本质

检查点只是一个数据库事件，它存在的根本意义在于减少崩溃恢复(Crash Recovery)时间。

当检查点发生时(此时的SCN被称为Checkpoint SCN)，Oracle会通知DBWR进程把修改过的数据，也就是此Checkpoint SCN之前的脏数据从Buffer Cache写入磁盘，当写入完成之后，CKPT进程更新控制文件和数据文件头，记录检查点信息，标示变更。

Checkpoint SCN可以从数据库中查询得到：

SQL> select file#,checkpoint_change#,to_char(checkpoint_time,'yyyy-mm-dd hh24:mi

:ss') cpt from v$datafile;

FILE# CHECKPOINT_CHANGE# CPT

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

1            5118009 2009-04-26 18:03:00

2            5118009 2009-04-26 18:03:00

3            5118009 2009-04-26 18:03:00

SQL> select dbid,checkpoint_change# from v$database;

DBID CHECKPOINT_CHANGE#

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

389716958            5118009

检查点的频度对于数据库的恢复事件具有极大的影响。

2、常规检查点和增量检查点

在Oracle 8i之前，Oracle实施的检查点通常被称为常规检查点(Conventional Checkpoint)，这类检查点按一定的条件触发(log_checkpoint_interval、log_checkpoint_timeout参数设置及log switch等条件触发)。从Oracle 8i开始，Oracle引入了增量检查点(Incremental Checkpoint)的概念。主要引入了检查点队列机制，在数据库内部，每一个脏数据块都会被移动到检查点队列，按照Low RBA的顺序(第一次对此数据块修改对应得Redo Byte Address)来排列，如果一个数据块进行过多次修改，该数据块在检查点队列上的顺序并不会发生变化。

当执行检查点时，DBWR从检查点队列按照Low RBA的顺序写出，实例检查点因此可以不断增进，CKPT进程使用非常轻量级的控制文件更新协议将当前的最低RBA写入控制文件。因为增量检查点可以连续地进行，因此检查点RBA可以比常规检查点更接近数据库的最后状态，从而在数据库的实例恢复中可以极大地减少恢复时间。而且，通过增量检查点，DBWR可以持续进行写出，从而避免了常规检查点触发的峰值写入对于I/O的过度征用。

在数据库中，增量检查点是通过Fast-Start Checkpointing特性来实现的，从Oracle 8i开始，这一特性包含在Oracle企业版的Fast-Start Fault Recovery组件中，可以查询v$option：

SQL> select * from v$option where parameter='Fast-Start Fault Recovery';

PARAMETER                           VALUE

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

Fast-Start Fault Recovery           TRUE

该组件包含3个主要特性，可以加快系统在故障后的恢复，提高系统的可用性：

Fast-Start Checkpointing

Fast-Start On-Demand Rollback

Fast-Start Parallel Rollback

3、FAST_START_MTTR_TARGET

FAST_START_MTTR_TARGET参数从Oracle 9i开始被引入，该参数定义数据库进行Crash恢复的时间。

SQL> select MTTR_TARGET_FOR_ESTIMATE mttrest,

2  ADVICE_STATUS ad,

3  DIRTY_LIMIT dl,

4  ESTD_CACHE_WRITES estcw,

5  ESTD_CACHE_WRITE_FACTOR estcwf,

6  ESTD_TOTAL_WRITES estw,

7  ESTD_TOTAL_WRITE_FACTOR estwf,

8  ESTD_TOTAL_IOS estio

9  from v$mttr_target_advice;

MTTREST   AD     DL   ESTCW  ESTCWF    ESTW  ESTWF     ESTIO

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

71    ON     1000    849       1        869       1         2652

93    ON     3000    849       1        869       1         2652

该视图评估在不同FAST_ START_MTTR_TARGET设置下，系统需要执行的I/O次数等操作。这个建议信息的收集受到Oracle 9i新引入的初始化参数statistics_level的控制，当该参数设置为Typical或ALL时MTTR建议信息被收集。

SQL> show parameter statistics_level

NAME                                 TYPE        VALUE

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

statistics_level                     string      TYPICAL

也可以通过v$statistics_level视图来查询MTTR Advice的当前设置。

SQL> select * from v$statistics_level

2  where statistics_name='MTTR Advice';

STATISTICS_NAME

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

DESCRIPTION

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

SESSION_ SYSTEM_S ACTIVAT

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

STATISTICS_VIEW_NAME                                             SES

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

MTTR Advice

Predicts the impact of different MTTR settings on number of physical I/Os

ENABLED  ENABLED  TYPICAL

V$MTTR_TARGET_ADVICE                                             NO

数据库的当前实例恢复状态可以通过视图v$instance_recovery得到：

SQL> select * from v$instance_recovery;

RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS TARGET_REDO_BLKS LOG_FILE_SIZE_REDO_BLKS

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

LOG_CHKPT_TIMEOUT_REDO_BLKS LOG_CHKPT_INTERVAL_REDO_BLKS

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

FAST_START_IO_TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR CKPT_BLOCK_WRITES

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

64             3845             4054                  184320

4054

93             42               179

从v$instance_recovery视图可以看到数据库估计的平均恢复时间参数：ESTIMATED_MTTR。ESTIMATED_MTTR的估计值是基于Dirty Buffer的数量和日志块数量得出的，这个参数值告诉我们如果此时数据库崩溃，那么进行实例恢复将会需要的时间。

在v$instance_recovery视图中，TARGET_MTTR代表的是期望的平均恢复时间，通常该参数应该等于FAST_START_MTTR_TARGET参数设置值。

当ESTIMATED_MTTR接近或超过TARGET_MTTR时，系统就会触发检查点，系统恢复信息将会重新计算。通过CKPT_BLOCK_WRITES字段可以看出检查点已经写出的数据块的数量，增量检查点的触发以及DBWR的持续写出，都会促使该值增加。

在繁忙的系统中，可能会观察到ESTIMATED_MTTR>TARGET_MTTR，这可能是因为DBWR正忙于写出，甚或出现Checkpoint不能及时完成的情况。

4、Oracle 10g自动检查点调整

使用自动调整的检查点，Oracle数据库可以利用系统的低I/O负载时段写出内存中的脏数据，从而提高数据库的效率。当FAST_START_MTTR_TARGET参数未设置时，自动检查点调整生效。

通常，如果必须严格控制实例或节点恢复时间，那么可以设置FAST_START_MTTR_TARGET为期望时间值；如果恢复时间不需要严格控制，那么可以不设置FAST_START_MTTR_TARGET参数，从而启用Oracle 10g的自动检查点调整特性。

10g在v$instance_recovery视图中，WRITES_AUTOTUNE字段值指由于自动调整检查点执行的写出次数，而CKPT_BLOCK_WRITES指的则是由于检查点写出的Block的数量。

5、从控制文件获取检查点信息

***************************************************************************

CHECKPOINT PROGRESS RECORDS

***************************************************************************

(blkno = 0x4, size = 104, max = 1, in-use = 1, last-recid= 0)

THREAD #1 - status:0x2 flags:0x0 dirty:69

low cache rba:(0x75.7e9e.0) on disk rba:(0x75.8f57.0)on disk scn: 0x0000.004e062f 04/26/2009 17:39:38

resetlogs scn: 0x0000.0002e872 04/04/2009 16:43:12

heartbeat: 685205139 mount id: 391608798

MTTR statistics status: 3

Init time: Avg: 35121550, Times measured: 3

File open time: Avg: 533711, Times measured: 29

Log block read time: Avg: 96, Times measured: 54758

Data block handling time: Avg: 10865, Times measured: 1109

这里low cache rba(Recovery block adress)指在Cache中最低的RBA地址，在实例恢复或者崩溃恢复中，需要从这里开始恢复。on disk rba是磁盘上的最高的重做值，在进行恢复时应用重做至少要达到这个值。

四、数据库是怎样根据SCN和Checkpoint来进行一致性判断及恢复控制的？

在控制文件和数据文件头上，对于每个数据文件都有一个“Checkpoint SCN”和“Stop SCN”。Oracle通过比较这些SCN值来确定数据库是否需要恢复。

因为在数据库正常关闭之前会执行完全检查点，所以线程检查点SCN和所有数据文件检查点SCN和数据文件Stop SCN都一致。

当数据库进行异常关闭的时候，各部分的Checkpoint SCN都一致，由于数据库是异常关闭，数据库没有完成最后的检查点，数据文件的Stop SCN仍然为无穷大，因此数据文件的Stop SCN不等于Checkpoint SCN，此时启动数据库需要进行恢复。

SQL> startup mount

ORACLE 例程已经启动。

Total System Global Area  135338868 bytes

Fixed Size                   453492 bytes

Variable Size             109051904 bytes

Database Buffers           25165824 bytes

Redo Buffers                 667648 bytes

数据库装载完毕。

SQL> alter session set sql_trace=true;

会话已更改。

SQL> alter database open;

数据库已更改。

SQL> alter session set sql_trace=false;

会话已更改。

SQL> select segment_name,file_id,block_id from dba_extents

2  where block_id=377 and file_id=1;

SEGMENT_NAME            FILE_ID   BLOCK_ID

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

BOOTSTRAP$                    1        377

SQL> select * from bootstrap$ where line#<5;

LINE#       OBJ#

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

SQL_TEXT

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

-1         -1

8.0.0.0.0

0          0

CREATE ROLLBACK SEGMENT SYSTEM STORAGE (  INITIAL 112K NEXT 1024K MINEXTENTS 1 M

AXEXTENTS 32765 OBJNO 0 EXTENTS (FILE 1 BLOCK 9))

从上面可以看出，bootstrap$中实际上是记录了一些数据库系统基本对象的创建语句。Oracle通过bootstrap$进行引导，进一步创建相关的重要对象，从而启动了数据库。