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。