oracle内核+相克军Oracle视频看懂绝对是高级DBA了-CSDN博客

本文链接：https://blog.csdn.net/jnrjian/article/details/123468292

本文深入探讨了数据库的事务处理，包括undo记录的前镜像、CR块的构建、回滚与提交机制。讲解了xid在ITL中的作用，如何利用undo和redo进行数据恢复，并分析了buffer cache、redo log buffer以及并发控制中的锁机制。同时，讨论了ASM条带化对I/O性能的影响以及数据库优化策略。

摘要由CSDN通过智能技术生成

相克军：

1.undo记录的不是块，而是前镜像，一条一条的，各undo块之间记录串起来，可以方便rollback 从后向前

2.undo 时，data block指向undo块的位置，为了构建CR块方便不需要根据xid看undo块头，同时写两份可以减少争用，不用老查段头，同步更新也有消耗，比起段头热块争用，还是值得了。另外如果更新了1000个块，1000个块上有这个信息，同时段头也有。那commit时，直接更新段头就可以（尤其是块已经写入磁盘，未提交写入磁盘啦。更新的话还要读到内存）。那这样块里面的flag没变，每次都要查一下？还是延迟块清理，只是不清行的信息？但也不对，行不清的话，lck也不能清，所以应该整个快都是延迟清理。视频里面说两个都有可能没清理的，只要有锁就要看一下undo header，因为决定要不要构造cr块。如果要构建就是cr读，如果不要构建cR就是current读。这个块同时也可能已经刷入磁盘了。如果没有刷入磁盘，那磁盘的信息就是很早的，我们能不能不构CR块，直接读磁盘的数据呢？好像不行，因为找块的时候都是CBClatch先看在不在cache的，在cache就不去磁盘了，因为在cache肯定是未提交或者刚提交。你新来的scn查，我去磁盘查万一查了很久的（commit还没有刷进盘的数）数据就不一致了。

块上的xid去查undo header，如果发现xid那一条覆盖次数比如15 超过xid-13的记录，说明我这个事务已经提交了。已经提交了再查就不能用他回滚了。这时oracle15555错误就出现啦。要找可以，去redo找。但是redo做事不像undo，他说我只能朝后跑，你去把xid12次覆盖的文件找来，我给你redo到13次。redo不能反着来。除非启用了flashback，这时可以反着来了。因为flashback时我没有提供12次覆盖的文件，只能倒退回去！！

3.xid记录了undo块头，第几行和第几次覆盖，所以xid可以唯一的标记在头内所有过的操作，类似hbase的记录多次修改了。块中有UBA已经可以回滚，但是只能回滚一次，所以记录xid可以超前串起回滚和第一步差不多。

（另外xid记录了可以延迟块清理，下次清理时根据xid对照块头覆盖次数（原来9 现在覆盖次数11，肯定是commit了，不commit不可以覆盖的。）决定块是不是脏块。。）后面学习了发现xid后面还有flag标志，lck，scn fsn 定位了块的scn，确定instance crash时块要不要恢复。

ITL中处理xiduba还有row 锁，行级锁。

由于itl数量限制，所以也会有争用。热块，buffer busy wait。这是update时才有，insert时是一次插多个块，比如阿里那个日志，一次插64块导致的问题，如果有几百个块，问题就少了。但是如果用了sequence，下次根据sequence，select就慢了，取几条记录访问多少块，本来就64块放了五百条。导致select慢了。。。

除了xid uba还有几个信息的，这个在两个里面都有一样的表。

lck就是锁的行数，加上行的锁（行上放itl number就行，反向也可以查出itl对应多少行。高明啊）一起配合使用，所有信息一目了然。

----

小结：

ITL中UBA指向data block的最后一个undo block地址，undo block之间指向，都是为了回滚操作；

Data block header 与Undo block的直接指向，为了构造cr块更快速；

ITL中XID指向undo segment header是为了多种提交方式。

1.行删除后回滚

中间表exchange partition

这种按月分区吧

system的buffer cache

2.索引读取次数

i/o出问题指标

等待事件oracle知道的，主动登记的 i./o network

等待事件表

gdb

kslwtbctx kslwait 等待任务

利用sid 找错误 spid

全局临时表

单独网段的重要性

指标突然升高降低很大

存储问题

redo 在pga产生

等待的状态

AWR

物理读

iops

到时看一下他的语句

唯一索引

读不阻塞写

写阻塞读如果频繁访问建唯一索引 pCTused大一点？

redo 我也遇到

redo太重要了 logbuffer大也没用，后面写满还是跟不上

redo记录后镜像，undo 记录前镜像

RBA UBA DBA 这些

DBWR 异步写，合并写异步IO相当于并行写

I.O 次数和写入总数不同，因为大块小块

LRU

大小表策略小表可以是热表大的不行

以前忽略的 dbwr checkpoint Q和lruw都要写数据cache

一般不用改变mttr 改变这个影响I/O 和CPU的使用情况，CPU换I/O

chain长了 latch就多 cpu就多，那就多写I/O 少用cpu，脏块写入不就是没有commit的写入了数据文件。。

上面这句是不是有点问题lruw不写脏块啊，看到脏的不是放到热端嘛

数据文件start scn的改变，写入就是写最新的scn进去，告诉你这块以前的redo已经不要了啊，可以覆盖了

ckpt dbwr 不想不等待，什么时候等，那就是所有的redo都是active的，那没有可用的redo，ckpt要等待dbwr写完，不过所谓的等也是中途要休息一下。 oracle 所谓的醒来，只是为了释放latch，不一直持有latch吧，就是cbclatch一样，加锁了就释放，不用等待一直完成。用户体验好，直接出光标。

redo大一点好啊

redo 什么时候inactive 什么时候写data header，并不是切换就要写完脏数据，active是不会改数据头的，只有改完数据头，LRBA才会更新，只有dbwr写完才可以覆盖，如果dbwr满，就会出现checkpoint not complete，can not allocate new log等待。