某单位信息中心一次数据库性能分析

一、性能分析

1. 数据库性能报告分析
   1. 数据库性能报告采样时段

截取当天9：00至11：00之间数据库性能指标快照

1. DB Time 远大于Elapsed时间，说明在9:00和11:00分之间 数据库比较繁忙，负载高.

1. 1. TOP10等待事件
   2. 

ADDM报告

1. 1. 等待事件说明

1. enq: TX - row lock contention : 数据库存在较为严重的行级锁等待事件。

触发行级锁enq: TX - row lock contention事件的原因有以下几种可能：

1. 不同的session更新或删除同一条记录；
2. 唯一索引有重复索引；
3. 位图索引同时被更新或同时并发的向位图索引字段上插入相同字段值；
4. 并发的对同一个数据块上的数据进行update操作；
5. 等待索引块完成分裂；

1. direct path read : 此等待事件说明数据库存在执行效率低的sql语句，同时也是Oralce11G版本的新特性（直接路径读取）

触发等待事件的原因可能为：

1. 由于部分SQL语句设计或编写效率低下，以及表缺少适应的索引，导致SQL语句需要全表扫描，在表较小时，ORACLE数据库将数据读取到缓存后，后续虽然是全表扫描，但均是从缓存中读取，所以问题未体现出来。
2. 在表的数据量不断增大后，根据ORACLE 11g数据库的算法，在表达到db_cache_size（GB）的2%（默认值）以后，认为采用直接路径读（跳过缓存，直接从磁盘文件中全扫描读取）

1. 1. TOP等待事件分析总结
2. 数据库负载较大，行级锁等待严重
3. 由于全是社康业务量较大，大量的执行低效SQL语句，触发Oracle 11G数据库新特性，直接从磁盘读取数据，导致IO阻塞。

1. TOPSQL

4.1 高耗时SQL

发现较多执行耗时较高的语句（如图）

1. 1. 逻辑读较高的SQL

发现逻辑读较高的SQL（如图）：

1. 1. 
   2. 物理读较高的SQL

SQLID	SQL语句
70zfdft202krb	select count(*) as col_0_0_ from HER_HealthRecipeRecord_MZ her_health0_ where WAYID=:1
80wsyc9ypxw5v	select count(*) as col_0_0_ from HER_HealthRecipeRecord her_health0_ where WAYID=:1 and GUIDEWAY='01'

1. 1. TOPSQL 问题总结

从上述报告中看出：

1. SQL语句的执行效率并不高，由于系统业务量较为庞大，其中部分模块发出的sql执行存在硬解析次数较多，硬解析次数过多会造成大量CUP资源耗费。

1. 执行次数不多，但逻辑读过高的SQL，业务发出语句在做sql tuning时一般会去抓取一些buffer gets很大的sql statement.然而这些会引起CPU、I/O、MEMORY等一些资源的耗费。

1. 数据库存在SQL语句通过直接路径读取数据，造成此类原因是因为表的大小不断增大后，根据ORACLE 11g数据库的算法，在表达到db_cache_size（GB）的2%（默认值）以后，认为采用直接路径读（跳过缓存，直接从磁盘文件中全扫描读取）。