0
oracle数据库启动过程分析
380
15页
4次
墨值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
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文档的来源(墨天轮),文档链接,文档作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论

关注
最新上传
暂无内容,敬请期待...
下载排行榜
Top250 周榜 月榜
近期活动
全部
暂无活动,敬请期待...
相关课程
全部