oracle数据库启动过程分析
5墨值下载
--10046 事件是 SQL_TRACE 的扩展，被戏称为"吃了兴奋剂的 SQL_TRACE"
有效的追踪级别：
① 0 级：SQL_TRACE=FASLE
② 1 级：SQL_TRACE=TRUE，这是缺省级别
③ 4 级：1 级+绑定变量
④ 8 级：4 级+等待事件
⑤ 12 级：4 级+8 级
--一、通过 10046 事件跟踪数据库启动过程
--1、通过 10046 跟踪获得一个跟踪文件
sqlplus / as sysdba
startup mount
alter session set events='10046 trace name context forever,level 12';
alter database open;
--2、查看跟踪文件
tail -200f /u01/app/oracle/diag/rdbms/nwppdb/nwppdb/trace/alert_nwppdb.log
Sun Feb 03 02:25:49 2019
alter database open
Sun Feb 03 02:25:49 2019
LGWR: STARTING ARCH PROCESSES
Sun Feb 03 02:25:49 2019
ARC0 started with pid=21, OS id=3162
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Sun Feb 03 02:25:50 2019
ARC1 started with pid=22, OS id=3164
Sun Feb 03 02:25:50 2019
ARC2 started with pid=23, OS id=3166
Sun Feb 03 02:25:51 2019
ARC3 started with pid=24, OS id=3168
ARC1: Archival started
ARC2: Archival started
ARC2: Becoming the 'no FAL' ARCH
ARC2: Becoming the 'no SRL' ARCH
ARC1: Becoming the heartbeat ARCH
Thread 1 opened at log sequence 6
Current log# 3 seq# 6 mem# 0:
/oracle/redolog/NWPPDB/onlinelog/o1_mf_3_g4z2no7t_.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sun Feb 03 02:25:51 2019
SMON: enabling cache recovery
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
[3157] Successfully onlined Undo Tablespace 2.
Undo initialization finished serial:0 start:645154 end:647934 diff:2780 (27
seconds)
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is ZHS16GBK
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication
found)
Sun Feb 03 02:26:01 2019
Starting background process QMNC
Sun Feb 03 02:26:01 2019
QMNC started with pid=25, OS id=3170
Sun Feb 03 02:26:11 2019
db_recovery_file_dest_size of 1500 MB is 5.37% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Sun Feb 03 02:26:11 2019
Completed: alter database open
Sun Feb 03 02:26:11 2019
Starting background process CJQ0
Sun Feb 03 02:26:11 2019
CJQ0 started with pid=28, OS id=3188
--3、第一个对象的创建
create table bootstrap$
( line# number not null,
obj# number not null,
SQL_text varchar2(4000) not null)
storage (initial 50K objno 56 extents (file 1 block 520))
注意：这一步骤实际上是 oracle 在内存中创建 bootstrap$的结构，然后从数据文件中读取数据到内存中，
完成第一次初始化。
在 9i 读取位置是文件 1 的 377 块，自动 11g 后变更为文件 1 的 520 块。
从数据库的创建脚本$ORACLE_HOME/rdbms/admin/SQL.bsq 文件中，可以获得 bootstrap$表的初始创
建语句。
从数据库查一下，file 1 block 520 上存储的是什么对象
SQL> select segment_name,file_id,block_id from dba_extents where block_id=520
and file_id=1;
SEGMENT_NAME FILE_ID BLOCK_ID
--------------- ---------- ---------
BOOTSTRAP$ 1 520
file 1 block 520 存放的正是 bootstrap$对象，查看 trace 文件内容，下一步执行什么操作
select line#, SQL_text from bootstrap$ where obj# != :1
在创建并从数据文件中加载了 bootstrap$的内容之后，oracle 开始递归的从该表中读取信息，加载数据。
那么 bootstrap$中记录什么信息呢？
在数据库中，bootstrap$是一张实际存在的系统表。
SQL> desc bootstrap$
Name Null? Type
--------------- -------- --------------------
LINE# NOT NULL NUMBER
OBJ# NOT NULL NUMBER
SQL_TEXT NOT NULL VARCHAR2(4000)
select * from bootstrap$ where rownum <5;
可以看到 bootstrap$实际上是记录了一些数据库系统基本对象的创建语句。oracle 通过 bootstrap$进
行引导，进一步创建相关的
重要对象，从而启动了数据库。
--4、如何去定位 bootstrap$的位置呢？
在系统表空间文件头存在一个重要的数据结构 rootdba，我们可以通过转储数据文件头获得这个信息，从生
成的 trace 文件中，获得以下信息。
V10 STYLE FILE HEADER:
Compatibility Vsn = 202375680=0xc100200
Db ID=2903506423=0xad0ffdf7, Db Name='PRODCDB'
Activation ID=0=0x0
Control Seq=60695=0xed17, File size=103680=0x19500
File Number=1, Blksiz=8192, File Type=3 DATA
Tablespace #0 - SYSTEM rel_fn:1
of 15
5墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论