ANBOB™

最近遇到一套9I数据库遇到了性能问题， 现象是数据库主机CPU使用率很高应用响应缓慢，Cpu Idel几乎为0， 从v$session_wait查看数据库当前的活动会话在等待’null event’和’latch free’.

JI enqueue is used to serialize the refresh of a materialized view, JI enqueue is acquired in exclusive mode on the mview base (container) table when the refresh is being performed, it ensures that two or more refresh processes do not try to refresh the same object.

部署GOLDENGATE时发现，当前库中存在较多的长事务，在v$transaction中显示状态一直是ACTIVE, 对于长事务的对OGG的BR或启动抽取位置有较大影响， 奇怪的是这些长事务的起动时间甚至都有3天以上，而且当前会话状态已是INACITVE.而且查看UNDO SEGMENT HEADER上对应的SLOT 的DBA是0x00000000。

前几日有11.2.0.3套库出现了性能问题，这里简单记录， 当时只是表现几个会话的同一条INSERT SQL语句出现了较高的latch: undo global data 等待，latch miss是 ktudba: KSLBEGIN ，同时还有BBS 等待

前面的方法我们还原了问题现象，因为CBO使用错误的统计信息，使用了INDEX_JOIN的方式， 现在尝试如何快速的解决该问题，也就是禁用INDEX_JOIN或使用我们指定的执行计划。

SQL涉及表的所有字段都有索引，不过分布在两个索引上，ORACLE 优化器会选择了使用index join的执行计划，避免了对table的访问路径， 因当时cpu过高，查询慢没成功记录两个索引的分区信息..

对于临时表不应该收集统计信息，TEMP TABLE是会话级数据，因为每个进程可以填充的数据不一样， 手动收集的统计信息如果不在insert的会话为0 ，影响了CBO生成正确执行计划

CPU + Wait for CPU CPU 21.64 41.99
log file sync Commit 21.63 41.97
enq: TX – row lock contention Application 19.71 38.23
buffer busy waits Concurrency 5.86 11.36
latch: cache buffers chains Concurrency 5.30 10.29

前几日一个数据库的负载非常高，查看数据库的活动会话发现大部分session在等待’wait for a undo record’的事件， 该事件通常发生在fast-start parallel rollback, 该特性通常是在SMON进程发现存在一个长时间的事务需要回滚，或遇到PARALLE DML需要回滚时，超过一定量的回滚任务时自动启动多个server process的并行回滚

CBC latch竞争的原因很多，通常也可以理解为一种热块， 对于CBC 通常都是从session wait中找到child latch address 然后再去x$bh的hladdr字段找到相应的obj，1个BH handle可以会关连多个obj, 再参考TCH 列确认比较hot的对象。大多数CBC的OLTP系统多数应该注意一下sql 的执行计划中使用了NL join的方式；

年前一套数据库出现了性能问题，一周出现了两次，很多session 等待“cursor: pin S wait on X” 事件，这是一套11.2.0.4 RAC on RHEL6 的环境，下面记录一下该案例的优化方案。

gc cr&current grant 2-way 是一种 grant message package 的传递，当取cr 或current block 时向block master instance 请求x或s的权限 ，当请求的block在从任何实例上的buffer cache中都没有发现, lms进程会通知FG进程从disk 读取block到local buffer cache中

很久以前遇到的一个问题简单记录一下，之前一个数据库出现了很高的I/O 负载，影响了全省的业务， 因为SQL 使用了错误的执行计划，当前修改app 重上线已来不及， 此时可以使用像sql profile,outline, sql baseline来指定个执行计划…

My colleague suddenly encountered a problem today,a Database becomes very slow , and the a lot of session wait library cache lock event, Let me help him to look. DB env is 10.2.0.4 rac.

a few days ago,My CRM DB face to a performance issue. DB is very slow. then I check DB wait event of active session ,Most sessions is waiting “DFS lock handel” , ‘DFS lock handle’ can cause massive performance issues in a busy RAC cluster. my db is 10R2 2NODE RAC ON AIX.

Yesterday I received a warning and a production db instance found many TX lock and wait event “transaction”, I check the TX lock model is 6, so we can make sure is caused by multiple sessions update the same data, and wait event “transaction” is relatively rare, Here the record about my diagnosis method.

接上一篇 http://www.anbob.com/archives/2323.html 下面我们从统计信息入 […]

当CBO产生的Cardinality过低，尤其是在表之间关连时，往往会差之毫厘差之千里，甚至影响表之间的join方式，注意下MERGE JOIN CARTESIAN部分，这里使用了一种NL style的MJ,..

今天开发的同事找我说是一个报表系统的SQL执行第一次很快，再执行就慢的几乎查询无响应，找他要来了SQL，也是常见的表关连LIFT JOIN 、GROUP BY的统计报表, 出于篇幅原因不再贴SQL， 把SQL放到TOAD 中问题依然可以再现，..

Adaptive Log File sync was introduced in 11.2. the feat […]