wish503的博客

描述：用户反应数据库任何操作都很慢，然后我查询到当前有大量的direct path read等待事件。数据库版本是oracle 11G。诊断与解决步骤：1查询当前等待事件，主要是direct path readselect event, count(1)  from v$session_wait WHERE EVENT NOT IN       (select E.

今天同事分享了一个特别好的案例，所以记录到我的博客现象：CPU冲高，大量latch: cache buffers chains等待事件.分析过程：1.根据等待事件查询出SQL信息。select t.BLOCKING_SESSION,t.BLOCKING_SESSION_STATUS,t.sql_id,t.SQL_HASH_VALUE,t.* from v$session t w

数据库发生了堵塞，例如大量latch free，大量log file sync， 大量enq ， 需要尽快查看并备份当前的v$active_session_history表，以免1s一次的统计数据被覆盖。 被覆盖后只能查dba_hist_active_sess_history，根据snapshot的频率不同（一般15分钟一次）而记录的历史统计数据。关键点： 找到大量堵塞event的ho

场景：测试库压力测试，用户反应oracle库很慢很慢1检查等待事件：select event,count(1) from  v$session_wait group by event order by  2 desc;发现 read by other session 排第一。2找到read by other session的SQL，同时可以取一个AWR报告看看TOP SQL，都指向

Wait until a buffer becomes available.There are four reasons that a session cannot pin a buffer in the buffer cache, and a separate wait event exists for each reason:1."buffer busy waits": A sessi