第一章 数据库的启动和关闭
一、数据库启动
1、启动数据库到nomount状态：
Oracle首先寻找参数文件（pfile/spfile），然后根据参数文件中的设置，创建实例，分配内存，启动后台进程。
Alert_<sid>.log中可以看到这一阶段的启动过程，读取参数文件，应用参数启动实例，所有在参数文件中定义的非缺省参数都会记录在警报日志文件中，然后后天进程依次启动。
在参数文件中，通常需要最少的参数是db_name，设置了这个参数之后，数据库实例就可以启动。
2、启动数据库到mount状态：
启动到nomount状态以后，Oracle就可以从参数文件中获得控制文件的位置信息，在mount数据库的过程中，Oracle需要找到控制文件并锁定控制文件。
启动到mount状态，数据库必须具备的另一个重要文件是口令文件，该文件位于$ORACLE_HOME/dbs目录下，缺省的名称为orapw<sid>。
口令文件中存放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:55
LOG 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:00
LOG 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$进行引导，进一步创建相关的重要对象，从而启动了数据库。
联系客服
微信登录中...
请勿关闭此页面
