-
编辑 删除
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内核》（点击链接可申领书籍哦~）一书终于和大家见面了，我是这本书的组织者和主要译者之一，同时也负责了所有文章的技术审校。
-
编辑 删除
SQL Profile（第四篇）
默认通过SQL Tuning Advisor创建的SQL Profile，是通过一些修正因子来达到修正执行计划的目的，但是随着数据的变化，时间的推移，这些SQL Profile里包含的修正因子可能也已经不再准确，因此在某些使用了SQL Profile的SQL上可能会发现刚开始这些SQL Profile工作的很好，但是不久就会产生一些问题。
-
编辑 删除
SQL Profile（第三篇）
我们已经学习了如何通过SQL Tuning Advisor来使用SQL Profile，接下来我们来学习一些更高级的知识，如何手工创建一个SQL Profile。本章一开头我们提到，SQL Profile其实也是通过一些存储的hint来发挥作用的，那么这些hint是存储在什么地方的？ORACLE 10G版本，可以通过查看sys.sqlprof$、sys.sqlprof$attr来获得SQL Profile使用的hint，但是11G后这两个数据字典基表不再有效，需要通过查看sys.sqlobj$data、sys.sqlobj$来查看SQL Profile使用的hint。
-
编辑 删除
SQL Profile（第二篇）
在11GR2上SQL Tuning Advisor已经变得非常好用，我非常喜欢将一些非常复杂的SQL语句交给SQL Tuning Advisor来调优，几乎每次都不让我失望，通常调优结束后，SQL Tuning Advisor都会给你一些建议，例如建议你创建索引或者收集统计信息，或者建议你接受SQL Profile并且给出了接受SQL Profile后性能将得到的提升。
-
编辑 删除
SQL Profile（第一篇）
SQL Profile是我非常喜欢的一个技术，通过它可以在不修改SQL语句的情况下，为SQL绑定任何需要的hint，与SQL代码是分离的，而且相对Baseline、outline来说，操作步骤简单，如果使用熟练可以在极短的时间内修正一个查询语句的执行计划，我已经在多个场合使用SQL Profile解决了数据库的性能问题。
-
编辑 删除
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值，那么此后的解析都要窥探绑定变量的值计算谓词选择率，如果计算选择率不在现有的游标的选择率范围内，就会基于窥探到的绑定变量的值重新硬解析产生一个新的游标，当然这个新游标的执行计划可能与之前是一样的。我们还是来看一个例子就会非常明白这种机制了。
-
编辑 删除
性能神化，聊聊Exadata 的“七宗罪”
性能神化，聊聊Exadata 的“七宗罪”前几天，ITPUB的总编老覃发布了一篇我的采访记录，我说到了我们新一代的QData T5比Exadata快，（点击这里查看），虽然有点标题党，但是我还是打算把这个事扩展一下，因为我发现很多人把Exadata神化了。性能，吾将上下而求索先说说性能的事。它很重要。人类在历史上有...
-
编辑 删除
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字节。
