-
编辑 删除
Buffer Busy Waits是怎么产生的？
Buffer Busy Waits等待设计的本质是为了降低CBC Latch的争用。在写写/写读场景下会产生Buffer Busy Waits，在读/写场景下，发生写操作的服务器进程会去Copy出一个current块来继续写操作，而不会去等待Buffer Busy Waits等待。
-
编辑 删除
为什么Oracle要搞出两个脏链表
为什么Oracle要搞出两个脏列表：一个Checkpoint Queue，一个LRUW。 两个链表设计的目的是不一样的。
-
编辑 删除
Oracle ASM神书《拨云见日 解密Oracle ASM内核》出版了
很高兴《拨云见日，解密Oracle ASM内核》（点击链接可申领书籍哦~）一书终于和大家见面了，我是这本书的组织者和主要译者之一，同时也负责了所有文章的技术审校。
-
编辑 删除
ORACLE OWI介绍
Oracle数据库对于做那些做运维的DBA是非常友好的，在Oracle的数据库中，有着大量的性能视图可以供DBA来进行性能诊断，也有AWR,ADDM这些极易上手的性能诊断工具帮助DBA分析数据库性能问题。但是就我看到的，依然存在着不少的DBA还是以一种毫无章法的方式优化着Oracle的性能问题。记得一次在杭州的面试另我印象深刻，面试我的是一位DBA老者，他说为什么一个根据主键更新的update语句执行了很久，而同样的根据这个主键的查询语句却很快。我当时的回答是：首先需要知道update所在会话在等待什么，然后兴致冲冲的讲了什么是OWI、什么是响应时间模型，但是看得出来老者对于我的回答并不满意，就在我继续滔滔不绝的说着等待事件时，他打断了我，说：其实是因为锁导致的。我当时觉得有点尴尬，我问：你是如何定位到是锁导致的，他面露得意的说：根据他多年的经验通过猜测最后验证确实是锁导致的。可能在其他非ORACLE数据库里，经验的重要性是首屈一指的，但是在ORACLE里，经验虽然重要，但是又不重要，经验这个词，有猜测的成分在。ORACLE提供了大量的性能视图、诊断工具方便我们去做调优、做诊断，让优化
-
编辑 删除
Adaptive Cursor Sharing（第五篇）
11G以前ORACLE处理带有绑定变量的SQL存在一些问题，由于SQL在硬解析时使用了绑定变量窥探，产生出的执行计划不是对所有值都好，取决于第一次硬解析时窥探到的值,产生出的执行计划有一定的随机性，11GR1版本推出了Adaptive Cursor Sharing,后面简称ACS，用来解决绑定变量窥探带来的问题，提升SQL语句的执行性能。优化器在使用ACS技术后，已经可以为一个带有绑定变量的SQL产生出多个执行计划（如果必要的话）。这个特性对于有数据倾斜的列非常有用，而在11G之前，一个SQL在一个特定的优化器环境下，只可能有一个执行计划（在不同的优化器环境下，可能存在多个执行计划，如：first_rows,all_rows）。本章会将为你启开ACS的神秘面纱，为你揭示ACS的技术内幕，通过本章几小节的学习，带你深入了解ACS的方方面面。
-
编辑 删除
Adaptive Cursor Sharing（第四篇）
ACS与PL/SQL前面的章节论述了ACS的特性，我们来看下ACS在PL/SQL里的工作情况，结果可能会令你非常失望。首先构造一个PL/SQL，里面使用到了我们在本章中创建的表T：SQL>var sql_id varchar2(255)SQL>alter system flush shared_pool;...
-
编辑 删除
Adaptive Cursor Sharing（第三篇）
一般情况下ACS必须结合直方图一起使用才能发挥作用，我们看看列上的数据有倾斜，但是却不收集直方图情况下，ACS的表现会怎么样，紧接着还会举出一个特例。
-
编辑 删除
Adaptive Cursor Sharing（第二篇）
我们上面提到了，在v$sql_cs_histogram视图中，如果此游标的3个桶中出现了两个桶中的count都有非0值，那么此后的解析都要窥探绑定变量的值计算谓词选择率，如果计算选择率不在现有的游标的选择率范围内，就会基于窥探到的绑定变量的值重新硬解析产生一个新的游标，当然这个新游标的执行计划可能与之前是一样的。我们还是来看一个例子就会非常明白这种机制了。
-
编辑 删除
Adaptive Cursor Sharing （第一篇）
11G以前ORACLE处理带有绑定变量的SQL存在一些问题，由于SQL在硬解析时使用了绑定变量窥探，产生出的执行计划不是对所有值都好，取决于第一次硬解析时窥探到的值,产生出的执行计划有一定的随机性，11GR1版本推出了Adaptive Cursor Sharing,后面简称ACS，用来解决绑定变量窥探带来的问题，提升SQL语句的执行性能。优化器在使用ACS技术后，已经可以为一个带有绑定变量的SQL产生出多个执行计划（如果必要的话）。这个特性对于有数据倾斜的列非常有用，而在11G之前，一个SQL在一个特定的优化器环境下，只可能有一个执行计划（在不同的优化器环境下，可能存在多个执行计划，如：first_rows,all_rows）。本章会将为你启开ACS的神秘面纱，为你揭示ACS的技术内幕，通过本章几小节的学习，带你深入了解ACS的方方面面。
-
编辑 删除
事务隔离级别读书笔记分享
1. 脏读、不可重复读、幻读，是一种缺陷2. 隔离级别越高，能解决的“缺陷”越多，为什么不直接使用最高的事务隔离级别，那不就没有缺陷了？因为传统的以锁的方式去实现的隔离级别，级别越高，并发性越低。3. 脏读，解决 写不阻塞读 的问题，提高并发现，牺牲一致性。现在绝大多数的主流数据库，都是...
-
编辑 删除
LOG FILE SYNC概述（第六篇）
事务在进行提交的时候，对事务修改的，还在内存里的块做commit cleanout，其实主要就是设置ITL槽位里的commit scn，不会去清楚lb信息。ORACLE在进行commit cleanout期间，会获取相关buffer的buffer pin，而且是排他模式获取，这个pin直到lgwr把日志刷入到磁盘才释放，如果在此期间，有进程对相关的buffer进行select/update/insert就会造成buffer busy waits。因此如果你的系统log file sync指标很高，也可能会导致一定程度的buffer busy waits等待事件。
-
编辑 删除
LOG FILE SYNC概述（第五篇）
新的调优手段10G之前，在事务做提交的时候，必须等待Lgwr刷日志完成才能继续做其它事，也就是说必须符合事务持久化的条件，可能学过其他数据库的同学学ORACLE的时候怪怪的，因为像MYSQL、MONGODB等数据库都支持对日志的异步刷新，我想之所以ORACLE这么晚才推出这一功能，主要还是使用ORACLE的客户都是金融、证券等行业巨多，这些行业对于数据的丢失是零容忍的，因此他们对此并无需求，直到10GR1，ORACLE公司才默默的推出了一个参数：commit_logging，这个参数可以实现让事务在提交时，并不同步刷新日志，而是在合适的时候去触发，这个参数可以有四种组合：
-
编辑 删除
LOG FILE SYNC概述（第四篇）
作为通用的log file sync的诊断、调优方法，一般可以通过诊断系统的IO延迟为多大，CPU资源是否充足来判断哪里出现了问题。
-
编辑 删除
LOG FILE SYNC概述（第三篇）
曾经有一个网友咨询我，说在自己的系统中看到了log file sync等待事件，问我该如何“消灭”这个等待事件，解决log file sync争用的问题。之所以提出这样的问题，还是对log file sync的产生过程不清楚导致的，log file sync不是争用产生的等待事件，而是事务在提交过程中产生的一个正常等待事件，只能去优化，而不能被消灭。
-
编辑 删除
LOG FILE SYNC概述（第二篇）
commit与log file sync是息息相关的，在每次事务提交时，commit会触发增进系统的SCN（通过函数kcmgas），然后产生一个commit的改变向量被拷贝进log buffer中，commit的改变向量一旦被拷贝到log buffer中，会触发通知Lgwr进程刷新日志。commit的改变向量是用来描述数据块（undo头块）的改变的，commit之所以会产生改变向量是由于commit本身修改了undo段头块的事务表，如：修改了事务表中此事务的提交状态，提交SCN等信息，这些修改信息组合成了一个commit的改变向量。10G之前commit的改变向量都是stand alone（独立的）的redo record，10G之后由于出现了私有redo，commit的改变向量可以跟事务的其他改变向量一起组成一个redo record。在10G版本，commit产生的stand alone的redo record有140个字节，如果是非stand alone的会有72字节。
-
编辑 删除
LOG FILE SYNC概述（第一篇）
曾经有将近半年的时间，我都在跟log file sync打交道，每次查看系统压测期间的TOP 5等待事件，log file sync都稳稳的排在第一的位置，而且平均响应时间已经达到了10ms，随着一步步的优化，系统压测的TPS从刚开始时候的4000到6000到8000，TPS提升的过程也是对log file sync等待事件优化的过程。本章主要介绍log file sync相关的原理和优化技巧，希望本章的内容能或多或少的帮助到你。
-
编辑 删除
Oracle Real Time SQL Monitoring
术语说明Table Queue，消息缓冲区，在并行操作中使用，用于PX进程之间的通信，或者PX进程与QC进程之间的通信，是内存中的一些page，每个消息缓冲区的大小由参数parallel_execution_message_size控制，11GR2版本默认为16K，之前的各个大版本这个值都不一样，详细请参考ORACLE官方文档。墙面时间、持续时间指的...
-
编辑 删除
12c 进程跟踪文件异常
<div style="font-family:'Microsoft YaHei UI';font-size:14px;line-height:21px;white-space:normal;widows:auto;background-color:#FFFFFF;">12C下进程产生不了跟踪文件的异常，记录一下，大家可以看看。</div><div style="font-family:'Microsoft YaHei UI';font-size:14px;line-height:21px;white-space:normal;wi...
-
编辑 删除
各种读取方式对CPU的消耗
<div style="font-family:'Microsoft YaHei UI';font-size:14px;line-height:21px;white-space:normal;widows:auto;background-color:#FFFFFF;"><span style="font-family:'\Microsoft YaHei UI\';">表大小 <span style="line-height:1.5;">136 BLOCKS </span><span style="line-height:1.5;">17,408</span></s...
-
编辑 删除
修复OCR和VOTING
<div style="font-family:'Microsoft YaHei UI';font-size:14px;line-height:21px;white-space:normal;widows:auto;"><span style="font-family:Simsun;">ora.cssd 起不来一般是voting disk数量不够，或者voting disk盘头损坏<br /></span></div><div style="font-family:'Microsoft YaHei UI';font-size:14px;line-he...
