Tuning ‘latch free’ & ‘null event’ wait event in Oracle 9i

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

Performance Tunning: enq: JI – contention

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.

Lots of Long transaction caused by database link, and undo hdr show DBA for that slot is 0x00000000

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

latch: undo global data(ktudba: KSLBEGIN) wait event when insert value

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

Index join SQL性能故障 之 disable index_join 使用sql profile hint, parameter 和sql patch

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

Index join SQL性能故障 之 通过恢复统计信息还原SQL问题

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

Tuning: Temporary table don’t collect statistics (临时表不要收集统计信息)

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

‘latch: cache buffers chains’ & Don’t underestimate the rownum = 1

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

Performance tuning ‘wait for a undo record’ event

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

Tuning: latch: cache buffers chains 又一案例

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

Performance Tuning DML hang wait event ‘cursor: pin S wait on X’

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

Performance tuning ‘gc cr&current grant 2-way’ event (当主机扩容cpu后)

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中

How to force a hint without touch sql text? 手动SQL Profile固定执行计划

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

Performance tuning library cache lock & single-task message

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.

Troubleshooting “DFS lock handle” wait event

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.

Tuning “transaction” & TX lock wait event ,speeding up rollback dead transaction

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.

SQL join problem caused by Low cardinality with Histogram(柱状图产生的过低Card.导致表join性能问题)(二)

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

SQL join problem caused by Low cardinality with Histogram(柱状图产生的过低Card.导致表join性能问题)(一)

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

Adaptive Cursor Sharing in 11R2 performance issues(自适应游标共享问题案例)

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

,

Adaptive Log File Sync In 11gr2 (_use_adaptive_log_file_sync)

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

,