DSI 401读书笔记

最近重拾了DSI 401,根据章节,大致做个笔记吧,以备后续的翻看。由于是断断续续的看的,所以下面的笔记的思路可能会有些跳跃。

第一、二章的dump,crash,corruption主要介绍的是数据库hang住,loop,还有crash的一些诊断。
loop和hang最大的区别就是loop消耗cpu,你可能会看到cpu使用率100%的情况,而hang的情况你会看到数据库基本没有压力。我个人觉得latch属于loop的情况,会不断的sleep/wake up,而且出现latch的时候,往往cpu中的user%部分会比较高。而hang的情况往往是数据库中的dml锁,前一个session的执行完成之后锁没释放,后一个session就只能等在那里了。
进行故障诊断的时候,我们可以查alertlog,trace file,application的log,coredump,syslog等等。
其中一个很重要的工具是oradebug hanganalyze,一般使用level 3进行分析。注意LEAF和LEAF_NW的节点。
dump systemstates可以用ass.awk来辅助分析trace文件。
下面是systemstates的tracefile中的几个解释:
通常情况下,一个process下是一个session,一个session开一个transaction。如果一个process下有多个session,一般是shared server模式或者OCI应用等等。因此在trace file中大致看到的也是这样的结构。最外层的时候process SO(SO:states objects,是SGA中的结构),里面是session的信息,再里面一层是transaction信息。
来看一个systemstate dump:
先看一个process states objects:

上述第3行SO: 700000025e5ef20 表示state object ID为700000025e5ef20 ,
第4行表示该Oracle pid为17
第5行表示是否有相关的ora-nnnn的报错。
第6~11行显示inter-process的信息。
第12行,latch信息
第31~32行os的一些信息.

再看一个session states objects:

第1行:states objects id和owner
第2行:session的sid,已经一些flag信息,如:
USR表示是user session
BSY表示session is busy, it is in a call
DED表示session mark dead by user process
DEL表示session being delete(通过alter system kill session)
KIL表示session mark kill (通过alter system kill session)
第3行:resource id(DID)的一些信息。
第4行:事务的关系分支。
第5行:oct(oracle command tye),和prv(user privilege),和oracle user,这里显示是SYS。
第6行:session的等待事件。

另外查看hang或者loop的等待的时候,对于buffer热块,可以查x$kcbfwait;对于enqueue可以查x$ksqst。

第三章,memeory management和heap corruption。
oracle的内存分为heap-extents-chunks。
连续的extents组成heap,各种类型的chunks组成extents,类型分别有free,permanent,re-creatable等等。如果一个extents是从另一个heap延伸过来的,那么从延伸过来的那个heap叫父heap,当前的heap叫子heap。
当用户向heap申请free的chunk的时候,发现没有多余的space可供使用时,heap manager会去LRU中找unpinned(即re-createable)的chunks,使其释放。

一个granule最小为4M,而sga最小包含一个fix(含redo buffer),一个buffer cache,一个shared pool,所以一个sga最小为12M。

ora-600是heap中的一致性检验失败触发的。此外bug和存储损坏也会触发ora-600。
ora-7445一般是内存指针指向失败造成,比如指向内存越界的区域。此外,代码bug和内存地址计算错误也会触发ora-7445。

dump memory:
alter session|system set events ‘trace name heapdump|heapdump_addr|buffers|row_cache|library_cache level n;
或者
oradeug dump heapdump|heapdump_addr|buffers|row_cache|library_cache n;
其中上述的n,如果为1代表dump PGA,2为SGA,3为UGA,32为large pool。

heapdump能dump出:(1)内存描述符。(2)extents和chunks。(3)LRU,free list,permanent chunks等等。
heapdump_addr能dump出子heap,n为子heap的address。

查heap中的各项chunk信息,可以查x$ksmhp, 如果是sga中的信息,可以查x$ksmsp;如果是pga,可以查 x$ksmpp,如果是uga,可查x$ksmup;

第四章,data block dump.

data block分成3层结构:
cache layer
transaction layer
data layer(含footer)

rowid:格式,6363,oooooofffbbbbbbsss
常用:
dbms_rowid.ROWID_BLOCK_NUMBER
dbms_rowid.ROWID_CREATE
dbms_rowid.ROWID_RELATIVE_FNO

如何dump block:
1)用dd

dd出来的block的格式:2248842244,2位type+2位format+4位为将来用+8位RDBA+8位scn base+4位scn wrap+2位seq+2位flag+4位chkval+4位将来用。
tail为scn base的后2位+type+seq

2) 用alter system dump datafile xx block xx;

注意data这部分可以通过asc转十六进制来翻译:
col 0: [ 3] 53 59 53
即为: S Y S
col 1: [ 1] 80
即为: €
col 2: [ 4] 4f 50 45 4e
即为: O P E N
col 3: *NULL*
col 4: *NULL*
col 5: [ 6] 53 59 53 54 45 4d
即为: S Y S T E M
col 6: [ 4] 54 45 4d 50
即为 T E M P

ora-600逻辑坏块,如块的scn base,seq以及tpye和footer不一致。
ora-1578,物理坏块。

注意dbv只能用在datafile上,不能用在redolog上。

flash freeze,可以通过event事件驱动,freeze之后,所有的状态都被冻结。

exp不会涉及上高水位之上的数据块,不会检查index和temporary的对象。

一个很有用的event:10231,在fts的时候,skip corrupt块,可用于设置之后的exp导出。再重建table,在导入。

block修复利器:bbed
set/dump/f/x/modify/sum apply/p/verify

第五章,index block dump
index block也是三层结构:
cache & tnx layer,即block header;注意,在这一层里含ITL信息。
branch & leaf,即common header;
row piece info

我们现在来dump一个索引块看看。
1.通过treedump来看索引的树状结构:

以下是dump文件:

我们看到该索引只有一个节点,只有一层。leaf block即为branch block,该地址用十六进制是0x40357e,如果是十进制是4207998。
kdxcoopc 0x80表示oracle8i以上的block,如果是70表示是oracle7的block,10表示IOT表的block,20表示键值压缩;
kdxcolev 0表示leaf的level,0表示是叶子。
kdxlenxt 表示next leaf block的地址。
kdxleprv 表示上一个leaf block的地址。
kdxledsz 0 如果是0表示非唯一索引,如果是非0表示唯一索引。

另外我们还可以用dump datafile block的方式dump出来:

我也可以看到了类似的leaf block的信息,我们还看到了leaf block有2个ITL。

event 10233能在索引进行rang scan操作时,skip掉逻辑损坏的索引块。

第六章,rollback segment corruption
说起事务,transaction,它的发生关系到2种segment,data segment和rollback segment。
data segment中有ITL和data row(注,ITL是在进行DML的那个data row的同一个数据块中),rollback segment头上有txn table(注,txn table中包含指向undo record的指针),后面有undo record(即原数据的镜像)。
txn id的组成为usn.tnx slot id+scn wrap

当data segment发生变化的时候,rollback segment中undo record也会对应的产生。

读一致(CR)的概念:当某session读取某个block的时候(这个block可能是在buffer中的),发现该block的ITL是被使用的,通过ITL找到rollback segment头中的txn table还是active状态,于是去读txn table中所指向的undo record。

锁的产生:DML后,未commit,则ITL为open状态,此时txn table还是active状态,所以就会等待。

当commit后,将tnx table 标记成inactive;注意此时data segment中的block未必会马上更新,即ITL还是open状态;直到这个block下次被读取的时候,ITL的状态才会被改成close。(即延时块清除)。使用延时块清除主要为了节省IO消耗(是指buffer中修改过的块,刷回到disk上,此部分消耗的IO)。

如果是rollback,则会undo原来的事务(从最近的开始,到最早的。),并且将ITL至于clear状态。rollback不存在延时块清除。注意在rollback的过程中会产生新的redo。会访问ITL,data block,rollback segment的header(因为有tnx table在那里),undo record。

当某个进程crash掉的时候,PMON会立即检测到,且开始回滚操作。

当数据库crash掉的时候,当再次open数据库的时候,开始做前滚。在system rollback segment中的事务会被立即回滚,在其他rollback segment中的事务会被mark成dead。
可以用x$ktxue.KTUXECFL=’DEAD’查询,另外,alter system dump undo header xxx的话,在trace文件中也能看到cflag也是0x10(即为DEAD)。

有2个隐含参数常常用于打开undo有问题的数据库:_corrupted_rollback_segment,_offline_rollback_segment。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据