关注系统性能调优

测试插入数据单条循环提交和批量提交对日志等待事件的差异。select event, total_waits, time_waited, average_wait from v$system_eventwhere event like '%log file%';create table TX_LOCK_TAB(  A NUMBER,  B CHAR(1),  C VAR

今天上午9:41，接到客户反馈数据库出现性能问题，有大量的行锁等待。经过分析，原因是实施组昨天下午删除了两条业务单据，一直没有提交导致。此次性能事件影响范围：         确认没有接到大量用户投诉系统慢的电话，但分析weblogic一个节点的日志，nohup.out日志中发现某模块有38次stuck线程，可以推断出还是影响了少部分用户收到了影响。 Snap Id

当发生单块读时，就会出现这种等待，大部分情况下是读索引，少部分情况下是读undo。构造索引范围扫描，用v$session_event中捕捉。session1:C:\Documents and Settings\guogang>sqlplus test/testSQL*Plus: Release 11.2.0.1.0 Production on 星期四 5月 23 20:10:12 20

当进行多块读时，就会产生这种等待事件。实验准备做一个表的全扫描和索引全扫描，用v$session_event中捕捉。session1:C:\Documents and Settings\guogang>sqlplus test/testSQL*Plus: Release 11.2.0.1.0 Production on 星期四 5月 23 19:21:50 2013Copyrigh

今天在建索引的时候，出现等待事件enq: TO - contention，到网上找不到对应的等待事件。可以通过这种方式找，SQL> select KSQSTTYP,KSQSTEXPL from x$ksqst where KSQSTTYP='TO';KS KSQSTEXPL-- ------------------------------------------------------

在帮助文档的Oracle® Database Performance Tuning Guide：Thecachebufferschains latches are used to protect a buffer list in the buffer cache. These latches are used when searching for, adding, or removing a

从7月3日开始某一系统总是产生大量等待事件SQL*Net message from dblink，以前都没有的。网上说是空闲等待事件，可以不用管。但是对于这个空闲等待这么大，我想必定是某一个功能出问题了。       通过对业务的了解，确定是两个数据库通过db link传送大量数据导致，一次有几万条，每个小时都会有大量SQL*Net message from dblink是有问题，每个小时同步

数据被直接读取到PGA内存中时，发生的等待，如排序由于内存不足，被写到磁盘上，然后重新读取。为了在v$session_wait中看到，在公司的环境上找了一个大表，进行测试，建大表的步骤省略。session1:SQL> select * from v$version;BANNER-----------------------------------------------------

是索引块分裂引起的锁等待，往往与enq: TX - index contention 伴随产生，enq:TX - index contention的解释。      Waits for TX in mode 4 also occur when a transaction inserting a row in an index has to wait for the end of an inde

公司内有一个系统普遍慢，对于这种普遍慢的情况，就看AWR报告，晚上在用户不适用的情况下负载都很高(有4个逻辑CPU)，可以看到library cache lock的占比非常大。SQL> select * from v$version;BANNER-----------------------------------------------------------------------

从下面的例子中可以看到，在生产数据库中对象的重新编译会导致library cache lock，所以应该尽量避免在业务高峰期编译对象。如果是package或过程中存在复杂的依赖关系就极易导致library cache lock的出现，所以在应用开发的过程中，也应该注意这方面的问题。SQL> select * from v$version;BANNER--------------

在做性能压力测试，测试结果不能通过，获取现场一个小时的AWR报告，发现大量的等待事件，数据库是RAC，版本是11.2.0.4.0。Snap IdSnap TimeSessionsCursors/SessionInstancesBegin Snap:160721-10月-14 20:00:03560

GD系统很慢，数据库负载是平常6倍，排行第一的等待事件是latch: row cache objectsEventWaitsTotal Wait Time (sec)Wait Avg(ms)% DB timeWait Classlatch: row cache objects14,465,199509.

昨天正式环境上出现数据库CPU 100%的问题，数据库是128个CPU，128G内存，power系列，非常强劲，十几万的逻辑读只需要1s。出现问题之后，调整两条负载最高的两条SQL，问题解决，但有两个cluster类别的等待事件第 一次见，在metlink中找了一篇文章：共享：RAC等待事件:gc buffer busy acquire 概述----------------

开发找到我说一个数据库定时任务一直没有执行，因为JOB下一次执行时间一直不动。遇到这种问题，首先要看数据库报告，因为有可能是JOB hang住了，特别是有DB link的业务。    果然，排在第一的就是这个JOB执行的存储过程。Elapsed Time (s)ExecutionsElapsed Time per Exec (s)%Total

一直有个疑问就是db file sequential read时间占比很大说明什么问题？是说明单块读很多吗？进而说明索引读取很多，很慢。今天看一个数据库报告我想知道原因了。先是用户反馈系统慢，看了下数据库报告，确实很多SQL慢，绝大部分时间都在等IO。Elapsed Time (s)ExecutionsElapsed Time per Exec (s)

直接路径读（direct path read）通常发生在Oracle直接读数据到进程PGA时，这个读取不需要经过SGA。直接路径读等待事件的3个参数分别是file number（指绝对文件号）、first dba、block cnt数量。在Oracle 10g/11g中，这个等待事件被归于User I/O一类。如何模拟出来呢？把PGA设置小一点，弄一张大表做排序。session1:SQL>

log file sync：     When a user session commits, the session's redo information needs to be flushed to the redo logfile. The user session will post the LGWR to write the log buffer to the redo log fi

与buffer cache相关的等待事件包括：latch free、buffer busy waits、free buffer waits1.latch free等待       等待事件“latch free”中与buffer cache有关的有两类：cache buffers chains latch和cache buffers lru chain latch。在理解了上面所描述的有关

今天在正式环境的PL/SQL删除一个视图，一直在堵塞。Drop view v_fast_outageinfo;1.     生成当前几分钟的ASH报告，看到top event中library cache lock排在第一位。2.     查询select *from v$session_waitwhere event='library cache lock'发现有几

发现问题：从10.23号开始，生产数据库CPU消耗异常，DB Time是平常的两倍多，我看了这几天的AWR报告，有一个等待事件cursor: pin S wait on一直独占鳌头。         定位问题：根据下列sql可以找到对应的业务系统执行的语句，然后根据执行语句到代码中找到那个功能。我定位到时的是一个定时功能，每个星期天凌晨5:00执行，更新TERMINAL_LOWER_USER_

oracle10g等待事件很多，看资料往往过于理论，不太容易记住。打算对常用的等待事件做实验重现，并能运用到实际的工作中解决问题。--创建表，插入数据create table tx_lock_tab(a number,b char(1), c varchar2(20));insert into tx_lock_tab(a,b,c) values(99,'c','aaa');inse

今天把数据导入到测试环境上准备搭建测试环境，在编译无效对象快了一下，然后就不动了。我第一反应是否被卡住，于是查询v$session_wait这个表，发现了一个single-task message等待事件。为了快速解决问题，错误对象不多，我一个个编译，发现有个视图是有db_link，编译这个视图会很慢，然后报超时。果断把db_link删掉，然后按照测试环境重建，重新编译，非常快。

这是下午正式环境不可用，数据库报告如下，等待事件是row cache lock. Snap IdSnap TimeSessionsCursors/SessionBegin Snap:2786505-11月-12 13:59:287915.9End Snap:2786905-11月-12 18:00:0085

首先看DB Time的时间，数据库是12核，正常上午上班4个小时CPU的消耗为500分钟，现在消耗为2,315.58 分钟，由经验推断系统大约有1个多小时不可用。 Snap IdSnap TimeSessionsCursors/SessionBegin Snap:1938214-12

在一个提交十分频繁的系统中，我们经常会看到LOG FILE SYNC等待事件排在TOP EVENTS中。这种情况下，我们可能就需要针对LOG FILE SYNC等待事件进行优化了。       首先我们会看一下这个等待事件平均的等待时长，正常情况下这个等待事件的平均等待时间不会超过10毫秒，如果等待时间太长，那说明LOG WRITER每次写入的时间过长，如果能够优化一下REDO LOG文件的存

今天出现严重的等待事件PX Deq Credit: send blkd，与实施组沟通，系统并没有慢的情况。Snap IdSnap TimeSessionsCursors/SessionBegin Snap:2152413-3月 -13 14:00:2436519.5End Snap:2152813-3月 -13 1

官方文档：    This wait indicates that there are some buffers in the buffer cache that multiple processes are attempting to access concurrently. Query V$WAITSTAT for the wait statistics for each class of

反馈：4月11日9点钟上班时，发现系统很慢，你使用脚本查到有锁表的问题，然后你对session进行kill，系统恢复正常。       原因分析：       下面4:00-6:00的数据库报告的TOP5的等待事件，数据库版本是10g,cpu是4个。EventWaitsTime(s)Avg Wait(ms)% Total Call TimeWait

今天看昨天的数据库报告，发现大量SQL*Net more data to client等待事件，然后看SQL语句的执行时间，都有延时，可以断定昨天的网络出问题了。然后联系现场实施同事，他很惊讶的问我怎么知道的。      SQL*Net more data to client说明数据库在向客户端发送数据，而且是"more"，不停的发送，如果网络状况不好，或者网络流量过大，都可能导致这一等待非常

今天下午某个时段，实施组反馈说系统慢。先检查数据awr报告，看到一个小时之内数据库负载非常高（当然，其实数据库服务器比较差，只有4个cpu，运行时间也很长了）。看到是下列的存储过程导致，与数据泵相关。随后检查了下weblogic的日志，没有发现有价值的信息。           有了结论后，要实施组与用户确认了下，确实有导出。Elapsed Time (s)CPU Ti

为什么会有索引的等待事件，是索引在进行分裂，5-5、9-1分裂。session 1:create table test(x number,y char(20),z date,q varchar2(4000)) tablespace users;create index t1_idx1 on test(q,z);begin     for x in 1..10000 loop

事情大致经过：4月7日20:15接到实施组邮件，反馈系统某查询功能白屏。进一步了解情况，实施组在19点多钟曾接到客户电话反馈18:00-19:00系统很慢，期间系统也在做安全扫描，应用服务器负载偏高。得到消息后，实施组回到现场，发现点击某查询有一次是可以的，然后多次又白屏。       早上收到数据库报告，分析最后的结论是18点到19点，系统处于不可用的状态。19点到20点情况数据库负载比

现场反馈:查询一张几千条数据的表，一直卡住，然后重启了数据库，还是这样。1.获取了数据库报告，发现排在第一位的是cursor:pin s on x等待事件。Top 10 Foreground Events by Total Wait TimeEvent Waits Total Wait Time (sec) Wait Avg(ms) % DB time Wait Classcursor: ...