11g ocp ocm考证信息

 

11g ocm 相关博文:

 

数据库恢复的配置 https://www.askmaclean.com/archives/11g-ocm-student-guide-backup-restore.html
配置备份的规范 https://www.askmaclean.com/archives/dbdao-11g-oracle-ocm-2.html
使用RMAN创建备份 https://www.askmaclean.com/archives/oracle-11g-ocm-rman.html
使用RMAN执行恢复 https://www.askmaclean.com/archives/oracle-11g-ocm-master-rman-restore.html
SPA https://www.askmaclean.com/archives/oracle-11g-ocm-spa.html
SQL执行计划管理 https://www.askmaclean.com/archives/oracle-11g-ocm-spm.html
grid control 架构 https://www.askmaclean.com/archives/oracle-11g-ocm-grid-control-architecture.html
grid control 安装 https://www.askmaclean.com/archives/oracle-11g-ocm-grid-control-install.html
配置EMGC https://www.askmaclean.com/archives/oracle-11g-ocm-setemgc.html
Oracle Data Guard 介绍 https://www.askmaclean.com/archives/oracle-11g-ocm-dg.html
使用SQL和RMAN命令来创建一个物理备库 https://www.askmaclean.com/archives/oracle-11g-ocm-create-dg.html
oracle Data Guard Broker:概述 https://www.askmaclean.com/archives/oracle-data-guard-broker.html
配置 DataGuard 保护模式 https://www.askmaclean.com/archives/oracle-11g-ocm-data-mode.html
grid 安装 https://www.askmaclean.com/archives/oracle-11g-install-grid.html
管理Oracle 集群 https://www.askmaclean.com/archives/oracle-11g-ocm-manage-clusterware.html
RAC数据库安装 https://www.askmaclean.com/archives/oracle-11g-ocm-rac-install.html
数据库安全与审计 https://www.askmaclean.com/archives/oracle-11g-ocm-audit.html
物化视图和分区表 https://www.askmaclean.com/archives/oracle-11g-ocm-materializedview.html
并行和传输表空间 https://www.askmaclean.com/archives/oracle-11g-ocm-parallel.html
SQL*Loader和外部表 https://www.askmaclean.com/archives/oracle-11g-ocm-sqlloader.html
手动建库和基本数据库管理 https://www.askmaclean.com/archives/oracle-11g-ocm-createdatabase.html

 

11g OCP 考试题库中英分析:

【诗檀学院】Oracle 11g OCP-051考试题库中英文对照详解

【诗檀学院】Oracle 11g OCP-052考试题库中英文对照详解

【诗檀学院】Oracle 11g OCP-053考试题库中英文对照详解

 

Oracle Lock 监视和检测锁争用

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 目录下的一个跟踪文件中 。 为了确定应用
程序是否存在问题, 为了确定应用程序是否存在问题。 为了确定应用程序是否存在问题。

 

 

Oracle CKPT checkpoint 检查点知识汇总

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

checkpoint_file_queue.png

 

ODM FINDING:
Understand SCN movement during online user managed backup;
Before online backup, check current scn, system and datafile scn in controlfile and scn in datafile header.

As expected checkpoint scn are same in controlfile and datafile headers, and it is behind current scn.

SQL> select current_scn, checkpoint_change# from v$database;

CURRENT_SCN CHECKPOINT_CHANGE#
———– ——————
325011036          325009912

SQL> select name,checkpoint_change# from v$datafile;

NAME                                               CHECKPOINT_CHANGE#
————————————————– ——————
+DBA_DATA/dbaprd/datafile/system.270.675355175              325009912
+DBA_DATA/dbaprd/datafile/sysaux.269.675355177              325009912
+DBA_DATA/dbaprd/datafile/undotbs1.266.675355179            325009912
+DBA_DATA/dbaprd/datafile/undotbs2.264.675355187            325009912
+DBA_DATA/dbaprd/datafile/users.263.675355189               325009912
+DBA_DATA/dbaprd/datafile/xml_data.262.675355189            325009912

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

NAME                                               CHECKPOINT_CHANGE#
————————————————– ——————
+DBA_DATA/dbaprd/datafile/users.263.675355189               325009912

Start online tablespace backup

Oracle did a checkpoint on USERS tablespace and datafile only, and freeze the checkpoint scn on datafile header.

SQL> alter tablespace users begin backup;

Tablespace altered.

SQL> select current_scn, checkpoint_change# from v$database;

CURRENT_SCN CHECKPOINT_CHANGE#
———– ——————
325011196          325009912

SQL>  select name,checkpoint_change# from v$datafile;

NAME                                               CHECKPOINT_CHANGE#
————————————————– ——————
+DBA_DATA/dbaprd/datafile/system.270.675355175              325009912
+DBA_DATA/dbaprd/datafile/sysaux.269.675355177              325009912
+DBA_DATA/dbaprd/datafile/undotbs1.266.675355179            325009912
+DBA_DATA/dbaprd/datafile/undotbs2.264.675355187            325009912
+DBA_DATA/dbaprd/datafile/users.263.675355189               325011168
+DBA_DATA/dbaprd/datafile/xml_data.262.675355189            325009912

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

NAME                                               CHECKPOINT_CHANGE#
————————————————– ——————
+DBA_DATA/dbaprd/datafile/users.263.675355189               325011168

during the online backup checkpoint scn is freeze on datafile belongs to USERS tablespace

SQL> alter system checkpoint;

System altered.

SQL> select current_scn, checkpoint_change# from v$database;

CURRENT_SCN CHECKPOINT_CHANGE#
———– ——————
325011272          325011243

SQL>  select name,checkpoint_change# from v$datafile;

NAME                                               CHECKPOINT_CHANGE#
————————————————– ——————
+DBA_DATA/dbaprd/datafile/system.270.675355175              325011243
+DBA_DATA/dbaprd/datafile/sysaux.269.675355177              325011243
+DBA_DATA/dbaprd/datafile/undotbs1.266.675355179            325011243
+DBA_DATA/dbaprd/datafile/undotbs2.264.675355187            325011243
+DBA_DATA/dbaprd/datafile/users.263.675355189               325011168
+DBA_DATA/dbaprd/datafile/xml_data.262.675355189            325011243

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

NAME                                               CHECKPOINT_CHANGE#
————————————————– ——————
+DBA_DATA/dbaprd/datafile/users.263.675355189               325011168

END online tablespace backup;

Oracle advanced checkpoint scn on USERS tablespace and datafile only to be same as system checkpoint scn

SQL> alter tablespace users end backup;

Tablespace altered.

SQL> select current_scn, checkpoint_change# from v$database;

CURRENT_SCN CHECKPOINT_CHANGE#
———– ——————
325011488          325011243

SQL> select name,checkpoint_change# from v$datafile;

NAME                                               CHECKPOINT_CHANGE#
————————————————– ——————
+DBA_DATA/dbaprd/datafile/system.270.675355175              325011243
+DBA_DATA/dbaprd/datafile/sysaux.269.675355177              325011243
+DBA_DATA/dbaprd/datafile/undotbs1.266.675355179            325011243
+DBA_DATA/dbaprd/datafile/undotbs2.264.675355187            325011243
+DBA_DATA/dbaprd/datafile/users.263.675355189               325011243
+DBA_DATA/dbaprd/datafile/xml_data.262.675355189            325011243

9 rows selected.

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

NAME                                               CHECKPOINT_CHANGE#
————————————————– ——————
+DBA_DATA/dbaprd/datafile/users.263.675355189               325011243

Oracle中终止会话KILL SESSION

Oracle中终止会话KILL SESSION

 

终止会话:

将例程置于受限模式后,在执行管理任务前可能想终止所有当前用户会话。此操作可通过以下命令来实现:

ALTER SYSTEM KILL SESSION ‘integer1,integer2’

其中:

  • integer1:V$SESSION 视图中的 SID 列的值
  • integer2:V$SESSION 视图中的 SERIAL# 列的值

注:会话 ID 和序列号用来唯一地标识会话。这样,即使用户注销身份并且新会话使用相
同的会话 ID,也可确保 ALTER SYSTEM KILL SESSION 命令能够应用于正确的会话。

终止会话的影响:

ALTER SYSTEM KILL SESSION 命令一执行,将使后台进程 PMON 立即执行以下步骤:

  • 回退用户的当前事务
  • 释放所有当前持有的表或行锁定
  • 释放用户当前保留的所有资源

终止特定实例上的会话

从 Oracle RAC 11gR1 开始,可以使用 ALTER SYSTEM KILL SESSION 语句终止特定实例上的会话。

幻灯片通过以下方式对此进行了说明:在另外一个不同于终止有问题会话的实例上,终止一个已启动的会话。

如果会话正在执行某个必须完成的活动(例如等待来自远程数据库的答复或者回退事务处理)则 Oracle DB 必须等待该活动完成,将该会话标记为“已终止”,然后将控制权返回给您。如果等待持续一段时间,则 Oracle DB 会将该会话标记为“待终止”并将控制权返回给您,同时向您发送一条消息说明会话被标记为“待终止”。然后,PMON 后台进程会在该活动完成后将该会话标记为“已终止”。

注:还可以在 ALTER SYSTEM 命令的末尾使用 IMMEDIATE 子句以便立即终止会话而不等待未完成活动完成。

 

 

SQL> SELECT SID, SERIAL#, INST_ID
  FROM GV$SESSION WHERE USERNAME='JFV';
SID    SERIAL#    INST_ID   
140       3340          2


SQL> ALTER SYSTEM KILL SESSION '140,3340,@2';
System altered.

SQL>


 

 

 

Oracle Archived log 归档重做日志/归档日志详解

Oracle Archived log 归档重做日志/归档日志详解

 

V$ARCHIVED_LOG
此视图显示包含归档日志名的控制文件中的归档日志信息 在联机重做日志成
功归档或清除后会插入归档日志记录 如果已清除日志 则名称列为
NULL 如果日志归档两次 将产生两个归档日志记录 它们具有相同的
THREAD# SEQUENCE# 和 FIRST_CHANGE# 但名称不同 使用备份集或
副本恢复归档日志后 也会插入归档日志记录

RECID 归档的日志记录 ID
STAMP 归档的日志记录标记
NAME 归档的日志文件名 如果设置为 NULL 则日志文件在归
档前被清除
THREAD# 重做线程编号
SEQUENCE# 重做日志序列号
RESETLOGS_
CHANGE#
写入此日志时数据库的重置日志更改 #
RESETLOGS_TIME 写入此日志时数据库的重置日志时间
FIRST_CHANGE# 归档日志中的第一更改 #
FIRST_TIME 第一更改的时间标记
NEXT_CHANGE# 下一日志中的第一更改
NEXT_TIME 下一更改的时间标记
BLOCKS 块中归档日志的大小
BLOCK_SIZE 重做日志块大小
COMPLETION_TIME 归档完成时的时间
DELETED YES/NO

V$ARCHIVE_PROCESSES

 

PROCESS 例程的 ARCH 进程标识符 编号为 0 至 9
STATUS ARCH 进程的状态 显示为一个关键字 可能的值有
STOPPED SCHEDULED STARTING ACTIVE
STOPPING 和 TERMINATED
LOG_SEQUENCE 这是当前正在归档的联机重做日志序列号 如果 STATE=BUSY
STATE 这是 ARCH 进程的当前状态 显示为一个关键字 可能的关键字为 IDLE 或 BUSY

 

归档日志文件配置

 

如果要归档 重要的是要有两个以上的重做日志组 当一个组切换到另外一个组时 DBWn 进程必须同往常一样进行检查 并且必须将一个文件归档 在LGWR 进程需要再次覆盖该文件之前 必须为上述两个操作留出时间

调整归档速度

有时 在非常繁忙的数据库中 单个 ARC0 进程跟不上写入重做日志的大量信息 Oracle8i 允许数据库管理员通过使用LOG_ARCHIVE_MAX_PROCESSES 参数 定义多个归档进程

只要当前的 ARCn 进程数不足以处理工作量 LGWR 进程就会启动新的ARCn 进程 如果预计有繁重的归档工作量 可通过运行下述命令 手动启动共享该工作的服务器进程
SQL>ALTER SYSTEM ARCHIVE LOG ALL TO ‘directory_name‘;

应监视 V$ARCHIVE_PROCESSES 以便任何时候 只要有两个以上的日志
需要归档 它就发出警报并产生额外的归档程序进程

 
SQL> select * from v$archive_processes;
PROCESS STATUS LOG_SEQUENCE STAT
——— ———- ———— —-
0 ACTIVE 122 BUSY
1 ACTIVE 0 IDLE
2 STOPPED 0 IDLE

 


当初始化参数 DBWR_IO_SLAVES 设置为大于 0 的值时 为归档重做日志
文件而由 ARC0 进程使用的多个 I/O 从属将自动设置为 4

不能在原始设备上创建归档重做日志文件

有关 LOG_ARCHIVE_MAX_PROCESSES, LOG_ARCHIVE_DEST_n, 和
LOG_ARCHIVE_DEST_STATE_n 参数的全面解释 请参照 Oracle8i 备份和恢复 课程的第 2 课

LOG_ARCHIVE_DEST_n 参数仅在已经安装了 Oracle 企业版时才有效 如果已经安装了 Oracle 企业版 则可以继续使用 LOG_ARCHIVE_DEST 但不能同时使用 LOG_ARCHIVE_DEST_n 和 LOG_ARCHIVE_DEST 因为它们不兼容

 

获得有关已归档日志文件及其位置的信息
若要从控制文件显示归档日志信息 包括归档日志名称 可以查询
V$ARCHIVED_LOG 动态性能视图 在联机重做日志已成功归档或清除 如果日志已清除 名称栏则为 NULL 之后 即会插入归档日志记录 如果日志归档两次 将产生两个归档日志记录 它们具有相同的 THREAD# SEQUENCE#和 FIRST_CHANGE# 但名称不同

对于当前的例程 动态性能视图 V$ARCHIVE_DEST 描述所有的归档日志目标 它们的当前值 模式和状态

Oracle Redo Online Logfile 重做在线日志

Oracle Redo Online Logfile 重做在线日志负责:

  • 记录数据库变更
  • 应该多路复用以避免遗失

 

重做日志文件是用来记录数据库的变更情形,而这些变更源自事务及内部Oracle是数据库服务器操作。

 

注意:【事务(Transaction)】是工作的逻辑单元,它是由的单一使用者所执行的一或多个SQL命令组成。当发生电源中断、从磁盘错误等问题时,重做日志文件能保护数据库以避免损坏完整性。平时应该多路复用重做日志文件,以确保在磁盘发生错误的时候,不至于遗失储存在其中的信息。

 

重做日志是由一组组的重做日志文件构成,而每个重做日志文件组则是由一个重做日志文件及其多重备份的副本组成。每个完全相同的副本是该组的成员之一。而每个组是透过一组号码来识别。日志写入器进程(LGWR)会从重做日志缓冲区讲重做记录写入重做日志组,一直到组中的文件被填满,或是出现日志切换要求为止。接着写入器就会进行切换,然后写入下一个组的文件中。重做日志组是以循环方式来使用的。

 

您可以查看数据库中重做日志文件的相关信息,请在【服务器(Server)】页面的【存储(Storage)】区中按一下【重做日志组(Redo Log Groups)】链接。您可以选择一个组,再按【查看(View)】来查看各种详细信息,例如重做日志文件名称。

 

 

 

多路复用重做日志

 

您可以在现有的日志组中新增一个成员,制作重做日志的多路复用。请按照下列步骤执行,将成员新增到重做日志组中:

  1. 在【服务器(Server)】页面的【存储(Storage)】区中按一下【重做日志组(Redo Log Groups)】。会出现【重做日志组(Redo Log Groups)】页面。
  2. 选择一个组,再按一下【编辑(Edit)】,或是按一下组的编号链接。接着会出现【编辑重做日志(Edit Redo Log)】.
  3. 在【重做日志成员(Redo Log Members)】区按一下【添加(Add)】。会出现【添加重做日志成员(Add Redo Log Member)】页面。
  4. 输入文件名称与文件目录。按一下【继续(Continue)】。之后点【应用(Apply)】。

 

 

注意: 建议您在不同的磁盘上储存成员,以免重做日志项目因磁盘失败事件而全部遗失。

  1. 为每个现有大的日志组重复执行这些步骤。

 

当您将重做日志成员加入日志组时,组的状态会标示为INVALID,这是因为此组的成员还没有被写入。当发生日志切换,而无效日志组成为当前组时,,状态就会变为CURRENT。

 

丢失了重做日志文件

 

丢失了单个重做日志组成员后进行恢复并不会影响运行的实例。要执行这种恢复,请执行以下步骤:

1. 检查预警日志,确定是否有缺失的日志文件。

2. 通过以下方式恢复缺失的文件,先删除丢失的重做日志成员:

SQL> ALTER DATABASE DROP LOGFILE MEMBER ‘redo01a.log’;

然后添加新的成员以替换丢失的重做日志成员:

SQL> ALTER DATABASE ADD LOGFILE MEMBER ‘redo01a.log’
TO GROUP 2;

注:如果使用的是重做日志文件的 OMF,并使用上述语法将新重做日志成员添加到现有组,则此新的重做日志成员文件不会是 OMF 文件。如果要确保新的重做日志成员是 OMF 文件,最简便的恢复方式是新建一个重做日志组,然后删除缺少重做日志成员的重做日志组。

3. 如果介质故障是由于丢失了磁盘驱动器或控制器造成的,请重命名缺失文件。

 

4. 如果重做日志组已归档,或者您处于 NOARCHIVELOG 模式下,则可选择在清除日志 组后重新创建缺失文件来解决问题。选择相应的组,然后选择“Clear Logfile(清除 日志文件)”操作。还可以使用以下命令手动清除受影响的组:

 

SQL> ALTER DATABASE CLEAR LOGFILE GROUP #;

注:Database Control 不允许清除尚未归档的日志组。这样做会打断重做信息链。如果必 须清除未归档的日志组,则应立即执行整个数据库完全备份。否则,在发生其它故障的 情况下,会导致数据丢失。要清除未归档的日志组,请使用以下命令:

 

SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP #;

 

日志写入程序 (LGWR) 将重做日志缓冲区中注册的更改写入重做日志文件

在重做日志缓冲区中 服务器进程记录将要对回退和数据进行的更改

  •  回退块更改记录数据修改以前的值 回退块用于存储成图象前的数据以便必要的情况下 DML 语句能够回退
  • 数据块更改记录数据的新值

 

归档程序进程

其它所有的后台进程都是可选的 这取决于数据库的配置 但是 其中的ARC0 对于磁盘丢失后的数据库恢复起着至关重要的作用 当联机重做日志文件填满时 Oracle 服务器开始写入下一个联机重做日志文件 从一个重做日志到另一个的切换过程称为日志切换

将重做日志文件归档

DBA 必须做出的一个重要决策是配置数据库以 ARCHIVELOG 模式还是以NOARCHIVELOG 模式操作

 

NOARCHIVELOG 模式 在 NOARCHIVELOG 模式中 每发生一次日志切换
都会覆盖联机重做日志文件 LGWR 直到重做日志组的检查点完成才覆盖该
组 这确保当发生例程崩溃时提交的数据能够得以恢复 在例程崩溃过程中
只丢失 SGA 磁盘没有任何丢失 只有内存会丢失 例如 操作系统的崩溃引
起例程崩溃

 

ARCHIVELOG 模式 如果配置数据库使它以 ARCHIVELOG 模式运行 那么已满的联机重做日志文件的非活动组必须归档之后才能够再次使用 因为对数据库所做的更改记录在联机重做日志文件中 所以 DBA 能够使用数据文件的物理备份和归档的联机重做日志文件来恢复数据库 而不会由于任何单个出错点 包括磁盘的丢失 而丢失任何已提交数据 通常将生产数据库配置为以ARCHIVELOG 模式运行

ARC0 进程

ARC0 进程在每次日志切换时启动已满日志组的备份或归档 在日志能够重新使用之前 它自动将联机重做日志归档 以便对数据库做的所有更改得以保留这样即使磁盘驱动器破坏 DBA 也能够将数据库恢复到出错时的程度

 

重做日志文件用途

Oracle 服务器维护联机重做日志文件以使数据库中的数据丢失减到最小 重做 日志文件记录对数据库缓冲区高速缓存内数据所做的所有更改 但也有例外 例如 在直接写入情况下 重做日志文件用来在诸如例程失败的情况下恢复尚未写入数据文件的提交数 据 重做日志文件仅用于恢复

 

重做日志文件结构

数据库管理员可设置 Oracle 数据库以维护联机重做日志文件副本 来避免由于 单点故障丢失数据库信息

 

联机重做日志组

一组相同的联机重做日志文件副本称作联机重做日志组

  • LGWR 后台进程向组内所有联机重做日志文件并发写入相同信息
  • 为保证数据库的正常操作 Oracle 服务器最少需要两个联机重做日志文件组

 

联机重做日志成员

  • 组内的每个联机重做日志文件称为成员
  • 组内的每个成员都有相同的日志序列号和同样的大小 Oracle 服务器每次开始写入日志组时 都分配一个日志序列号以唯一识别每个重做日志文件 当前日志序列号存储在控制文件和所有数据文件的标题内

创建初始重做日志文件
联机重做日志组和成员的初始集是在数据库创建时创建的
下面的参数限制了联机重做日志文件的数量

  • CREATE DATABASE 命令中的 MAXLOGFILES 参数指定联机重做日志组的绝对最大数量MAXLOGFILES 的最大值和缺省值取决于您的操作系统
  • CREATE DATABASE 命令所使用的 MAXLOGMEMBERS 参数决定每个组成员的最大数量 MAXLOGMEMBERS 的最大值和缺省值取决于您的操作系统
  • LOG_FILES 初始化参数设置在运行时可以为数据库打开的日志组的当前最大数量 该参数不能超过 MAXLOGFILES

技术注释
LOG_FILES 参数在 8.1 版本内已作废以简化数据库管理

 

重做日志缓冲区和 LGWR 后台进程

Oracle 服务器将对数据库所做的所有更改连续记录到重做日志缓冲区中 重做 日志缓冲区以循环方式使用 在下列情况下 LGWR 进程将重做条目写入到被 称为当前联机重做日志组的联机重做日志组之一:

  • 当提交事务时
  • 当重做日志缓冲区三分之一满时
  • 当重做日志缓冲区内有超过 1 MB 的已更改记录时
  • 当发生超时时 每三秒钟
  • 在 DBWn 将数据库缓冲区高速缓存内的修改块写入数据文件之前

 

日志切换

LGWR 连续向联机重做日志文件写入 也就是说 当当前联机重做日志组已满 时 LGWR 开始向下一个组写入 当最后一个可用联机重做日志文件已满时 LGWR 返回到第一个联机重做日志组并再次开始写入

 

数据库管理员也可以强制日志切换 见后续部分 每次发生日志切换并且 LGWR 开始向新日志组写入时 Oracle 服务器都会指定一个所谓的日志序列号 以识别重做条目集。

当发生日志切换时 将启动一个称为检查点的事件。

日志切换 是一个事件 在该事件期间 LGWR 停止向一个联机重做日志组写入 并开始向另一个联机重做日志组写入。

 

检查点

在检查点期间:

  • DBW n 将许多由正在经历检查点事件的日志覆盖的灰数据库缓冲区写入到 数据文件中 由 DBWn 写入的缓冲区数量由参数 FAST_START_IO_TARGET 决定 如果指定了的话 这在 Enterprise DBA Part 1B: Backup and Recovery 企业 DBA 1B 部分 备份和恢复 课程 中有更详细阐述
  • 检查点后台进程 CKPT 更新所有数据文件和控制文件的标题以反映该进程已 成功完成

 

检查点可以为数据库内所有 数据文件发生或者仅为特定数据文件发生

例如 检查点可发生在下面情况中

 

• 每次日志切换时
• 当已通过正常 事务处理或者立即选项关闭例程时
• 当通过设置初始化参数 LOG_CHECKPOINT_INTERVALLOG_CHECKPOINT_TIMEOUT 和 FAST_START_IO_TARGET 强制时见后续部分
• 当数据库管理员手动请求时 见后续部分

如果初始化参数 LOG_CHECKPOINTS_TO_ALERT 设置为 TRUE 则每个检查 点信息都记录在 ALERT 文件内 该参数缺省值为 FALSE 不记录检查点

 

 

决定是否应当启用将重做日志文件归档

数据库管理员必须做的一个重要决策是数据库配置为在 ARCHIVELOG 模式下
还是在 NOARCHIVELOG 模式下操作

NOARCHIVELOG 模式 在 NOARCHIVELOG 模式下 在每次联机重做日志
文件已满并发生日志切换时 都要覆盖联机重做日志文件 直到该重做日志组
检查点完成 LGWR 才覆盖该重做日志组
ARCHIVELOG 模式 如果数据库配置为在 ARCHIVELOG 模式运行下 那么
必须将已满联机重做日志文件的不活动组归档 因为对数据库所做的所有更改
都记录在联机重做日志文件内 数据库管理员可以使用物理备份和归档的联机
重做日志文件恢复数据库 而不会丢失任何已提交数据
归档联机重做日志文件有两种方法
• 手动
• 自动

LOG_ARCHIVE_START 初始化参数表明例程启动时 使用手动还是自动归档
• TRUE 表明归档是自动的 ARCn 将在每次日志切换时启动将已满日志组归

• FALSE 缺省值 表明数据库管理员将手动 将已满重做日志文件归档 在
每次归档联机重做日志文件时 数据库管理员必须手动执行一条命令 可以
对所有或特定的联机重做日志文件进行手动归档。

获取日志组信息
若要查看联机重做日志组数量 当前日志组和序列号 请查询动态性能视图
V$THREAD Parallel Server 并行服务器 管理员对这一点尤为感兴趣
SQL> SELECT groups, current_group#, sequence#
2 FROM v$thread;
GROUPS CURRENT_GR SEQUENCE#
———- ———- ———-
2 1 689
1 row selected.
下面的查询返回控制文件中关于联机重做日志文件的信息
SQL> SELECT group#, sequence#, bytes, members, status
2 FROM v$log;
GROUP# SEQUENCE# BYTES MEMBERS STATUS
——— ———- ——– ——— ———
1 688 1048576 1 CURRENT
2 689 1048576 1 INACTIVE
2 rows selected.
下面的项是 STATUS 列的常见值

• UNUSED 表明从未对联机重做日志组进行写入 这是刚添加的联机重做日
志文件的状态
• CURRENT 表明当前的联机重做日志组 这意味着该联机重做日志组是活动

• ACTIVE 表明联机重做日志组是活动的 但是并非当前联机重做日志组 崩
溃恢复需要该状态 它可能正用于块恢复 它可能归档 也可能不归档

• CLEARING 表明在 ALTER DATABASE CLEAR LOGFILE 命令后正在将该
日志重建为一个空日志 日志清除后 其状态更改为 UNUSED

• CLEARING_CURRENT 表明正在清除当前日志文件中的已关闭线程 如果
切换时发生某些故障 如写入新日志标题时的 I/O 错误 则该日志可以停
留在该状态

• INACTIVE 表明例程恢复不再需要联机重做日志组 它可能归档 也可能不
归档
获取日志成员信息

若要获取组内所有成员的名称 请查询动态性能视图 V$LOGFILE
SQL> SELECT *
2> FROM v$logfile;
GROUP#STATUSMEMBER
—————– —————————–
1 /DISK3/log1a.rdo
2 /DISK4/log2a.rdo
STATUS 列的值可以为下列之一
• INVALID 表明该文件不可访问
• STALE 表明该文件内容不完全 例如 正在添加一个日志文件成员
• DELETED 表明该文件已不再使用
• 空白表明文件正在使用中
强制日志切换和检查点
当 LGWR 停止向一个联机重做日志组写入并开始向另一个联机重做日志组写入时 就发生了日志切换
日志切换和检查点是自动发生的事件 例如 当当前联机日志文件组已满时
但日志切换和检查点也可以强制执行
强制日志切换
可以使用下面的 SQL 命令来强制日志切换
SQL> ALTER SYSTEM SWITCH LOGFILE;
强制检查点
可以使用下面的 SQL 命令手动强制检查点
SQL> ALTER SYSTEM CHECKPOINT;

设置数据库检查点时间间隔
当数据库使用大型联机重做日志文件时 您可以通过设置以下初始化参数来设
置其它数据库检查点
• LOG_CHECKPOINT_INTERVAL
• LOG_CHECKPOINT_TIMEOUT
• FAST_START_IO_TARGET 版本 8.1 但只限于企业版
LOG_CHECKPOINT_INTERVAL 对于低于 8.1 的版本 LGWR 一写入参数
LOG_CHECKPOINT_INTERVAL 指定的块数 就启动了检查点
LOG_CHECKPOINT_INTERVAL 值在操作系统块中指定而不是在 Oracle 数据
库块中指定
无论该值如何 当从一个联机重做日志文件切换到另一个时 检查点始终发

如果该值超过实际联机重做日志文件大小 那么检查点仅在日志切换时发生
请注意将时间间隔值指定为 0 可能导致非常频繁地启动检查点 因为即使上一
个请求启动后仅对单个重做日志缓冲区写入 仍会启动新的请求
在版本 8.1 内 当指定了 LOG_CHECKPOINT_INTERVAL 后 检查点位置目标
相对于日志尾的滞后不能大于该参数指定的重做日志块数 这确保了在例程恢
复期间 需要读取不超过固定数目的重做块
LOG_CHECKPOINT_TIMEOUT 对于低于 8.1 的版本 该初始化参数值指
定了另一个检查点发生前的最大时间量 该值按秒指定 该时间从前一个检查
点启动时开始 经过该参数指定的时间量后发生另一个检查点
将超时值指定为 0 以禁用基于时间的检查点
在 8.1 版本内 当指定了 LOG_CHECKPOINT_TIMEOUT 后 该参数将检查点
位置目标设置到日志文件中的某个位置 而该日志在该参数指定的秒数前结
束 这确保了在恢复期间 需要读取的重做块数不超过与指定秒数相当的块

FAST_START_IO_TARGET 参数 FAST_START_IO_TARGET 改善了崩溃和
例程恢复的性能 该参数值越小 由于需要恢复的块就越少 因而恢复性能就
越好 该参数设置后 DBWn 更积极地将灰缓冲区写出 该参数在版本 8.1 中
引入
添加重做日志组
在某些情况下 您可能需要创建其它日志文件组 例如 添加组可以解决可用
性问题 若要创建一个新的联机重做日志文件组 请使用下面的 SQL 命令
ALTER DATABASE [database]
ADD LOGFILE [GROUP integer] filespec
[, [GROUP integer] filespec]…]
您可以通过文件说明来指定成员名称和位置 可以选择每个重做日志文件组的
GROUP 参数值 如果您省略了该参数 Oracle 服务器自动生成其值

添加重做日志成员
您可以使用下面的 ALTER DATABASE ADD LOGFILE MEMBER 命令向现有的
重做日志文件组添加新成员
ALTER DATABASE [database]
ADD LOGFILE MEMBER
[ ‘filename’ [REUSE]
[, ‘filename’ [REUSE]]…
TO {GROUP integer
|(‘filename'[, ‘filename’]…)
}
]…
请使用日志文件成员的完全指定名 否则将在数据库服务器缺省目录下创建该
文件
如果该文件已经存在 其大小必须与指定值相同 并且必须指定 REUSE 选项
您可以通过指定一个或多个组内成员或者指定组号来识别目标组

重命名重做日志文件
可以通过重命名联机重做日志文件来更改联机重做日志文件的位置 在重命名
联机重做日志文件之前 请确保新的联机重做日志文件存在 Oracle 服务器仅
更改控制文件内的指针 并不从物理上重命名或创建任何操作系统文件
下面的 ALTER DATABASE RENAME FILE 命令可更改联机重做日志文件的名

ALTER DATABASE [database]
RENAME FILE ‘filename'[, ‘filename’]…
tO ‘filename'[, ‘filename’]..

丢弃重做日志组
若要增大或者减小联机重做日志组的大小 请添加新的联机重做日志组 具有
新的大小 然后丢弃旧组
可以使用下面的 ALTER DATABASE DROP LOGFILE 命令丢弃整个联机重做日
志组
ALTER DATABASE [database]
DROP LOGFILE
{GROUP integer|(‘filename'[, ‘filename’]…)}
[,{GROUP integer|(‘filename'[, ‘filename’]…)}]…
限制
• 一个例程至少需要两组联机重做日志文件
• 无法丢弃活动组或者当前组
• 如果数据库运行在 ARCHIVELOG 模式下并且未将日志文件组归档 那么无
法丢弃该组
• 在丢弃联机重做日志组时 并没有删除操作系统文件
您可能因为一个联机重做日志成员状态为 INVALID 而想丢弃它 如果您想丢弃
一个或者多个特定的联机重做日志成员 请使用下面的 ALTER DATABASE
DROP LOGFILE MEMBER 命令
ALTER DATABASE [database]
DROP LOGFILE MEMBER ‘filename'[, ‘filename’]…
限制
• 如果要丢弃的是组内的最后一个有效成员 那么您不能丢弃该成员
• 如果该组是当前组 那么在能够丢弃该成员之前 您必须强制日志文件切

• 如果数据库正运行在 ARCHIVELOG 模式下并且未将该成员所属日志文件组
归档 那么您无法丢弃该成员
• 在丢弃联机重做日志成员时 并未删除操作系统文件
清除联机重做日志文件
如果一个重做日志文件的所有成员都已破坏 数据库管理员可以通过重新初始
化这些日志文件来解决该问题
SQL 命令 ALTER DATABASE CLEAR LOGFILE 重新初始化联机重做日志文

ALTER DATABASE [database]
CLEAR [UNARCHIVED] LOGFILE
{GROUP integer|(‘filename'[, ‘filename’]…)}
[,{GROUP integer|(‘filename'[, ‘filename’]…)}]…

使用该命令等效于添加和丢弃联机重做日志文件 但即使只有两个日志组 每
个组内只有一个文件 并且即使已清除组可用但没有归档 您仍可以发出该命令
限制
无论联机重做日志文件是否归档 您都可以清除它 但是 在其没有归档时
您必须包含关键字 UNARCHIVED 如果恢复需要该联机重做日志文件 这将
使得备份不可用

联机重做日志文件数量

要确定一个数据库例程的联机重做日志文件的合适数量 您必须测试不同的配置
在某些情况下 数据库例程可能只需要两个组 在其它情况下 数据库例程可
能需要其它组以保证组始终可供 LGWR 使用 例如 如果 LGWR 跟踪文件或
者 ALERT 文件中的消息表明 LGWR 经常不得不因为检查点尚未完成或者组尚
未归档而等待 您就需要添加组
尽管 Oracle 服务器允许多路复用的组包含不同数量的成员 但请尽量建立对称
配置 不对称配置应仅是非常情况 如磁盘故障 的临时结果
联机重做日志文件位置
在多路复用联机重做日志文件时 请将组内的成员放置在不同磁盘上 这样即使一个成员不可用而其它成员可用 该例程也不会关闭将归档日志文件和联机重做日志文件分隔在不同磁盘上 以减少 ARCn 和LGWR 后台进程之间的争用
数据文件和联机重做日志文件应当放置在不同的磁盘上以减少 LGWR 和 DBWn
的争用 并减少在发生介质失败事件时同时丢失数据文件和联机重做日志文件
的风险
调整联机重做日志文件的大小
联机重做日志文件的大小最小为 50 KB 最大大小因操作系统而定 不同组的
成员可以有不同的大小 但是 大小不同的组不会带来任何好处
应当仅在想更改联机重做日志组内成员的大小时才需要大小不同的组作为临时
结果 在这种情况下 您必须创建新的大小不同的联机重做日志组 然后删除
旧组
下面的情况可能影响联机重做日志文件的配置
• 日志切换和检查点的数量
• 重做条目的量和个数
• 存储介质的空间量 例如 启用归档时磁带上的空间量
不可用重做日志成员

当某些联机重做日志成员不可用时 LGWR 反应不一
• 如果 LGWR 至少能够访问一个组内成员 对组内可访问成员的写入将照常
进行 LGWR 忽略组内的不可用成员 如果该组不活动 即检查点已完
成 那么丢弃和添加一个新的重做日志成员就可以解决问题 否则 您必
须首先强制日志切换
• 如果在日志切换时 LGWR 无法访问下一个组的所有成员 则该例程关闭
如果组不活动 那么丢弃和添加一个新的重做日志组就可解决问题 如果活
动 数据库可能需要从联机重做日志文件残留物进行介质恢复
• 如果正在写入当前组的所有成员时 LGWR 突然无法访问这些成员 则该数
据库例程关闭 在这种情况下 数据库可能需要从联机重做日志文件残留物
进行介质恢复

LogMiner 能用来干什么 ?

LogMiner 提供了一个处理重做日志文件并将其内容翻译成代表对数据库的逻辑
操作的 SQL 语句的过程
使用 LogMiner 之前应当做什么
无论数据库装载或卸载 LogMiner 都可在 Oracle 例程上运行 LogMiner 使用字典文件 该特殊文件表明创建它的数据库以及文件创建时间 字典文件并非必需 但建议使用
没有字典文件 等效 SQL 语句将使用 Oracle 内部对象 ID 作为对象名称并以十
六进制数据提供列值

创建字典文件

• 指定初始化参数 UTL_FILE_DIR 以指定一个允许 PL/SQL 文件 I/O 的目录
• 执行 BMS_LOGMNR_D.BUILD 过程以创建字典文件
设置 LogMiner 会话

一旦创建了字典文件 您就可以开始分析重做日志 第一步是使用DBMS_LOGMNR.ADD_LOGFILE 过程指定要分析的日志文件

使用下列常量
• DBMS_LOGMNR.NEW 创建一个新列表并指定第一个日志文件
• DBMS_LOGMNR.ADDFILE 向列表中添加其它日志文件
• DBMS_LOGMNR.REMOVEFILE 从列表中删除重做日志

LogMiner 可以分析联机和归档日志文件
启动 LogMiner 会话

一旦创建了字典文件并指定了重做日志列表 您就可以启动 LogMiner 并开始
分析 启动时 使用如下选项来缩小搜索范围
选项 说明
StartScn 系统更改号 (SCN) 范围的起始
EndScn SCN 范围的终止
StartTime 时间间隔的开始
EndTime 时间间隔的结束
DictFileName 字典文件名
选项 使用 logmnr.opt 文件中指定的列映射 值为
USE_COLMAP

追踪对表的更改

可通过 V$LOGMNR_CONTENTS 视图查看输出 只有执行分析的会话可以查
看日志信息 其它会话无法查看该信息 如果其它会话要查看结果 可将信息
存储在其它表中

停止 LogMiner 会话

执行 DBMS_LOGMNR.END_LOGMNR 过程以完成分析重做日志的会话
查看数据字典

LogMiner 一旦启动 就可以使用下面的数据字典视图视图 说明

V$LOGMNR_DICTIONARY 正在使用的字典文件
V$LOGMNR_PARAMETERS LogMiner 的当前参数设置
V$LOGMNR_CONTENTS 正在分析的重做日志文件内容

 

了解Oracle Alert.log 警报/告警/日志文件

Oracle Alert.log警报日志文件

每个 Oracle 例程都有一个警报日志文件。如果该文件尚未创建,将在例程启动过程中进行创建。警报日志文件由您进行管理,并随着数据库的继续运行而不断增长。诊断日常操作或错误时,应该首先查看警报日志文件。警报日志文件还包含指向跟踪文件的指针,从而可获得更详细的信息。

警报日志文件记录了以下信息:

  • 数据库启动或关闭的时间
  • 所有非缺省初始化参数的列表
  • 后台进程的启动
  • 例程使用的线程
  • 正在向其中写入信息的日志序列号 LGWR
  • 有关日志切换的信息
  • 表空间的创建和撤消段
  • 已发出的警报声明
  • 有关 ORA-600 等错误消息和区错误的信息

 

  • alertSID.log 文件:
    • 记录命令
    • 记录主要事件结果
    • 用于记录日常操作信息
    • 用于诊断数据库错误
  • 每个条目都带有与之相关联的时间戳
  • 必须由 DBA 进行管理
  • 存储位置由 BACKGROUND_DUMP_DEST 定义

 

 

告警日志这个文件里包含了依照之间排列的信息与错误日志。告警日志包括下列项目:

  • 所有发生的内部错误(ORA-600)、数据块损坏错误(ORA-1578)以及死锁错误(ORA-60)的记录。
  • 例如create、alter、drop命令以及startup、shutdown、archivelog命令等管理操作记录。
  • 与共享服务器与调度器进程功能相关的信息及错误。
  • 所有在实例启动时有非预设值的初始化参数数值。

Oracle服务器会将这些作业都记录在告警日志中,作为在操作员主控台(Operator’s console)显示信息的替代方式。如果操作成功,则会在告警日志中写入”completed”信息,并加上时间戳。

在Enterprise Manager中,您可以藉由按一下”数据库(Database)”首页中”相关链接(Related Links)”区域的”告警日志内容(Alert Log Content)”来检查告警日志中的内容。会显示”最近的告警日志项(Most Recent Alert Log Entries)”页面。

 

 

警报日志文件中的信息示例

ALTER DATABASE CLOSE NORMAL
ORA-1507 signalled during:ALTER DATABASE CLOSE NORMAL...
控制文件和联机表空间备份

Fri Jun 4 10:54:20
alter tablespace user_data begin backup
Fri Jun 4 10:54:21
ORA-1123 signalled during:alter tablespace user_data begin backup
...

由于轮换重做日志文件太快而导致未完成检查点

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

创建表空间

Fri Jun 4 10:57:20
create tablespace SYSTEM datafile '/home/disk3/user30/DATA/DISK1/
sys01.dbf' size 20m
default storage (initial 10K next 10K) online
Fri Jun 4 10:57:30
Completed:create tablespace SYSTEM datafile '/home/disk3/user30/
DATA/DISK1/sys01.dbf'
create tablespace rbs
datafile '/home/disk3/user30/DATA/DISK2/rbs01.dbf' size 30m
Fri Jun 4 10:58:48
Completed:create tablespace rbs datafile '/home/disk3/user30/DATA/
DISK2/rbs01.dbf'

创建和修改回退段

Fri Jun 4 11:57:48
create rollback segment SYSTEM tablespace SYSTEM
storage (initial 50K next 50K)
Completed:create rollback segment SYSTEM tablespace SYSTEM
Fri Jun 4 12:07:58
alter rollback segment rbs01 online
Completed:alter rollback segment rbs01 online
Fri Jun 4 12:58:48

由于警报日志文件会越来越大 占用的磁盘空间也会不断增加 所以应该经常
对其进行归档并删除 或者定期进行整理

 

 

找到 警报日志的SQL :

 


For Unix / Linux 

select
   vp.value||'/alert_'||INSTANCE_NAME||'.log'
from
   v$parameter vp ,v$instance  vi
where
   vp.name = 'background_dump_dest';


For Windows 

select
   vp.value||'\alert_'||INSTANCE_NAME||'.log'
from
   v$parameter vp ,v$instance  vi
where
   vp.name = 'background_dump_dest';

Oracle Controlfile 控制文件详解

Oracle Controlfile 控制文件详解

 

Oracle Controlfile控制文件

  • 包含物理数据库结构信息
  • 多路复用以免遗失
  • 在挂载mount阶段读取

 

当您启动数据库实例和挂载数据库时,就会读取控制文件。而控制文件中的项目则指定了构成数据库的物理文件。

当您将其他文件加入到数据库时,会自动更新控制文件。

您必须在CONTROL_FILES初始化参数中指定控制文件的位置。

为了避免数据库因为遗失控制文件而失败,您必须【多路复用(multiplex)】控制文件。在初始化参数中指定多个文档,就可以让Oracle数据库保有控制文件的多个副本。

您可以存取数据库中控制文件的相关信息,只要在Enterprise Manager的【服务器(Server)】页面【存储(Storage)】区中按一下【控制文件(Controlfiles)】链接。在【控制文件(Controlfiles General)】页面中会显示数据库控制文件的名称与位置。另外,【高级(Advanced)】页面中会提供建立控制文件和数据库识别的相关信息。而【记录文档段(Record Section)】页面则显示控制文件中项目的相关信息。

 

打开数据库与控制文件

 

当数据库从关闭阶段转到完全打开阶段时,数据库会执行内部一致性检查。这些阶段包括:

  • NOMOUNT:实例要达到 NOMOUNT(又称 STARTED)状态,就必须读取初始化参数文件。实例进入 NOMOUNT 状态时,不会检查任何数据库文件。
  • MOUNT:实例进入 MOUNT 状态时,会检查初始化参数文件中列出的所有控制文件是否都存在且已同步。即使有一个控制文件缺失或损坏,实例也会向管理员返回错误(指明缺失了控制文件)并保持在 NOMOUNT 状态。
  • OPEN:实例从 MOUNT 状态转到 OPEN 状态时,它会:- 检查控制文件知道的所有重做日志组是否都至少有一个成员。任何缺失的成员都会记录在预警日志中。

 

丢失了控制文件

执行以下步骤可在丢失了控制文件后进行恢复(只要至少保留了一个控制文件):

  1. 如果实例尚未失败,可使用 SHUTDOWN ABORT 关闭实例。
  2. 将剩余的一个控制文件复制到缺失文件的位置。如果介质故障是由于丢失了磁盘驱动器或控制器而造成的,则将剩余的一个控制文件复制到其它某个位置,然后通过更新实例的参数文件来指向新位置。也可从初始化参数文件中删除对缺失的控制文件的引用。记住,Oracle 建议在任何时间至少要保留两个控制文件。
  3. 启动实例。

 

维护控制文件

1 现有控制文件的位置及其名称是什么
提示 查询动态性能视图 V$CONTROLFILE 或 V$PARAMETER或者执行 SHOW PARAMETER 命令以显示控制文件的名称和位置
2 试着在无任何控制文件的情况下启动数据库 可以通过更改参数文件中的控制文件名称或只是更改控制文件名来模拟此操作 发生了什么提示 该问题没有提示
3 使用 DISK2 目录对现有的控制文件进行多元备份 并将新的控制文件命名为control02.con 确保 Oracle 服务器可以写入新的控制文件 例如 在UNIX 上使用 chmod 660 命令 确认两个控制文件都在使用

 

提示
关闭数据库
将现有的控制文件复制到 DISK2 目录下名为 control02.con 的新文件中
在 UNIX 上使用命令 chmod 660
修改参数文件以包含新文件名
启动数据库
查询动态性能视图 V$CONTROLFILE 或 V$PARAMETER 或使用 SHOW PARAMETER 命令确认两个控制文件都在使用

 

 

控制文件的使用

数据库的控制文件是成功启动和操作数据库所必需的小型二进制文件 每个控制文件只与一个 Oracle 数据库相关联。因为 Oracle 服务器在数据库使用的过程中会不断更新控制文件 所以控制文件必须在数据库打开时随时都可供写入 只有 Oracle 服务器能修改控制文件中的信息 DBA 或最终用户不能编辑控制文件。如果由于某些原因控制文件无法访问 则数据库将无法正确运行。

如果数据库控制文件的所有副本都丢失 则必须先恢复数据库 然后才能将其打开。

控制文件内容

  • 数据库名称取自初始化参数 DB_NAME 所指定的名称或 CREATE DATABASE 语句中所用的名称
  • 当创建数据库时会记录数据库标识
  • 当创建数据库时 还记录创建数据库的时间戳
  • 当在数据库中添加 重命名或删除数据文件或重做日志时 会更新相关数据文件和联机重做日志文件的名称和位置
  • 当添加或删除表空间时会更新表空间信息
  • 在日志切换过程中会记录日志历史信息
  • 归档日志的位置和状态会在归档时记录
  • 备份的位置和状态由恢复管理器实用程序记录
  • 在进行日志切换时记录当前日志序列号
  • 在建立检查点时记录检查点信息

控制文件由以下两种类型的部分组成

  • 可重用
  • 不可重用

可重用部分存储恢复管理器的信息 如备份数据文件名和备份重做日志文件
名 只有恢复管理器能够以循环方式重复使用该部分

 

多路复用控制文件

与联机重做日志文件相同 Oracle 允许同时打开并写入多个相同的控制文件
可以使用初始化参数 CONTROL_FILES 指定多达八个完全限定的控制文件名
称 Oracle 服务器在例程启动时创建和维护本参数中所列的全部文件
可以通过以下方法多路复用控制文件

  • 创建数据库时创建多个控制文件
  • 创建数据库后添加控制文件

随数据库创建控制文件 创建多个控制文件 数据库创建控制文件 最简便的方法是 在创建数据库时
将控制文件的名称包括在 CONTROL_FILES 初始化参数中
CONTROL_FILES = (/DISK1/control01.con,/DISK2/control02.con)
Oracle 服务器将创建该参数中列出的全部控制文件 在此参数中指定的文件名
应当包括完整的路径名 文件名规范与操作系统有关
如何添加控制文件 添加控制文件或更改控制文件的 如何添加控制文件 编号或位置

  1. 关闭数据库
  2. 使用操作系统命令复制当前的控制文件
  3. 将新的控制文件名添加到 CONTROL_FILES 参数中
  4. 启动数据库

控制文件的原则
• 您应该:
– 对控制文件进行多元备份
– 在 CONTROL_FILES 中包括完整的路径名
– 更改数据库结构后备份控制文件
• 控制文件:
– 大小由 CREATE DATABASE 关键字决定
– 具有可重用部分, Recovery Manager 的更新使之
可以扩展

多路复用的目的
若要防止控制文件的单点故障 我们强烈建议您多路复用控制文件 在不同的
物理磁盘上存储副本
如果某控制文件丢失 则使用该控制文件的副本重新启动例程
如果在不同磁盘上有当前控制文件的多个副本 则无须恢复数据库即可方便地
启动例程

CREATE DATABASE 关键字
在创建数据库过程中指定的关键字会影响控制文件的大小 当参数的值较大
时 这一点尤其明显 可能需要重新创建控制文件以更改一个或多个数据库限
制参数 该操作有可能增加或减小控制文件的大小
CREATE DATABASE 或 CREATE CONTROLFILE 命令中的下列关键字影响控
制文件的大小
• MAXLOGFILES
• MAXLOGMEMBERS
• MAXLOGHISTORY
• MAXDATAFILES
• MAXINSTANCES
必须创建新的控制文件 才可更改这些关键字所创建的空间大小
可重用部分可以扩展
当使用恢复管理器时 控制文件的可重用部分可以基于恢复管理器所要求的条
目数进行扩展
更改数据库结构后备份
由于控制文件记录数据库的物理结构 所以在更改数据库的物理结构后应当立
即备份控制文件
获取关于控制文件的信息
若要获得控制文件的位置和名称 请使用动态性能视图 V$CONTROLFILE

SQL> SELECT name FROM v$controlfile;
NAME
———————–
/DISK1/control01.con
/DISK2/control02.con
2 rows selected.
也可以使用 V$PARAMETER 视图 但是因为列长度的原因 控制文件名称可
能会被截断

若要获得控制文件不同部分的信息 查询
V$CONTROLFILE_RECORD_SECTION 动态性能视图
SQL> SELECT type, record_size, records_total, records_used
2 FROM v$controlfile_record_section
3 WHERE type=’DATAFILE’;
TYPE RECORD_SIZ RECORDS_TO RECORDS_US
————- ———- ———- ———-
DATAFILE 180 30 4
1 row selected.
RECORDS_TO 列指定分配给某特殊部分的记录数 例如 在我们的示例中您可以看到数据文件的最大数为 30 该数由 CREATE DATABASE 命令中的MAXDATAFILES 参数确定
其它几个动态性能视图中的信息从控制文件获取
• V$BACKUP
• V$DATAFILE
• V$TEMPFILE
• V$TABLESPACE
• V$ARCHIVE
• V$LOG
• V$LOGFILE
• V$LOGHIST
• V$ARCHIVED_LOG
• V$DATEBASE
• 其它

快速参考
上下文 参考
初始化参数 CONTROL_FILES
动态性能视图 V$CONTROLFILE
V$CONTROLFILE_RECORD_SECTION
V$PARAMETER
数据字典视图 无
命令 无
程序包过程和打包函数 无

Oracle PFILE/SPFILE 初始化参数文件

Oracle PFILE/SPFILE 初始化参数文件

初始化参数文件

要启动一个例程,Oracle 服务器必须读取初始化参数文件。

 

初始化参数文件

  • 文件中的条目专用于要启动的例程
  • 有两种类型的参数:

显式:文件中有一个条目

隐式:文件中没有条目,但假定取 Oracle 缺省值

  • 可存在多个初始化参数文件
  • 对文件中条目的更改的生效时间,取决于使用的初始化参数文件类型

静态参数文件 PFILE

永久参数文件 SPFILE

Oracle 服务器在启动例程时读取初始化参数文件。共有两种类型的初始化参数文件:

  • 静态参数文件 PFILE,一般名为 initSID.ora。
  • 永久参数文件 SPFILE,一般名为 spfileSID.ora。

初始化参数文件内容:

  • 例程参数列表
  • 与该例程相关联的数据库的名称
  • 系统全局区 (SGA) 的内存结构的分配
  • 如何处理已满的联机重做日志文件
  • 控制文件的名称和位置
  • 有关撤消段的信息

为在各种不同情况下优化性能,一个例程可有多个初始化参数文件。

初始化参数文件

使用 Oracle Enterprise Manager 查看初始化参数

从“OEM 控制台”(OEM Console):

  1. 导航到“数据库”(Databases) >“例程”(Instance) >“配置” (Configuration)。

2.从“常规”(General) 页选择“全部初始化参数”( All Initialization Parameters)。

 

 

PFILE initSID.ora

  • 文本文件
  • 使用操作系统编辑器进行修改
  • 手动进行修改
  • 所作更改在下次启动时生效
  • 仅在例程启动过程中打开
  • 缺省位置为 $ORACLE_HOME/dbs

PFILE

PFILE 是可使用标准的操作系统编辑器进行维护的文本文件。PFILE 在例程启动过程
中是只读的。如果文件发生修改,则必须关闭然后重新启动例程以使新的参数值生效。

缺省情况下,该文件位于 $ORACLE_HOME/dbs 目录中,文件名是 initSID.ora。

 

创建 PFILE  

cp init.ora $ORACLE_HOME/dbs/initdba01.ora

使用样本 init.ora 文件创

  • 样本文件由 Oracle Universal Installer 安装
  • 使用操作系统复制命令复制样本
  • 由数据库 SID 唯一标识

修改 initSID.ora
编辑参数
针对数据库要求

 

样本 init.ora 文件由 Universal Installer 在安装过程中创建。该样本 init.ora 文件可用于创建特定于某一例程的 initSID.ora。可使用文本编辑器修改 initSID.ora 文件中的参数。

 

PFILE 示例

 

# Initialization Parameter File: initdba01.ora
db_name              = dba01
instance_name        = dba01
control_files        = ( 		home/dba01/ORADATA/u01/control01dba01.ctl,
	home/dba01/ORADATA/u02/control01dba02.ctl)
db_block_size        = 4096
db_cache_size        = 4M
shared_pool_size     = 50000000
java_pool_size       = 50000000 			
max_dump_file_size   = 10240
background_dump_dest = /home/dba01/ADMIN/BDUMP
user_dump_dest       = /home/dba01/ADMIN/UDUMP
core_dump_dest       = /home/dba01/ADMIN/CDUMP
undo_management      = AUTO
undo_tablespace      = UNDOTBS
. . .


以这样的格式指定值:keyword=value(关键字 = 值)。
服务器为每个参数都设置了缺省值。根据参数的不同,缺省值可能与操作系统相关。
可以按任意顺序指定参数,但也存在例外。
注释行以 # 符号开头。
参数中如果包括字符文字,可将参数用双引号括起。
可以使用关键字 IFILE 使参数中包括其它文件。
如果使用的操作系统区分大小写,那么文件名也区分大小写。
如果有多个值,应该用圆括号将它们括起来,用逗号隔开。
注:请为参数的列出顺序指定一个标准:按字母顺序列出或按功能进行分组。PFILE 根据例程的不同而变化,不一定与上例相同。

 

PFILE 与SPFILE的差异

SPFILE spfileSID.ora

SPFILE

SPFILE 是 Oracle9i 中新增的二进制文件。该文件不能手动修改,且必须始终驻留在服务器端。创建该文件后,即由 Oracle 服务器进行维护。如果进行手动修改,SPFILE 将无效。SPFILE 具有对数据库进行永久更改的功能,不受关闭和启动操作的影响,它还提供自动调节记录在文件中的参数值的功能。使用 SPFILE,RMAN 可以支持初始化参数文件的备份,因为 SPFILE 驻留在服务器端。缺省情况下,它位于 $ORACLE_HOME/dbs 目录中,缺省名称为 spfileSID.ora。

 

  • 二进制文件
  • Oracle 服务器进行维护
  • 始终驻留在服务器端
  • 所做更改永久有效,不受关闭和启动的影响
  • 可以自行调节参数值
  • 使恢复管理器能够备份初始化参数文件

创建 SPFILE

SPFILE 是使用 CREATE SPFILE 命令从 PFILE 文件创建的。该命令需要具有 SYSDBA 权限才能执行。该命令可在例程启动之前或之后执行。

SQL> CREATE SPFILE [=’SPFILE-NAME’]

2 FROM PFILE[=’PFILE-NAME’]

其中:

  • SPFILE-NAME:要创建的 SPFILE 的名称
  • PFILE-NAME:用于创建 SPFILE 的 PFILE 的名称。PFILE 必须在服务器端可用

如果在语法中未包括 SPFILE-NAME 和 PFILE-NAME,Oracle 将使用缺省 PFILE 来生成 SPFILE(其名称由系统生成)。

SQL> CREATE SPFILE FROM PFILE;

 

从 PFILE 文件创建

CREATE SPFILE = $ORACLE_HOME/dbs/spfileDBA01.ora’ FROM PFILE = $ORACLE_HOME/dbs/initDBA01.ora;

 

其中
SPFILE-NAME:要创建的 SPFILE
PFILE-NAME:用于创建 SPFILE 的 PFILE
可在例程启动之前或之后执行

导出 SPFILE  

可将 SPFILE 的内容导出到 PFILE 中。

SQL> CREATE PFILE FROM SPFILE;

以上命令在服务器端创建了一个文本文件格式的 PFILE 。该命令可在例程启动之前或
之后执行。这样就提供了一种查看 SPFILE 并进行修改的简单方法:

  • 将 SPFILE 导出到 PFILE
  • 编辑 PFILE
  • 从编辑过的 PFILE 重新创建 SPFILE

将 SPFILE 导出到 PFILE 还可用作创建永久参数文件的备份的备用方法。

注:使用 Oracle9i,RMAN 还可备份永久参数文件。

V$SPPARAMETER

如上所述,查看 SPFILE 内的参数设置时有几个选项。V$SPPARAMETER 是显示和查看 SPFILE 的内容的另一种方法。

 

 

创建 SPFILE

使用 Oracle Enterprise Manager 创建 SPFILE

从 OEM 控制台:

  1. 从主菜单选择“对象”(Object) >“创建 spfile”(Create spfile)。

使用 Oracle Enterprise Manager 导出 SPFILE

从 OEM 控制台:

1.从主菜单选择“对象”(Object)>“创建 pfile”(Create pfile)。

 

SPFILE 示例

 

*.background_dump_dest=‘/home/dba01/ADMIN/BDUMP’
*.compatible='9.0.0'
*.control_files='/home/dba01/ORADATA/u01/ctrl01.ctl’ *.core_dump_dest=‘/home/dba01/ADMIN/CDUMP’
*.db_block_size=4096
*.db_name='dba01‘
*.db_domain=‘world’
*.global_names=TRUE
*.instance_name='dba01'
*.remote_login_passwordfile='exclusive‘
*.java_pool_size=50000000’
*.shared_pool_size=50000000
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS'
. . .

SPFILE 示例

PFILE 中的参数设置行上指定的注释保留在 SPFILE 中。所有其它注释都被忽略。

尽管 SPFILE 中的文本在 UNIX 中易于查看,但 SPFILE 是一个二进制文件,对
SPFILE 进行手动修改将使之无效。如果需要查看 SPFILE 的特定内容或进行一些
更改,可将 SPFILE 导出到 PFILE。

 

STARTUP 命令行为

优先顺序:

  • 使用命令 STARTUP 时,服务器端的 spfileSID.ora 用于启动例程。
  • 如果找不到 spfileSID.ora,则使用服务器端的缺省 SPFILE 来启动例程。
  • 如果找不到缺省 SPFILE,将使用服务器端的 initSID.ora 来启动例程。

指定的 PFILE 可覆盖缺省 SPFILE 来启动例程。

可在 PFILE 中包含一个定义以指示要使用 SPFILE。这是在非缺省位置使用 SPFILE
启动例程的唯一方法。要使用非缺省位置的 SPFILE 启动数据库,必须在 PFILE 中指
定 SPFILE=<完整路径和文件名>。

示例:SPFILE=$HOME/ADMIN/PFILE/$ORACLE_SID.ora。

 

 

优先顺序

  • spfileSID.ora
  • 缺省 SPFILE
  • initSID.ora
  • 缺省 PFILE
  • 指定的 PFILE 可覆盖优先顺序

STARTUP PFILE = $ORACLE_HOME/dbs/initDBA1.ora
PFILE 可指示要使用 SPFILE

SPFILE = /database/startup/spfileDBA1.ora

 

修改 SPFILE 中的参数

ALTER SYSTEM SET 命令用于更改例程参数的值。

ALTER SYSTEM SET parameter_name = parameter_value

[COMMENT ‘text’] [SCOPE = MEMORY|SPFILE|BOTH]

[SID= ‘sid’|’*’]

其中

parameter_name:要更改的参数的名称

parameter_value:要将参数更改为的值

COMMENT:添加在 SPFILE 中被更改的参数旁的注释

SCOPE:确定应在内存中、在 SPFILE 中还是同时在这两个位置进行更改

MEMORY:只能在当前运行的例程中更改参数值

SPFILE:只能在 SPFILE 中更改参数值

BOTH:在当前运行的例程和 SPFILE 中均可更改参数值

SID:标识要使用的 SPFILE 的 ORACLE_SID

‘sid’:更改 SPFILE 时使用的特定 SID

‘*’:使用缺省 SPFILE

 

  • 使用 ALTER SYSTEM 更改参数值
  • ALTER SYSTEM SET undo_tablespace = ‘UNDO2’;

  • 指定所做更改是临时的还是永久的
  • ALTER SYSTEM SET undo_tablespace = ‘UNDO2’ SCOPE=BOTH;

  • 删除或重置值
  • ALTER SYSTEM RESET undo_suppress_errors SCOPE=BOTH SID=’*’;

示例:

SQL>  SHOW PARAMETERS undo_suppress_errors

NAME                   TYPE        VALUE

———————- ———– ——-

undo_suppress_errors   boolean     FALSE

SQL> ALTER SYSTEM SET undo_suppress_errors = TRUE

2  COMMENT = ‘temporary testing’ SCOPE=BOTH

3  SID=‘DBA01’;

SQL> SHOW PARAMETERS undo_suppress_errors

NAME                   TYPE        VALUE

———————- ———– ——-

undo_suppress_errors   boolean     TRUE

ALTER SYSTEM RESET 命令用于删除或还原为缺省值。

SQL> ALTER SYSTEM RESET parameter_name [SCOPE = MEMORY|SPFILE|BOTH] [SID= ‘sid’|’*’]

示例:

SQL> ALTER SYSTEM RESET undo_suppress_errors

2  SCOPE=BOTH SID=‘dba01’;

从 SPFILE 中删除一个参数有以下几种方法:

  • 将参数重设为缺省值来模拟使用 ALTER SYSTEM SET 的删除操作。
  • 使用 CREATE SPFILE FROM PFILE 重新创建 SPFILE。
  • 使用 ALTER SYSTEM RESET 从 SPFILE 删除参数。

 

修改 SPFILE 中的参数(续

使用 Oracle Enterprise Manager 修改 SPFILE 配置

从 OEM 控制台:

1.导航到“数据库”(Databases) >“例程”(Instance)。

2.单击“配置”(Configuration)。

  1. 在“常规”(General) 页上,单击“全部初始化参数”( All Initialization Parameters)。
  2. 在参数值栏中修改参数 。
  3. 单击“确定”(OK)。

沪ICP备14014813号

沪公网安备 31010802001379号