读书笔记:深入解析oracle-第2章控制文件与数据库初始化-CSDN博客

1、控制文件是数据库的大脑，而SYSTEM表空间是数据库的心脏。

2、从oracle 11g开始，可以通过v$diag_info获得当前会话转储文件的名称。

3、 SCN由两部分组成，高位SCN Wrap由2Bttes记录，低位Scn Base由4Bytes记录。

4、 9i前，通过查询x$KTUXE获得系统最接近当前值的SCN

SQL> select max(ktuxescnw*power(2,32)+ktuxescnb) from x$ktuxe;

MAX(KTUXESCNW*POWER(2,32)+KTUXESCNB)

------------------------------------

594496

9i开始，可以使你用dbms_flashback.get_system_change_number来获得。

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER

------------------------

594555

10g开始，在v$database视图中增加了current_scn字段。

SQL> select current_scn from v$database;

CURRENT_SCN

-----------

594565

还可以使用oradebug从内存中直接读取该值

SQL> oradebug setmypid

Statement processed.

SQL> oradebug dumpvar sga kcsgscn_

kcslf kcsgscn_ [20009104, 20009124) = 00000000 00091293 00000159 00000000 00000000 00000000 00000000 20008F10

SQL> select to_number('91293','xxxxx') scn from dual;

SCN

----------

594579

5、 SCN通常在事务提交或回滚时改变，在控制文件、数据文件头、数据块、日志文件头、日志文件change vector中都有SCN，但其作用各不相同。

A、数据文件头中包含了该数据文件的Checkpoint SCN，表示该数据文件最近一次执行检查点操作时的SCN。

使用如下命令dump数据文件头：

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

FILE_HEADER部分之前信息来自控制文件，之后信息来自数据文件头，在数据库的启动过程中，需要依赖两部分信息进行比对判断，从而确保数据库的一致性和判断是否需要进行恢复。

B、日志文件头中包含了Low SCN 和Next SCN

SQL> alter system dump logfile '/oracle/ orcl/redo01.log';

这两个SCN标示该日志文件包含有介于Low SCN到Next SCN的重做信息，对于Current的日志文件，其最终SCN不可知，所以Next SCN被置为无穷大，也就是ffffffff。

6、实际上，检查点只是一个数据库时间，它存在的根本意义在于减少崩溃恢复(crash recovery)时间。

7、当数据在buffer cache中被修改之后，dirty buffer会被转移到dirty list，以便将来执行的检查点可以将这些修改过的buffer写出到数据文件上。

a、 在oracle8之前，由于检查点时需要写出全部脏数据，所以被称为完全检查点。

B、从oracle 8 开始，引入了检查点队列(Checkpoint Queue,CKPTQ)机制。当执行增量检查点时，DBWR从检查点队列按照LOW RBA的顺序写出，同时，CKPT进程也阶段性的使用非常轻量级的控制文件更新协议，将当前的最低RBA写入控制文件。

C、通过增量检查点，数据库可以将以前的全量写出变更为增量渐进写出，从而可以极大的减少对于数据库性能的影响；而检查点队列进一步地将RBA和检查点关联起来，从而可以通过检查点来确定恢复的起点。

8、文件检查点队列(FILE QUEUE)，通常缩写为FILEQ，它的引入提高了表空间检查点的性能。通常对表空间执行offline等操作时会触发表空间检查点。

9、使用如下命令转储buffer cache信息

alter session set events 'immediate trace name buffers level 10';

10、 Sga中存在一块内存区域用来记录这个检查点队列

SQL> select name,bytes from v$sgastat where upper(name) like '%CHECKPOINT%';

NAME BYTES

---------------------------------------------------- ----------

Checkpoint queue 128320

11、设置参数log_checkpoints_to_alert为TRUE，则数据库会将检查点的执行情况记入告警日志文件。

12、通过以下步骤跟踪数据库的启动过程，可以获得跟踪文件

Sql>startup nomount

Sql>alter session set events=’10046 trace name context forever,level 12’;

Sql>alter database open;

或者如下

Sql>startup mount;

Sql>alter session set sql_trace=true

Sql>alter database open;

13、

在10g中，当fast_start_mttr_target参数未设置时，自动检查点调整生效。

实例恢复包括两个步骤：cache recovery 和 transaction recovery。

注意到oracle在恢复过程中，首先读取日志，从最后完成的检查点开始，应用所有重做记录，这个过程叫前滚(Rolling Forward),也就是Cache Recovery过程，完成前滚之后，数据库可以被打开提供访问和使用。

此后进入实例恢复的第二阶段，oracle回滚未提交事务。Oracle使用两个特点来增加这个恢复阶段的效率，这两个特点是Fast-Start On-Demand Rollback和Fast-Start Parallel Rollback(这些特点是Fast-Start Fault Recovery的组成部分，仅在oracle8i之后的企业版中使用)。

使用Fast-Start On-Demand Rollback特点，Oracle自动允许在数据库打开之后开始新的事务，这通常只需要很短的Cache Recuvery时间，如果一个用户试图访问被异常中止进程锁定的记录，oracle回滚那些新事物请求的记录，也就是说，因需求而回滚。因而，新事物不需要等待漫长的事物回滚时间。在Fast-Start On-Demand Rollback中，后台进程SMON充当一个调度员，使用多个服务器进程并行回滚一个事务集。

Fast-Start On-Demand Rollback主要对于长时间运行的未提交事务有效，尤其是并行INSERT、UPDATE和DELETE等操作。SMON自动决定何时开始并行回滚并且自动在多个进程之间分散工作。

Fast-Start Parallel Rollback的一个特殊形式是内部事务恢复(Intra-Transaction Recovery)。在内部事务恢复中，一个大的事务可以被拆分，分配给几个服务器进程并行回滚。可以通过初始化参数FAST_START_PARALLEL_ROLLBACK来控制并行回滚，该参数有3个参数值。

FALSE：禁止Fast-Start Parallel Rollback

LOW：限制恢复进程不能超过2倍的CPU_COUNT.

HIGH：限制恢复进程不能超过4倍的CPU_COUNT

14、从oracle 10g开始，数据库开始实现自动调整的检查点(SelfTune Checkpoint)，使用自动调整的检查点，Oracle数据库开始利用系统的低I/O负载时段写出内存中的脏数据，从而提高数据库的效率。当FAST_START_MTTR_TARGET参数未设置时，自动检查点调整生效。

15、数据库在创建过程中最先运行的是一个叫作CreateDB.sql的脚步，在这个创建过程中，会隐含的调用$ORACLE_HOME/rdbms/admin/sql.bsq脚步，用于创建数据字典。这个文件的位置受到一个隐含的初始化参数_init_sql_file的控制。

16、在系统表空间system的文件头存在一个重要的数据结构root dba，用于定位数据库引导的bootstrap$信息。

17、数据库及文件号的转换工具：

execute dbms_utility_data_block_address_file(to_number(‘4001a1’,’xxxxxxx’))

execute dbms_utility_data_block_address_block(to_number(‘4001a1’,’xxxxxxx’))

18、在oracle以ORA-00701错误来阻止用户更改系统对象时，可以用如下方法处理：

A、通过migrate模式

Sql>shutdown immediate

Sql>startup migrate;

B、通过一个内部事件

Sql>alter system set event=’ 38003 trace name context forever,level 10’ scope=spfile;

--38003事件的作用是CBO Disable column stats for the dictionary objects in recursive SQL,也就是说可以将部分对象从启动的bootstrap$需要里剥离出来，从而可以被在线rebuild。