读书笔记：深入解析Oracle（作者：盖国强）

Item: 深入解析Oracle
Rating: 5
Author: 吕何甲

2010-08-18 22:26:33

深入解析Oracle

注1：该笔记为未完成版（最后修改日期为2010.5.4）
注2：转帖请注明出处（笔记作者：城市行走者）

第1章数据库的启动和关闭
1.1 数据库的启动
1.1.1 启动数据库到NOMOUNT状态的过程
1. 实例及进程的创建
2. V$PROCESS视图
3. 参数文件的选择
4. 实例启动最小参数需求
5. ORACLE_SID的含义
6. INSTANCE_NAME的含义
7.DB_NAME
8.RMAN的缺省实例
1.1.2 启动数据库到MOUNT状态
1. 控制文件的定位
2. 数据文件的存在性判断
3. 控制文件的HeartBeat(略)
4. 口令文件的作用（略）
5. lk<ORACLE_SID>文件及作用（略）
6. MOUNT相同DB_NAME的数据库（略）
1.1.3 启动数据库OPEN阶段
1. OPEN阶段的一致性校验
2. Oracle 11g Automatic Diagnostic Repository新特性（略）
3. Oracle 11g Fault Diagnosability Infrastration 新特性（略）
4. 关于诊断的建议
1.2 数据库的访问
1.2.1 客户端的tnsnames.ora文件配置
1.2.2 服务器端的监听器文件listener.ora配置
1.2.3 通过不同服务名对数据库访问
1.2.4 动态监听器注册服务
1.3 数据库的关闭
第2章控制文件与数据库初始化
2.1 控制文件的内容
2.2 SCN（系统改变号）
2.2.1 SCN的定义
2.2.2 SCN的获取方式
2.2.3 SCN的进一步说明
2.3 CHECKPOINT（检查点）
2.3.1 Checkpoint（检查点）的工作原理
2.3.2 常规检查点（完全检查点）与增量检查点（略）
2.3.3 LOG_CHECKPOINT_TO_ALERT参数
2.3.4 控制文件与数据文件头信息
2.3.5 数据库的启动验证
2.3.6 使用备份的控制文件（略）
2.3.7 FAST_START_MTTR_TARGET（略）
2.3.8 关于检查点执行的案例（略）
2.3.9 Oracle 10g自动检查点设置（略）
2.3.10 检查点信息及恢复起点（略）
2.3.11 正常关闭数据库的状况
2.3.12 异常关闭数据库的情况
2.3.13 数据库并行恢复案例一则（略）
2.3.14 判断一个死事务的恢复进度（略）
2.4 数据库的初始化（略）
第3章参数及参数文件
3.1 初始化参数的分类
3.1.1 推导参数（Derived Parameters）
3.1.2 操作系统依赖参数
3.1.3 可变参数
3.1.4 初始化参数的获取
3.2 参数文件
3.2.1 PFILE和SPFILE
3.2.2 获取参数的视图
3.2.3 SPFILE的创建
3.2.4 参数文件的搜索顺序
3.2.5 使用PFILE/SPFILE启动数据库
3.2.6 修改SPFILE文件的参数
3.2.7 解决SPFILE参数修改的错误
3.2.8 重置SPFILE中设置的参数
3.2.9 判断是否使用了SPFILE
3.2.10 SPFILE的备份与恢复
1. 设置控制文件自动备份
2. 更改自动备份的位置
3. 检查自动备份
4. 记录数据库变化
5. 测试
3.2.11 Oracle 11g参数文件恢复
3.2.12 如何设置Events事件（略）
3.2.13 导出SPFILE参数文件
3.3 案例诊断之一：参数文件
3.4 案例诊断之二：RAC环境参数文件
第4章数据字典
4.1 数据字典概述
4.2 内部RDBMS（X$）表（略）
4.3 数据字典表（略）
4.4 静态数据字典视图
4.4.1 静态数据字典视图的分类
4.4.2 静态数据字典视图的内部实现（略）
4.4.3 常用的数据字典视图举例
1. DICT/DICTIONARY
2. DICT_COLUMES
3. OBJ$/DBA_OBJECTS/OBJ
4. DBA_SOURCE
4.5 动态性能视图（V$）
4.5.1 GV$和V$视图
4.5.2 GV_$、V_$视图和GV$、V$同义词（略）
4.5.3 进一步说明（略）
4.5.4 动态性能视图与数据库启动
4.6 最后的验证（略）
第5章内存管理
5.1 PGA管理
5.1.1 什么是PGA
5.1.2 UGA与CGA
5.1.3 PGA管理技术变迁
5.1.4 参数的设置与内存分配
5.1.5 自动PGA管理实现原理（略）
5.1.6 PGA的调整建议
5.1.7 PGA的转储（略）
5.2 SGA管理
5.2.1 SGA的组成
1. 固定区域
2. Buffer Cache
3. Shared Pool
4. Redo Log Buffer
5. 其他内存组件(有疑问)
5.2.2 SGA与共享内存（略）
5.2.3 SGA管理的变迁
1. 8i中的静态SGA管理（略）
2. 9i中的静态SGA管理
3. 10g中的自动共享内存调整
4. 11g中的自动内存管理
5.3 ORACLE的内存分配和使用
5.3.1 案例诊断一：SGA和SWAP
5.3.2 案例诊断二：SGA设置过高导致的系统故障
5.3.3 案例诊断三：如何诊断和解决CPU高度消耗问题
第6章 BUFFER CACHE与SHARE POOL原理（略）
6.1 BUFFER CACHE原理
6.1.1 LRU与Dirty List
第7章重做（RODO）
7.1 RODO的作用
7.2 REDO的原理
7.3 REDO与LATCH（略）
7.4 ORACLE 9I REDO的增强（略）
7.5 ORACLE 10G REDO的增强（略）
7.6 REDO的内容（TRACE文件还是看不懂）
7.7 产生多少REDO
7.8 REDO写的触发条件
7.8.1 每3秒超市（Timeout）
7.8.2 阈值达到
7.8.3 用户提交
7.8.4 在DBWn写之前（不懂）
7.9 REDO LOG BUFFER的大小设置
7.10 COMMIT做了什么
7.11 日志的状态
7.12 日志的块大小（略）
7.13 日志文件的大小（本节没有讲具体的优化原则、方法）
7.14 如何调整日志文件大小
7.15 热备份期间的REDO（略）
7.16 能否不生成REDO（暂时略，需结合后面章节一起看）
7.17 REDO故障的恢复
7.17.1 丢失非活动日志组的故障恢复
7.17.2 丢失活动或当前日志文件的恢复
7.18 案例一：通过CLEAR日志恢复数据库
7.19 案例二：日志组过度激活的诊断
7.20 数值在ORACLE内部存储

第1章数据库的启动和关闭
        通常所说的Oracle Server主要有两个部分组成：Instance和Database。Instance是指一组后台进程和一块共享内存区域。Database是指存储在磁盘上的一组物理文件。通过Instance和Database的协同，Oracle才能形成一个动态的可访问的关系数据库模型。
1.1 数据库的启动
        启动过程：
 NOMOUNT：启动实例（这个步骤只和参数文件相关）。
 MOUNT：打开控制文件；并进行数据文件的存在性判断。
 OPEN：打开所有控制文件中描述的文件；并进行检查点及完整性检查。

1.1.1 启动数据库到NOMOUNT状态的过程
        1. 实例及进程的创建
        启动过程：
SQL> startup nomount
ORACLE 例程已经启动。

Total System Global Area 121634816 bytes
Fixed Size 787748 bytes
Variable Size 95419100 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes

        Oracle根据参数文件内容，创建了Instance，分配了相应的内存区域，启动了相应的后台进程。

        告警日志文件：
Sun Mar 21 00:18:13 2010
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
KCCDEBUG_LEVEL = 0
Autotune of undo retention is turned on.
Dynamic strands is set to TRUE
Running with 1 shared and 18 private strand(s). Zero-copy redo is FALSE
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 10.1.0.2.0.
System parameters with non-default values:
  processes = 150
  shared_pool_size = 83886080
  large_pool_size = 8388608
  java_pool_size = 0
  control_files = D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\CONTROL01.CTL, D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\CONTROL02.CTL, D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\CONTROL03.CTL
  db_block_size = 8192
  db_cache_size = 25165824
  compatible = 10.1.0.2.0
  log_archive_dest_1 = location=d:\oracle\archive1\
  log_archive_dest_2 = location=d:\oracle\archive2\
  db_file_multiblock_read_count= 16
  db_recovery_file_dest = D:\oracle\product\10.1.0\flash_recovery_area
  db_recovery_file_dest_size= 2147483648
  undo_management = AUTO
  undo_tablespace = UNDOTBS1
  remote_login_passwordfile= EXCLUSIVE
  db_domain =
  local_listener = LISTENER_OCP10G
  job_queue_processes = 10
  background_dump_dest = D:\ORACLE\PRODUCT\10.1.0\ADMIN\OCP10G\BDUMP
  user_dump_dest = D:\ORACLE\PRODUCT\10.1.0\ADMIN\OCP10G\UDUMP
  core_dump_dest = D:\ORACLE\PRODUCT\10.1.0\ADMIN\OCP10G\CDUMP
  sort_area_size = 65536
  db_name = OCP10G
  open_cursors = 300
  pga_aggregate_target = 25165824
PMON started with pid=2, OS id=2712
MMAN started with pid=3, OS id=2164
DBW0 started with pid=4, OS id=3296
LGWR started with pid=5, OS id=3640
CKPT started with pid=6, OS id=2568
SMON started with pid=7, OS id=2360
RECO started with pid=8, OS id=692
CJQ0 started with pid=9, OS id=736

        2. V$PROCESS视图
        通过V$PROCESS视图，可以找到对应于操作系统的每个进程信息。

        3. 参数文件的选择
        启动过程中Oracle选择参数文件的顺序为：
        spfile<ORACLE_SID>.ora
        spfile.ora
        init<ORACLE_SID>.ora
        如果三个文件都不存在，则Oracle无法启动实例。

        4. 实例启动最小参数需求
        在参数文件中，通常需要最少的参数是DB_NAME.

        5. ORACLE_SID的含义
        当Oracle实例启动时，在操作系统上fork的进程就是一句这个ORACLE_SID来创建，这就是ORACLE_SID的作用。
        后台进程的名称是通过ORACLE_SID决定的。
        参数文件的名称是通过ORACLE_SID决定的。

        6. INSTANCE_NAME的含义
        INSTANCE_NAME用于标识数据库实例的名称，其缺省值通常是ORACLE_SID。
        INSTANCE_NAME的另一个作用是，在监听器动态注册时作为缺省的服务名注册。监听器（listener）配置文件中的SID_NAME就是来自INSTANCE_NAME参数，监听器通过INSTANCE_NAME才能确定将连接请求注册到哪一个实例上。

SID_LIST_LISTENER2 =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = ocp10g)
      (SID_NAME = ocp10g)
    )

        7.DB_NAME
        DB_NAME代表了实例即将挂接的数据库的名称，关系到具体的物理文件。通常数据库缺省的INSTANCE_NAME和DB_NAME可以设置相同。（在RAC环境下，由于多个实例对应一个数据库，所以INSTANCE_NAME和DB_NAME不同）。

        总结：
        一个实例（INSTANCE_NAME）可以mount并打开任何数据库(DB_NAME),但是同一时间一个实例只能打开一个数据库；一个数据库(DB_NAME)可以为任何实例（INSTANCE_NAME）所打开（但是在非OPS/RAC情况下，同时只能被一个实例打开）

        8.RMAN的缺省实例
        在使用RMAN时，Oracle允许在不存在参数的情况下启动一个实例，数据库的DB_NAME会被缺省的命名为DUMMY。

1.1.2 启动数据库到MOUNT状态
 MOUNT：打开控制文件；并进行数据文件的存在性判断。
        加载过程：
SQL> alter database mount;
数据库已更改。

        告警日志：
Sun Mar 21 01:18:02 2010
alter database mount
Sun Mar 21 01:18:03 2010
Controlfile identified with block size 16384
Sun Mar 21 01:18:07 2010
Setting recovery target incarnation to 2
Sun Mar 21 01:18:07 2010
Successful mount of redo thread 1, with mount id 3562458506
Sun Mar 21 01:18:07 2010
Database mounted in Exclusive Mode.
Completed: alter database mount
1. 控制文件的定位
        涉及到参数文件恢复的问题。
2. 数据文件的存在性判断
        如果数据文件不存在，则后台进程将在告警日志文件中记录文件缺失信息，并却在动态视图（比如v$recover_file）中记录这些信息。
3. 控制文件的HeartBeat(略)
        HeartBeat表明实例已经被特定的例程所Mount，这个属性主要用于OPS/RAC环境。
SQL> select event#,event_id,name from v$event_name where name like '%heartbeat%';

    EVENT# EVENT_ID NAME
---------- ---------- -------------------------
       175 40893507 control file heartbeat
       755 1299431751 ASM mount : wait for heartbeat
4. 口令文件的作用（略）
5. lk<ORACLE_SID>文件及作用（略）
6. MOUNT相同DB_NAME的数据库（略）
1.1.3 启动数据库OPEN阶段
        打开所有控制文件中描述的文件；并进行检查点及完整性检查。
        打开过程：
SQL> alter database open;

数据库已更改。

        告警日志：
Sun Mar 21 01:20:34 2010
         alter database open
Sun Mar 21 01:20:35 2010
Maximum redo generation record size = 120832 bytes
Maximum redo generation change vector size = 116476 bytes
Private_strands 4 at log switch
Thread 1 opened at log sequence 681
  Current log# 3 seq# 681 mem# 0: D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO03.LOG
  Current log# 3 seq# 681 mem# 1: D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO03B.LOG
Successful open of redo thread 1
Sun Mar 21 01:20:35 2010
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sun Mar 21 01:20:35 2010
SMON: enabling cache recovery
Sun Mar 21 01:20:36 2010
Successfully onlined Undo Tablespace 1.
Sun Mar 21 01:20:36 2010
SMON: enabling tx recovery
Sun Mar 21 01:20:36 2010
Database Characterset is ZHS16GBK
Sun Mar 21 01:20:36 2010
Published database character set on system events channel
Sun Mar 21 01:20:36 2010
All processes have switched to database character set
Sun Mar 21 01:20:39 2010
Starting background process QMNC
QMNC started with pid=11, OS id=2068
Sun Mar 21 01:20:40 2010
replication_dependency_tracking turned off (no async multimaster replication found)
Sun Mar 21 01:20:41 2010
Starting background process MMON
Starting background process MMNL
MMNL started with pid=13, OS id=120
Sun Mar 21 01:20:41 2010
Completed: alter database open
MMON started with pid=12, OS id=2308
Sun Mar 21 01:20:46 2010
db_recovery_file_dest_size of 2048 MB is 0.15% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.

1. OPEN阶段的一致性校验
        在数据库的OPEN阶段过程中，Oracle进行的检查包括以下两项：
        1、第一次检查数据文件头中的检查点计数（Checkpoint CNT）是否和控制文件中的检查点计数（Checkpoint CNT）相一致。此步骤检查用已确认数据文件是来自同一版本，而不是从备份中恢复而来的（因为检查点计数Checkpoint CNT不会被冻结，会一直被修改）。
        2、第二次检查数据文件头的开始SCN和控制文件中记录的该文件的结束SCN是否一致，如果一致，则不需对该文件恢复。
        对每个数据文件完成检查后，打开数据库，锁定数据文件，同时将每个数据文件的结束SCN设置为无穷大。

        本节的例子不全面，后面有详细的介绍：2.3.5（P66），后面的例子是完整的启动过程。
2. Oracle 11g Automatic Diagnostic Repository新特性（略）
3. Oracle 11g Fault Diagnosability Infrastration 新特性（略）
4. 关于诊断的建议
        注意：在数据库出现问题的时候，首先检查告警日志文件，研究其中的告警信息或者提供给他人寻求帮助，这是通常解决问题的第一个步骤。
        启动日志中的每条信息都是值得研究的。

1.2 数据库的访问
1.2.1 客户端的tnsnames.ora文件配置
        一段典型的配置如下：
v2p =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = *.*.32.40)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = v2p)
    )
  )

v2ptj =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = *.*.32.36)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = v2p)
    )
  )

        SERVICE_NAME用于标识访问的数据库服务
        配置完成后，可以通过tnsping工具进行连通性测试：

C:\Documents and Settings\Owner>tnsping v2ptj

TNS Ping Utility for 32-bit Windows: Version 10.1.0.2.0 - Production on 24-3月 -
2010 22:08:28

Copyright (c) 1997, 2003, Oracle. All rights reserved.

已使用的参数文件:
D:\oracle\product\10.1.0\db_1\network\admin\sqlnet.ora

已使用 TNSNAMES 适配器来解析别名
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = *.*.32.36)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = v2p)))
OK (20 毫秒)

        如果能够顺利通信，则可以通过SQL*Plus或其他工具通过网络服务名进行数据库网络访问：
C:\Documents and Settings\Owner>sqlplus username/password@v2ptj

SQL*Plus: Release 10.1.0.2.0 - Production on 星期三 3月 24 22:12:11 2010

Copyright (c) 1982, 2004, Oracle. All rights reserved.

连接到:
Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
With the Partitioning option
JServer Release 9.2.0.6.0 - Production

SQL>

1.2.2 服务器端的监听器文件listener.ora配置
        查看Oracle数据库的service_name参数：
SQL> show parameter service_name

NAME TYPE VALUE
---------- ------- -----------
service_names string v2p

        一段典型的监听器文件listener.ora配置：
$ hostname
P570A
$ pwd
/oracle2/app/oracle/product/9.2.0/network/admin
$ more listener.ora
# LISTENER.ORA.P570A Network Configuration File: /oracle2/app/oracle/product/9.2.0/network/admin/listener.ora.P
570A
# Generated by Oracle configuration tools.

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = P570A)(PORT = 1521))
)
)
)

SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /oracle2/app/oracle/product/9.2.0)
(PROGRAM = extproc)
)
)

        第一部分LISTENER信息，这部分包含了监听的协议、地址、端口等信息。
        第二部分SID_LIST_LISTENER信息，这部分信息用于提供对外的数据库服务列表。第一个SID_DESC部分（SID_NAME = PLSExtProc）是数据库缺省就包含的对外部存储过程提供的本地监听。

oracle1@P570A/oracle1#lsnrctl status

LSNRCTL for IBM/AIX RISC System/6000: Version 9.2.0.6.0 - Production on 24-MAR-2010 23:31:28

Copyright (c) 1991, 2002, Oracle Corporation. All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=P570A)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for IBM/AIX RISC System/6000: Version 9.2.0.6.0 - Production
Start Date 25-MAY-2009 22:41:02
Uptime 303 days 0 hr. 50 min. 26 sec
Trace Level off
Security OFF
SNMP OFF
Listener Parameter File /oracle1/app/oracle/product/9.2.0/network/admin/listener.ora
Listener Log File /oracle1/app/oracle/product/9.2.0/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=P570A)(PORT=1521)))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
  Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "his" has 1 instance(s).
  Instance "his", status READY, has 1 handler(s) for this service...
Service "v2p" has 2 instance(s).
  Instance "v2p", status BLOCKED, has 1 handler(s) for this service...
  Instance "v2p", status READY, has 1 handler(s) for this service...
The command completed successfully

1.2.3 通过不同服务名对数据库访问
1.2.4 动态监听器注册服务
        所谓当台注册是指，当实例启动之后，有后台进程PMON在监听器中注册数据库服务信息。
        动态注册的服务名，由于监听器确切地知道实例的状态，所以正常状态通常显示为READY，而对于静态注册的服务名，则状态显示为UNKNOW。
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=P570A)(PORT=1521)))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
  Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "v2p" has 2 instance(s).
  Instance "v2p", status BLOCKED, has 1 handler(s) for this service...
  Instance "v2p", status READY, has 1 handler(s) for this service...

        如果监听器具有缺省的名称、端口及协议，则无需任何特殊的配置，Oracle就能够执行动态注册。例如：
SQL> show parameter local_listener

NAME TYPE VALUE
------------------------ ---------- ------------
local_listener string

        但是如果监听器具有非缺省配置，则需要设置local_listener参数。

        关于共享服务器模式和RAC环境的部分，暂时略。

1.3 数据库的关闭
        shutdown immediate是一种最为常见的数据库关闭方式。
需补充
        如果不得不用非常规方式关闭数据库，可以在关闭数据库之前执行一次checkpoint（alter system checkpoint），如果此后再使用ABORT方式关闭数据库，那么在下次启动恢复时，需要恢复的数据就可以减少。

第2章控制文件与数据库初始化
2.1 控制文件的内容
        控制文件中保存着下列信息：
        。。。
        检查点及SCN信息
        P51
        由于控制文件是个二进制文件，无法直接打开查阅，但是可以通过下面的命令将控制文件的内容转储出来查看：
        alter session set events 'immediate trace name controlf level 8';
2.2 SCN（系统改变号）
2.2.1 SCN的定义
        SCN是Oracle内部的时钟机制，Oracle通过SCN来维护数据库的一致性，并通过SCN实施Oraclede恢复机制。
        SCN通常在系统提交或回滚时改变。
2.2.2 SCN的获取方式
        1、从Oracle 9i开始：
SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                13699237
        2、从Oracle 10g开始，在V$DATABASE视图中增加了current_scn字段：
SQL> select current_scn from v$database;

CURRENT_SCN
-----------
   13699237
2.2.3 SCN的进一步说明
        SCN通常在系统提交或回滚时改变，在控制文件、数据文件头、数据块、日志文件头、日志文件change vector中都有SCN，但其作用各不相同。
        1、数据文件头中包含了该数据文件的Checkpoint SCN，表示该数据文件最近一次执行检查点操作时的SCN。
        2、日志文件头中包含了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 ARCHIVED STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- -------- ---------------- ------------- -----------
         1 1 715 10485760 2 NO INACTIVE 13688389 2010-3-25 5
         2 1 716 10485760 2 NO CURRENT 13697204 2010-3-25 9
         3 1 714 10485760 2 NO INACTIVE 13679431 2010-3-25 1
SQL> select GROUP#,STATUS,FIRST_CHANGE#,FIRST_TIME from v$log;

    GROUP# STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------------- ------------- -----------
         1 INACTIVE 13688389 2010-3-25 5
         2 CURRENT 13697204 2010-3-25 9
         3 INACTIVE 13679431 2010-3-25 1

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                13700036

SQL> alter system switch logfile;

System altered

SQL> select GROUP#,STATUS,FIRST_CHANGE#,FIRST_TIME from v$log;

    GROUP# STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------------- ------------- -----------
         1 INACTIVE 13688389 2010-3-25 5
         2 ACTIVE 13697204 2010-3-25 9
         3 CURRENT 13700053 2010-3-25 1

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                13700066

        控制文件的转储中可以看到Low SCN和Next SCN。P56，略

2.3 Checkpoint（检查点）
        检查点事件由CKPT后台进程触发，当检查点发生时，CKPT进程会负责通知DBWR进程将脏数据（Dirty Buffer）写出到数据文件上。Checkpoint的另外一个职责是负责更新数据文件头及控制文件上的检查点信息。
        检查点事件存在的根本意义在于减少崩溃恢复（Crash Recovery）的时间。参考2.3.7（P73）。
2.3.1 Checkpoint（检查点）的工作原理
P57-P58
SQL> select dbid,name,checkpoint_change#,current_scn from v$database;

      DBID NAME CHECKPOINT_CHANGE# CURRENT_SCN
---------- --------- ------------------ -----------
3542321520 OCP10G 13715332 13715775

SQL> select file#,checkpoint_change#,checkpoint_time from v$datafile;

     FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME
---------- ------------------ ---------------
         1 13715332 2010-3-25 17:07
         2 13715332 2010-3-25 17:07
         3 13715332 2010-3-25 17:07
         4 13715332 2010-3-25 17:07
         5 13715332 2010-3-25 17:07
2.3.2 常规检查点（完全检查点）与增量检查点（略）
        常规检查点（完全检查点）时，CKPT进程需要写出全部脏数据，同时更新数据文件头及控制文件上的检查点信息。
        增量检查点时，CKPT进程进行轻量级更新，并不会更新数据文件头及控制文件上的检查点信息。而只是记录控制文件检查点SCN（Controlfile Checkpointed at scn）并且根据增量检查点的写出增进RBA（Redo Byte Address）信息。（不理解）

        从Oracle 8i开始，完全检查点仅在以下两种情况下出现：
        1、ALTER SYSTEM CHECKPOINT；
        2、SHUTDOWN （除了ABORT方式外）。
        LOG SWITCH事件同样触发的是增量检查点，但是在LOG SWITCH触发的检查点促使数据文件头与控制文件信息的同步。（作者在这里说的不明白，也没有举例）

2.3.3 LOG_CHECKPOINT_TO_ALERT参数
SQL> alter system set log_checkpoints_to_alert =true;

System altered

        日志文件中信息：
Thu Mar 25 11:23:57 2010
ALTER SYSTEM SET log_checkpoints_to_alert=TRUE SCOPE=BOTH;
... ...
Thu Mar 25 15:24:26 2010
Private_strands 7 at log switch
Beginning log switch checkpoint up to RBA [0x2d0.2.10], SCN: 0x0000.00d13865 （也就是十进制的13711461）
Thread 1 advanced to log sequence 720
  Current log# 3 seq# 720 mem# 0: D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO03.LOG
  Current log# 3 seq# 720 mem# 1: D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO03B.LOG
Thu Mar 25 15:29:34 2010
Completed checkpoint up to RBA [0x2d0.2.10], SCN: 13711461
Thu Mar 25 15:33:55 2010
Incremental checkpoint up to RBA [0x2d0.65.0], current log tail at RBA [0x2d0.b4.0]
Thu Mar 25 16:04:42 2010
Incremental checkpoint up to RBA [0x2d0.39f.0], current log tail at RBA [0x2d0.ff9.0]
Thu Mar 25 16:35:28 2010
Incremental checkpoint up to RBA [0x2d0.1343.0], current log tail at RBA [0x2d0.13bc.0]
... ...
        具体的解释参考P64

        此时，数据库的SCN和检查点分别为
SQL> select current_scn,checkpoint_change# from v$database;

CURRENT_SCN CHECKPOINT_CHANGE#
----------- ------------------
   13714637 13711461

2.3.4 控制文件与数据文件头信息
        需要进行转储
SQL> shutdown immediate

数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。

SQL> startup mount

ORACLE 例程已经启动。
Total System Global Area 121634816 bytes
Fixed Size 787748 bytes
Variable Size 95419100 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
数据库装载完毕。

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

会话已更改。

        trace文件内容包含两部分，一部分来自控制文件，另一部分来自数据文件：
*** 2010-03-28 16:05:39.781
DUMP OF DATA FILES: 6 files in database

DATA FILE #4:
  (name #8) D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\USERS01.DBF
creation size=640 block size=8192 status=0xe head=8 tail=8 dup=1
tablespace 4, index=5 krfil=4 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:2885 scn: 0x0000.00d3cf84 03/28/2010 13:10:58
Stop scn: 0x0000.00d3cf84 03/28/2010 13:10:58
Creation Checkpointed at scn: 0x0000.00001c2c 08/05/2009 00:41:52
thread:1 rba:(0x2.2114.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Offline scn: 0x0000.00879357 prev_range: 0
Online Checkpointed at scn: 0x0000.00879358 12/29/2009 17:54:09
thread:1 rba:(0x1.2.0)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED

V10 STYLE FILE HEADER:
        Compatibility Vsn = 168821248=0xa100200
        Db ID=3542321520=0xd3238970, Db Name='OCP10G'
        Activation ID=0=0x0
        Control Seq=467447=0x721f7, File size=640=0x280
        File Number=4, Blksiz=8192, File Type=3 DATA
Tablespace #4 - USERS rel_fn:4
Creation at scn: 0x0000.00001c2c 08/05/2009 00:41:52
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x2a227b41 scn: 0x0000.00879358 reset logs terminal rcv data:0x0 scn: 0x0000.00000000
prev reset logs count:0x295e6b30 scn: 0x0000.00000001 prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000
recovered at 03/06/2010 10:35:08
status:0x0 root dba:0x00000000 chkpt cnt: 2885 ctl cnt:2884
begin-hot-backup file size: 0
Checkpointed at scn: 0x0000.00d3cf84 03/28/2010 13:10:58
thread:1 rba:(0x308.24d3.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Backup Checkpointed at scn: 0x0000.00000000
thread:0 rba:(0x0.0.0)
enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
External cache id: 0x0 0x0 0x0 0x0
Absolute fuzzy scn: 0x0000.00000000
Recovery fuzzy scn: 0x0000.00000000 01/01/1988 00:00:00
Terminal Recovery Stamp scn: 0x0000.00000000 01/01/1988 00:00:00
Platform Information: Creation Platform ID: 7
Current Platform ID: 7 Last Platform ID: 7

2.3.5 数据库的启动验证
        在数据库的OPEN阶段过程中，Oracle进行的检查包括以下两项：
        1、第一次检查数据文件头中的检查点计数（Checkpoint CNT）是否和控制文件中的检查点计数（Checkpoint CNT）相一致。此步骤检查用已确认数据文件是来自同一版本，而不是从备份中恢复而来的（因为检查点计数Checkpoint CNT不会被冻结，会一直被修改）。
        2、第二次检查数据文件头的开始SCN和控制文件中记录的该文件的结束SCN是否一致，如果一致，则不需对该文件恢复。
        对每个数据文件完成检查后，打开数据库，锁定数据文件，同时将每个数据文件的结束SCN设置为无穷大。（上一节的实验没有做到这一步alter database open）

        具体例子见上一节2.3.4。
2.3.6 使用备份的控制文件（略）
2.3.7 FAST_START_MTTR_TARGET（略）
        在数据库中，增量检查点是通过Fast_Start Checkpointing特性来实现的。
SQL> select parameter,value from v$option
  2 where parameter='Fast-Start Fault Recovery';

PARAMETER VALUE
------------------------------------------- --------------
Fast-Start Fault Recovery TRUE

SQL> show parameter fast_start_mttr_target

NAME TYPE VALUE
------------------------------- ----------- ----------
fast_start_mttr_target integer 300

        当前的实例恢复状态可以通过v$instance_recovery视图查询得到“
SQL> select target_mttr,estimated_mttr from v$instance_recovery;

TARGET_MTTR ESTIMATED_MTTR
----------- --------------
        300 7

        当ESTIMATED_MTTR接近或超过FAST_START_MTTR_TARGET参数设置（v$instance_recovery.TARGET_MTTR）时，系统会触发检查点，执行写出。
2.3.8 关于检查点执行的案例（略）
2.3.9 Oracle 10g自动检查点设置（略）
        生产系统没有使用这一特性。
        在实验系统上
SQL> select TARGET_MTTR,ESTIMATED_MTTR,WRITES_AUTOTUNE,CKPT_BLOCK_WRITES
  2 from v$instance_recovery;

TARGET_MTTR ESTIMATED_MTTR WRITES_AUTOTUNE CKPT_BLOCK_WRITES
----------- -------------- --------------- -----------------
          0 28 120702 95327

SQL> select name,value from v$sysstat where upper(name) like '%DBWR%';

NAME VALUE
------------------------------------------------- ----------
DBWR checkpoint buffers written 122395
DBWR thread checkpoint buffers written 1693
DBWR tablespace checkpoint buffers written 0
．．．．．．
        具体字段值参考P76
2.3.10 检查点信息及恢复起点（略）
        参考2.3.2（P59）
2.3.11 正常关闭数据库的状况
        常规关闭数据库（即除了shutdown abort方式之外）后，下次启动时不需要执行恢复，这是因为常规关闭数据库时执行了完全检查点（Full Checkpoint），所有脏数据已经写入到数据文件。在控制文件的数据文件信息部分，对于每一个数据文件都有一个Checkpoint SCN和Stop SCN，用于启动时校验判断。
SQL> shutdown immediate

数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。

SQL> startup mount

ORACLE 例程已经启动。
Total System Global Area 121634816 bytes
Fixed Size 787748 bytes
Variable Size 95419100 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
数据库装载完毕。

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

会话已更改。

        trace文件中会记录控制文件的详细内容：
*** 2010-03-28 13:14:26.640
*** SERVICE NAME:() 2010-03-28 13:14:26.609
*** SESSION ID:(162.7) 2010-03-28 13:14:26.609
DUMP OF CONTROL FILES, Seq # 467449 = 0x721f9
1、数据库的相关信息：
***************************************************************************
DATABASE ENTRY
***************************************************************************
(blkno = 0x1, size = 192, max = 1, in-use = 1, last-recid= 0)
08/05/2009 00:41:20
DB Name "OCP10G"
Database flags = 0x00404000 0x00000000
Controlfile Creation Timestamp 08/05/2009 00:41:20
Incmplt recovery scn: 0x0000.00000000
Resetlogs scn: 0x0000.00879358 Resetlogs Timestamp 12/29/2009 17:54:09
Prior resetlogs scn: 0x0000.00000001 Prior resetlogs Timestamp 08/05/2009 00:41:20
Redo Version: compatible=0xa100200
#Data files = 5, #Online files = 5
Database checkpoint: Thread=1 scn: 0x0000.00d3cf84
Threads: #Enabled=1, #Open=0, Head=0, Tail=0
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Max log members = 3, Max data members = 1
Arch list: Head=3, Tail=3, Force scn: 0x0000.00d3774escn: 0x0000.00a426d6
Controlfile Checkpointed at scn: 0x0000.00d3c0b3 03/28/2010 11:33:23
thread:0 rba:(0x0.0.0)
enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000

2、Redo检查点信息
***************************************************************************
REDO THREAD RECORDS
***************************************************************************
(blkno = 0x8, size = 104, max = 8, in-use = 1, last-recid= 0)
THREAD #1 - status:0xe thread links forward:0 back:0
#logs:3 first:1 last:3 current:2 last used seq#:0x308
enabled at scn: 0x0000.00879358 12/29/2009 17:54:09
disabled at scn: 0x0000.00000000 01/01/1988 00:00:00
opened at 03/21/2010 01:20:35 by instance ocp10g
Checkpointed at scn: 0x0000.00d3cf84 03/28/2010 13:10:58
thread:1 rba:(0x308.24d3.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
log history: 2603

3、数据文件检查点信息
***************************************************************************
DATA FILE RECORDS
***************************************************************************
DATA FILE #4:
  (name #8) D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\USERS01.DBF
creation size=640 block size=8192 status=0xe head=8 tail=8 dup=1
tablespace 4, index=5 krfil=4 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:2885 scn: 0x0000.00d3cf84 03/28/2010 13:10:58
Stop scn: 0x0000.00d3cf84 03/28/2010 13:10:58
Creation Checkpointed at scn: 0x0000.00001c2c 08/05/2009 00:41:52
thread:1 rba:(0x2.2114.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Offline scn: 0x0000.00879357 prev_range: 0
Online Checkpointed at scn: 0x0000.00879358 12/29/2009 17:54:09
thread:1 rba:(0x1.2.0)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED

        注意：常规关闭数据库时执行了完全检查点（Full Checkpoint），所有脏数据已经写入到数据文件；数据文件处于一致状态。Checkpoint SCN和Stop SCN相等（0x0000.00d3cf84）。
        可以参考2.3.4以及2.3.5。例子本质都相同，虽然前面的例子是转储数据文件头file_hdr，本节的例子是转储控制文件CONTROLF。

2.3.12 异常关闭数据库的情况
SQL> shutdown abort
ORACLE 例程已经关闭。

SQL> startup mount
ORACLE 例程已经启动。

Total System Global Area 121634816 bytes
Fixed Size 787748 bytes
Variable Size 95419100 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
数据库装载完毕。

SQL> alter session set events 'immediate trace name CONTROLF level 12';
会话已更改。
        trace文件中会记录控制文件的详细内容：
*** 2010-03-28 16:47:41.921
*** SERVICE NAME:() 2010-03-28 16:47:41.890
*** SESSION ID:(162.7) 2010-03-28 16:47:41.890
DUMP OF CONTROL FILES, Seq # 467453 = 0x721fd

1、数据库的相关信息：
***************************************************************************
DATABASE ENTRY
***************************************************************************
(blkno = 0x1, size = 192, max = 1, in-use = 1, last-recid= 0)
08/05/2009 00:41:20
DB Name "OCP10G"
Database flags = 0x00404000 0x00000000
Controlfile Creation Timestamp 08/05/2009 00:41:20
Incmplt recovery scn: 0x0000.00000000
Resetlogs scn: 0x0000.00879358 Resetlogs Timestamp 12/29/2009 17:54:09
Prior resetlogs scn: 0x0000.00000001 Prior resetlogs Timestamp 08/05/2009 00:41:20
Redo Version: compatible=0xa100200
#Data files = 5, #Online files = 5
Database checkpoint: Thread=1 scn: 0x0000.00d3cf85
Threads: #Enabled=1, #Open=1, Head=1, Tail=1
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Max log members = 3, Max data members = 1
Arch list: Head=3, Tail=3, Force scn: 0x0000.00d3774escn: 0x0000.00a426d6
Controlfile Checkpointed at scn: 0x0000.00d3cffa 03/28/2010 16:45:16
thread:0 rba:(0x0.0.0)
enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000

2、Redo检查点信息
***************************************************************************
REDO THREAD RECORDS
***************************************************************************
(blkno = 0x8, size = 104, max = 8, in-use = 1, last-recid= 0)
THREAD #1 - status:0xf thread links forward:0 back:0
#logs:3 first:1 last:3 current:2 last used seq#:0x308
enabled at scn: 0x0000.00879358 12/29/2009 17:54:09
disabled at scn: 0x0000.00000000 01/01/1988 00:00:00
opened at 03/28/2010 16:45:08 by instance ocp10g
Checkpointed at scn: 0x0000.00d3cf85 03/28/2010 16:45:08
thread:1 rba:(0x308.24d3.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
log history: 2603

3、数据文件检查点信息
DATA FILE #4:
  (name #8) D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\USERS01.DBF
creation size=640 block size=8192 status=0xe head=8 tail=8 dup=1
tablespace 4, index=5 krfil=4 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:2886 scn: 0x0000.00d3cf85 03/28/2010 16:45:08
Stop scn: 0xffff.ffffffff 03/28/2010 13:10:58
Creation Checkpointed at scn: 0x0000.00001c2c 08/05/2009 00:41:52
thread:1 rba:(0x2.2114.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Offline scn: 0x0000.00879357 prev_range: 0
Online Checkpointed at scn: 0x0000.00879358 12/29/2009 17:54:09
thread:1 rba:(0x1.2.0)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
        注意此处：由于数据库是异常关闭的，数据库没有完成最后的检查点，数据文件的Stop SCN无穷大（Stop scn: 0xffff.ffffffff）。
        在以上的信息中，各部分的Checkpoint SCN信息都一致（scn: 0x0000.00d3cf85），但是数据文件的Stop SCN无穷大（Stop scn: 0xffff.ffffffff），不等于Checkpoint SCN，这意味着上一次关闭没有执行完全检查点，是异常关闭。此时启动数据库需进行恢复。

4、数据库实例恢复
P81

实例恢复的两个步骤：
？？？在alert中如何体现？？？
Sun Mar 28 17:01:47 2010
alter database open

Sun Mar 28 17:01:47 2010
Beginning crash recovery of 1 threads
Sun Mar 28 17:01:47 2010
Started first pass scan
Sun Mar 28 17:01:47 2010
Completed first pass scan
290 redo blocks read, 74 data blocks need recovery
Sun Mar 28 17:01:47 2010
Started redo application at
Thread 1: logseq 776, block 9428, scn 0.0
Recovery of Online Redo Log: Thread 1 Group 2 Seq 776 Reading mem 0
  Mem# 0 errs 0: D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO02.LOG
  Mem# 1 errs 0: D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO02B.LOG
Sun Mar 28 17:01:48 2010
Completed redo application
Sun Mar 28 17:01:48 2010
Completed crash recovery at
Thread 1: logseq 776, block 9718, scn 0.13901436
74 data blocks read, 74 data blocks written, 290 redo blocks read
Sun Mar 28 17:01:49 2010
Thread 1 advanced to log sequence 777
Maximum redo generation record size = 120832 bytes
Maximum redo generation change vector size = 116476 bytes
Private_strands 7 at log switch
Thread 1 opened at log sequence 777
  Current log# 3 seq# 777 mem# 0: D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO03.LOG
  Current log# 3 seq# 777 mem# 1: D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO03B.LOG
Successful open of redo thread 1
Sun Mar 28 17:01:49 2010
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sun Mar 28 17:01:49 2010
SMON: enabling cache recovery
Sun Mar 28 17:01:50 2010
Incremental checkpoint up to RBA [0x309.3.0], current log tail at RBA [0x309.17.0]
Sun Mar 28 17:01:51 2010
Successfully onlined Undo Tablespace 1.
Sun Mar 28 17:01:51 2010
SMON: enabling tx recovery
Sun Mar 28 17:01:52 2010
Database Characterset is ZHS16GBK
Sun Mar 28 17:01:52 2010
Published database character set on system events channel
Sun Mar 28 17:01:52 2010
All processes have switched to database character set
Sun Mar 28 17:01:53 2010
Starting background process QMNC
QMNC started with pid=10, OS id=3828
Sun Mar 28 17:01:55 2010
replication_dependency_tracking turned off (no async multimaster replication found)
Sun Mar 28 17:01:56 2010
Starting background process MMON
Starting background process MMNL
MMNL started with pid=14, OS id=1452
Sun Mar 28 17:01:56 2010
Completed: alter database open
MMON started with pid=12, OS id=3724
Sun Mar 28 17:02:02 2010
db_recovery_file_dest_size of 2048 MB is 0.15% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.

2.3.13 数据库并行恢复案例一则（略）
2.3.14 判断一个死事务的恢复进度（略）

2.4 数据库的初始化（略）

第3章参数及参数文件
3.1 初始化参数的分类
        按照参数得出方式的不同可以分为：推导参数、操作系统依赖参数、可变参数。
        按周参数修改方式的不同可以分为：静态参数、动态参数。
3.1.1 推导参数（Derived Parameters）
        推导参数通常来自于其他参数的推导运算，依赖于其他参数得出。所以这类参数通常不需要修改。
        注意：通常在创建数据库时，建议将processes参数值（其默认值为150）修改为500或500以上（生产系统的值为1024）
SQL> show parameter processes

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
processes integer 1024

3.1.2 操作系统依赖参数
        某些参数的有效值或者取值范围依赖于或者受限于操作系统，比如db_cache_size。
SQL> show parameter db_ca

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_cache_advice string ON
db_cache_size big integer 25G

3.1.3 可变参数
3.1.4 初始化参数的获取
        show parameter命令或者v$parameter视图。
        通过在SQL*Plus提示符下进行如下设置，我们可以减少错误删除的可能性。
SQL> set sqlprompt "_user'@'_connect_identifier> "
SYS@OCP10G> conn eygle/eygle
已连接。
EYGLE@OCP10G>
在ORACLE_HOME/sqlplus/admin目录内的glogin.sql文件中植入前面给出的命令，就可以为所有的SQL*Plus会话自动设置SQL提示符。
3.2 参数文件
        参数文件是一个包含一系列参数及其对应值的操作系统文件。分为两类：
        1、初始化参数文件PFILE（Initialization Parameter File）。9i之前使用，文本文件，可以手工修改。
        2、服务器参数文件SPFILE（Server Parameter File）。从9i开始使用，二进制格式，不能手工修改。
3.2.1 PFILE和SPFILE
        Oracle强烈推荐使用SPFILE，应用其新特性来存储和维护初始化参数。
        P108，使用DBCA创建数据库时的脚本。
3.2.2 获取参数的视图
        V$SYSTEM_PARAMETER：对于实例（Instance）级别生效的参数设置。
        V$PARAMETER：对于会话（Session）级别生效的参数设置。
3.2.3 SPFILE的创建
        P111
        语法
        案例
3.2.4 参数文件的搜索顺序
        启动过程中Oracle选择参数文件的顺序为：
        spfile<ORACLE_SID>.ora
        spfile.ora
        init<ORACLE_SID>.ora
        如果三个文件都不存在，则Oracle无法启动实例。
3.2.5 使用PFILE/SPFILE启动数据库
        如果想使用PFILE启动数据库,可以在启动时指定PFILE或者将原SPFILE重命名。
        SQL> startup pfile='...\INITocpq0g.ora'
        SQL> startup pfile=$ORACLE_HOME/DBS/INITocpq0g.ora

        不能以同样的方式指定SPFILE，但是可是常见一个包含SPFILE的PFILE。即，在PFILE中链接SPFILE，同时在PFILE中定义其他或者需要修改的参数。如果参数重复设置，后读取的参数将取代先前的设置。
        例如：新建一个参数文件initnew.ora，这个文件只包含两行：
SPFILE=’...\ SPFILEOCP10G.ORA’
db_cache_size=123456789

        然后就可以用这个新的PFILE启动数据库了。（这是修改参数的方法一，请对比方法二在3.2.6）
3.2.6 修改SPFILE文件的参数
        语法:
        ALTER SYSTEM SET <parameter_name>=<value> SCOPE= ... SID= ...

        其中SCOPE选项有三个可选值：MEMORY、SPFILE、BOTH。如果不指定，则相当于BOTH。

        在RAC环境中，不同实例的undo_tablespace设置是不同的，当修改一个实例的undo表空间时，一定要注意制定相应的实力，以免修改错误。

        在关闭数据库状态修改SPFILE：
        1、由SPFILE生成PFILE：create pfile from spfile;
        2、修改新生成的PFILE;
        3、由PFILE生成SPFILE：create spfile from pfile;
        然后就可以启动数据库了：startup
（这是修改参数的方法二，请对比方法一在3.2.5）
3.2.7 解决SPFILE参数修改的错误
        参考前两节。
3.2.8 重置SPFILE中设置的参数
        ALTER SYSTEM RESET parameter_name <SCOPE=...> SID=...;
3.2.9 判断是否使用了SPFILE
        show parameter命令或者v$parameter视图中查找参数spfile。
SQL> show parameter spfile

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile string D:\ORACLE\PRODUCT\10.1.0\DB_1\DATABASE\SPFILEOCP10G.ORA

SQL> select name,value from v$parameter where name='spfile';

NAME VALUE
-----------------------------------------------------------------
spfile D:\ORACLE\PRODUCT\10.1.0\DB_1\DATABASE\SPFILEOCP10G.ORA
3.2.10 SPFILE的备份与恢复
1. 设置控制文件自动备份
        注意：控制文件自动备份功能是关闭的，强烈推荐大家打开该功能！
        RMAN> configure controlfile autobackup on;
        查询该功能是否打开，通过视图V$RMAN_CONFIGRATION：
SQL> select * from v$rman_configuration where name like upper('%control%');

     CONF# NAME VALUE
---------- -----------------------------------------------------------------
         1 CONTROLFILE AUTOBACKUP ON

2. 更改自动备份的位置
P122
3. 检查自动备份
        检查自动备份，通过视图v$backup_spfile：
SQL> select * from v$backup_spfile;
．．．．．．
  RECID STAMP SET_STAMP SET_COUNT MODIFICATION_TIME BYTES COMPLETION_TIME
---------- ---------- ---------- ---------- ----------------- ---------- ---------------
        25 707353738 707353738 52 2009-11-23 17:36: 2 2010-1-3 23:08:
        26 707354793 707354793 53 2009-11-23 17:36: 2 2010-1-3 23:26:

26 rows selected

        列出备份集：
RMAN> list backup of spfile;

备份集列表
===================

BS 关键字类型 LV 大小设备类型经过时间完成时间
------- ---- -- ---------- ----------- ------------ ----------
52 Full 0 DISK 00:00:01 03-1月 -10
        BP 关键字: 52 状态: AVAILABLE 已压缩: NO 标记: TAG20100103T232633
段名:D:\ORACLE\PRODUCT\10.1.0\FLASH_RECOVERY_AREA\OCP10G\AUTOBACKUP\2010_01_03\O
1_MF_S_707354793_5N1FSB98_.BKP
  包含的 SPFILE: 修改时间: 23-11月-09
4. 记录数据库变化
5. 测试

RMAN> restore controlfile to 'd:\temp\control01.ctl' from autobackup;

启动 restore 于 01-4月 -10
使用通道 ORA_DISK_1

恢复区域目标: D:\oracle\product\10.1.0\flash_recovery_area
用于搜索的数据库名 (或锁定名称空间): OCP10G
通道 ORA_DISK_1: 在恢复区域中找到自动备份
通道 ORA_DISK_1: 已找到的自动备份: D:\ORACLE\PRODUCT\10.1.0\FLASH_RECOVERY_AREA\
OCP10G\AUTOBACKUP\2010_01_03\O1_MF_S_707354793_5N1FSB98_.BKP
通道 ORA_DISK_1: 从自动备份复原控制文件已完成
完成 restore 于 01-4月 -10

RMAN> restore spfile to 'd:\temp\spfile01.ora' from autobackup;

启动 restore 于 01-4月 -10
使用通道 ORA_DISK_1

恢复区域目标: D:\oracle\product\10.1.0\flash_recovery_area
用于搜索的数据库名 (或锁定名称空间): OCP10G
通道 ORA_DISK_1: 在恢复区域中找到自动备份
通道 ORA_DISK_1: 已找到的自动备份: D:\ORACLE\PRODUCT\10.1.0\FLASH_RECOVERY_AREA\
OCP10G\AUTOBACKUP\2010_01_03\O1_MF_S_707354793_5N1FSB98_.BKP
通道 ORA_DISK_1: 从自动备份复原 SPFILE 已完成
完成 restore 于 01-4月 -10

P124
数据库无法MOUNT或者NOMOUNT的情况，没有上机实验。

set linesize 120
set pagesize 999
set heading off
set feedback off
spool d:\temp\inittmp.ora
select '*.' ||name||' = '||value from v$parameter where isdefault='FALSE';
spool off

        生成的临时参数文件格式如下：
*.db_block_size = 8192
*.db_cache_size = 25165824
*.compatible = 10.1.0.2.0
*.log_archive_dest_1 = location=d:\oracle\archive1\
*.log_archive_dest_2 = location=d:\oracle\archive2\
... ...
3.2.11 Oracle 11g参数文件恢复
        Oracle 11g引入了新的命令：
        SQL> create <spfile|pfile> from memory;
3.2.12 如何设置Events事件（略）
P128
3.2.13 导出SPFILE参数文件
本节的方法比较罗嗦，比如了前面给出的两种方法好（参考3.2.5以及3.2.6）。

3.3 案例诊断之一：参数文件
3.4 案例诊断之二：RAC环境参数文件

第4章数据字典
4.1 数据字典概述
        数据字典包括以下内容：P138

        总之，数据字典是数据库核心，通过数据字典，Oracle数据库基本可实现自解释。（通过后面的4.4.3小节可以看出来）

        数据字典由4部分组成：内部RDBMS（X$）表、数据字典表、动态性能视图（V$）和数据字典视图。
4.2 内部RDBMS（X$）表（略）
4.3 数据字典表（略）
4.4 静态数据字典视图
4.4.1 静态数据字典视图的分类
        DBA_视图包含ALL_视图；ALL_视图包含USER_视图。
        即：DBA_视图>ALL_视图>USER_视图
        通过3类视图在本质上是为了实现权限控制。
4.4.2 静态数据字典视图的内部实现（略）
4.4.3 常用的数据字典视图举例
1. DICT/DICTIONARY
        DICT/DICTIONARY用以检索数据字典。
SQL> select * from dict where table_name in('DICT','DICTIONARY');

TABLE_NAME COMMENTS
------------------ -------------------------------------------
DICTIONARY Description of data dictionary tables and views
DICT Synonym for DICTIONARY

SQL> select owner,object_name,object_type
  2 from dba_objects where object_name in ('DICT','DICTIONARY');

OWNER OBJECT_NAME OBJECT_TYPE
--------------------- ------------------- ------------------
SYS DICTIONARY VIEW
PUBLIC DICTIONARY SYNONYM
PUBLIC DICT SYNONYM

        DICT'/DICTIONARY对象的内容非常简单，只包含两个字段
SQL> desc dictionary
Name Type Nullable Default Comments
---------- -------------- -------- ------- ----------------------
TABLE_NAME VARCHAR2(30) Y Name of the object
COMMENTS VARCHAR2(4000) Y Text comment on the object

        注意：不要被TABLE_NAME这个描述所迷惑了，这里应该用OBJECT_NAME更合适。

SQL> select * from dict where table_name like 'DBA%COLUMNS';

TABLE_NAME COMMENTS
------------------------ ------------------------------------
DBA_CLU_COLUMNS Mapping of table columns to cluster columns
DBA_IND_COLUMNS COLUMNs comprising INDEXes on all TABLEs and CLUSTERs
DBA_JOIN_IND_COLUMNS Join Index columns comprising the join conditions
DBA_TAB_COLUMNS Columns of user's tables, views and clusters

        通过上面这些表，很容易可以实现一些统计，比如：数据库中字段最多的表和索引等等。
2. DICT_COLUMES
        DICT_COLUMES记录了数据字典的列。
SQL> select * from dict_columns where table_name='DICT';

TABLE_NAME COLUMN_NAME COMMENTS
------------------- -------------- ---------------------
DICT TABLE_NAME Name of the object
DICT COMMENTS Text comment on the object

3. OBJ$/DBA_OBJECTS/OBJ
        OBJ$是一个底层的字典表，记录了数据库中的所有对象的信息；
        DBA_OBJECTS视图基于OBJ$建立。
        OBJ是USER_OBJECTS的同义词
SQL> select owner,object_name,object_type
  2 from dba_objects
  3 where object_name in('OBJ$','DBA_OBJECTS','OBJ');

OWNER OBJECT_NAME OBJECT_TYPE
------------------------------ --------------- -------------------
SYS DBA_OBJECTS VIEW
SYS OBJ$ TABLE
PUBLIC DBA_OBJECTS SYNONYM
PUBLIC OBJ SYNONYM

        类似的字典表还有：
TAB$/DBA_TABLES/TAB；IND$/DBA_INDEXS/IND等等。

SQL> select owner,object_name,object_type
  2 from dba_objects where object_name in ('TAB$','DBA_TABLES','TAB');

OWNER OBJECT_NAME OBJECT_TYPE
----------------------- --------------- -------------------
SYS TAB VIEW
SYS DBA_TABLES VIEW
SYS TAB$ TABLE
PUBLIC TAB SYNONYM
PUBLIC DBA_TABLES SYNONYM
SYSTEM TAB SYNONYM

6 rows selected

4. DBA_SOURCE
        *_SOURCE用以保存存储对象（Stored Object）的源码。
        存储对象包括FUNCTION、PACKAGE、PROCEDURE、TRIGGER、TYPE等等。
SQL> select column_name,comments from dict_columns where table_name='DBA_SOURCE';

COLUMN_NAME COMMENTS
----------------------- ---------------
OWNER
NAME Name of the object
TYPE Type of the object
LINE Line number of this line of source
TEXT Source text

SQL> select distinct(type) from dba_source;

TYPE
------------
FUNCTION
PACKAGE
PACKAGE BODY
PROCEDURE
TRIGGER
TYPE
TYPE BODY

7 rows selected
4.5 动态性能视图（V$）
        动态性能视图（V$）记录了数据库运行时的信息和统计数据。这是我们研究和管理数据库的主要依据。
4.5.1 GV$和V$视图
        在OPS/RAC环境中，GV$视图返回有所有实例的信息；而每个V$视图只返回当前连接实例的信息。

SQL> select inst_id,instance_name,status,version from gv$instance;

   INST_ID INSTANCE_NAME STATUS VERSION
---------- ---------------- ------------ -----------------
         1 ngact1 OPEN 10.2.0.4.0
         2 ngact2 OPEN 10.2.0.4.0

SQL> select instance_name,status,version from v$instance;

INSTANCE_NAME STATUS VERSION
---------------- ------------ -----------------
ngact1 OPEN 10.2.0.4.0
4.5.2 GV_$、V_$视图和GV$、V$同义词（略）
4.5.3 进一步说明（略）
4.5.4 动态性能视图与数据库启动
P157

4.6 最后的验证（略）

第5章内存管理
5.1 PGA管理
        PGA指的是程序全局区（Program Global Area），PGA是服务器进程使用的一块内存区域，PGA是非共享内存。
        PGA在服务器进程启动或创建时分配，并为服务器进程排他访问。
5.1.1 什么是PGA
        进程的创建通常有两种模式：专用服务器模式（Dedicated Server）以及共享服务器模式（Shared Server）。
        通常数据库口应当运行在专用服务器模式下。

        PGA的创建过程

        游标P163

        PGA分为：
 固定PGA
 可变PGA。

        可变PGA由两部分组成：
 会话内存
 私有SQL区

        私有SQL区由两部分组成：
 永久区域
 运行时区域
5.1.2 UGA与CGA
5.1.3 PGA管理技术变迁
        从9i开始，Oracle提供了一种新的PGA管理方法：自动化SQL执行内存管理，也称为自动PGA管理。
5.1.4 参数的设置与内存分配
        SQL在工作区以3中方式执行：
workarea executions - optimal
workarea executions - onepass
workarea executions - multipass
P168

        PGA性能指标（生产系统）：
SQL> select name, value,
  2 100*round((value/(select sum(value) from v$sysstat where name like 'workarea executions%')),4) PCT
  3 from v$sysstat where name like 'workarea executions%' ;

NAME VALUE PCT
------------------------------- ---------- ----------
workarea executions - optimal 18340525 99.95
workarea executions - onepass 7919 0.04
workarea executions - multipass 906 0
5.1.5 自动PGA管理实现原理（略）
5.1.6 PGA的调整建议
SQL> select name, round(value/1024/1024,2) PGA_MB from v$parameter where name like '%pga%';

NAME PGA_MB
-------------------------------------------------------- ----------
pga_aggregate_target 119.37
        视图v$pga_target_advice的字段意义需上网查。
SQL> select round(p.PGA_TARGET_FOR_ESTIMATE/1024/1024,2) PGA_MB, p.PGA_TARGET_FACTOR, p.ESTD_PGA_CACHE_HIT_PERCENTAGE,p.ESTD_OVERALLOC_COUNT
  2 from v$pga_target_advice p order by PGA_MB;

    PGA_MB PGA_TARGET_FACTOR ESTD_PGA_CACHE_HIT_PERCENTAGE ESTD_OVERALLOC_COUNT
---------- ----------------- ----------------------------- --------------------
     14.92 0.125 27 11321
     29.84 0.25 27 5194
     59.68 0.5 28 703
     89.53 0.75 29 50
    119.37 1 45 0
    143.24 1.2 45 0
    167.11 1.4 46 0
    190.99 1.6 46 0
    214.86 1.8 46 0
    238.73 2 48 0
     358.1 3 51 0
    477.47 4 53 0
     716.2 6 61 0
    954.94 8 61 0

14 rows selected
        OEM界面上可以直观的看到这些建议信息。
5.1.7 PGA的转储（略）
5.2 SGA管理
        SGA指的是系统全局区（System Global Area），是一块共享内存；在数据库启动时分配，当实例关闭时释放。
        当实例启动到NOMOUNT状态时，SGA已分配，同时启动后台进程。
SYSTEM @ OCP10G> show sga

Total System Global Area 121634816 bytes
Fixed Size 787748 bytes
Variable Size 95419100 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes

SYSTEM @ OCP10G> select * from v$sga;

NAME VALUE
-------------------- ----------
Fixed Size 787748
Variable Size 95419100
Database Buffers 25165824
Redo Buffers 262144

5.2.1 SGA的组成
1. 固定区域
        这部分内存分配和特定的数据库版本以及平台有关，不受用户控制，而这些信息对数据库来说非常重要，但是——用户通常不需要关心。

2. Buffer Cache
        Buffer Cache（缓冲区高速缓存）用于存储近期使用的数据块，这些数据块有可能是被修改过的，也可能是未经修改过的。
        Oracle管理Buffer Cache使用的是LRU算法。
        除此之外，Oracle还使用了多缓冲池技术。将Buffer Cache分为Default、Keep、和Recycle池3个部分。
        在默认情况下，所有表都使用Default池，它的大小就是数据缓冲区（Buffer Cache）的大小，由初始化参数db_cache_size决定。

SQL> show parameter db_cache

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_cache_advice string ON
db_cache_size big integer 25G

SQL> select id, name, block_size, current_size, target_size from v$buffer_pool;

        ID NAME BLOCK_SIZE CURRENT_SIZE TARGET_SIZE
---------- ---------------- ---------- ------------ -----------
         1 KEEP 8192 2048 2048
         3 DEFAULT 8192 25600 25600

3. Shared Pool
        Shared Pool，共享池，大小由参数shared_pool_size决定。
SQL> show parameter shared_pool

NAME TYPE VALUE
----------------------------- ---------- -----------
shared_pool_reserved_size big integer 161061273
shared_pool_size big integer 3G

4. Redo Log Buffer
        Redo Log Buffer，日志缓冲区存储重做日志条目（redo entries）
5. 其他内存组件(有疑问)
        Large Pool（大池）、Java Pool（Java池）、Streams Pool（10g中引入）。
SQL> select * from v$sga;

NAME VALUE
-------------------- ----------
Fixed Size 2147144
Variable Size 5,335,157,944
Database Buffers 2,899,102,924
Redo Buffers 31,404,032

SQL> select * from v$sgainfo;

NAME BYTES RESIZEABLE
-------------------------------- ---------- ----------
Fixed SGA Size 2147144 No
Redo Buffers 31404032 No
Buffer Cache Size 2899102924 Yes
Shared Pool Size 3221225472 Yes
Large Pool Size 536870912 Yes
Java Pool Size 536870912 Yes
Streams Pool Size 0 Yes
Granule Size 16777216 No
Maximum SGA Size 3435973836 No
Startup overhead in Shared Pool 1308622848 No
Free SGA Memory Available 1040187392

11 rows selected

SQL> show parameter db_cache_size

NAME TYPE VALUE
------------------------------------ -----------
db_cache_size big integer 25G

SQL> select value from v$parameter where name ='db_cache_size';

VALUE
--------------------------------------------------------------------------------
26843545600
        25G=25×1024×1024×1024 KB= 26,843,545,600 KB 2,899,102,924（生产系统不一致）

$$$$$$$$$$$$$$$$$$$$$$$

SQL> select * from v$sga;

NAME VALUE
-------------------- ----------
Fixed Size 752592
Variable Size 989855744
Database Buffers 6,006,243,328
Redo Buffers 52703232
SQL> select value from v$parameter where name ='db_cache_size';

VALUE
--------------------------------------------------------------------------------
6,006,243,328

SQL> show parameter db_cache_size

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_cache_size big integer 6,006,243,328

（旧生产系统一致）

$$$$$$$$$$$$$$$$$$$$$$$

SQL> select * from v$sga;

  NAME VALUE
  -------------------- ----------
  Fixed Size 787748
  Variable Size 95,419,100
  Database Buffers 25165824
  Redo Buffers 262144

        在9i中，Variable Size包括shared_pool_size、java_pool_size和large_pool_size部分，sga_max_size去除db_cache_size部分也被归入可变部分。
SQL> select
    2 (select value from v$parameter where name ='shared_pool_size')+
    3 (select value from v$parameter where name ='java_pool_size')+
    4 (select value from v$parameter where name ='large_pool_size') Vsize
    5 from dual;

       VSIZE
  ----------
    92,274,688

        Database Buffers指的是Buffer Cache的设置

  SQL> show parameter db_cache_size

  NAME TYPE VALUE
  ------------------------------------ ----------- ------------------------------
  db_cache_size big integer 24M


        24M = 24×1024×1024KB = 25165824KB。（实验环境一致）

        Redo Buffers指的是缓冲日志区分配的内存大小，这个数值通常比比参数log_buffers略大。
SQL> show parameter log_buffer

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_buffer integer 262144

SQL> select * from v$sgainfo;

NAME BYTES RESIZEABLE
-------------------------------- ---------- ----------
Fixed SGA Size 787748 No
Redo Buffers 262144 No
Buffer Cache Size 25165824 Yes
Shared Pool Size 83886080 Yes
Large Pool Size 8388608 Yes
Java Pool Size 0 Yes
Streams Pool Size 0 Yes
Granule Size 4194304 No
Maximum SGA Size 121634816 No
Startup overhead in Shared Pool 25165824 No
Free SGA Memory Available 0

11 rows selected

SQL> select value from v$parameter where name ='shared_pool_size';

VALUE
--------------------------------------------------------------------------------
83886080

SQL> select sum(bytes) from v$sgastat where pool='shared pool';

SUM(BYTES)
----------
  83886080

5.2.2 SGA与共享内存（略）
5.2.3 SGA管理的变迁
1. 8i中的静态SGA管理（略）
2. 9i中的静态SGA管理
        sga_max_size参数。P191

SQL> show parameter db_cache_ad

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_cache_advice string ON

select * from v$db_cache_advice;
--当size_factor=1时，size_for_estimate=24

select value from v$parameter where name = 'db_cache_size'; --25165824(24M)

select * from v$shared_pool_advice;
--当shared_pool_size_factor=1时，shared_pool_size_for_estimate=80
select value from v$parameter where name = 'shared_pool_size'; --83886080(80M)

        也即：
SQL> select d.SIZE_FOR_ESTIMATE sfe, d.SIZE_FACTOR sf,
  2 d.ESTD_PHYSICAL_READ_FACTOR eprf, d.ESTD_PHYSICAL_READS epr
  3 from v$db_cache_advice d;

       SFE SF EPRF EPR
---------- ---------- ---------- ----------
         4 0.1667 4.915 363274
         8 0.3333 3.7738 278929
        12 0.5 1.6716 123550
        16 0.6667 1.5419 113966
        20 0.8333 1.3074 96629
        24 1 1 73911
        28 1.1667 0.5855 43277
        32 1.3333 0.5568 41151
        36 1.5 0.5486 40546
        40 1.6667 0.5415 40022
        44 1.8333 0.5366 39662
        48 2 0.5222 38599

12 rows selected
SQL> select value from v$parameter where name = 'db_cache_size';

VALUE
--------------------------------------------------------------------------------
25165824
SQL> select s.SHARED_POOL_SIZE_FOR_ESTIMATE spsfe, s.SHARED_POOL_SIZE_FACTOR spsf,
  2 s.ESTD_LC_TIME_SAVED_FACTOR eltsf, s.ESTD_LC_MEMORY_OBJECT_HITS elmoh
  3 from v$shared_pool_advice s;

     SPSFE SPSF ELTSF ELMOH
---------- ---------- ---------- ----------
        32 0.4 0.995 80767
        40 0.5 0.9983 81062
        48 0.6 1 81313
        56 0.7 1 81402
        64 0.8 1 81455
        72 0.9 1 81468
        80 1 1 81468
        88 1.1 1 81468
        96 1.2 1 81468
       104 1.3 1 81468
       112 1.4 1 81468
       120 1.5 1 81468
       128 1.6 1 81468
       136 1.7 1 81468
       144 1.8 1 81468
       152 1.9 1 81468
       160 2 1 81468

17 rows selected
SQL> select value from v$parameter where name = 'shared_pool_size';

VALUE
--------------------------------------------------------------------------------
83886080

        用户的选择在于在db_cache_size的设置和physical_size之间寻找一个边际效益最高点，使用可以接受的内存设置获得尽量低的物理读。

        也即：（只显示一行结果不能体现该视图的意义，用户的选择在于在db_cache_size的设置和physical_size之间寻找一个边际效益最高点，使用可以接受的内存设置获得尽量低的物理读。）
SQL> select size_for_estimate, size_factor from v$db_cache_advice where size_factor=1;

SIZE_FOR_ESTIMATE SIZE_FACTOR
----------------- -----------
               24 1
SQL> select value from v$parameter where name ='db_cache_size';

VALUE
--------------------------------------------------------------------------------
25165824
SQL> select shared_pool_size_for_estimate, shared_pool_size_factor from v$shared_pool_advice where shared_pool_size_factor=1;

SHARED_POOL_SIZE_FOR_ESTIMATE SHARED_POOL_SIZE_FACTOR
----------------------------- -----------------------
                           80 1
SQL> select value from v$parameter where name ='shared_pool_size';

VALUE
--------------------------------------------------------------------------------
83886080

        注意：虽然在9i中Oracle提供了动态内存修改功能，但是仍然建议在系统规划时做好设置，尽量避免运行时的动态调整。
3. 10g中的自动共享内存调整
        10g中进入了一个新的初始化参数sga_target，P197：
SQL> show parameter sga_target

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
sga_target big integer 0


        生产系统没有使用“自动共享内存调整”这一特性。
        使用“自动共享内存调整”这一特性前提，statistics_level为TYPICAL或ALL：
SQL> show parameter statistics_level

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
statistics_level string TYPICAL

4. 11g中的自动内存管理
        10g中进入了一个新的初始化参数memory_target，P200：

图5-15，P201 （这个图很重要，但是不理解，需上网查）

5.3 Oracle的内存分配和使用
5.3.1 案例诊断一：SGA和SWAP
5.3.2 案例诊断二：SGA设置过高导致的系统故障
5.3.3 案例诊断三：如何诊断和解决CPU高度消耗问题

第6章 Buffer Cache与Share Pool原理（略）
6.1 Buffer Cache原理
        当一个进程需要访问数据时，P215
6.1.1 LRU与Dirty List
第7章重做（Rodo）
7.1 Rodo的作用
        Oracle通过Redo来保证数据库的事务可以被重演，从而使得在故障之后，数据可以被恢复。
        Redo的功能主要通过个组件来实现：Redo log buffer、LGWR后台进程和Redo log file（在归档模式下，Redo log file最终由ARCn进程写出为归档日志文件）。
        图7-2说明了Redo log buffer、LGWR后台进程和Redo log file三者之间的关系。P300

7.2 Redo的原理
        盖国强在本节讲解得非常有条理，来龙去脉非常清晰。P301
7.3 Redo与Latch（略）
7.4 Oracle 9i Redo的增强（略）
7.5 Oracle 10g Redo的增强（略）
7.6 Redo的内容（trace文件还是看不懂）
7.7 产生多少Redo
        本节内容很重要，实践中会用到。
P310
7.8 Redo写的触发条件
7.8.1 每3秒超市（Timeout）
7.8.2 阈值达到
7.8.3 用户提交
        后面在7.10小节有详细的介绍。
7.8.4 在DBWn写之前（不懂）

7.9 Redo Log Buffer的大小设置
        从10g开始，LOG_BUFFER的分配算法有所改变。P316
        如果不是有明显的性能问题，一般缺省的设置是足够的。
7.10 commit做了什么
P317
7.11 日志的状态
SQL> select group#, status, first_change# from v$log;

    GROUP# STATUS FIRST_CHANGE#
---------- ---------------- -------------
         1 CURRENT 15700987
         2 INACTIVE 15683193
         3 INACTIVE 15692072
        常见的日志状态有4种：
1、CURRENT
2、ACTIVE：该状态意味着，。。。严重的等待事件“checkpoint incomplete”P318
3、INACTIVE：如果数据库处于归档模式，在未完成。。。P320
4、UNUSED
7.12 日志的块大小（略）
7.13 日志文件的大小（本节没有讲具体的优化原则、方法）
P324第2段
7.14 如何调整日志文件大小
具体命令P324
alter database add logfile group 4 ‘/.../redo04.dbf’ size 1024m;

alter database drop logfile group 1;
7.15 热备份期间的Redo（略）
7.16 能否不生成Redo（暂时略，需结合后面章节一起看）
        需要使用NOLOGGING选项的操作有：
        P329
7.17 Redo故障的恢复
7.17.1 丢失非活动日志组的故障恢复
        因为实验环境使用的是Windows系统，无法在不关闭Oracle数据库的情况下删除redo日志，所以本节所举的例子不是恰当的（其实相当于下一小节：在损失当前日志时，如果数据库是正常关闭的）。

        第一种情况：
        如果丢失非活动日志组中的一个成员，那么数据库不会奔溃，只会在告警日志中写入如下信息：
Fri Apr 30 16:04:50 2010
Errors in file d:\oracle\product\10.1.0\admin\ocp10g\bdump\ocp10g_lgwr_2788.trc:
ORA-00313: open failed for members of log group 3 of thread 1
ORA-00312: online log 3 thread 1: 'D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO03.LOG'
ORA-27041: unable to open file
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。

Fri Apr 30 16:04:50 2010
Errors in file d:\oracle\product\10.1.0\admin\ocp10g\bdump\ocp10g_lgwr_2788.trc:
ORA-00321: log 3 of thread 1, cannot update log file header
ORA-00312: online log 3 thread 1: 'D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO03.LOG'

Private_strands 7 at log switch
Fri Apr 30 16:04:50 2010
Errors in file d:\oracle\product\10.1.0\admin\ocp10g\bdump\ocp10g_lgwr_2788.trc:
ORA-00313: open failed for members of log group 3 of thread 1

Thread 1 advanced to log sequence 1074
  Current log# 3 seq# 1074 mem# 1: D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO03B.LOG

        第二种情况：
        1、如果丢失非活动日志组中的所有成员，当时用到该组时，数据库会奔溃。
        通过删除REDO03.LOG以及REDO03B.LOG模拟故障
        2、此时，启动数据库，数据库会提示日志丢失：
SYS AS SYSDBA@ OCP10G> startup
ORACLE 例程已经启动。

Total System Global Area 121634816 bytes
Fixed Size 787748 bytes
Variable Size 95419100 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
数据库装载完毕。
ORA-00313: 无法打开日志组 3 (用于线程 1) 的成员
ORA-00312: 联机日志 3 线程 1:
'D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO03.LOG'
ORA-00312: 联机日志 3 线程 1:
'D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO03B.LOG'

        3、此时，数据库将处于MOUNT状态，可以查看日志组及各日志的情况：

SYS AS SYSDBA@ OCP10G> select instance_name, status from v$instance;

INSTANCE_NAME STATUS
---------------- ------------
ocp10g MOUNTED

SQL> select * from v$log;

    GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARCHIVED STATUS
---------- ---------- ---------- ---------- ---------- -------- ---------
         1 1 1075 10485760 2 NO INACTIVE
         2 1 1076 10485760 2 NO CURRENT
         3 1 0 10485760 2 NO UNUSED

SQL> select * from v$logfile;

    GROUP# STATUS TYPE MEMBER
---------- ------- ------- ------------------------------------------------------
         1 ONLINE D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO01.LOG
         2 ONLINE D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO02.LOG
         3 INVALID ONLINE D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO03.LOG
         1 ONLINE D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO01B.LOG
         2 ONLINE D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO02B.LOG
         3 ONLINE D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO03B.LOG

6 rows selected

        4、清除该日志组后即可启动数据库。

SYS AS SYSDBA@ OCP10G> alter database clear logfile group 3;

数据库已更改。

SQL> select * from v$logfile;

    GROUP# STATUS TYPE MEMBER
---------- ------- ------- -------------------------------------------------------
         1 ONLINE D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO01.LOG
         2 ONLINE D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO02.LOG
         3 ONLINE D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO03.LOG
         1 ONLINE D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO01B.LOG
         2 ONLINE D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO02B.LOG
         3 ONLINE D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO03B.LOG

6 rows selected

SYS AS SYSDBA@ OCP10G> alter database open;

数据库已更改。

        如果数据库处于归档模式，并且该日志组未完成归档，则需要用如下命令强制清除，详见。。。小节
需结合后面的章节一起看

7.17.2 丢失活动或当前日志文件的恢复
1. 在损失当前日志时，如果数据库是正常关闭的
        参考1.3小节（数据库的关闭）
        由于正常关闭数据库前，Oracle会执行全面检查点，当前日志在实例恢复中不再需要。
需结合后面的章节一起看
        在9i中，可能无法对当前日志进行clear，需要通过Until Cancel恢复后，以Resetlogs方式打开，例子如下：

SQL> startup
ORACLE 例程已经启动。

Total System Global Area 121634816 bytes
Fixed Size 787748 bytes
Variable Size 95419100 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
数据库装载完毕。
ORA-00313: 无法打开日志组 1 (用于线程 1) 的成员
ORA-00312: 联机日志 1 线程 1:
'D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO01B.LOG'
ORA-00312: 联机日志 1 线程 1:
'D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO01.LOG'

SQL> select * from v$log;

    GROUP# THREAD# SEQUENCE# ARCHIVED STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- -------- ---------------- ------------- -----------
         1 1 5 NO INACTIVE 15825696 2010-4-30 1
         2 1 6 NO INACTIVE 15825698 2010-4-30 1
         3 1 7 NO CURRENT 15825700 2010-4-30 1

SQL> alter database clear logfile group 1;

Database altered

SQL> select * from v$log;

    GROUP# THREAD# SEQUENCE# ARCHIVED STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- -------- ---------------- ------------- -----------
         1 1 0 NO UNUSED 15825696 2010-4-30 1
         2 1 6 NO INACTIVE 15825698 2010-4-30 1
         3 1 7 NO CURRENT 15825700 2010-4-30 1

SQL> alter database clear logfile group 2;

Database altered

SQL> select * from v$log;

    GROUP# THREAD# SEQUENCE# ARCHIVED STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- -------- ---------------- ------------- -----------
         1 1 0 NO UNUSED 15825696 2010-4-30 1
         2 1 0 NO UNUSED 15825698 2010-4-30 1
         3 1 7 NO CURRENT 15825700 2010-4-30 1

SQL> alter database clear logfile group 3;

alter database clear logfile group 3

ORA-00313: 无法打开日志组 3 (用于线程 1) 的成员
ORA-00312: 联机日志 3 线程 1: 'D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO03B.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
ORA-00312: 联机日志 3 线程 1: 'D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\REDO03.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。

SQL> select * from v$log;

    GROUP# THREAD# SEQUENCE# ARCHIVED STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- -------- ---------------- ------------- -----------
         1 1 0 NO UNUSED 0 2010-4-30 1
         2 1 0 NO UNUSED 15825698 2010-4-30 1
         3 1 0 NO CLEARING_CURRENT 15825700 2010-4-30 1

SQL> recover database until cancel;
Medie recover compelete. （完成介质恢复。）

SQL> alter database open resetlogs;

Database altered

SQL> select * from v$log;

    GROUP# THREAD# SEQUENCE# ARCHIVED STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- -------- ---------------- ------------- -----------
         1 1 0 YES UNUSED 0
         2 1 0 YES UNUSED 0
         3 1 1 NO CURRENT 15826091 2010-4-30 1

SQL> alter system switch logfile;

System altered

SQL> select * from v$log;

    GROUP# THREAD# SEQUENCE# ARCHIVED STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- -------- ---------------- ------------- -----------
         1 1 2 NO CURRENT 15826543 2010-4-30 1
         2 1 0 YES UNUSED 0
         3 1 1 NO ACTIVE 15826091 2010-4-30 1

SQL> alter system switch logfile;

System altered

SQL> select * from v$log;

    GROUP# THREAD# SEQUENCE# ARCHIVED STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- -------- ---------------- ------------- -----------
         1 1 2 NO INACTIVE 15826543 2010-4-30 1
         2 1 3 NO CURRENT 15826551 2010-4-30 1
         3 1 1 NO INACTIVE 15826091 2010-4-30 1

SQL>

2. 在损失当前日志时，如果数据库是异常关闭的
需结合后面的章节一起看

        本节作者介绍的处理方法不详细，只是说与上面的介绍的方法类似，不再赘述P337

7.18 案例一：通过Clear日志恢复数据库


7.19 案例二：日志组过度激活的诊断
7.20 数值在Oracle内部存储

有关键情节透露