[AD]数据库启动关闭
一，SPFILE
1，用户可以在sql*plus中，通过show parameter spfile 命令来检查数据库是否使用了spfile文件，如果value不为null，则数据库使用了spfile文件。在参数文件中，通常需要最少的参数是db_name，设置了这个参数之后，数据库实例就可以启动。
2，有了参数文件，虽然可以启动实例，但是不能mount，会有错误：ORA-00205: error in identifying control file, check alert log for more info（在mount数据库的过程中，Oracle需要找到控制文件并锁定控制文件，如果控制文件全部丢失此时就会报上面的错误）
注：如果不设置，background_dump.dest目录，（警报日志文件alert_.log的存放地点）位于$ORACLE_HOME/rdbms/log目录下。
二，nomount
在nomount的状态下，可以查询v$parameter视图，获取控制文件信息，这部分信息来自启动的参数文件，当数据库mount以后，可以查询v$controlfile视图获得关于控制文件的信息，此时，这部分信息来自控制文件。
三，mount
在正常的mount的过程中，数据库需要计算Mound id并将其记录在控制文件中，然后开始启动hearbeat（心跳）。每3秒更新一个控制文件，可以用一下命令间隔3秒存储2次控制文件信息：
SQL> alter session set events 'immediate trace name CONTROLF level 10';
Session altered.
oracle数据库内部通过等待事件control file heartbeat来记录这个事件的相关等待；
SQL> select event#,name
from v$event_name where name like '%heart%';
EVENT# NAME
---------- ----------------------------------------------------------------
278 ASM mount : wait for heartbeat
419 control file heartbeat
SQL>
四，口令文件
1，[oracle@rhel dbs]$ strings orapworcl
]\[Z
ORACLE Remote Password file
INTERNAL
AB27B53EDC5FEF41
8A8F025737A9097A
2，[oracle@rhel dbs]$ pwd
/u01/app/oracle/10.2.0/db_1/dbs
[oracle@rhel dbs]$
3，如果丢失口令文件，在mount阶段会出现错误。
创建口令文件：SQL> host orapwd file=$ORACLE_HOME/dbs/orapworcl password=oracle entries=10;
五，undo
1，在完成数据库的验证和恢复过程后，数据库处于一致的状态，数据库还需要进行一系列的处理过程，将undo段在线操作，然后数据库可以提供访问，同时SMON可以开始进行事务回滚等。
2，在启动日志里，读者可能看到这样的一行：Database Characterset is ZHS16GBK；在每一次数据库的启动过程中，Oracle都需要判断控制文件的字符集和数据库的字符集是否相符，如果相符，则记录如上的一行日志，如果不符，则以数据库的字符集为准更新控制文件中的字符集记录，类似的日志如下：Updating character set in controlfile to ZHS16GBK232180
3，SCN：SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
------------------------
1173632
SQL>
SQL> select * from v$logfile;
SQL> select * from v$log;
六，检查点
1，检查点只是一个数据库事件，它存在的根本意义在于减少崩溃恢复的时间。当修改数据时，需要首先将数据读入到内存（Buffer Cache），修改数据的同时，Oracle会记录重做信息（Redo），用于恢复，因为有重做信息的存在，Oracle不需要在提交的时候立即将变化的数据块写回到磁盘（立即写的效率很低），重做（redo）的存在也正是为了在数据库崩溃以后，数据可以恢复。
2，当检查点发生时（此时的SCN成为ChcekpointSCN），ORACLE会通知DBWR进程，把修改过的数据，也就是此CheckpointSCN之前的脏数据（Dirty Data）从Buffer Cache写入磁盘，当写入完成之后，CKPT进程更新控制文件和数据文件头，记录检查点信息，标识变更。
3，SQL> select name,file#,CHECKPOINT_CHANGE#,to_char(CHECKPOINT_TIME,'yyyy-mm-dd hh24:mi:ss')CPT
from v$datafile;
NAME FILE# CHECKPOINT_CHANGE# CPT
------------------------------ ---------- ------------------ -------------------
/u01/app/oracle/oradata/orcl/s 1 1170539 2014-03-28 17:59:04
ystem01.dbf
/u01/app/oracle/oradata/orcl/u 2 1170539 2014-03-28 17:59:04
ndotbs01.dbf
/u01/app/oracle/oradata/orcl/s 3 1170539 2014-03-28 17:59:04
ysaux01.dbf
/u01/app/oracle/oradata/orcl/u 4 1170539 2014-03-28 17:59:04
sers01.dbf
NAME FILE# CHECKPOINT_CHANGE# CPT
------------------------------ ---------- ------------------ -------------------
/u01/app/oracle/oradata/orcl/e 5 1170539 2014-03-28 17:59:04
xample01.dbf
4，SQL> select dbid,CHECKPOINT_CHANGE# from v$database;
DBID CHECKPOINT_CHANGE#
---------- ------------------
1356398003 1170539
6，在检查点完成以后，此检查点之前的修改的数据都已经写入到了磁盘，重做日志文件中的相应的记录对于崩溃/实例恢复不再有用。检查点的频度对于数据库的恢复时间具有极大的影响，如果检查点的频率高，那么恢复时需要应用的重做日志就相对少，恢复时间就可以缩短。但是过于频繁的检查点同样会带来性能问题，尤其是更新频繁的数据库。
7，常规检查点：
Oracle实施的检查点通常被称为常规检查点（convention Checkpoint），这类检查点按一定的条件触发（log_checkpoint_interval,log_checkpoint_timeout参数设置及log switch等条件触发）。
8，增量检查点：
Oracle主要引入了检查点队列（Checkpoint Queue）机制，在数据库内部，每一个脏块都会被移动到检查点队列，按照Low RBA的顺序（第一次对此数据块修改对应的Redo Byte Address）来排列，如果一个数据块进行了多次修改，该数据块在检查点队列上的顺序并不会发生变化。当执行检查点时，DBWR从检查点队列按照Low RBA的顺序写出，实例检查点因此可以不断增进、阶段性的，CKPT进程使用非常轻量级的控制文件更新协议，将当前的最低RBA导入控制文件。因为增量检查点可以连续地进行，一次检查点RBA可以比常规检查点更接近数据库的最后状态，从而在数据库的实例恢复中可以极大的减少恢复的时间。通过增量检查点，DBWR可以持续进行写出，从而避免了检查点出发的峰值写入对于I/O的过度的征用。
七，查看oracle的版本
1，SQL> select * from v$version where rownum<2;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
2，SQL> select * from v$version ;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for Linux: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
SQL>
3，SQL> select * from v$option
where parameter='Fast-Start Fault Recovery';
PARAMETER VALUE
------------------------------ --------------------
Fast-Start Fault Recovery TRUE
SQL>
八，参数
1，Fast_Start Checkpointing 特性在oracle 8i中主要通过参数FAST_START_IO_TARGET来实现；在oracle 9i中，Fast_Start Checkpointing主要通过参数FAST_START_MTTR_TARGET来实现。
2，FAST_START_MTTR_TARGET，FAST_START_MTTR_TARGET参数从9i开始被引入，该参数定义数据库进行crash恢复的时间，单位是秒，取值范围是0~3600秒之间。在Oracle 9i中，oracle推荐设置这个参数代替FAST_START_IO_TARGET、LOG_CHECKPOINT_TIMEOUT及LOG_CHECKPOINT_INTERVAL参数。在缺省的情况下，oracle 9i中FAST_START_IO_TARGET和LOG_CHECKOUTPOINT_INTERVAL参数被设置为0.
3，SQL> show parameter fast_start_io;
NAME TYPE VALUE
------------------------------------ ----------- -----
fast_start_io_target integer 0
SQL> show parameter interval;
NAME TYPE VALUE
------------------------------------ ----------- -----
log_checkpoint_interval integer 0
SQL>
4，从oracle 9i R2开始，oracle引入了一个新的视图提供MTTR建议：
SQL> select MTTR_TARGET_FOR_ESTIMATE MttrEst,
ADVICE_STATUS AD,
DIRTY_LIMIT DL,
ESTD_CACHE_WRITES ESTCW,
ESTD_CACHE_WRITE_FACTOR EstCWF,ESTD_TOTAL_WRITES ESTW,
ESTD_TOTAL_WRITE_FACTOR ETWF,ESTD_TOTAL_IOS ETIO
from v$mttr_target_advice;
5，这个建议的收集受到oracle 9i 新引入的初始化参数statics_level的控制；
SQL> show parameter statistics_level;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
statistics_level string TYPICAL
SQL>
6，也可以通过v$statistics_level视图来查询MTTR Advise
SQL> select * from v$statistics_level
2 where STATISTICS_NAME='MTTR Advice'
3 /
STATISTICS_NAME DESCRIPTION SESSION_ SYSTEM_S ACTIVAT STATISTICS_VIEW_NAME SES
-------------------- -------------------------------------------------- -------- -------- ------- ------------------------- ---
MTTR Advice Predicts the impact of different MTTR settings on ENABLED ENABLED TYPICAL V$MTTR_TARGET_ADVICE NO
number of physical I/Os
SQL>
7，SQL> select RECOVERY_ESTIMATED_IOS REIO,
ACTUAL_REDO_BLKS ARB,
TARGET_REDO_BLKS TRB,
LOG_FILE_SIZE_REDO_BLKS LFSRB,
LOG_CHKPT_TIMEOUT_REDO_BLKS LCTRB,
LOG_CHKPT_INTERVAL_REDO_BLKS LCIRB,
FAST_START_IO_TARGET_REDO_BLKS FSIOTRB,
TARGET_MTTR TMTTR,
ESTIMATED_MTTR EMTTR,
CKPT_BLOCK_WRITES CBW
from v$instance_recovery;
REIO ARB TRB LFSRB LCTRB LCIRB FSIOTRB TMTTR EMTTR CBW
---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
31 102 2794 184320 2794 0 10 471
SQL>
九，v$instance_recovery
1，从v$instance_recovery视图，可以看到当前数据库估计的平均恢复时间（MTTR）参数ESTIMATED_MTTR。ESTIMATED_MTTR的估算值基于Dirty Buffer的数量和日志块数量得出的，这个参数数值告诉我们，如果此时数据库崩溃，那么进行实例恢复将会需要的时间。
2，在v$instance_recovery视图中，TARGET_MTTR代表的是期望的平均恢复时间，通常该参数应该等于FAST_START_MTTR_TARGET 参数设置值（但是如果FAST_START_MTTR_TARGET参数定义的极大或极小，TARGET_MTTR可能不等于FAST_START_MTTR_TARGET的设置）。
3，当ESTIMATED_MTTR接近或超过FAST_START_TARGET参数设置（v$instance_recovery， TARGET_MTTR）时，系统就会触发检查点，执行写出之后，系统恢复信息将会重新计算：在繁忙的系统中，可能会观察到ESTIMATED_MTTR>TARGET_TIME,这可能因为DBWR正忙于写出，甚或出现checkpoint不能及时完成的情况。
4，如果发现ESTIMATED_MTTR>TARGET_TIME，继续查询，ESTIMATED_MTTR继续升高。
5，通过CKPT_BLOCK_WRITES字段，可以看出检查点应经写出的数据块的数量，增量检查点的触发以及DBWR的持续写出，都会促使该值的增加。
6，当一个系统完成检查点之后，我们可以看到ESTIMATED_MTTR逐渐恢复到较为正常的状态（非正常的状态到正常的状态：238-183-138）；
十，v$session_wait
1,此时查询v$session_wait，查询原因，（例如：发生了一个checkpoint incomplete事件）
SQL> select sid,seq#,event from v$session_wait;
SID SEQ# EVENT
---------- ---------- ----------------------------------------------------------------
134 5 Streams AQ: qmn slave idle wait
136 1 Streams AQ: waiting for time management or cleanup tasks
147 1 jobq slave wait
151 6 Streams AQ: qmn coordinator idle wait
155 212 rdbms ipc message
156 1660 rdbms ipc message
158 211 SQL*Net message to client
160 222 rdbms ipc message
161 6 rdbms ipc message
162 780 rdbms ipc message
163 6 rdbms ipc message
2,查询v$log视图，看繁忙程度（例如：发现除啦current日志组外，所有日志组都处于Active状态）。
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1 1 10 52428800 1 NO CURRENT 1201384 29-MAR-14
2 1 8 52428800 1 YES INACTIVE 1159883 25-MAR-14
3 1 9 52428800 1 YES INACTIVE 1159889 25-MAR-14
SQL>
3,然后通过os查看iostat状态信息（例如：发现swap已经严重（si、sw较高），CPU等待IO（wa）也很高）这就意味着系统的IO存在瓶颈或者系统有突发的大规模的操作。
[root@rhel ~]# vmstat 2
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 83964 115132 694320 0 0 111 38 1093 79 0 0 98 1 0
0 0 0 83964 115140 694312 0 0 0 30 1009 65 0 0 100 0 0
0 0 0 83964 115140 694320 0 0 0 16 1001 63 0 0 100 0 0
0 0 0 83964 115140 694320 0 0 0 24 1008 59 0 1 99 0 0
0 0 0 83964 115148 694312 0 0 0 46 1012 72 0 0 100 0 0
0 0 0 83964 115148 694320 0 0 0 2 1006 58 0 0 100 0 0
0 0 0 83964 115148 694320 0 0 0 24 1006 57 0 0 99 1 0
0 0 0 83964 115156 694312 0 0 0 32 1008 67 0 0 100 0 0
0 0 0 83964 115156 694320 0 0 0 0 1003 59 0 0 100 0 0
4,从oracle的10g开始，数据库可以实现自动调整检查点，使用自动调整检查点，oracle数据库可以利用系统的低I/O负载时写出内存中的脏数据，从而提高数据库的效率。因此，即使数据库管理员设置了不合理的检查点相关的参数，oracle仍然能够通过自动调整数据库的CashRecovery时间控制在合理的范围内。当FAST_START_MTTR_TARGET参数未设置，自动检查点调整生效。通常，如果必须严格控制实例或者节点恢复时间，那么可以设置FAST_START_MTTR_TARGET为期望时间值；如果回复时间不需要严格控制，那么可以不设置FAST_START_MTTR_TARGET参数，从而启动oracle的自动检查点调整特性。
5,SQL> show parameter fast_start_mttr;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
fast_start_mttr_target integer 0
SQL>
6,SQL> select RECOVERY_ESTIMATED_IOS REIOS,TARGET_MTTR TMTTR,
ESTIMATED_MTTR EMTTR,WRITES_MTTR WMTTR,WRITES_OTHER_SETTINGS WOSET,
CKPT_BLOCK_WRITES CKPTBW,
WRITES_AUTOTUNE WAUTO,WRITES_FULL_THREAD_CKPT WFTCKPT
from v$instance_recovery;
REIOS TMTTR EMTTR WMTTR WOSET CKPTBW WAUTO WFTCKPT
---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
60 0 11 0 0 111 600 0
WRITES_AUTOTUNE字段值是指由于自动调整检查点执行的写出次数，而CKPT_BLOCK_WRITES指的则是由于检查点写出的block的数量。
Low cache rba（recovery block address）指在cache中，最低的RBA地址，在实例恢复或者崩溃恢复中，需要从这里开始恢复，on disk rba是磁盘上的最高的重做值，在进行恢复时应用重做至少要达到这个值。
1，用户可以在sql*plus中，通过show parameter spfile 命令来检查数据库是否使用了spfile文件，如果value不为null，则数据库使用了spfile文件。在参数文件中，通常需要最少的参数是db_name，设置了这个参数之后，数据库实例就可以启动。
2，有了参数文件，虽然可以启动实例，但是不能mount，会有错误：ORA-00205: error in identifying control file, check alert log for more info（在mount数据库的过程中，Oracle需要找到控制文件并锁定控制文件，如果控制文件全部丢失此时就会报上面的错误）
注：如果不设置，background_dump.dest目录，（警报日志文件alert_
二，nomount
在nomount的状态下，可以查询v$parameter视图，获取控制文件信息，这部分信息来自启动的参数文件，当数据库mount以后，可以查询v$controlfile视图获得关于控制文件的信息，此时，这部分信息来自控制文件。
三，mount
在正常的mount的过程中，数据库需要计算Mound id并将其记录在控制文件中，然后开始启动hearbeat（心跳）。每3秒更新一个控制文件，可以用一下命令间隔3秒存储2次控制文件信息：
SQL> alter session set events 'immediate trace name CONTROLF level 10';
Session altered.
oracle数据库内部通过等待事件control file heartbeat来记录这个事件的相关等待；
SQL> select event#,name
from v$event_name where name like '%heart%';
EVENT# NAME
---------- ----------------------------------------------------------------
278 ASM mount : wait for heartbeat
419 control file heartbeat
SQL>
四，口令文件
1，[oracle@rhel dbs]$ strings orapworcl
]\[Z
ORACLE Remote Password file
INTERNAL
AB27B53EDC5FEF41
8A8F025737A9097A
2，[oracle@rhel dbs]$ pwd
/u01/app/oracle/10.2.0/db_1/dbs
[oracle@rhel dbs]$
3，如果丢失口令文件，在mount阶段会出现错误。
创建口令文件：SQL> host orapwd file=$ORACLE_HOME/dbs/orapworcl password=oracle entries=10;
五，undo
1，在完成数据库的验证和恢复过程后，数据库处于一致的状态，数据库还需要进行一系列的处理过程，将undo段在线操作，然后数据库可以提供访问，同时SMON可以开始进行事务回滚等。
2，在启动日志里，读者可能看到这样的一行：Database Characterset is ZHS16GBK；在每一次数据库的启动过程中，Oracle都需要判断控制文件的字符集和数据库的字符集是否相符，如果相符，则记录如上的一行日志，如果不符，则以数据库的字符集为准更新控制文件中的字符集记录，类似的日志如下：Updating character set in controlfile to ZHS16GBK232180
3，SCN：SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
------------------------
1173632
SQL>
SQL> select * from v$logfile;
SQL> select * from v$log;
六，检查点
1，检查点只是一个数据库事件，它存在的根本意义在于减少崩溃恢复的时间。当修改数据时，需要首先将数据读入到内存（Buffer Cache），修改数据的同时，Oracle会记录重做信息（Redo），用于恢复，因为有重做信息的存在，Oracle不需要在提交的时候立即将变化的数据块写回到磁盘（立即写的效率很低），重做（redo）的存在也正是为了在数据库崩溃以后，数据可以恢复。
2，当检查点发生时（此时的SCN成为ChcekpointSCN），ORACLE会通知DBWR进程，把修改过的数据，也就是此CheckpointSCN之前的脏数据（Dirty Data）从Buffer Cache写入磁盘，当写入完成之后，CKPT进程更新控制文件和数据文件头，记录检查点信息，标识变更。
3，SQL> select name,file#,CHECKPOINT_CHANGE#,to_char(CHECKPOINT_TIME,'yyyy-mm-dd hh24:mi:ss')CPT
from v$datafile;
NAME FILE# CHECKPOINT_CHANGE# CPT
------------------------------ ---------- ------------------ -------------------
/u01/app/oracle/oradata/orcl/s 1 1170539 2014-03-28 17:59:04
ystem01.dbf
/u01/app/oracle/oradata/orcl/u 2 1170539 2014-03-28 17:59:04
ndotbs01.dbf
/u01/app/oracle/oradata/orcl/s 3 1170539 2014-03-28 17:59:04
ysaux01.dbf
/u01/app/oracle/oradata/orcl/u 4 1170539 2014-03-28 17:59:04
sers01.dbf
NAME FILE# CHECKPOINT_CHANGE# CPT
------------------------------ ---------- ------------------ -------------------
/u01/app/oracle/oradata/orcl/e 5 1170539 2014-03-28 17:59:04
xample01.dbf
4，SQL> select dbid,CHECKPOINT_CHANGE# from v$database;
DBID CHECKPOINT_CHANGE#
---------- ------------------
1356398003 1170539
6，在检查点完成以后，此检查点之前的修改的数据都已经写入到了磁盘，重做日志文件中的相应的记录对于崩溃/实例恢复不再有用。检查点的频度对于数据库的恢复时间具有极大的影响，如果检查点的频率高，那么恢复时需要应用的重做日志就相对少，恢复时间就可以缩短。但是过于频繁的检查点同样会带来性能问题，尤其是更新频繁的数据库。
7，常规检查点：
Oracle实施的检查点通常被称为常规检查点（convention Checkpoint），这类检查点按一定的条件触发（log_checkpoint_interval,log_checkpoint_timeout参数设置及log switch等条件触发）。
8，增量检查点：
Oracle主要引入了检查点队列（Checkpoint Queue）机制，在数据库内部，每一个脏块都会被移动到检查点队列，按照Low RBA的顺序（第一次对此数据块修改对应的Redo Byte Address）来排列，如果一个数据块进行了多次修改，该数据块在检查点队列上的顺序并不会发生变化。当执行检查点时，DBWR从检查点队列按照Low RBA的顺序写出，实例检查点因此可以不断增进、阶段性的，CKPT进程使用非常轻量级的控制文件更新协议，将当前的最低RBA导入控制文件。因为增量检查点可以连续地进行，一次检查点RBA可以比常规检查点更接近数据库的最后状态，从而在数据库的实例恢复中可以极大的减少恢复的时间。通过增量检查点，DBWR可以持续进行写出，从而避免了检查点出发的峰值写入对于I/O的过度的征用。
七，查看oracle的版本
1，SQL> select * from v$version where rownum<2;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
2，SQL> select * from v$version ;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for Linux: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
SQL>
3，SQL> select * from v$option
where parameter='Fast-Start Fault Recovery';
PARAMETER VALUE
------------------------------ --------------------
Fast-Start Fault Recovery TRUE
SQL>
八，参数
1，Fast_Start Checkpointing 特性在oracle 8i中主要通过参数FAST_START_IO_TARGET来实现；在oracle 9i中，Fast_Start Checkpointing主要通过参数FAST_START_MTTR_TARGET来实现。
2，FAST_START_MTTR_TARGET，FAST_START_MTTR_TARGET参数从9i开始被引入，该参数定义数据库进行crash恢复的时间，单位是秒，取值范围是0~3600秒之间。在Oracle 9i中，oracle推荐设置这个参数代替FAST_START_IO_TARGET、LOG_CHECKPOINT_TIMEOUT及LOG_CHECKPOINT_INTERVAL参数。在缺省的情况下，oracle 9i中FAST_START_IO_TARGET和LOG_CHECKOUTPOINT_INTERVAL参数被设置为0.
3，SQL> show parameter fast_start_io;
NAME TYPE VALUE
------------------------------------ ----------- -----
fast_start_io_target integer 0
SQL> show parameter interval;
NAME TYPE VALUE
------------------------------------ ----------- -----
log_checkpoint_interval integer 0
SQL>
4，从oracle 9i R2开始，oracle引入了一个新的视图提供MTTR建议：
SQL> select MTTR_TARGET_FOR_ESTIMATE MttrEst,
ADVICE_STATUS AD,
DIRTY_LIMIT DL,
ESTD_CACHE_WRITES ESTCW,
ESTD_CACHE_WRITE_FACTOR EstCWF,ESTD_TOTAL_WRITES ESTW,
ESTD_TOTAL_WRITE_FACTOR ETWF,ESTD_TOTAL_IOS ETIO
from v$mttr_target_advice;
5，这个建议的收集受到oracle 9i 新引入的初始化参数statics_level的控制；
SQL> show parameter statistics_level;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
statistics_level string TYPICAL
SQL>
6，也可以通过v$statistics_level视图来查询MTTR Advise
SQL> select * from v$statistics_level
2 where STATISTICS_NAME='MTTR Advice'
3 /
STATISTICS_NAME DESCRIPTION SESSION_ SYSTEM_S ACTIVAT STATISTICS_VIEW_NAME SES
-------------------- -------------------------------------------------- -------- -------- ------- ------------------------- ---
MTTR Advice Predicts the impact of different MTTR settings on ENABLED ENABLED TYPICAL V$MTTR_TARGET_ADVICE NO
number of physical I/Os
SQL>
7，SQL> select RECOVERY_ESTIMATED_IOS REIO,
ACTUAL_REDO_BLKS ARB,
TARGET_REDO_BLKS TRB,
LOG_FILE_SIZE_REDO_BLKS LFSRB,
LOG_CHKPT_TIMEOUT_REDO_BLKS LCTRB,
LOG_CHKPT_INTERVAL_REDO_BLKS LCIRB,
FAST_START_IO_TARGET_REDO_BLKS FSIOTRB,
TARGET_MTTR TMTTR,
ESTIMATED_MTTR EMTTR,
CKPT_BLOCK_WRITES CBW
from v$instance_recovery;
REIO ARB TRB LFSRB LCTRB LCIRB FSIOTRB TMTTR EMTTR CBW
---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
31 102 2794 184320 2794 0 10 471
SQL>
九，v$instance_recovery
1，从v$instance_recovery视图，可以看到当前数据库估计的平均恢复时间（MTTR）参数ESTIMATED_MTTR。ESTIMATED_MTTR的估算值基于Dirty Buffer的数量和日志块数量得出的，这个参数数值告诉我们，如果此时数据库崩溃，那么进行实例恢复将会需要的时间。
2，在v$instance_recovery视图中，TARGET_MTTR代表的是期望的平均恢复时间，通常该参数应该等于FAST_START_MTTR_TARGET 参数设置值（但是如果FAST_START_MTTR_TARGET参数定义的极大或极小，TARGET_MTTR可能不等于FAST_START_MTTR_TARGET的设置）。
3，当ESTIMATED_MTTR接近或超过FAST_START_TARGET参数设置（v$instance_recovery， TARGET_MTTR）时，系统就会触发检查点，执行写出之后，系统恢复信息将会重新计算：在繁忙的系统中，可能会观察到ESTIMATED_MTTR>TARGET_TIME,这可能因为DBWR正忙于写出，甚或出现checkpoint不能及时完成的情况。
4，如果发现ESTIMATED_MTTR>TARGET_TIME，继续查询，ESTIMATED_MTTR继续升高。
5，通过CKPT_BLOCK_WRITES字段，可以看出检查点应经写出的数据块的数量，增量检查点的触发以及DBWR的持续写出，都会促使该值的增加。
6，当一个系统完成检查点之后，我们可以看到ESTIMATED_MTTR逐渐恢复到较为正常的状态（非正常的状态到正常的状态：238-183-138）；
十，v$session_wait
1,此时查询v$session_wait，查询原因，（例如：发生了一个checkpoint incomplete事件）
SQL> select sid,seq#,event from v$session_wait;
SID SEQ# EVENT
---------- ---------- ----------------------------------------------------------------
134 5 Streams AQ: qmn slave idle wait
136 1 Streams AQ: waiting for time management or cleanup tasks
147 1 jobq slave wait
151 6 Streams AQ: qmn coordinator idle wait
155 212 rdbms ipc message
156 1660 rdbms ipc message
158 211 SQL*Net message to client
160 222 rdbms ipc message
161 6 rdbms ipc message
162 780 rdbms ipc message
163 6 rdbms ipc message
2,查询v$log视图，看繁忙程度（例如：发现除啦current日志组外，所有日志组都处于Active状态）。
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1 1 10 52428800 1 NO CURRENT 1201384 29-MAR-14
2 1 8 52428800 1 YES INACTIVE 1159883 25-MAR-14
3 1 9 52428800 1 YES INACTIVE 1159889 25-MAR-14
SQL>
3,然后通过os查看iostat状态信息（例如：发现swap已经严重（si、sw较高），CPU等待IO（wa）也很高）这就意味着系统的IO存在瓶颈或者系统有突发的大规模的操作。
[root@rhel ~]# vmstat 2
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 83964 115132 694320 0 0 111 38 1093 79 0 0 98 1 0
0 0 0 83964 115140 694312 0 0 0 30 1009 65 0 0 100 0 0
0 0 0 83964 115140 694320 0 0 0 16 1001 63 0 0 100 0 0
0 0 0 83964 115140 694320 0 0 0 24 1008 59 0 1 99 0 0
0 0 0 83964 115148 694312 0 0 0 46 1012 72 0 0 100 0 0
0 0 0 83964 115148 694320 0 0 0 2 1006 58 0 0 100 0 0
0 0 0 83964 115148 694320 0 0 0 24 1006 57 0 0 99 1 0
0 0 0 83964 115156 694312 0 0 0 32 1008 67 0 0 100 0 0
0 0 0 83964 115156 694320 0 0 0 0 1003 59 0 0 100 0 0
4,从oracle的10g开始，数据库可以实现自动调整检查点，使用自动调整检查点，oracle数据库可以利用系统的低I/O负载时写出内存中的脏数据，从而提高数据库的效率。因此，即使数据库管理员设置了不合理的检查点相关的参数，oracle仍然能够通过自动调整数据库的CashRecovery时间控制在合理的范围内。当FAST_START_MTTR_TARGET参数未设置，自动检查点调整生效。通常，如果必须严格控制实例或者节点恢复时间，那么可以设置FAST_START_MTTR_TARGET为期望时间值；如果回复时间不需要严格控制，那么可以不设置FAST_START_MTTR_TARGET参数，从而启动oracle的自动检查点调整特性。
5,SQL> show parameter fast_start_mttr;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
fast_start_mttr_target integer 0
SQL>
6,SQL> select RECOVERY_ESTIMATED_IOS REIOS,TARGET_MTTR TMTTR,
ESTIMATED_MTTR EMTTR,WRITES_MTTR WMTTR,WRITES_OTHER_SETTINGS WOSET,
CKPT_BLOCK_WRITES CKPTBW,
WRITES_AUTOTUNE WAUTO,WRITES_FULL_THREAD_CKPT WFTCKPT
from v$instance_recovery;
REIOS TMTTR EMTTR WMTTR WOSET CKPTBW WAUTO WFTCKPT
---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
60 0 11 0 0 111 600 0
WRITES_AUTOTUNE字段值是指由于自动调整检查点执行的写出次数，而CKPT_BLOCK_WRITES指的则是由于检查点写出的block的数量。
Low cache rba（recovery block address）指在cache中，最低的RBA地址，在实例恢复或者崩溃恢复中，需要从这里开始恢复，on disk rba是磁盘上的最高的重做值，在进行恢复时应用重做至少要达到这个值。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/29611940/viewspace-1143692/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
[AD]参数文件
请登录后发表评论
登录
全部评论
