Oracle中的PR Enqueue 队列锁

PR即process creation队列锁enqueue lock ，该 PR队列锁在当启动/创建Oracle后台进程，MTS进程(dispatchers)，或parallel slave进程时被排他持有exclusive mode。

为了创建上述这些进程时会需要对SGA内存内数据结构的更新，这些进程启动后又会去读取SGA以便了解其自身具体的职责。 由于需要对SGA的更新，则需要将该操作与enqueue 队列相同步。

如何调优PR enqueue lock队列锁

一般而言该enqueue lock不应当存在争用。 若确实出现了争用则一般说明是MTS 或parallel slave进程生成的速度有些太快了（并不正常）。在此种情况下调整应用或实例参数来保证不要那么快的产生上述进程，一个数据库实例正常情况下用不着频繁的关闭和打开这些进程。

 

ID1/ ID2的含义

一般情况下这里的id1 和 id2 总是0 。

相关BUG

Bugs 1. Bug 1889323 documents a possible problem with this enqueue when running under RAC

Oracle  锁定机制

• 自动管理
• 高水平的数据并发性
  • 用于 DML 事务处理的行级锁
  • 查询不需要锁
• 改变中的数据一致性级别
• 专用锁模式和共享锁模式
• 锁要一直保持到提交或回退发生之前

 

Oracle 服务器自动管理锁定 Oracle 服务器的缺省锁定机制以最低的限制级别
锁定数据 以便在允许最大程度的数据并发性时 保证数据的一致性

 

数据并发性

根据设计 锁定允许高级别的数据并发性 也就是说 多个用户可以同时安全地访问相同的数据 数据并发性涉及两个级别的锁定 行级或不锁定

• 数据操纵语言 (DML) 锁定是行级锁定

示例

事务处理 1
SQL> update scott.s_emp
2 set salary=salary*1.1
3 where id= 24877;
1 row updated.

事务处理 2

SQL> update scott.s_emp
2 set salary=salary*1.1
3 where id= 24878;
1 row updated.

 

除非用户指定 否则查询不持有锁

 

示例

事务处理 1
SQL> UPDATE s_emp
2 SET salary = salary*1.1;
13120 rows updated.
事务处理 2
SQL> select salary
2 from s_emp
3 where id= 10;
SALARY
———
1000

 

数据一致性

Oracle 服务器也提供不同级别的数据一致性 也就是说 即使其他用户正在更改数据 用户仍会看到数据的静态图

 

持续时间

一直持有锁 直到发生 COMMIT 或 ROLLBACK 或者一个事务处理终止为止 如果一个事务处理异常终止 则 PMON 清除锁

 

锁定模式

排它锁模式 防止相关的资源被其它事务处理共享 直到排它锁被释放为止示例 对于 DML 事务处理 排它锁被设置为行级

事务处理 1

SQL> update scott.s_emp
2 set salary=salary*1.1
3 where id= 24877;
1 row updated.

 

事务处理 2

SQL> update scott.s_emp
2 set salary=salary*1.1
3 where id= 24877;
Transaction 2 waits.

 

在共享锁模式 下 几个事务处理可以在同一资源上获取共享锁

示例 对于 DML 事务处理 共享锁被设置为表级

 

事务处理 1

SQL> update scott.s_emp
2 set salary=salary*1.1
3 where id= 24877;
1 row updated.

 

事务处理 2

SQL> update scott.s_emp
2 set salary=salary*1.1
3 where id= 24878;
1 row updated.

 

两个事务处理更新同一个表中的行

 

锁的持续时间

事务处理一直持有锁 直到它们提交或回退为止

示例

事务处理 1

 

SQL> update scott.s_emp
2 set salary=salary*1.1
3 where id= 24877;
1 row updated.
SQL> commit;
Commit complete.

 

事务处理 2

SQL> update scott.s_emp
2 set salary=salary*1.1
3 where id= 24877;
Transaction 2 waits.
1 row updated.

 

事务处理 1 一提交 事务处理 2 就可以更新行 因为事务处理获取了所请求的锁。

 

锁的类型

DML 锁

多个用户并发地访问数据时 可以使用 DML 锁以保证数据的完整性 锁防止由同时的 冲突的 DML 和 DDL 操作引起的破坏性干扰 DML 锁提供两个级别的锁

表级锁 TM 类型 为任何修改表的 DML 事务处理设置 INSERT UPDATE DELETE SELECT…FOR UPDATE 或 LOCK TABLE 表锁防止 与该事务处理冲突的 DDL 操作

 

示例

事务处理 1

SQL> UPDATE s_emp
2 SET salary=salary*1.1;
13120 rows updated.

 

事务处理 2

SQL> DROP TABLE s_emp;
ERROR at line 1:
ORA-00054:resource busy and
acquire with NOWAIT specified

 

为 INSERT UPDATE DELETE 或 SELECT…FOR UPDATE 更改的每个行 自动地获得行级 锁 TX 类型 行级锁定确保没有其他用户可以同时更改相同的行 因此 不存在用户修改这样的行的危险 其他用户正在修改
该行且仍未提交

示例

事务处理 1

SQL> update scott.s_emp
2 set salary=salary*1.1
3 where id= 24877;
1 row updated.

 

事务处理 2

SQL> update scott.s_emp
2 set salary=salary*1.1
3 where id= 24877;
Transaction 2 waits.

 

DDL 锁

在一个正在进行的 DDL 操作执行或引用方案对象的同时， DDL 锁保护该方案对象的定义。 Oracle 服务器自动地获取 DDL 锁，以防止任何对其它 DDL 操作的破坏性干涉，这些操作可能修改或引用同一方案对象。

 

DML 锁

• 一个 DML 事务处理至少需要两个锁:
  • 一个共享的表锁定
  • 一个专用的行锁
• 这种入队机制保持跟踪:
  • 等待锁的用户
  • 所请求的锁模式
  • 用户请求此锁的顺序

DML 事务处理至少获取两个锁

有两种锁结构用于 DML 语句 INSERT UPDATE DELETE SELECT…FOR UPDATE
事务处理获取在表上的共享锁 无论是什么类型的共享锁模式 ，都称为TM 锁。

事务处理在其正在更改的行上获取一个排它锁， 称为 TX 锁 。每个行会使该行标题中的一个锁字节开启 该标题指向由事务处理使用的， 感兴趣的事务处理列表 (ITL) 插槽。 行级锁定模式只能是排它的

 

入队机制

Oracle 服务器将所有的锁作为入队 来维护 入队机制可以跟踪

• 等待由其他用户持有的锁的用户
• 这些用户需要的锁定模式
• 用户请求锁的顺序

如果三个用户同时希望更新同一个行 他们都会获得共享表锁 但是只有一个
用户,即第一个用户,可以获得行锁 .表锁定机制会跟踪谁持有行锁,以及谁在等待行锁。
通过增加参数 DML_LOCKS 和 ENQUEUE_RESOURCES，可增加可用于例程的总锁数。 这在并行服务器配置时是必要的

表锁定模式

自动获取:

• 行专用 (RX): INSERT, UPDATE, DELETE
• 行共享 (RS): SELECT…FOR UPDATE

 

自动表锁定模式自动表锁定模式通常看到由 DML 事务处理持有的两个 TM 表锁定模式， RX 和 RS 。这些是由Oracle 服务器自动分配给 DML 事务处理的表锁定模式。

表锁定模式的限制， 决定了在同一表中获得和持有其它表锁的模式。

 

专用行 (RX)

• 允许其它事务处理并发地查询、插入、 更新、 删除或锁定在相同表中的其他行。
• 阻止其它事务处理手动地锁定表 以便进行独占式读写。

示例

事务处理 1 持有 RX 表锁
SQL> update s_emp
2 set salary=salary*1.1
3 where id= 24877;
1 row updated.

 

事务处理 2 持有 RX 表锁

SQL> update s_emp
2 set salary=salary*1.1
3 where id= 24878;
1 row updated

 

Row Share (RS)
可以使用 SELECT…FOR UPDATE 语句 在查询期间选择锁定行 这阻止其它 事务处理手动地锁定表 以便进行独占式写入访问

示例

Transaction 1 (RS table lock held)

SQL> select id,salary
2 from s_emp
3 where id=24877
4 for update;
ID SALARY
——— ———
24877 1100
SQL> commit;
Commit complete.

 

Transaction 2 (X table lock requested)

SQL> lock table s_emp
2 in exclusive mode;
Transaction 2 waits.
Table(s) Locked.

手动锁定模式

通过显式 LOCK TABLE 命令 手动地分配三个其它表锁定模式

SQL> LOCK TABLE s_emp IN exclusive MODE;
Table(s) Locked.

使用显式锁定往往有较好的应用理由 但如果遇到锁争用 则可能需要与开发人员联系
后台开发人员 (而非 Oracle 开发人员),有时使用的锁定级别过高 这是不必要的。

 

共享 (S)

• 仅允许其它事务处理查询表 (SELECT …FOR UPDATE)
• 防止对表的任何修改

隐式获得 共享 锁的 SQL 语句受到引用完整性约束条件的限制 在子表中
如果没有对外键列的索引 那么

• 父级上的任何 DELETE 都持有子级上的 共享 锁
• 父级引用列上的任何 UPDATE 都持有子级的 共享 锁

 

该行为的原因是，当子行持有在任何相关的表中时，其父行决不能被删除 (也决不能更新父行的主键 )锁定子表是为了防止破坏该规则的更新和插入。

示例

事务处理 1 在 （s_dept 上持有的 RX 表锁 在 s_emp 上持有的 S 表锁）

SQL> delete from s_dept
2 where id=60;
1 row deleted.
SQL> commit;
Commit complete.

 

事务处理 2 (请求 RX 表锁）

SQL> update s_emp
2 set salary=salary*1.1
3 where id=24877;
Transaction 2 waits.
1 row updated.

 

为了避免该行为 ，请在引用 （子） 表中设置外键列索引。

如果在子表中索引外键， 则通过锁定索引中被更改的值 ，Oracle 服务器可以防止对子行的更改

示例

事务处理 1 （持有 RX 表锁)

SQL> delete from s_dept
2 where id=60;
1 row deleted.

 

事务处理 2 (持有 RX 表锁)

SQL> create index i on s_emp
2 (dept_id);
Index created.

 

SQL> update s_emp
2 set salary=salary*1.1
3 where id=24877;
1 row updated.

 

表锁定模式

 

• 在 LOCK 语句中手动获取:
• 共享行专用 (SRX)
  • 不允许 DML 或共享模式
  • 隐式地用于引用完整性
• 专用 (X)

 

共享行排它 (SRX)
这种锁定模式防止其它语句获取 DML 或手动共享锁。
再次隐式地获得 共享行排它 锁的 SQL 语句涉及引用完整性 。在下述情况下，当在父表中执行 DELETE 时 需要子级的 共享行排它 锁定

• 外键约束条件包含 ON DELETE CASCADE
• 在子表中 没有对外键列的索引

示例

事务处理 1 （持有 s_dept 上的 RX 表锁 持有 s_emp 上的 SRX 表锁）

SQL> delete from s_dept
2 where id=60;
1 row deleted.
SQL> commit;
Commit complete.

 

事务处理 2 （请求 RX 表锁）

SQL> update s_emp
2 set salary=salary*1.1
3 where id=24877;
Transaction 2 waits.
1 row updated.

 

同样 该解决方案用于在子表中索引外键列。

 

排它 (X)

这是表锁的最高级别 因此是限制最多的模式 排它锁：

• 只允许其它事务处理查询表
• 防止任何类型的 DML 语句和任何手动锁定模式

示例

事务处理 1 （持有 X 表锁）

SQL> lock table s_dept in exclusive
mode;
Table(s) Locked.

 

事务处理 2 （请求 RS 表锁）

SQL> select * from s_dept
2 for update;
Transaction 2 waits.

 

块中的行级锁定

事务处理提交时 ，不清除块中的行级锁定的锁定信息 ，而是在下一个查询读取块时清除 。这称为延迟的块清除。

执行清除的查询 ，必须检查事务处理的状态 ，以及事务处理表中的系统更改序号 (SCN) 事务处理表持有在回退段标题中。

在块中 Oracle ，服务器在块标题中为每个活动的事务处理持有标识符 。在行级 锁字节为包含事务处理的插槽存储一个标识符。

DDL 锁

• 专用 DDL 锁:
  • DROP TABLE 语句
  • ALTER TABLE 语句
• 共享 DDL 锁:
  • CREATE PROCEDURE 语句
  • AUDIT 语句
• 可分开的分析锁: 使共享 SQL 区域无效

 

DDL 锁

不大可能看到 DDL 锁的争用，因为它们仅短暂地被持有，并且应在 NOWAIT模式中请求这种锁。共有三种类型的 DDL 锁。

排它 DDL 锁

一些 DDL 语句 ，如 CREATE、 ALTER 及 DROP ，必须在它们正在工作的对象上获取一个排它锁。

一些 DDL 语句 如 CREATE ALTER 及 DROP 必须在它们正在工作的对象上获取一个排它锁， 用户就无法在该表上获取排它锁，所以， 如果有用户在表上有未提交的事务处理， ALTER TABLE 语句就会
失败。
示例

事务处理 1

SQL> UPDATE s_emp
2 SET salary=salary*1.1;
3120 rows updated.

 

事务处理 2

SQL> ALTER TABLE s_emp
2 DISABLE primary key;
ORA-00054:resource busy and
acquire with NOWAIT specified

 

注 ：使用本地管理的表空间而不是字典管理表空间 ， 可以消除对 ST 空间事务处理 锁的争用， 因为在请求空间配置时， 本地管理的表空间不更新数据字典中的表。

共享 DDL 锁

共享 DDL 锁 不阻止类似的 DDL 语句或任何 DML 但阻止其他用户改变或删除引用的对象。

一些语句 如 GRANT 和 CREATE PACKAGE 需要在它们引用的对象上有共享 DDL 锁。

易碎的分析锁

易碎的分析锁 用于检查对象更改时语句是否应失效。

在库高速缓存中的一个语句或 PL/SQL 对象， 在库高速缓存中的一个语句或 PL/SQL 对象， 直到语句从共享池中超龄释放为止。

可以把该锁看作一个指针 。 可以把该锁看作一个指针 。

 

锁争用

Oracle 服务器锁花费不多但效率高 ， 多数站点没有锁定的问题。  如果锁导致争用， 经常是因为：

• 开发人员用不必要的高锁定级别编写代码
• 开发人员不必要的长的事务处理编写代码
• 用户在应提交更改时未提交
• 应用程序联合使用 Oracle 服务器和其它使用较高锁定级别的产品

V$LOCK 视图

V$LOCK 视图提供有关例程中当前持有的锁的信息

锁类型 ID1
TX 回退段编号和插槽编号
TM 正在被修改的表的 ID

 

示例 若要查找 V$LOCK 视图的某个特定 资源 ID 1 相应的表名称：

SQL> SELECT owner, object_id, object_name, object_type,
2 v$lock.type
3 FROM dba_objects, v$lock
4 WHERE object_id = v$lock.id1 and object_name = table_name;

 

阻塞其它进程的任何进程，很可能正持有用户应用程序获得的锁。用户应用程序获取的锁为

• 表锁 (TM)
• 行级锁 (TX)

这里未列出的其它锁为系统锁 它们仅被短暂地持有。

V$LOCKED_OBJECT 视图

锁类型 ID1
XIDUSN 回退段编号
OBJECT_ID 正被修改的对象的 ID
SESSION_ID 锁定对象的会话的 ID
ORACLE_USERNAME
LOCKED_MODE

 

示例 若要查找与 V$LOCKED_OBJECT 视图的某个特定 OBJECT_ID 相应的表名称:

SQL> select xidusn, object_id, session_id, locked_mode
2 from v$locked_object;
XIDUSN OBJECT_ID SESSION_ID LOCKED_MODE
——— ——— ———- ———–
3 2711 9 3
0 2711 7 3
SQL> select object_name
2 from dba_objects
3 where object_id = 2711;
OBJECT_NAME
————-
S_EMP

 

如果 XIDUSN 的值为 0，相应的 SESSION_ID 正在请求和等待 SESSION_ID 持有的锁， 对于 SESSION_ID XIDUSN 有非 0 的值。

 

锁管理的原则解决争用

终止会话

如果一个用户持有由另一个用户所请求的锁 则可以：

• 与持有者联系并要求该用户提交或回退事务处理
• 作为最后的手段 终止该 Oracle 用户会话 这样将回退事务处理并释放锁

上述的任何监视方法都将给出用户的会话标识符。

可以使用以下语句终止用户会话：

The ALTER SYSTEM KILL SESSION SQL command :

SQL> select sid,serial#,username
2 from v$session
3 where type=’USER’;
SID SERIAL# USERNAME
——— ——— ——————————
8 122 SYSTEM
10 23 SCOTT
SQL> alter system kill session ‘10,23’;
System altered.

解决死锁

当两个或更多用户等待彼此锁定的数据时 会出现死锁。

Oracle 服务器会自动检测死锁 并通过回退检测到有死锁的语句来解决死锁。

假设 事务处理 1 的第二个更新检测到死锁 ， Oracle 服务器回退该语句并返回消息 。 尽管导致死锁的语句回退， 但事务处理并不回退 ， 您将收到 ORA-00060 错误 。 下一个操作应为回退剩余的事务处理。

技术注释

在事务处理明显地覆盖 Oracle 服务器的缺省锁定时， 会频繁导致死锁 。 一旦检测到 ， 一旦检
测到 。

跟踪文件

死锁情况记录在 USER_DUMP_DEST 目录下的一个跟踪文件中 。 为了确定应用
程序是否存在问题， 为了确定应用程序是否存在问题。 为了确定应用程序是否存在问题。

 

 

CKPT Checkpoint Process
Signals DBWn at checkpoints and updates all the data files and control files of the database to indicate the most recent checkpoint.
At specific times CKPT starts a checkpoint request by messaging DBWn to begin writing dirty buffers. On completion of individual checkpoint requests, CKPT updates data file headers and control files to record most recent checkpoint.
See Also: Oracle Database Concepts
CKPT performs tasks such as recording and starting checkpoints, generating heartbeat redo,and completing outstanding object drop/truncate cross-instance calls.

 

Oracle CKPT checkpoint 检查点知识汇总

CKPT 检查点进程：检查点(CKPT): 在检查点传送信号给DBWn, 并且更新数据库的所有数据文件及控制文件，以指示最近的检查点。当出现检查点时，所有确认的交易所造成的变更，都会被写入磁盘中数据文件。

 

检查点

LGWR 后台进程在一个周期中依次写入重做日志组
当一个组写满时 Oracle 服务器必须执行检查点 这意味着

DBWn 将全部或部分的坏块写入到数据文件 正在进行检查的日志会记录这些坏块
CKPT 更新数据文件标题和控制文件

虽然检查点产生许多磁盘写入 但检查点通常允许其它工作同时继续执行 如果 DBWn 进程没有完成对文件的检查 并且 LGWR 还需要该文件 则 LGWR
必须等待频繁的检查点意味着例程恢复时间更短 但也意味着 DBWn 写入 到数据文件 和 CKPT 写入 到数据文件标题 会增多 您的选择取决于恢复时间和运行时性能的优先级

 

后台进程和恢复：检查点 (CKPT)

CKPT 负责：

• 在检查点向 DBWn 发出信号
• 使用检查点信息更新数据文件头
• 使用检查点信息更新控制文件

要了解实例恢复，需要了解特定后台进程的功能。
每隔三秒（或频率更高），CKPT 进程就在控制文件中存储一次数据，以记录 DBWn 从SGA 写入到磁盘的已修改数据块。这就称为“检查点”。检查点的用途是标识联机重做日志文件开始进行实例恢复的位置（这个位置称为“检查点位置”）。
如果使用日志切换，CKPT 进程还会将这个检查点信息写入到数据文件头。使用检查点的原因如下：

• 确保定期将内存中的已修改数据块写入磁盘，以便在系统或数据库出现故障的情况下不会丢失数据
• 减少实例恢复所需的时间。在进行恢复时只需处理跟在最后一个检查点后面的联机重做日志文件
• 确保在关闭过程中所有已提交数据都写入到数据文件中

由 CKPT 进程写入的检查点信息包括检查点位置、系统更改号、联机重做日志文件中开始恢复的位置、关于日志的信息等等。

注：CKPT 进程并不将数据块写入到磁盘，也不将重做块写入到联机重做日志文件。

检查点优化原则

 

• 确定联机重做日志文件的大小以削减检查点数
• 添加联机重做日志组以延长 LGWR 开始重写之前的时间
• 用初始化参数控制检查点:
– FAST_START_IO_TARGET
– LOG_CHECKPOINT_INTERVAL
– LOG_CHECKPOINT_TIMEOUT
– DB_BLOCK_MAX_DIRTY_TARGET

 

监视检查点的频率

可以检查 alert.log 文件中日志切换的次数

同样 检查该文件是否有 Checkpoint not complete; unable to allocate file. 的错误消息 这些消息表示 LGWR 等待检查点的完成
如果系统统计 已启动的后台检查点 和 已完成的后台检查点 的值相差超过 1 则日志切换之间的检查点没有完成 您需要更大的日志文件
可以设置 LOG_CHECKPOINTS_TO_ALERT 参数 以便将检查点的开始和结束时间都记录在 alert.log 文件中
在 report.txt 中 DBWn 检查点写入请求 统计表明检查点发送到 DBWn的次数 如果每个事务都有大量检查点 则表明产生了过多的检查点

 

调整检查点

DBWn 必须总是在每个重做日志组的结尾执行检查点 也可以用初始化参数设置检查点
注 有关检查点和快速启动检查点的完整解释 以及这些概念所涉及的所有数的全部说明 。

如果有效的性能是您需要优先考虑的因素 则应选择重做日志文件的大小 以便检查点的发生频率尚不足以导致明显的响应延迟 但又不过于频繁

对许多站点 该频率一般为每 30 分钟一次 但是根据业务需要 数据库的检查点频率可以是 2 秒到 8 小时的任何值

您可以实验不同的检查点频率 例如 如果 SGA 非常大并且检查点很少发生则 OLTP 系统可能在检查点期间发生磁盘争用 在这种情况下 较频繁的检查点会使坏块更少

注 优化 DBWn I/O 一节中将解释 DB_BLOCK_MAX_DIRTY_TARGET参数

 

 

下面的alert.log例子是： 由于轮换重做日志文件太快而导致未完成检查点
Thread 1 advanced to log sequence 1597
Current log# 2 seq# 1597 mem# 0:/users/cours/tun8_08/DATA/DISK3/
log2a.rdo
Thread 1 cannot allocate new log, sequence 1598
Checkpoint not complete

 

下面的例子是： 示例 1 数据库写入器检查点
Statistic Total Per Trans Per Logon
————————— ——- ———– ———
DBWR checkpoint buffers written 1 1 1
DBWR free buffers found 11 11 11
DBWR 检查点 表明发送给数据库写入器的检查点消息数
检查点期间数据 I/O 的增长可导致系统性能下降
您可以通过增大 init.ora 参数 LOG_CHECKPOINT_INTERVAL 和
LOG_CHECKPOINT_TIMEOUT 来减少检查点的数目和频率 然而要注意 检
查点频率低会增加数据库的恢复时间

 

 

checkpoint 分成很多种  full 、file、thread、parallel query、 object 、incremental 、logfile switch

每一种checkpoint 都有其自身的特性，例如Incremental Checkpoint会要求ckpt 每3s 更新一次controlfile 但是不更新datafile header， 而FULL CHECKPOINT要求立即完成(同步的) 且会同时更新 controlfile 和 datafile header。

各种checkpoint 的特点见下表：

Full Checkpoint

Writes block images to the database for all dirty buffers from all instances

Statistics updated:
DBWR checkpoints
DBWR checkpoint buffers written
DBWR thread checkpoint buffers written

Caused by:
Alter system checkpoint [global]
Alter database begin backup
Alter database close
Shutdown

Controlfile and datafile headers are updated
CHECKPOINT_CHANGE#

Thread Checkpoint

Writes block images to the database for all dirty buffers from one instance

Statistics updated:
DBWR checkpoints
DBWR checkpoint buffers written
DBWR thread checkpoint buffers written

Caused by:
Alter system checkpoint local

Controlfile and datafile headers are updated
CHECKPOINT_CHANGE#

File Checkpoint

Writes block images to the database for all dirty buffers for all files of a tablespace from all instances
Statistics updated:

DBWR tablespace checkpoint buffers written
DBWR checkpoint buffers written
DBWR checkpoints

Caused by:

Alter tablespace XXX offline
Alter tablespace XXX begin backup
Alter tablespace XXX read only

Controlfile and datafile headers are updated
CHECKPOINT_CHANGE#

Parallel Query Checkpoint

Writes block images to the database for all dirty buffers belonging to objects accessed by the query from all instances

Statistics updated:
DBWR checkpoint buffers written
DBWR checkpoints

Caused by:
Parallel Query
Parallel Query component of PDML or PDDL
Mandatory for consistency

Object “Checkpoint”

Writes block images to the database for all dirty buffers belonging to an object from all instances

Statistics updated:

DBWR object drop buffers written
DBWR checkpoints

Caused by:
Drop table XXX
Drop table XXX purge
Truncate table XXX
Mandatory for media recovery purposes

Incremental Checkpoint

Writes the contents of “some” dirty buffers to the database from CKPT-Q
Block images written in SCN order
Checkpoint RBA updated in SGA

Statistics updated:
DBWR checkpoint buffers written

Controlfile is updated every 3 seconds by CKPT
Checkpoint progress record

Log Switch Checkpoint(8i 以前 LOG switch checkpoint是FULL CHECKPOINT)

Writes the contents of “some” dirty buffers to the database

Statistics updated:

DBWR checkpoints
DBWR checkpoint buffers written
background checkpoints started
background checkpoints completed

Controlfile and datafile headers are updated
CHECKPOINT_CHANGE#

 

 

无论是什么类型的checkpoint 检查点 ，所有的本地检查点(CKPT)已类似的本地化方法处理。 每一个实例中所有本地的活跃检查点请求(active local checkpoint request)都保存在一个队列(queue)中，这个队列叫做 Active Checkpoint Queue。 在这个队列(queue)中的每一条记录代表一个本地检查点(local checkpoint request)。 当某一个进程( 可能是前台进程 foreground process –例如前台进程执行“alter tablespace users begin/end backup”， 也可能是CKPT 或者其他后台进程) ， 这个进程都会将新的 request 记录放到这个Active Checkpoint Queue中。 典型的一个checkpoint request 由 检查点类型checkpoint request type，优先级priority , 以及与该checkpoint request 关联的checkpoint structure， 等待进程 waiter process，  还有其余一些相关的属性如 FILE Checkpoint 的tablespace id、FILE NUMBER、 Object checkpoint的object id 等。

DBWR进程会不断地扫描这个Active Checkpoint Queue， 并服务于这个Queue上的checkpoint request 检查点请求。 一旦某个request 被完成了，DBWR 将这个request标记为completed 。 CKPT 进程也会不断监控这个  Active Checkpoint Queue 查看是否所有request都被完成了。 当CKPT发觉一个checkpoint request完成了， CKPT会将这个request从 Active Checkpoint Queue中移除。  取决于不同的检查点种类和目的， 当一个本地检查点(local checkpoint)完成，这意味着 某些特定的磁盘上的数据结构被更新，以反映这个检查点完成的物理表现。 这个操作 或者由 直接CKPT完成， 或者由提交checkpoint request的 等待进程直接完成， 或者由CKPT唤醒这个提交checkpoint request的等待进程间接地完成，以上具体由谁来完成操作 取决于检查点种类和目的。

 

图解Low RBA, Thread Checkpoint Queue, File Checkpoint Queue