1、得到数据库名和创建日期

SELECT name, created, log_mode, open_mode FROM v$database;

2、ORACLE数据库的计算机的主机名，ORACLE数据库的实例名及ORACLE数据库管理系统的版本信息

SELECT host_name, instance_name, version FROM v$instance;

3、为了知道oracle数据库版本的一些特殊信息

select * from v$version;

4、获取控制文件名字

select * from v$controlfile;

5、得到Oracle数据库的重做日志配置信息

SELECT group#, members, bytes, status, archived FROM v$log;

select GROUP#,MEMBER from v$logfile;

6、获取oracle的每个重做日志（成员）文件所存放的具体位置

select * from v$logfile;

7、知道ORACLE数据库的备份和恢复策略和归档文件的具体位置

archive log list

8、知道ORACLE数据库中到底有多少表空间以及每个表空间的状态

select tablespace_name, block_size, status, contents, logging from dba_tablespaces;

select tablespace_name, status from dba_tablespaces;

9、知道每个表空间存在哪个磁盘上以及文件的名字等信息

SELECT file_id, file_name, tablespace_name, status, bytes from dba_data_files;

select file_name, tablespace_name from dba_data_files;

10、知道Oracle数据库系统上到底有多少用户和都是什么时候创建的

select username,created from dba_users;

select username, DEFAULT_TABLESPACE from dba_users;

11、从控制文件中取出信息涉及到以下一些相关的命令

select * from v$archived

select * from v$archived_log

select * from v$backup

select * from v$database

select * from v$datafile

select * from v$log

select * from v$logfile

select * from v$loghist

select * from v$tablespace

select * from v$tempfile

12、控制文件由两大部份组成：可重用的部份和不可重用的部分。可重用的部分的大小可用CONTROL_FILE_RECORD_KEEP_TIME参数来控制，该参数的默认值为7天，即可重用的部份的内容保留7天，一周之后这部份的内容可能被覆盖。可重用的部份是供恢复管理器来使用的，这部份的内容可以自动扩展。Oracle数据库管理员可以使用CREAT DATABASE或CREAT CONTROLFILE语句中的下列关键字（参数）来间接影响不可重用的部份的大小：

MAXDATAFILES

MAXINSTANCES

MAXLOGFILES

MAXLOGHISTORY

MAXLOGMEMBERS

13、查看控制文件的配置

SELECT type, record_size, records_total, records_used  FROM v$controlfile_record_section;

14、如果您的显示被分成了两部分，您需要使用类似于set pagesize 100的SQL*Plus命令先格式化输出。有关的格式化输出命令有以下这些：

record_size：  为每个记录的字节数。

records_total：为该段所分配的记录个数。

records_used：为该段所使用的记录个数。

15、知道控制文件中的所有数据文件(DATAFILE)，表空间(TABLESPACE)，和重做日志(REDO LOG)所使用的记录情况

SELECT type, record_size, records_total, records_used

FROM  v$controlfile_record_section

WHERE type IN ( ‘DATAFILE’, ‘TABLESPACE’, ‘REDO LOG’);

16、获取控制文件名字

select value from v$parameter where name =’control_files’;

或者：select * from v$controlfile

17、如何在一个已经安装的Oracle数据库中添加或移动控制文件呢?

以下是在一个已经安装的Oracle数据库中添加或移动控制文件的具体步骤：

a、利用数据字典v$controlfile来获取现有控制文件名字。

b、正常关闭Oracle数据库。

c、将新的控制文件名添加到参数文件的CONTROL_FILES参数中。

d、使用操作系统的复制命令将现有控制文件复制到指定位置。

e、重新启动Oracle数据库。

f、利用数据字典v$controlfile来验证新的控制文件名字是否正确。

g、如果有误重做上述操作，如果无误删除无用的旧控制文件。

注： 如果您使用了服务器初始化参数文件(SPFILE),您不能关闭Oracle数据库而且应该在第3步使用alter system set control_files的Oracle命令来改变控制文件的位置。

SQL> alter system set control_files =

‘D:\Disk3\CONTROL01.CTL’,

‘D:\Disk6\CONTROL02.CTL’,

‘D:\Disk9\CONTROL03.CTL’ SCOPE=SPFILE;

18、由于控制文件是一个极其种要的文件，除了以上所说的将控制文件的多个副本存在不同的硬盘上的保护措施外，在数据库的结构变化之后，您应立即对控制文件进行备份。可以用Oracle命令来对控制文件进行备份：

alter database backup controlfile to ‘D:\backup\control.bak’;

19、您也可将备份到一个追踪文件中。该追踪文件包含有重建控制文件所需的SQL语句。可使用以下SQL语句来产生这一追踪文件：

alter database backup controlfile to trace;

20、正常关闭oracle命令

shutdown immeditae

在Oracle中，从9i开始引入了spfile，也就是服务 器端初始化参数，有很多是可以支持在线修改的，也就是修改会马上生效，详细内容看下面的说明：

The ISSYS_MODIFIABLE column in V$PARAMETER tells us whether the parameters are static or dynamic. Static parameters require the instance to be restarted while dynamic parameters can take effect（生效） immediately upon（在…之后） being changed.

SQL> select distinct issys_modifiable from v$parameter;

ISSYS_MODIFIABLE

—————————

DEFERRED

FALSE

IMMEDIATE

If the ISSYS_MODIFIABLE value is set to FALSE for a parameter, it means that the parameter cannot change its value in the lifetime（一生） of the instance; the database needs to be restarted for changes to take effect（生效）.

A parameter set to IMMEDATE value means that it is dynamic（动态的） and can be set to change the present（当前） active instance as well as future database restarts.

A parameter set to DEFERRED is also dynamic, but changes only affect（生效） subsequent（后来的） sessions, currently active sessions will not be affected and retain（保持） the old parameter value.

1 数据库的物理结构和逻辑结构之间的关系由后台进程来维护和实现，后台进程由数据库来管理

2 只有当出现问题，才创建跟踪文件。后台进程追踪文件的命令约定和位置随操作系统和数据库版本而定

3 一般而言，追踪文件含有后台进程名和后台进程的操作系统进程ID。通过设定BACKGROUND_DUMP_DEST来指定后台进程追踪文件位置

4 排除数据库故障时，追踪文件是最重要的

5 影响后台进程的严重问题通常记录在数据库的警告日志中，警告日志通常位于BACKGROUND_DUMP_DEST目录下，路径为Oracle_BASE目录下的/admin/INSTANCE_NAME/bdump目录

6 可以查看视图V$BGPROCESS查看数据库中可用后台进程的完整清单

7 SMON （系统监控程序）进程执行所需的实例恢复操作（使用联机重做日志文件），它也可以清除数据库，消除系统不再需要的事务对象，还可以将连续的自由空间合成一个大的自由空间，SMON只合并表空间中的空闲空间，这些表空间的默认pctincrease存储值为0

8 PMON （进程监控程序）后台进程清除失败的用户进程，释放用户当时正在使用的资源，同SMON一样，PMON周期性地唤醒检测它是否需要被使用。

9：DBWR（数据库写入程序）后台进程负责管理数据块缓冲区及字典缓存区的内容，它以批量写入的方式将修改块从SGA写到数据文件中. 当缓冲区中的一缓冲区被修改，它被标志为“弄脏”，DBWR的主区的缓冲区填入数据库或被用户进程弄脏，未用的缓冲区的数目减少。当未用的缓冲区下降到很少，以致用户进程要从磁盘读入块到内存存储区时无法找到未用的缓冲区时, DBWR将管理缓冲存储区，使用户进程总可得到未用的缓冲区。 ORACLE采用LRU（LEAST RECENTLY USED）算法（最近最少使用算法）保持内存中的数据块是最近使用的，使I/O最小。

在下列情况预示DBWR 要将弄脏的缓冲区写入磁盘：

n         当一个服务器进程将一缓冲区移入“弄脏”表，该弄脏表达到临界长度时，该服务进程将通知DBWR进行写。该临界长度是为参数DB-BLOCK-WRITE-BATCH的值的一半。

n         当一个服务器进程在LRU表中查找DB-BLOCK-MAX-SCAN-CNT缓冲区时，没有查到未用的缓冲区，它停止查找并通知DBWR进行写。

n         出现超时（每次3秒），DBWR 将通知本身。

n         当出现检查点时，LGWR将通知DBWR .

在前两种情况下，DBWR将弄脏表中的块写入磁盘，每次可写的块数由初始化参数DB-BLOCK-WRITE-BATCH所指定。如果弄脏表中没有该参数指定块数的缓冲区，DBWR从LUR表中查找另外一个弄脏缓冲区。 如果DBWR在三秒内未活动，则出现超时。在这种情况下DBWR对LRU表查找指定数目的缓冲区，将所找到任何弄脏缓冲区写入磁盘。每当出现超时，DBWR查找一个新的缓冲区组。每次由DBWR查找的缓冲区的数目是为寝化参数DB-BLOCK-WRITE-BATCH的值的二倍。如果数据库空运转，DBWR最终将全部缓冲区存储区写入磁盘。

在出现检查点时，LGWR指定一修改缓冲区表必须写入到磁盘。DBWR将指定的缓冲区写入磁盘。

10 每个数据库只有一个SMON和一个PMON进程在运行，但可有多个DBWR进程，多个DBWR有助于在进行大的操作期间减少DBWR冲突。

11 DBWR的数量由参数DB_WRITER_PROCESSES 决定，命名方式为：DBW1、DBW2、DBW3…

12 LGWR(日志写程序)后台进程负责把联机重做日志缓冲区的内容写入联机重做日志文件,LGWR分批将日志条目写入联机重做日志文件,重做日志缓冲区条目总是包含着数据库的最新状态,这是因为将数据块缓冲区中的修改数据块写入到数据文件中之前,DBWR进程将一直处于等待状态

12 LGWR是数据库正常操作时唯一向联机重做日志文件写入内容并从重做日志缓冲区直接读取内容的进程.与DBWR对数据文件执行的完全随机访问相反,联机重做日志文件按顺序方式写入,如果联机重做日志文件被镜像,LGWR同时向镜像日志文件中写入内容.

以下几个条件触发LGWR执行写操作：

（1）超时(timeout)

当LGWR处于空闲状态时，它依赖于rdbms ipc message等待，处于休眠状态，直到3秒超时时间到。如果LGWR发现有redo需要写出，那么LGWR将执行写出操作，log file parallel write等待事件将会出现。

（2）缺省的_log_io_size等于1/3 log buffer大小，上限值为1M，此参数在X$KSPPSV中显示的0值，意为缺省值。也就是，LGWR将在Min(1M,1/3 log buffer size)时触发。注意此处的log buffer size是以log block来衡量的。此值通常为512 bytes.

（3）提交(commit)

当一个事物提交时，在redo stream中将记录一个提交标志。

在这些redo被写到磁盘上之前，这个事物是不可恢复的。所以，在事务返回成功标志给用户前，必须等待LGWR写完成。进程通知LGWR写，并且以log file sync事件开始休眠，超时时间为1秒。

Oracle的隐含参数_wait_for_sync参数可以设置为false避免redo file sync的等待，但是就将无法保证事务的恢复性。

注意,在递归调用(recursive calls)中的提交(比如过程中的提交)不需要同步redo直到需要返回响应给用户。因此递归调用仅需要同步返回给用户调用之前的最后一次Commit操作的RBA。存在一个SGA变量用以记录redo线程需要同步的log block number。

如果多个提交在唤醒LGWR之前发生，此变量记录最高的log block number，在此之前的所有redo都将被写入磁盘。这有时候被称为组提交(group commit).

（4）在DBWR写之前

如果DBWR将要写出的数据的高RBA超过LGWR的on-Disk RBA，DBWR将post LGWR去执行写出。在Oracle8i之前，此时DBWR将等待log file sync事件。从Oracle8i开始，DBWR把这些Block放入一个defer队列，同时通知LGWR执行redo写出，DBWR可以继续执行无需等待的数据写出。

13 CKPT(检查点进程)用来减少执行实例恢复所需的时间,检查点使DBWR将自上一个检查点之后的全部已修改的数据块写入数据文件,并更新数据文件头和控制文件以记录该检查点.当一个联机重做日志文件被填满时,检查点进程会自动出现,可以使用实例的初始化参数文件中的 LOG_CHECKPOINT_INTERVAL 参数设置让一个更频繁的检查点出现

14 ARCH 后台进程以循环方式写入联机重做日志文件,一旦最后一个重做日志文件被填满时,LGWR 就开始重写第一个重做日志文件的内容。当Oracle以ARCHIVELOG（归档方式）模式运行时，数据库在开始重写重做日志文件之前先对其进行备份。归档可以写入到一个磁盘、备份数据库和网络磁盘中

15 RECO（恢复进程）用于解决分布式数据库中的故障问题，只有在平台支持Distributed

Option（分布式选项）且初始化参数文件中的DISTRIBUTED_TRANSACTIONS参数值大于零时才创建这个进程。

16 CJQn Oracle的作业队列管理依赖于后台进程的执行，它们进行数据刷新及其他定期的作业。调度进程CJQ0，选择将要执行的作业并扩展作业队列进程（J000-J999）以执行这些作业，其最大数量由初始化参数JOB_QUEUE_PROCESSES 决定

17 LMSn 当使用Oracle真正的应用集群(Oracle Real Application Clusters)选项时，多个LMS后台进程（命令为LCK0-LCK9）用于解决内部实例的锁定问题

18 Dnnn （调度程序进程）是共享服务器结构的一部分，有助于减少处理多个连接所需要的资源。对于数据库服务器支持的每一种协议必须至少创建一个调度程序进程，调度程序进程在数据库启动时，基于初始化参数DISPATCHERS创建，也可以在数据库打开时创建或取消。

19 Server:Snnn 创建服务器进程来管理需要专用服务器的数据库连接。服务器进程可以数据文件进行I/O操作。它的最大数量由初始化参数SHARED_SERVERS确定

20 Pnnn(并行查询服务器进程) 当数据库内部启用并行查询选项，一个查询的资源要求可以分布在多个处理器中。当实例启动时，就启动指定数量的并行查询服务器进程，其数量由参数：PARALLEL_MIN_SERVERS参数决定。这样的进程出现在操作系统级，其命名为P000、P0001等。其最大数量由PARALLEL_MAX_SERVERS 决定。

需要牢牢记住的几个进程触发条件

查询( Query )处理步骤
查询不同于其它类型的SQL 语句，因为如果查询成功它们会返回作为结果的数据，查询可以返回一行或者上千行，而其它语句只是返回成功或失败，查询的处理有三个主要阶段:
l 分析编译SQL 语句
执行标识选定的行或对数据应用DML 更改l
提取返回SELECTl 语句查询的行

1. 分析SQL 语句：在分析阶段SQL 语句从用户进程传递到服务器进程，并且SQL 语句的分析说明被载入共享的SQL 区,在分析过程中服务器进程做如下工作：
在共享池中搜索SQL 语句的现有副本l
通过检查语法验证SQLl 语句
执行数据字典查找来验证表和列的定义l
分析SQL 语句续l
l 获取对象的分析锁以便在语句的分析过程中对象的定义不会改变
检查用户访问引用方案对象的权限l
l 确定语句的最佳执行计划
将语句和执行计划载入共享的SQLl 区
主意：分析阶段包括处理某些要求，不论语句执行多少次这些要求通常只需要处理一次。Oracle 服务器总是验证用户是否具有执行SQL 语句所需的权限。
2. 执行SELECT 语句：到了SELECT 语句这一步服务器进程准备要检索数据了
3. 提取查询行：在提取阶段对行进行选择和排序（如有必要）并且由服务器返回给用户
发出COMMIT 命令时执行下面的步骤
1.        服务器进程随同SCN 一起在重做日志缓冲区中放置一个提交记录。
2.        LGWR 向重做日志文件中连续写入，直到提交记录（含提交记录）的所有重做日志缓冲区条目，这之后Oracle 服务器就能够保证即使存在例程失败也不会丢失更改。
3.        通知用户COMMIT 命令已完成。
4.        服务器进程记录信息以指出事务处理已完成，并且可以释放资源锁，将灰数据缓冲区刷新到数据文件由DBW0 独立执行，在提交之前或之后进行都可以。（因此请牢记，DBWR的触发不依赖于Commit行为）

快速提交( Fast Commit )
快速提交机制将更改写入重做日志缓冲区而不是写入数据文件，这样确保数据得以恢复，Oracle 服务器使用这种机制来保证提交的更改能够在例程失败的情况下得以恢复。它有如下优势
l 连续写入日志文件比写入数据文件的各个块更快。（因为日志文件是顺序写的）
l 只将记录更改必须的最少信息写入日志文件，然而写入数据文件却需要写入整个数据块（它记录被更改的块，更改位置，以及重做条目中的新值。）。
l 如果多个事务处理同时请求提交那么例程将重做日志记录合成为单个写入。
l 除非重做日志缓冲区特别满否则每个事务处理只需要一个同步写入，如果发生合成，那么每个事务处理的同步写入可能不到一个，  因为提交之前可能会刷新重做日志缓冲区，所以事务处理的大小并不影响实际的提交操作所需的时间量。（因为，每3秒，重做日志缓冲区填满1M，重做日志缓冲区填满1/3，或者事务提交的时候，LGWR进程会将REDO LOG BUFFER中内容的写入到REDO LOG FILE 中。）
注：回退事务处理并不会触发LGWR 写入磁盘（因为没有提交的数据本身不会被写入数据文件）。

数据库写入进程( DBWR )（8i之前的条件）
服务器进程在缓冲区高速缓存中记录回退和数据块的更改，数据库写入进程(DBW0) 将灰数据缓冲区从数据库缓冲区高速缓存写入数据文件，它确保有足够数量的空闲缓冲区，即当服务器进程需要读取数据文件中的块时，可以覆盖的缓冲区在数据库缓冲区高速缓存中可用。由于服务器进程只在缓冲区高速缓存中进行更改，因此数据库性能得到改善，而且DBW0 延迟写入数据文件直到发生下列事件之一：
l 灰数据缓冲区的数量达到阈值；
l 当进行扫描而无法找到任何空闲缓冲区时进程扫描了指定数量的块；
l 出现超时每三秒；
l 出现检查点（检查点是使数据库缓冲区高速缓存与数据文件同步的一种方法）

9i是这么写的:
DBWn defers writing to the data files until one of the following events occurs:
* Incremental or normal checkpoint
* The number of dirty buffers reaches a threshold value
* A process scans a specified number of blocks when scanning for free buffers and cannot
fine any.
* Timeout occurs.
* A ping request in Real Application Clusters environment.
* Placing a normal or temporary tablespace offline.
* Placing a tablespace in read only mode.
* Dropping or Truncating a table.
* ALTER TABLESPACE tablespace name BEGIN BACKUP

日志写入进程（ LGWR ）
LGWR 在下列情况下执行从重做日志缓冲区到重做日志文件的连续写入：
l 当提交事务处理时( Commit )
l 当重做日志缓冲区的三分之一已满时
l 当重做日志缓冲区中记录了超过1 MB 的更改时
l 在DBW0 将数据库缓冲区高速缓存中修改的块写入数据文件以前

l 在DBWR写之前

因为恢复操作需要重做，所以LGWR 只在重做写入磁盘后确认COMMIT 命令。（所以，LGWR是5个不可缺少的后台进程中，唯一个与SQL语句执行相关的进程。当然，SQL语句的执行还要依赖于在客户端运行的用户进程和在服务器端执行的服务器进程。）

检查点( CKPT )
检查点后台进程（CKPT）用于更新所有数据文件的标题和控制文件以反映该进程已成功完成，使数据库文件同步。

数据库在检查点期间做如下工作： DBWn 将许多由正在经历检查点事件的日志覆盖的灰数据库缓冲区写入到数据文件中。由DBWn写入的缓冲区数量由参数FAST_START_IO_TARGET 决定。

检查点可发生在下面情况中：
l 每次日志切换时;（alter system switch logfile）
l 当已通过正常事务处理或者立即选项关闭例程时；shutdown immediate或者shutdown）
l当通过设置初始化参数LOG_CHECKPOINT_INTERVAL、LOG_CHECKPOINT_TIMEOUT 和FAST_START_IO_TARGET 强制时；
l 当数据库管理员手动请求时；（ALter system checkpoint）
如果初始化参数LOG_CHECKPOINTS_TO_ALERT设置为TRUE ，则每个检查点信息都记录在ALERT文件内；该参数缺省值为FALSE，不记录检查点。

注意：FAST_START_IO_TARGET 参数是在 ORACLE 8.1.x Enterprise Edition 版本及其后续版本中添加的参数。

强制检查点
可以使用下面的SQL 命令手动强制检查点发生：
SQL> ALTER SYSTEM CHECKPOINT;

设置数据库检查点时间间隔
当数据库使用大型联机重做日志文件时，可以通过设置以下初始化参数来设置其它数据库检查点，以改善数据库的性能：
l       LOG_CHECKPOINT_INTERVAL
l       LOG_CHECKPOINT_TIMEOUT

l      FAST_START_IO_TARGET （只限于ORACLE 8.1.x Enterprise

Edition 版本及其后续版本）

LOG_CHECKPOINT_INTERVAL
在低于ORACLE 8.1.X 的版本中，LGWR 一写入参数LOG_CHECKPOINT_INTERVAL 指定的块数就启动了检查点。LOG_CHECKPOINT_INTERVAL 值在操作系统块中指定而不是在Oracle 数据库块中指定。

但是，无论该值如何，当从一个联机重做日志文件切换到另一个时检查点始终发生。
如果该值超过实际联机重做日志文件大小，那么检查点仅在日志切换时发生。
注意：将时间间隔值指定为0 可能导致非常频繁地启动检查点，因为即使上一个请求启动后仅对单个重做日志缓冲区写入仍会启动新的请求。
在ORACLE 8.1.x Enterprise Edition 版本及其后续版本内，当指定了LOG_CHECKPOINT_INTERVAL 后，检查点位置目标相对于日志尾的滞后不能大于该参数指定的重做日志块数，这确保了在例程恢复期间需要读取不超过固定数目的重做块。

LOG_CHECKPOINT_TIMEOUT
对于低于ORACLE 8.1 的版本，该初始化参数值指定了另一个检查点发生前的最大时间量，该值按秒指定该时间。从前一个检查点启动时，开始经过该参数指定的时间量后发生另一个检查点，将超时值指定为0 就可以禁用基于时间的检查点。
在ORACLE 8.1.x Enterprise Edition 版本及其后续版本内，当指定了LOG_CHECKPOINT_TIMEOUT 后，该参数将检查点位置目标设置到日志文件中的某个位置，而该日志在该参数指定的秒数前结束，这确保了在恢复期间需要读取的重做块数不超过与指定秒数相当的块数。

FAST_START_IO_TARGET
参数FAST_START_IO_TARGET 改善了实例失败恢复的性能，该参数值越小，由于需要恢复的块就越少因而恢复性能就越好。该参数设置后DBWn 更频繁地将灰缓冲区写出。该参数在在ORACLE 8.1.x Enterprise Edition 版本及其后续版本中引入。

CheckPoint Process 的深入研究

“三个钟”的故事：假设一个公司只有三个员工，每个员工有自己的一个钟。该公司规定，每天早晨８：３０上班。有一天，非常不幸，三个员工的钟的时间各不相同，在没有其他外部因素的帮助下，他们无法确定当前的确切时间，他们无法上班，该公司无法正常的OPEN 运作。

这个故事，帮助我们说明，在实例经过分配内存结构，加载控制文件后，然后要打开数据库的时候，需要做到控制文件，数据文件，联机重做日志保持相互状态一致性，数据库才可以打开。当数据库发生实例不正常关闭时（比如系统掉电或者Shutdown abort 进行关闭），要进行实例恢复，Oracle 数据库具有相应的机制来实现这一点。

像任何一家公司一样，不同的员工具有不同的技能专长，负责不同的工作，但是一个成功的项目，需要一个优秀的项目经理，来保持，督促项目中的成员各自工作步调相互一致。在Oracle 实例中，这样的一个重要角色，被检查点(CheckPoint) 进程（CKPT）担任。Oracle 实例在必要的时候，出现检查点，当检查点出现时，CKPT 进程一方面催促DBWR 进程及时地把该检查点时刻前DB_Buffer 中被一些Service_Process 进程修改过的数据及时写入数据文件中，写完之后，CKPT 进程更新相关的数据文件和控制文件的同步时刻点。也就是说，Oracle 实例在运行过程中，需要CKPT 进程来定期同步控制文件、数据文件和联机日志文件的“时间点”。
在这篇文章当中，我们将详细，深入的讨论检查点和检查点进程的作用。

——————————————————————————————————————–

大多数关系型数据库都采用“在提交时并不强迫针对数据块的修改完成”而是“提交时保证修改记录（以重做日志的形式）写入日志文件”的机制，来获得性能的优势。这句话的另外一种描述是：当用户提交事务，写数据文件是“异步”的，写日志文件是“同步”的。这就可能导致数据库实例崩溃时，内存中的DB_Buffer 中的修改过的数据，可能没有写入到数据块中。数据库在重新打开时，需要进行恢复，来恢复DB Buffer 中的数据状态，并确保已经提交的数据被写入到数据块中。检查点是这个过程中的重要机制，通过它来确定，恢复时哪些重做日志应该被扫描并应用于恢复。

检查点和检查点进程的操作的三个步骤：

A、系统触发一个检查点，系统并记录该检查点时刻的Checkpoint SCN 号，并记录该时刻修改的DB Buffer的块所参考的RBA作为Checkpoint RBA RBA (Redo Byte Address)。

B、该Checkpoint RBA 之前的日志实体所参考的DB_Buffer 中数据块的修改，要被写出到数据文件中。

C、完成２步骤后，CKPT 进程记录该检查点完成信息到控制文件。

只有上面三个步骤完成，才表示系统的检查点已经被推进，推进了日志文件，数据文件，控制文件到一个新的“同步点”。

检查点只发生在下列情形：

管理员使用：Alter system checkpoint 命令；

实例被正常的关闭；

特别注意：日志切换并不导致一个完全检查点的发生。

如何确定哪些DB_Buffer中的数据块需要被写到磁盘上，是一个蛮复杂的算法。大致思想就是：所有dirty data按照Low RBA 的升序进行链接成一个list，当CKPT被唤醒的时候，首先先从控制文件读取上次check point，把中间这段时间的dirty data 写到磁盘上。

二、触发的条件

这里需要明白两个概念“完全检查点和增量检查点”的区别。

增量检查点（incremental checkpoint）
oracle8以后推出了incremental checkpoint的机制，在以前的版本里每checkpoint时都会做一个full thread checkpoint,这样的话所有脏数据会被写到磁盘，巨大的i/o对系统性能带来很大影响。为了解决这个问题，oracle引入了checkpoint queue机制，每一个脏块会被移到检查点队列里面去，按照low rdb（第一次对此块修改对应的redo block address）来排列，靠近检查点队列尾端的数据块的low rba值是最小的，而且如果这些赃块被再次修改后它在检查点队列里的顺序也不会改变，这样就保证了越早修改的块越早写入磁盘。每隔3秒钟ckpt会去更新控制文件和数据文件，记录checkpoint执行的情况。

在运行的Oracle 数据中，有很多事件、条件或者参数来触发检查点。比如
l 当已通过正常事务处理或者立即选项关闭例程时；（shutdown immediate或者Shutdown normal;）
l  当通过设置初始化参数LOG_CHECKPOINT_INTERVAL、LOG_CHECKPOINT_TIMEOUT 和FAST_START_IO_TARGET强制时；
l 当数据库管理员手动请求时；（ALter system checkpoint）

l alter tablespace … offline;

l  每次日志切换时;（alter system switch logfile）

需要说明的是，alter system switch logfile也将触发完全检查点的发生。

alter database datafile … offline不会触发检查点进程。

如果是单纯的offline datafile，那么将不会触发文件检查点，只有针对offline tablespace的时候才会触发文件检查点，这也是为什么online datafile需要media recovery而online tablespace不需要。

对于表空间的offline后再online这种情况，最好做个强制的checkpoint比较好。

上面几种情况，将触发完全检查点，促使DBWR 将检查点时刻前所有的脏数据写入数据文件。

另外，一般正常运行期间的数据库不会产生完全检查点，下面很多事件将导致增量检查点，比如：

在联机热备份数据文件前，要求该数据文件中被修改的块从DB_Buffer 写入数据文件中。所以，发出这样的命令：

l  ALTER TABLESPACE tablespace_name BIGEN BACKUP & end backup; 也将触发和该表空间的数据文件有关的局部检查点；另外，

l  ALTER TABLESPACE tablespace_name READ ONLY;

l  ALTER TABLESPACE tablespace_name OFFLINE NORMAL;

等命令都会触发增量检查点。

三、检查点位置的影响因素

相比传统检查点（也就是指那些有明确含义的检查点） ，增量检查点可以平缓的、持续的推进日志文件和数据文件的同步点。理解这一点是学习Checlpoint 有关原理的关键点。。很多朋友（包括我自己），总是将增量检查点和那些有明确含义的检查点做对比联系起来，竭力去探求，什么时候该出现增量检查点？很难得到确定的答案，是大家学习的难点。实际上，对于增量检查点，主要讨论的并不是什么时候出现增量检查点，而是：如何控制增量检查点推进的速率？检查点本质上是为了推进写日志和写数据.

文件的“异步机制”的同步，我们感兴趣的内容终究要归结到：系统崩溃时，“异步的距离”将需要系统多少时间来进行恢复？事实上，Oracle 正是这样设计的，数据库提供了一些参数设置（以oracle 9.2 为例）

A、FAST_START_MTTR_TARGET 参数来控制增量检查点的推进速率

我们都希望当实例崩溃后，恢复需要读取的日志流尽可能的短，恢复需要的时间尽可能的短。这样，我们会将FAST_START_MTTR_TARGET 设置值更小, 增量检查点会出现的更加密集频繁。但设置值太小，将显剧增加DBWR 写数据文件的工作量，写数据文件的I/O 的增加将降低系统的性能，降低“写日志文件和写数据文件的异步机制”所带来的性能效益。

难以说明设置FAST_START_MTTR_TARGET 为多少是合适的设置，这和我们各自的数据库应用业务有关。Oracle 提供了一个视图V$MTTR_TARGET_ADVICE 作为我们设置参考，从该视图中，Oracle 会给出一些估计，当您设置不同的FAST_START_MTTR_TARGET 的值时，对应的物理写数据文件的数量的估计值。我们可以选择一个合适的值，可以降低恢复时间，但是不让DBWR 的工作量增加太大。

数据库恢复的内在机制

数据库在“事务”当中发生变化，Oraccle 数据库系统使用系统变更号（System Change Number，简写为SCN）来记录数据库内部的变化。数据库内部的很多事件，以及用户通过SQL 语句对数据库内容进行变化，会让SCN 值增长。

我们知道，当应用程序提交（Commit）某个事务时，先是日志写入进程（LGWR）将Log Buffer 中的该事务的纪录写入到联机重做日志文件成功后，才由Service Process 通知相关的用户进程：你的提交已成功。

检查点出现，将推动检查点时刻前的日志文件中所参考的数据块的修改，已经被DBWR 写入到数据文件中。CKPT进程会纪录该检查点的Checkpoint SCN 的信息到数据文件和控制文件中。从而推动了数据库的一个“同步点”。如果在下一个同步点完成之前，数据库发生失败，在数据库的实例恢复从系统当前检查点开始，运用后面的日志进行实例恢复。

可以看出，检查点的出现，可以让数据库在运行时，“定期”的维护日志文件，数据文件进行状态一致性。有些类似于我们生活中：不同的公司定期的账目结清，当一个检查点完成后，大家都承认，这个时间之前的一切账目已经结清。

一、Oracle 是如何确定需要恢复的

1、正常运行的数据库的有关检查点信息纪录

在数据库正常OPEN 运行时，当一个检查点完成后，Oracle存储新的System Checkpoint SCN 值

到控制文件中，我们可以通过下面的查询来得到该值。

SQL> select a.CHECKPOINT_CHANGE# from v$database a;

CHECKPOINT_CHANGE#

——————

2798752785243

SQL> select a.NAME,a.CHECKPOINT_CHANGE# from v$datafile a;

NAME CHECKPOINT_CHANGE#

——————————————————————– ——————

C:ORACLEORADATAJACKYSYSTEM01.DBF 2798752785243

C:ORACLEORADATAJACKYUNDOTBS01.DBF 2798752785243

C:ORACLEORADATAJACKYCWMLITE01.DBF 2798752785243

C:ORACLEORADATAJACKYDRSYS01.DBF 2798752785243

C:ORACLEORADATAJACKYEXAMPLE01.DBF 2798752785243

C:ORACLEORADATAJACKYINDX01.DBF 2798752785243

C:ORACLEORADATAJACKYODM01 2798752785243

C:ORACLEORADATAJACKYTOOLS01.DBF 2798752785243

D:DATAFILEUSERS01.DBF 2798752785243

C:ORACLEORADATAJACKYXDB01.DBF 2798752785243

C:ORACLEORADATAJACKYBLOCK.DBF 2798752785243

C:ORACLEORADATAJACKYRMAN.DBF 2798752785243

C:ORACLEORADATAJACKYTEST01.DBF 2798752785243

13 rows selected

Oracle 也会在每个数据文件的头部存储存储Checkpoint SCN的值，名称叫做Start SCN。主要作用是在数据库Open的时候，用于和控制文件有关信息进行比较，从而确定是否需要做恢复。

SQL> select a.NAME,a.CHECKPOINT_CHANGE# from v$datafile_header a;

NAME CHECKPOINT_CHANGE#

——————————————————————– ——————

C:ORACLEORADATAJACKYSYSTEM01.DBF 2798752785243

C:ORACLEORADATAJACKYUNDOTBS01.DBF 2798752785243

C:ORACLEORADATAJACKYCWMLITE01.DBF 2798752785243

C:ORACLEORADATAJACKYDRSYS01.DBF 2798752785243

C:ORACLEORADATAJACKYEXAMPLE01.DBF 2798752785243

C:ORACLEORADATAJACKYINDX01.DBF 2798752785243

C:ORACLEORADATAJACKYODM01 2798752785243

C:ORACLEORADATAJACKYTOOLS01.DBF 2798752785243

D:DATAFILEUSERS01.DBF 2798752785243

C:ORACLEORADATAJACKYXDB01.DBF 2798752785243

C:ORACLEORADATAJACKYBLOCK.DBF 2798752785243

C:ORACLEORADATAJACKYRMAN.DBF 2798752785243

C:ORACLEORADATAJACKYTEST01.DBF 2798752785243

13 rows selected

Oracle 在控制文件为每个数据文件存储Stop SCN 的值，在正常OPEN 的数据库中，该值为一个无穷大，查询时，显示NULL。

SQL> select a.NAME,a.LAST_CHANGE# from v$datafile a;

NAME LAST_CHANGE#

——————————————————————————– ————

C:ORACLEORADATAJACKYSYSTEM01.DBF

C:ORACLEORADATAJACKYUNDOTBS01.DBF

C:ORACLEORADATAJACKYCWMLITE01.DBF

C:ORACLEORADATAJACKYDRSYS01.DBF

C:ORACLEORADATAJACKYEXAMPLE01.DBF

C:ORACLEORADATAJACKYINDX01.DBF

C:ORACLEORADATAJACKYODM01.DBF

C:ORACLEORADATAJACKYTOOLS01.DBF

D:DATAFILEUSERS01.DBF

C:ORACLEORADATAJACKYXDB01.DBF

C:ORACLEORADATAJACKYBLOCK.DBF

C:ORACLEORADATAJACKYRMAN.DBF

C:ORACLEORADATAJACKYTEST01.DBF

13 rows selected

2、正常关闭的数据库的有关检查点记录信息

当我们正常关闭数据库（Shutdown immediate 或者Shutdown normal），此时会执行一个检查点的过程，该过程会把控制文件中记录的每个数据文件的Stop SCN 进行设置，等于每个数据文件头部的StartSCN。所以，我们以start mount 加载数据库，然后进行上面的查询。得到下图的结果：

正常关闭数据库，在Mount 模式下启动数据库，查询System Checkpoint SCN 和Data File

Checkpoint SCN 以及Start SCN、Stop 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> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

——————

2.7988E+12

SQL> select name,checkpoint_change#,last_change# from v$datafile where name like ‘%USER%’;

NAME CHECKPOINT_CHANGE# LAST_CHANGE#

——————————-

D:DATAFILEUSERS01.DBF 2.7988E+12 2.7988E+12

SQL>

在OPEN 数据库时，Oracle 先检查数据文件头部所记录的Start SCN 和控制文件中所记录的数据文件的Checkpoint SCN 是否一致，如果一致，Oracle 进一步检查Start SCN 和控制文件中记录的数据文件的Stop SCN，如果一致。这表示所有的已经被修改的数据块已经反映到了数据文件中。在是正常关闭数据库的情况。数据库可以正常OPEN，无需作实例恢复，当数据库打开后，控制文件中的Stop SCN 会变为NULL。

SQL> alter database open;

数据库已更改。

SQL> select name,checkpoint_change#,last_change# from v$datafile where name like ‘%USER%’;

NAME CHECKPOINT_CHANGE# HANGE#

——————————————————————————–

D:DATAFILEUSERS01.DBF 2.7988E+12

数据库在打开时，对每个数据文件要进行两个比对：

A、控制文件中记录的数据文件的Checkpoint SCN 　和　数据文件头部所记录的Start SCN 是否相等；

B、然后检查：控制文件中记录数据文件的Stop SCN 和　数据文件头部所记录的Start SCN 是否相等；

3、实例Crash 后的有关检查点记录信息

SQL> create table test (a number) tablespace test ;

Table created

SQL> insert into test values(1);

1 row inserted

SQL> shutdown abort

ORACLE 例程已经关闭。

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> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

——————

2.7988E+12

SQL> select name,checkpoint_change#,last_change# from v$datafile where name like ‘%TEST%’;

NAME CHECKPOINT_CHANGE# LAST_CHANGE#

—————— ————

C:ORACLEORADATAJACKYTEST01.DBF 2.7988E+12 NULL

SQL> select name,checkpoint_change# from v$datafile_header where name like’%TEST%’;

NAME CHECKPOINT_CHANGE#

——————

C:ORACLEORADATAJACKYTEST01.DBF 2.7988E+12

从上面可以看出控制文件中记录的Stop SCN （查询中的Last_Change#）为无穷大。不等于数据文件头部的Start SCN。这表示：数据库在Crash 关闭时，没有进行Checkpoint和相关过程。实例在Open 之前，需要做实例恢复。

实例恢复由Oracle 实例自动完成。Oracle 依照控制文件记录的数据库的Checkpoint SCN 定位联机重做日志文件中的重做日志位置。从该位置开始应用重做日志一直到Crash 时日志结束点。这中间所有被提交的事务，将会确保写入到数据文件，这个过程叫做前滚过程（Roll Forward）。没有提交的活动事务将从回滚段中恢复过来；在上面的例子中Crash 前，我们插入了一行数据，但是没有被提交。所以，实例恢复后，将查询不到该行数据。

SQL> alter database open;（oracle 实例自动完成）

数据库已更改。

SQL> select * from test;

未选定行

控制文件中记录的数据文件的Checkpoint SCN 和数据文件头部所记录的Start SCN 始终是相等的。这是因为数据库在经历检查点后，检查点后台进程会同时修改数据库的System Checkpoint SCN、控制文件中记录的数据文件的Checkpoint SCN、以及数据文件头文件中的Start SCN，设置它们的值为检查点开始的系统变更号SCN。

只有在当数据文件丢失时，我们使用以前的备份的数据文件时，这个比对就不一致，数据文件头部纪录的Start SCN 将会小于控制文件中所记录的该数据文件的Checkpoint SCN。将使用到必要的归档／联机日志文件进行恢复。

4、使用备份的控制文件进行恢复

在正常情况下，数据文件头部所记录的Start SCN 都不会大于控制文件中记录的数据文件的CheckpointSCN 的。我们也许觉得奇怪，控制文件已经记录了Checkpoint SCN，为何还需要纪录System Checkpoint SCN 呢，这主要有下列原因：

A、有时候，数据库的某些表空间处于只读模式，当系统经历检查点，只读表空间的数据文件头部的StartSCN 将不会更新；System Checkpoint SCN 有助于识别这一点。

B、有时候，我们的控制文件丢失了，当我们使用以前备份的控制文件。此时，数据文件头部的Start SCN会大于控制文件的System Checkpoint SCN，这表明使用了备份的控制文件。如果我们使用正常的recover database 的恢复方法，将会出现错误消息。我们应该使用：recover database using backup controlfile;

二、实例恢复的详细过程

当我们系统掉电，或者通过Shutdown abort 关闭数据后，再重新打开数据库前，系统会自动进行恢复，这个恢复过程可以分为下列三个阶段

A.     前滚过程，前滚是按照redo file的记录来前滚的，不管有没有commit，都会利用联机日志文件的有关重做信息，写入到数据文件中。

前滚是按照redo file的记录来前滚的，不管有没有commit，只要有已经写入redo就会前滚，所以前滚完成后，data file中可能会有 没有提交的数据，这样才需要后面的回退过程。另外，由于undo的生成也是要记录redo的，所以这个过程还会按照redo重新生成后面回退时需要的undo信息。另外，实例恢复是在从最近的一次checkpoint后开始到失败的一刻，所以，增加checpoint的频率可以减少实例恢复所需要的时间，但同时会影响系统的性能，所以需要在这两者之间做一个权衡。

前滚又叫缓冲区恢复cache recovery，顾名思义，就是恢复已经在内存中存在但还没有写入数据文件中的内容，而不管这个内容所在的事务是不是已经提交。

B.      数据库打开：进行完毕前滚过程后，数据库就可以打开，可以接受用户连接访问了。

C.         回退(Roll Back) 过程：没有提交的事务将会被回退。
回退阶段又叫事务恢复transaction recoery，也就是恢复完后将保持事务一致性。该过程保证数据库中的数据只有已经提交的，没有提交的事务将会被回退。

1、redo buffer 的操作

当用户User A 发出数据修改命令：　UPDATE emp SET sal=10 WHERE

数据块被读入DB Buffer 中；相应的回滚段的数据块也被读入到DB Buffer 中，并将数修改前的值信息记录下来，作为前映像；这样的变化过程会作为REDO 实体记录在Redo Buffer中。

然后，修改DB Buffer 中数据块的值为新值；并在Redo Buffer中生成重做信息。在Redo Buffer 中的重做记录实体主要包含三部分信息：

事务的识别号

修改目标Column 的地址

修改Column 的新值

然后，用户User A 发出提交命令：

Commit

在Redo Buffer 中生成相应的重做信息实体，该信息主要包含三部分：

A、一个标志指示该实体是一个Commit。如果是Rollback 或者是Checkpoint也有相应的标志。

B、时间。

C、当前的SCN 号。

SCN 是System Change Number，用来帮助识别数据库的事务，数据库在事务当中变化，我们可以认为SCN 是数据库变化的“时钟”。SCN 一般用来标识数据库内事务的开始，事务的提交，回滚，或者是检查点的时间，以及其他数据库内部的事件。

LGWR 进程负责将Log Buffer 中内容写入到联机日志文件中去。触发LGWR 工作的机制有：

用户提交

Redo Buffer 的1/3 写满了

Redo Buffer 中写满1M 内容

超时3 秒

DBWR 写

总之，LGWR是一个极为频繁的工作进程，从而保证事务信息被非常快速，及时地写入到联机日志文件。

当联机日志文件Log 1 写满之后，则发生日志切换到Log 2。在正常的生产数据库上，联机日志文件的组数和大小需要灵活考虑，通常情况下，较好的经验值是让日志切换的发生时间间隙为２０－３０分钟之间。这只是一个建议，某些情况或者某些特别的需求，也有要求日志切换更加频繁或者间隙更长。

2、数据库恢复的过程

因为系统掉电或者不正常关闭数据库（Shutdown abort），当数据库要重新打开前，系统自动会进行恢复过程。这个恢复过程是首先从读取控制文件的信息开始的。控制文件中记录的Checkpoint RBA (Redo Byte Address) 指向联机日志文件中一个恢复开始点。由于每次操作都在redo log都有记录，所以可以从这个开始点往后的重做信息直到重做信息的结束点，每次操作都进行“重演”，也就是恢复。

对于已经提交的事务，事务被“重新提交（Re-Commit)”，这就是前滚的概念。然而，在数据库Crash 前没有提交的事务，当时所引起的数据文件的修改变化。在恢复过程后，数据库打开运行期间，如果有用户访问到这些数据块，才利用以前的“前映像”来重新修改回去。这是未提交的事务的回退过程。

从oracle9i开始，Oracle 改善了恢复过程中“前滚”的操作。这个小的改变提高了实例恢复过程中的效率－－在实例失败后可以更快速的恢复过来。当一次DBWR写 完成后，LGWR会在Redo Buffer 中记录该次写完成的数据块。

这种新的快速前滚机制分为两个步骤：

A、 先快速选择哪些块的事务需要处理；扫描一次Redo Log, 根据DBWR的写块记录滤去已经写入了数据文件的那些重做实体的处理，这个过程不需要读取数据文件块。速度非常快。

B、 然后对选择的块进行处理；

这个小的改善，显剧减少了恢复过程中去读取和修改数据块的数量。再加上Checkpoint 的同步特性和有关参数控制。让实例Crash后的快速恢复过程的时间是快速的，可控的。

—————-Derived From http://www.ixdba.net/hbcms/article/4e/265.html——–

A granule is a unit of contiguous virtual memory allocated to a process.

Oracle instance

If an Oracle instance starts up, it allocates the SGA (System Global Area) in granule sized memory units. The size of these granules depends on your database version and somtimes even on the operating system port. For example, for Oracle 9i it is typically 4MB if your SGA is smaller than 128MB and 16MB if your SGA is bigger. For later releases it is typically 4MB if your SGA is smaller than 1GB and 16MB if your SGA is bigger. Issue the below query to get your instance’s exact granule size:

SQL> SELECT * FROM v$sgainfo WHERE name = 'Granule Size';
NAME                                  BYTES RES
-------------------------------- ---------- ---
Granule Size                        4194304 No

The minimum SGA size is three granules, based on:

1. One Granule for Fixed SGA (includes redo buffers)
2. One Granule for Buffer Cache
3. One Granule for the Shared Pool

The maximum SGA size is determined by the sga_max_size parameter.

SQL> show parameter sga_max_size;

NAME                                               TYPE        VALUE

———————————— ———– ——————————

sga_max_size                              big integer 328M

Note that Oracle will always round-up memory values to the next granule size. The Buffer Cache, Shared Pool, Large Pool and Java Pool, to name a few, can only grow or shrink based on granule boundaries.

In Oracle Database,the db_cache_size and db_nk_cache_size parameters determine the size of Database Buffer Cache.

Default value of the db_cache-size :If SGA_TARGET is set: If the parameter is not specified, then the default is 0 (internally determined by the Oracle Database). If the parameter is specified, then the user-specified value indicates a minimum value for the memory pool.

If SGA_TARGET is not set, then the default is either 48 MB or 4MB * number of CPUs * granule size, whichever is greater.

DB_CACHE_SIZE specifies the size of the DEFAULT buffer pool for buffers with the primary block size (the block size defined by the DB_BLOCK_SIZE initialization parameter).

The value must be at least 4M * number of cpus * granule size (smaller values are automatically rounded up to this value). A user-specified value larger than this is rounded up to the nearest granule size. A value of zero is illegal because it is needed for the DEFAULT memory pool of the primary block size, which is the block size for the SYSTEM tablespace.

————–Derived From Oracle 10g References——————–

DB_CACHE_SIZE 数据缓冲区

SQL> select * from v$version where rownum<=1;
BANNER
—————————————————————-
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 – 64bi
SQL> show parameter db_cache
NAME                                 TYPE        VALUE
———————————— ———– ——————————
db_cache_advice                      string      ON
db_cache_size                        big integer 0

data buffers
8i中是Db_block_buffers(数据块缓冲缓存区Data block buffers cache)*Db_block_size，
9i及以后版本用Db_cache_size来代替这个参数。
10g中，由oracle本身自动管理的，可以不用手工设置。

在内存的配置中把其他参数设置完后，应把能给的都给Data buffers。Oracle在运行期间向数据库高速缓存读写数据，高速缓存命中表示信息已在内存中，高速缓存失败意味着

Oracle必需进行磁盘I/O。保持高速缓存失败率最小的关键是确保高速缓存的大小。Oracle8i中初始化参数Db_block_buffers控制数据库缓冲区高速缓存的大小。

通过查询V$sysstat表，求出命中率，以确定是否应当增加Db_block_buffers的值。
高速缓存命中率=1-physical   reads/(dbblock   gets+consistent   gets)
select 1 – (select value from v$sysstat where name = ‘physical reads’) /
((select value from v$sysstat where name = ‘consistent gets’) +
(select value from v$sysstat where name = ‘db block gets’)) ratio
from dual;
如果该命中率太小，考虑增大数据库缓冲区。

–原始数据查询
SQL> 1  select name,value
2  from v$sysstat
3* where name in (‘db block gets’,’consistent gets’,’physical reads’)
SQL> /

NAME                                                                  VALUE
—————————————————————- ———-
db block gets                                                      49148660
consistent gets                                                  4223352513
physical reads                                                     51914221

–命中率查询
SQL> select 1 – (select value from v$sysstat where name = ‘physical reads’) /
2         ((select value from v$sysstat where name = ‘consistent gets’) +
3         (select value from v$sysstat where name = ‘db block gets’)) ratio
4    from dual;

RATIO
———-
.987851628

Oracle 10g中，与内存相关的参数可以分为两类：
自动调优的SGA参数：包括DB_CACHE_SIZE、SHARED_POOL_SIZE、LARGE_POOL_SIZE和JAVA_POOL_SIZE。
手动SGA参数：包括LOG_BUFFER、STREAMS_POOL、DB_NK_CACHE_SIZE、DB_KEEP_CACHE_SIZE和DB_RECYCLE_CACHE_SIZE。

SQL> show parameter cache_size
NAME                                 TYPE        VALUE
———————————— ———– ——————————
db_16k_cache_size                    big integer 0
db_2k_cache_size                     big integer 0
db_32k_cache_size                    big integer 0
db_4k_cache_size                     big integer 0
db_8k_cache_size                     big integer 0
db_cache_size                        big integer 0
db_keep_cache_size                   big integer 0
db_recycle_cache_size                big integer 0
SQL> show parameter pool
NAME                                 TYPE        VALUE
———————————— ———– ——————————
buffer_pool_keep                     string
buffer_pool_recycle                  string
global_context_pool_size             string
java_pool_size                       big integer 0
large_pool_size                      big integer 0
olap_page_pool_size                  big integer 0
shared_pool_reserved_size            big integer 47815065
shared_pool_size                     big integer 0
streams_pool_size                    big integer 0

Oracle 10g中，任何时候你都能查询V$SGAINFO，来查看SGA的哪些组件的大小可以调整。
使用自动SGA内存管理，参数STATISTICS_LEVEL必须设置为TYPICAL或ALL。如果不支持统计集合，数据库就没有足够的历史信息来确定大小。采用自动SGA内存管理时，确定自动

调整组件大小的主要参数是SGA_TARGET，该参数在数据库运行时动态调整，最大可以达到SGA_MAX_SIZE参数设置的值(默认等于SGA_TARGET，所以如果想增加SGA_TARGET，就必须在

启动数据库实例之前先把SGA_MAX_SIZE设置得大一些)。
数据库会使用SGA_TARGET值，再减去其他手动设置组件的大小(如DB_KEEP_CACHE_SIZE、DB_RECYCLE_CACHE_SIZE)，使用计算得到的内存量来设置默认缓冲区池、共享池、大池和

Java池的大小。在运行时，实例会根据需要动态地对这4个内存区分配和撤销内存。如果共享池内存用光了，实例不会向用户返回一个ORA-04031″Unable to allocate N bytes of

shared memory”错误，而是会把缓冲区缓存缩小几MB(一个granule的大小)，再相应地增加共享池的大小。
–Granule的大小查询
SQL> select name,bytes from v$sgainfo where name =’Granule Size’;
NAME                                  BYTES
——————————– ———-
Granule Size                       16777216
SQL> select bytes/1024/1024/8 from v$sgainfo where name =’Granule Size’;
BYTES/1024/1024/8
—————–
2
SQL> show parameter db_block_size
NAME                                 TYPE        VALUE
———————————— ———– ——————————
db_block_size                        integer     8192

也就是2048个db_block_size为一个Granule

SQL> show parameter statistics_level
NAME                                 TYPE        VALUE
———————————— ———– ——————————
statistics_level                     string      TYPICAL
SQL> show parameter sga_target
NAME                                 TYPE        VALUE
———————————— ———– ——————————
sga_target                           big integer 1536M
SQL> show parameter sga_max_size
NAME                                 TYPE        VALUE
———————————— ———– ——————————
sga_max_size                         big integer 1536M

V$sysstat

SQL> desc V$sysstat
Name       Type         Nullable Default Comments
———- ———— ——– ——- ——–
STATISTIC# NUMBER       Y
NAME       VARCHAR2(64) Y
CLASS      NUMBER       Y
VALUE      NUMBER       Y
STAT_ID    NUMBER       Y

v$sgainfo

SQL> desc v$sgainfo
名称                                      是否为空? 类型
—————————————– ——– —————–
NAME                                               VARCHAR2(32)
BYTES                                              NUMBER
RESIZEABLE                                         VARCHAR2(3)

SQL> select * from v$sgainfo;
NAME                                  BYTES RES
——————————– ———- —
Fixed SGA Size                      2128760 No
Redo Buffers                        4325376 No
Buffer Cache Size                 721420288 Yes
Shared Pool Size                  838860800 Yes
Large Pool Size                    16777216 Yes
Java Pool Size                     16777216 Yes
Streams Pool Size                         0 Yes
Granule Size                       16777216 No
Maximum SGA Size                 1610612736 No
Startup overhead in Shared Pool    67108864 No
Startup NUMA Shared Pool memory    33554432 No
Free SGA Memory Available                 0

已选择12行。

———–Derived From http://my.unix-center.net/~Zianed/?p=477————