- 浏览: 4370189 次
- 性别:
- 来自: 厦门
-
文章分类
- 全部博客 (634)
- Oracle日常管理 (142)
- Oracle体系架构 (45)
- Oracle Tuning (52)
- Oracle故障诊断 (35)
- RAC/DG/OGG (64)
- Oracle11g New Features (48)
- DataWarehouse (15)
- SQL, PL/SQL (14)
- DB2日常管理 (9)
- Weblogic (11)
- Shell (19)
- AIX (12)
- Linux/Unix高可用性 (11)
- Linux/Unix日常管理 (66)
- Linux桌面应用 (37)
- Windows (2)
- 生活和工作 (13)
- 私人记事 (0)
- Python (9)
- CBO (15)
- Cognos (2)
- ORACLE 12c New Feature (2)
- PL/SQL (2)
- SQL (1)
- C++ (2)
- Hadoop大数据 (5)
- 机器学习 (3)
- 非技术 (1)
最新评论
-
di1984HIT：
xuexilee!!!
Oracle 11g R2 RAC高可用连接特性 – SCAN详解 -
aneyes123：
谢谢非常有用那
PL/SQL的存储过程和函数(原创) -
jcjcjc：
写的很详细
Oracle中Hint深入理解(原创) -
di1984HIT：
学习了，学习了
Linux NTP配置详解 (Network Time Protocol) -
avalonzst：
大写的赞..
AIX内存概述(原创)
前言
这两天一只对外提供查询的数据库CPU使用率频繁攀升到100%，客户记得焦头烂额，总希望我抓点sql让开发商优化。和客户通完电话后，我心里想到，这烂系统，抓几个sql顶什么用，问题早就提过好几次了，每次都不了了之，出了问题就知道在那瞎忙，找点表面问题修修补补，本质问题从来都是置之不理。一通抱怨后，开始逐步分析，人就是这样，吃人嘴软，谁让客户是上帝呢？抱怨归抱怨，工作还是要认认真真去对待的，分析报告如下，抛砖引玉，如有错误，望批评指正，谢谢！
分析报告
系统环境：AIX 6.1 Oracle 10g 10.2.0.5.4
查询库db2 2012-07-02 09:00~~10:00 AWR 报告
查询库db2 2012-07-04 11:00~~12:00 AWR 报告
通过以上等待事件的对比可以发现，CPU等待事件明显，同时都伴随着gc cr multi block request和db file sequential read等待事件。CPU等待事件与应用上表现出CPU占用率100%的现象相吻合。结合gc cr multi block request和db file sequential read事件明显这个因素，推测是由于节点之间频繁交换数据块(构造gc cr时所进行的请求和调度需要消耗CPU时间)和磁盘与内存直接频繁读写(内存的分配与撤销同样需要消耗CPU时间)。
查看磁盘信息如下
#sar -d 1
AIX fjlt_zgcx_db02 1 6 00F65AD44C00 07/04/12
System configuration: lcpu=32 drives=150 mode=Capped
11:56:31 device %busy avque r+w/s Kbs/s avwait avserv
11:56:32 hdisk3 0 0.0 0 0 0.0 0.0
hdisk5 0 0.0 0 0 0.0 0.0
hdisk10 0 0.0 0 0 0.0 0.0
hdisk16 0 0.0 0 0 0.0 0.0
hdisk7 0 0.0 0 0 0.0 0.0
hdisk9 0 0.0 0 0 0.0 0.0
hdisk14 0 0.0 0 0 0.0 0.0
hdisk13 0 0.0 0 0 0.0 0.0
hdisk8 0 0.0 0 0 0.0 0.0
hdisk15 0 0.0 0 0 0.0 0.0
hdisk18 23 0.0 792 6481 0.0 0.3
hdisk19 0 0.0 0 0 0.0 0.0
hdisk20 2 0.0 33 270 0.0 0.8
hdisk22 10 0.0 320 2563 0.0 0.5
hdisk23 0 0.0 0 0 0.0 0.0
hdisk24 0 0.0 0 0 0.0 0.0
hdisk21 0 0.0 0 0 0.0 0.0
hdisk25 0 0.0 0 0 0.0 0.0
hdisk26 0 0.0 0 0 0.0 0.0
hdisk27 0 0.0 0 0 0.0 0.0
hdisk28 0 0.0 0 0 0.0 0.0
hdisk29 0 0.0 0 0 0.0 0.0
hdisk30 0 0.0 0 0 0.0 0.0
hdisk31 35 0.0 1140 9122 0.0 0.4
hdisk32 0 0.0 0 0 0.0 0.0
hdisk33 0 0.0 5 47 0.0 0.2
hdisk34 0 0.0 0 0 0.0 0.0
hdisk35 0 0.0 0 0 0.0 0.0
hdisk36 0 0.0 0 0 0.0 0.0
hdisk37 0 0.0 0 0 0.0 0.0
hdisk39 0 0.0 0 0 0.0 0.0
hdisk40 0 0.0 0 0 0.0 0.0
hdisk41 0 0.0 0 0 0.0 0.0
hdisk38 0 0.0 0 0 0.0 0.0
hdisk42 0 0.0 0 0 0.0 0.0
hdisk43 0 0.0 0 0 0.0 0.0
hdisk44 17 0.0 951 7609 0.0 0.2
hdisk46 0 0.0 10 87 0.0 0.2
hdisk47 0 0.0 0 0 0.0 0.0
hdisk48 0 0.0 0 0 0.0 0.0
hdisk45 0 0.0 0 0 0.0 0.0
hdisk49 0 0.0 0 0 0.0 0.0
hdisk50 0 0.0 0 0 0.0 0.0
hdisk51 0 0.0 0 0 0.0 0.0
hdisk52 0 0.0 0 0 0.0 0.0
hdisk53 0 0.0 0 0 0.0 0.0
hdisk54 0 0.0 0 0 0.0 0.0
hdisk55 0 0.0 0 0 0.0 0.0
hdisk57 7 0.0 487 3900 0.0 0.2
hdisk58 0 0.0 0 0 0.0 0.0
hdisk59 0 0.0 23 191 0.0 0.5
hdisk56 0 0.0 0 0 0.0 0.0
hdisk60 0 0.0 0 0 0.0 0.0
hdisk61 7 0.0 540 4322 0.0 0.2
hdisk62 0 0.0 0 0 0.0 0.0
hdisk63 0 0.0 0 0 0.0 0.0
hdisk64 0 0.0 0 0 0.0 0.0
hdisk65 0 0.0 0 0 0.0 0.0
hdisk66 0 0.0 0 0 0.0 0.0
hdisk68 0 0.0 0 0 0.0 0.0
hdisk69 0 0.0 0 0 0.0 0.0
hdisk67 0 0.0 0 0 0.0 0.0
hdisk71 0 0.0 0 0 0.0 0.0
hdisk70 0 0.0 0 0 0.0 0.0
hdisk74 0 0.0 0 0 0.0 0.0
hdisk76 0 0.0 0 0 0.0 0.0
hdisk77 0 0.0 0 0 0.0 0.0
hdisk78 0 0.0 0 0 0.0 0.0
hdisk75 0 0.0 0 0 0.0 0.0
hdisk73 0 0.0 0 0 0.0 0.0
hdisk80 0 0.0 0 0 0.0 0.0
hdisk81 0 0.0 0 0 0.0 0.0
hdisk82 0 0.0 0 0 0.0 0.0
hdisk79 0 0.0 0 0 0.0 0.0
hdisk84 0 0.0 0 0 0.0 0.0
hdisk72 0 0.0 0 0 0.0 0.0
hdisk83 0 0.0 0 0 0.0 0.0
hdisk87 0 0.0 0 0 0.0 0.0
hdisk88 0 0.0 0 0 0.0 0.0
hdisk89 0 0.0 0 0 0.0 0.0
hdisk86 0 0.0 0 0 0.0 0.0
hdisk92 0 0.0 0 0 0.0 0.0
hdisk85 0 0.0 0 0 0.0 0.0
hdisk93 0 0.0 0 0 0.0 0.0
hdisk90 0 0.0 0 0 0.0 0.0
hdisk94 0 0.0 0 0 0.0 0.0
hdisk91 0 0.0 0 0 0.0 0.0
hdisk96 0 0.0 0 0 0.0 0.0
hdisk98 0 0.0 0 0 0.0 0.0
hdisk95 0 0.0 0 0 0.0 0.0
hdisk99 0 0.0 0 0 0.0 0.0
hdisk100 0 0.0 0 0 0.0 0.0
hdisk97 0 0.0 0 0 0.0 0.0
hdisk101 0 0.0 0 0 0.0 0.0
hdisk102 0 0.0 0 0 0.0 0.0
hdisk103 0 0.0 0 0 0.0 0.0
hdisk105 0 0.0 0 0 0.0 0.0
hdisk106 0 0.0 0 0 0.0 0.0
hdisk107 0 0.0 0 0 0.0 0.0
hdisk104 0 0.0 0 0 0.0 0.0
hdisk109 0 0.0 0 0 0.0 0.0
hdisk110 0 0.0 0 0 0.0 0.0
hdisk111 0 0.0 0 0 0.0 0.0
hdisk113 0 0.0 0 0 0.0 0.0
hdisk114 0 0.0 0 0 0.0 0.0
hdisk108 0 0.0 0 0 0.0 0.0
hdisk115 0 0.0 0 0 0.0 0.0
hdisk112 0 0.0 0 0 0.0 0.0
hdisk117 0 0.0 0 0 0.0 0.0
hdisk118 0 0.0 0 0 0.0 0.0
hdisk119 0 0.0 0 0 0.0 0.0
hdisk116 0 0.0 0 0 0.0 0.0
hdisk121 0 0.0 0 0 0.0 0.0
hdisk122 0 0.0 0 0 0.0 0.0
hdisk123 0 0.0 0 0 0.0 0.0
hdisk125 0 0.0 0 0 0.0 0.0
hdisk120 0 0.0 0 0 0.0 0.0
hdisk124 0 0.0 0 0 0.0 0.0
hdisk128 0 0.0 0 0 0.0 0.0
hdisk126 0 0.0 0 0 0.0 0.0
hdisk127 0 0.0 0 0 0.0 0.0
hdisk131 0 0.0 0 0 0.0 0.0
hdisk132 0 0.0 0 0 0.0 0.0
hdisk129 0 0.0 0 0 0.0 0.0
hdisk130 0 0.0 0 0 0.0 0.0
hdisk134 0 0.0 0 0 0.0 0.0
hdisk135 0 0.0 0 0 0.0 0.0
hdisk133 0 0.0 0 0 0.0 0.0
hdisk136 0 0.0 0 0 0.0 0.0
hdisk138 0 0.0 0 0 0.0 0.0
hdisk139 0 0.0 0 0 0.0 0.0
hdisk140 0 0.0 0 0 0.0 0.0
hdisk137 0 0.0 0 0 0.0 0.1
hdisk141 0 0.0 0 0 0.0 0.0
hdisk143 0 0.0 0 0 0.0 0.0
hdisk144 0 0.0 0 0 0.0 0.0
hdisk142 0 0.0 0 0 0.0 0.0
hdisk147 0 0.0 0 0 0.0 0.0
hdisk148 0 0.0 0 0 0.0 0.0
hdisk149 0 0.0 0 0 0.0 0.0
hdisk146 0 0.0 0 0 0.0 0.0
hdisk145 0 0.0 0 0 0.0 0.0
hdisk4 0 0.0 0 0 0.0 0.0
hdisk12 0 0.0 0 0 0.0 0.0
hdisk11 0 0.0 0 0 0.0 0.0
hdisk17 0 0.0 0 0 0.0 0.0
hdisk6 0 0.0 0 0 0.0 0.0
hdisk0 0 0.0 0 0 0.0 0.0
hdisk1 0 0.0 0 0 0.0 0.0
hdisk2 0 0.0 0 0 0.0 0.0
可以看到虽然本机连接的磁盘有140 余块，但读写主要发生在disk18,disk22,disk44,disk57,disk61 。
查看热点对象
SQL> set linesize 180
SQL> col object_name for a40
SQL> select * from
2 (select
3 ob.owner, ob.object_name, sum(b.tch) Touchs
4 from x$bh b , dba_objects ob
5 where b.obj = ob.data_object_id
6 and b.ts# > 0
7 group by ob.owner, ob.object_name
8 order by sum(tch) desc)
9 where rownum <=10 ;
OWNER OBJECT_NAME TOUCHS
------------------------------ ---------------------------------------- ----------
DSG DJ_NSRXX 8248380
DSG SB_ZSXX 4351836
DSG FP_DEAL_INFO 4013427
DSG IDX_SB_ZSXX_FQ_DZDAH 317808
DSG SB_SBXX 258592
DSG HD_DQDEHDB 141183
DSG IDX_SB_SBXX_DZDAH_SSQ 128800
DSG DJ_SZ_JBXX 112147
DSG IND_SB_ZSXX_FQ_NSRSWJG 68625
DSG IDX_FPDEALINFO_NSRDZDAH 41999
可以看到DJ_NSRXX 和SB_ZSXX 这两张表为热点对象
SQL> select TABLE_NAME ,INDEX_NAME ,TABLESPACE_NAME from dba_indexes where table_name='DJ_NSRXX'
TABLE_NAME INDEX_NAME TABLESPACE_NAME
------------------------------ ------------------------------ ------------------------------
DJ_NSRXX IDX_DJ_NSRXX_NSRDNBM XMZG_TEM_DAT
DJ_NSRXX IDX_DJ_NSRXX_NSRSBH XMZG_TEM_DAT
DJ_NSRXX PK_DJ_NSRXX XMZG_TEM_DAT
DJ_NSRXX PK_DJ_NSRXX FJLTAIS_IDX
DJ_NSRXX IDX_DJ_NSRXX_DJZCLX_DM FJLTAIS_IDX
DJ_NSRXX IDX_DJ_NSRXX_HY_DM FJLTAIS_IDX
DJ_NSRXX IDX_DJ_NSRXX_JDXZ_DM FJLTAIS_IDX
DJ_NSRXX IDX_DJ_NSRXX_LRR_DM FJLTAIS_IDX
DJ_NSRXX IDX_DJ_NSRXX_NSRDNBM FJLTAIS_IDX
DJ_NSRXX IDX_DJ_NSRXX_NSRSBH FJLTAIS_IDX
DJ_NSRXX IDX_DJ_NSRXX_NSRZT_DM FJLTAIS_IDX
TABLE_NAME INDEX_NAME TABLESPACE_NAME
------------------------------ ------------------------------ ------------------------------
DJ_NSRXX IDX_DJ_NSRXX_NSR_SWJG_DM FJLTAIS_IDX
DJ_NSRXX IDX_DJ_NSRXX_WSPZXH FJLTAIS_IDX
DJ_NSRXX IDX_DJ_NSRXX_ZGSWRY_DM FJLTAIS_IDX
DJ_NSRXX IDX_DJ_NSRXX_ZJHM FJLTAIS_IDX
DJ_NSRXX IDX_DJ_NSRXX_NSRMC FJLTAIS_IDX
DJ_NSRXX IDX_DJ_NSRXX_NSRDNBM FJLTAIS_IDX
DJ_NSRXX IDX_DJ_NSRXX_DJZCLX_DM
DJ_NSRXX IDX_DJ_NSRXX_HY_DM
DJ_NSRXX IDX_DJ_NSRXX_JDXZ_DM
DJ_NSRXX IDX_DJ_NSRXX_LRR_DM
DJ_NSRXX IDX_DJ_NSRXX_NSRSBH FJLTAIS_IDX
TABLE_NAME INDEX_NAME TABLESPACE_NAME
------------------------------ ------------------------------ ------------------------------
DJ_NSRXX IDX_DJ_NSRXX_NSRMC
DJ_NSRXX IDX_DJ_NSRXX_SWDJBLX FJLTAIS_IDX
DJ_NSRXX IDX_DJ_NSRXX_NSRZT_DM
DJ_NSRXX IDX_DJ_NSRXX_NSR_SWJG_DM
DJ_NSRXX IDX_DJ_NSRXX_WSPZXH
DJ_NSRXX IDX_DJ_NSRXX_ZGSWRY_DM
DJ_NSRXX IDX_DJ_NSRXX_ZJHM
DJ_NSRXX PK_DJ_NSRXX FJLTAIS_DAT
可以看到
IDX_DJ_NSRXX_DJZCLX_DM
IDX_DJ_NSRXX_HY_DM
IDX_DJ_NSRXX_JDXZ_DM
IDX_DJ_NSRXX_LRR_DM
IDX_DJ_NSRXX_NSRMC
IDX_DJ_NSRXX_NSRZT_DM
IDX_DJ_NSRXX_NSR_SWJG_DM
IDX_DJ_NSRXX_WSPZXH
IDX_DJ_NSRXX_ZGSWRY_DM
IDX_DJ_NSRXX_ZJHM
PK_DJ_NSRXX
IDX_DJ_NSRXX_NSRDNBM
IDX_DJ_NSRXX_NSRSBH
PK_DJ_NSRXX
这些索引并没有正确的存储在索引表空间FJLTAIS_IDX 上，查看消耗CPU 时间最多的sql
SELECT (select NSRDNBM from dj_nsrxx where nsrdzdah=a.nsrdzdah) AS NSRDNBM, A.MC AS NSRMC, (select NSRSBH from dj_nsrxx where nsrdzdah=a.nsrdzdah) AS NSRSBH, A.ZJHM AS ZJHM, A.XSSR AS JSJE, A.SL AS SL, A.YNSE AS YNSE, A.SE AS SE, TO_CHAR(A.SBRQ, 'YYYY-MM-DD') AS SBRQ, TO_CHAR(A.SSSQ_Q, 'YYYY-MM-DD') || ' - ' || TO_CHAR(A.SSSQ_Z, 'YYYY-MM-DD') AS SKSSQ, TO_CHAR(A.XJQX, 'YYYY-MM-DD') AS XJQX, TO_CHAR(A.SJRQ_JZ, 'YYYY-MM-DD') AS SJRQ, TO_CHAR(A.RKRQ, 'YYYY-MM-DD') AS RKRQ, TO_CHAR(A.RKRQ_JZ, 'YYYY-MM-DD') AS RKRQ_JZ, TO_CHAR(A.KPRQ, 'YYYY-MM-DD') AS KPRQ, P_GET_CODENAME('DM_SBFS', A.SBFS_DM) AS SBFS_MC, P_GET_CODENAME('DM_SKZT', A.SKZT_DM) AS SKZT_MC, P_GET_CODENAME('DM_SKSX', A.SKSX_DM) AS SKSX_MC, (SELECT ZSPM_MC FROM DM_ZSPM WHERE ZSXM_DM =A.ZSXM_DM AND ZSPM_DM=A.ZSPM_DM) AS ZSPM_MC, A.NSR_SWJG_DM AS NSR_SWJG_DM, A.ZSXM_DM AS ZSXM_DM, A.YSKM_DM AS YSKM_DM, A.YSFPBL_DM AS YSFPBL_DM, A.JKPZLRR_DM AS JKPZLRR_DM, A.SJXHR_DM AS SJXHR_DM, A.RKXHR_DM AS RKXHR_DM, A.ZGSWRY_DM AS ZGSWRY_DM, A.LRR_DM AS LRR_DM, A.SKSS_SWJG_DM AS SKSS_SWJG_DM, A.ZSJG_DM AS ZSJG_DM, A.JKPZZL_DM AS JKPZZL_DM, TO_CHAR(A.JKPZXH) AS JKPZXH, A.ZG AS ZG, A.ZH AS ZH, A.SKGK_DM as skgkDm, DECODE( B.DDLXQY_BZ, 'Z', '????????', 'S', '????????', '') AS "ddlxqyBz" FROM SB_ZSXX A, DJ_DDLXQY B, (SELECT E.SWJG_DM FROM DM_SWJG E WHERE E.SWJG_BZ = 'J' CONNECT BY SJ_SWJG_DM = PRIOR SWJG_DM START WITH SWJG_DM = :1) C WHERE A.NSR_SWJG_DM = C.SWJG_DM AND A.NSRDZDAH = B.NSRDZDAH(+) AND A.TZLX_DM IN('1', '4') AND A.SE!=0 AND A.YZFSRQ_JZ IS NOT NULL AND A.SBRQ >= TO_DATE(:2, 'YYYY-MM-DD') AND A.SBRQ <= TO_DATE(:3, 'YYYY-MM-DD') AND A.ZSXM_DM = :4 AND A.DQ=:5
执行计划如下
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1223 | 273K| | 17606 (1)| 00:03:32 | | |
|* 1 | TABLE ACCESS BY INDEX ROWID | GF_CBDJYB_DZ | 1 | 37 | | 4 (0)| 00:00:01 | | |
|* 2 | INDEX RANGE SCAN | IDX_GF_CBDJYB_DZ_YBIDXH | 1 | | | 3 (0)| 00:00:01 | | |
|* 3 | TABLE ACCESS BY INDEX ROWID | GF_CBDJYB_DZ | 1 | 37 | | 4 (0)| 00:00:01 | | |
|* 4 | INDEX RANGE SCAN | IDX_GF_CBDJYB_DZ_YBIDXH | 1 | | | 3 (0)| 00:00:01 | | |
| 5 | SORT AGGREGATE | | 1 | 27 | | | | | |
|* 6 | TABLE ACCESS FULL | GF_CBDJYB_DZ | 1 | 27 | | 332 (1)| 00:00:04 | | |
| 7 | SORT AGGREGATE | | 1 | 27 | | | | | |
|* 8 | TABLE ACCESS FULL | GF_CBDJYB_DZ | 1 | 27 | | 332 (1)| 00:00:04 | | |
|* 10 | HASH JOIN SEMI | | 1223 | 200K| | 15159 (1)| 00:03:02 | | |
|* 11 | HASH JOIN | | 5633 | 836K| 2104K| 12688 (1)| 00:02:33 | | |
| 12 | NESTED LOOPS | | 18507 | 1879K| | 10148 (1)| 00:02:02 | | |
| 13 | VIEW | | 15 | 195 | | 2 (0)| 00:00:01 | | |
|* 14 | FILTER | | | | | | | | |
|* 15 | CONNECT BY WITH FILTERING | | | | | | | | |
| 16 | TABLE ACCESS BY INDEX ROWID | DM_SWJG | 1 | 24 | | 2 (0)| 00:00:01 | | |
|* 17 | INDEX UNIQUE SCAN | PK_DM_SWJG | 1 | | | 1 (0)| 00:00:01 | | |
| 18 | NESTED LOOPS | | | | | | | | |
| 19 | CONNECT BY PUMP | | | | | | | | |
| 20 | TABLE ACCESS BY INDEX ROWID | DM_SWJG | 15 | 360 | | 2 (0)| 00:00:01 | | |
|* 21 | INDEX RANGE SCAN | IDX_DM_SWJG_SJ_SWJG_DM | 15 | | | 1 (0)| 00:00:01 | | |
| 22 | PARTITION RANGE ITERATOR | | 1234 | 109K| | 676 (0)| 00:00:09 | KEY | KEY |
|* 23 | TABLE ACCESS BY LOCAL INDEX ROWID| DJ_NSRXX | 1234 | 109K| | 676 (0)| 00:00:09 | KEY | KEY |
|* 24 | INDEX RANGE SCAN | IDX_DJ_NSRXX_NSR_SWJG_DM | 2049 | | | 42 (0)| 00:00:01 | KEY | KEY |
|* 25 | TABLE ACCESS FULL | GF_NFRXX | 240K| 11M| | 1752 (1)| 00:00:22 | | |
|* 26 | TABLE ACCESS FULL | GF_DJXZ | 229K| 3592K| | 2469 (2)| 00:00:30 | | |
| 27 | TABLE ACCESS BY INDEX ROWID | DJ_NSRXX_KZ | 1 | 61 | | 2 (0)| 00:00:01 | | |
|* 28 | INDEX UNIQUE SCAN | PK_DJ_NSRXX_KZ | 1 | | | 1 (0)| 00:00:01 | | |
-------------------------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("CBDJYIDZ"."NSRDZDAH"=:B1 AND "CBDJYIDZ"."ZIDBZ"='Y' AND "CBDJYIDZ"."YXBZ"='Y' AND "CBDJYIDZ"."XYBZ"='Y')
2 - access("CBDJYIDZ"."YBIDXH"=:B1)
3 - filter("CBDJYIDZ"."NSRDZDAH"=:B1 AND "CBDJYIDZ"."ZIDBZ"='Y' AND "CBDJYIDZ"."YXBZ"='Y' AND "CBDJYIDZ"."XYBZ"='Y')
4 - access("CBDJYIDZ"."YBIDXH"=:B1)
6 - filter("CBDJYIDZ"."NSRDZDAH"=:B1 AND "CBDJYIDZ"."ZIDBZ"<>'Y' AND "CBDJYIDZ"."YXBZ"='Y' AND "CBDJYIDZ"."XYBZ"='Y')
8 - filter("CBDJYIDZ"."NSRDZDAH"=:B1 AND "CBDJYIDZ"."ZIDBZ"<>'Y' AND "CBDJYIDZ"."YXBZ"='Y' AND "CBDJYIDZ"."XYBZ"='Y')
10 - access("DJXZ"."NSRDZDAH"="NSRXX"."NSRDZDAH")
11 - access("NSRXX"."NSRDZDAH"="NFRXX"."NSRDZDAH")
14 - filter("YXBZ"='Y')
15 - access("SJ_SWJG_DM"=PRIOR "SWJG_DM")
17 - access("SWJG_DM"='23503000000')
21 - access("SJ_SWJG_DM"=PRIOR "SWJG_DM")
23 - filter("NSRXX"."HJBZ_DM"<>'000' AND "NSRXX"."HJBZ_DM"<>'001')
24 - access("F"."SWJG_DM"="NSRXX"."NSR_SWJG_DM")
25 - filter("NFRXX"."NFRZT_DM"<>'50' AND "NFRXX"."NFRZT_DM"<>'10')
26 - filter("DJXZ"."XZ"='45' AND "DJXZ"."SXBZ"='Y' AND "DJXZ"."YXBZ"='Y')
28 - access("NSRXX"."NSRDZDAH"="NSRXXKZ"."NSRDZDAH")
54 rows selected.
可以看到，使用了IDX_DJ_NSRXX_NSR_SWJG_DM 索引，但由于没有有效分离表和索引的存储，有可能造成db file sequential read 顺序读取磁盘等待事件。个人认为就本例而言，db file sequential read 和 CPU 100% 关系不会太大，但这也是值得注意的一方面。
使用vmstat 1 查看系统内存及cpu 使用情况
并没有发生内存不足的现象，但CPU 却有高达38 的进程等待
查询了下当时系统中活动的session ，发现只在90 左右。并发数不高(查询记录没有及时保存)
查询库db2 2012-07-02 09:00~~10:00 AWR 报告
查询库db2 2012-07-04 11:00~~12:00 AWR 报告
可以看到cache buffers chains 很高，该等待事件是由于不同进程在buffer 中争用同一个数据块导致的，即热点对象，很容易引起CPU 进程堵塞，使用率升高。
查看数据库热点对象如下
热点对象有DJ_NSRXX ，SB_ZSXX ，FP _DEAL_INFO
查看这些表的pct_free 值
SQL> select table_name,pct_free from dba_tables where table_name in ('DJ_NSRXX','SB_ZSXX','FP _DEAL_INFO');
TABLE_NAME PCT_FREE
------------------------------ ----------
SB_ZSXX 10
DJ_NSRXX 10
SB_ZSXX 10
SB_ZSXX 10
SB_ZSXX 10
DJ_NSRXX 10
SB_ZSXX
DJ_NSRXX
8 rows selected.
这些表的pct_free 均为10% ，可以考虑扩大pct_free 值，使数分布到多个数据块中以减少热点块争用。Pct_free 值需要逐步调整并同时进行观察才可确认调整为何值合适。
查询库db2 2012-07-02 09:00~~10:00 AWR 报告
|
Estd Interconnect traffic (KB) |
119,976.69 |
查询库db2 2012-07-04 11:00~~12:00 AWR 报告
|
Estd Interconnect traffic (KB) |
142,074.05 |
可以看到Estd Interconnect traffic (KB) 非常的高，表示节点之间频繁数据块，进行gc cr 块的构造。而且从上文提到的等待事件也可以看出，gc cr multi block request 在两个awr 中都有体现，是主要等待事件。
查询库db2 2012-07-02 09:00~~10:00 AWR 报告
查询库db2 2012-07-04 11:00~~12:00 AWR 报告
Logical reads
非常高和
gc cr multi block request
等待事件相吻合。如上文所述，
gc cr multi block request
会造成CPU
对内存的调度和管理，会消耗CPU
时间。结合gc cr multi block request
和逻辑读非常高以及
cache buffers chains
的情况来看，个人认为，gc cr multi block request
和热点块共同造成了CPU 100%
的问题，且gc cr multi block request
为主要问题，主要依据
：Estd Interconnect traffic (KB)异常的高，而且一般
cache buffers chains引起的问题都会在top 5等待事件中体现，故判断
gc cr multi block request为主要原因。
个人建议开放商在调整sql
时避免全表扫描，这样会避免内存的频繁调度。
解决
gc cr multi block request
问题应在rac
层面上进行应用分离，即不同节点处理不同应用，节点之间通过配置，做为彼此的备用节点，在节点宕机时可以结果相关应用，提供高可用性。事实上在整理这篇报告给客户的时候也整理出了一些SQL ordered by CPU Time给客户，毕竟客户要的就是这个吗，总得满足下人家的需求
本文原创，转载请注明出处、作者
如有错误，欢迎指正
邮箱:czmcj@163.com
顶
踩
发表评论
-
AIX平台下磁盘的PVID对ASM磁盘的破坏
2014-03-19 20:53 2702这篇文章将通过两篇MOS文章来讨论AIX平台下为磁盘分配 ... -
Bug 9020054,ORA-8103 BEING HIT DURING GATHERING OF STATISTICS ON TABLE PARTITION
2013-12-01 09:22 1829Bug 9020054 : ORA-8103 ... -
oracle数据库hanganalyze(原创)
2013-06-23 14:11 8241为什么要使用hanganalyzeOracle 数据库“真 ... -
Oracle:并行操作为什么无法执行(老白)
2013-06-23 10:30 5663在一次系统割接的时候，我们碰到一个十分奇怪的现象。由于进行 ... -
补写的2小节DBA日记
2013-06-05 21:52 13576月8日 ITL等待引发的RAC性能问题 从这几天的情况 ... -
ORA-27054故障排除
2013-03-08 17:57 12852在数据备份过程中，由于目标是使用NFS文件系统，因此在导入 ... -
长时间latch free等待——记一次系统异常的诊断过程
2013-01-09 19:17 3636今天发现一个报表数据库中SQL运行异常，简单记录一下问题的诊断 ... -
ORA-15063: ASM discovered an insufficient number of disks for diskgroup(原创)
2012-11-25 16:59 13015ORA-15063: ASM discovered an in ... -
libpthread.so.0: cannot open shared object file解决方法(原创)
2012-11-24 17:33 17633在linux 5上装10G RAC时，常常会碰到“libpth ... -
ora-02020故障诊断详解(原创)
2012-07-16 12:54 3102ORA-2020错发生在一个分布式事务使用的dblink数超过 ... -
DBA手记:System State转储分析之问题定位
2012-04-19 22:20 2067在 Oracle 数据库的运行过程中，可能会因为一些异常遇 ... -
ORA-02050故障诊断一例
2012-04-05 17:20 8500昨天客户反映说在下午某时间段有几个事务失败了，让我查下当时数据 ... -
ORA-00308: cannot open archived log(原创)
2012-03-23 09:36 16144笔者在为客户配置DG时发现主备库日志无法正常传输，经仔细检查后 ... -
ORA-00600: internal error code, arguments: [kcblasm_1], [103]原创
2012-03-23 09:36 3062故障报错 Mon Mar 19 11:30:03 GMT ... -
ORA-00600: internal error code, arguments: [kglhdda-bad-free](原创)
2012-03-22 09:16 2928故障报错如下 Thu Mar 15 09:51:29 G ... -
ORA-27300,ORA-27301,ORA-27302: failure occurred at: skgpalive1(原创)
2012-03-22 08:58 3299故障报错如下 Wed Mar 07 16:4 ... -
ora-07445错误相关内容
2012-03-01 17:14 1756本文档主要介绍ora-07445 错误相关内容，并给出了对这 ... -
记一次Oracle 生产库还原归档日志经历(原创)
2012-02-17 10:12 4326中午刚去吃饭，就接到同事电话说急着要恢复生产库上的归档日志。系 ... -
SMON: Parallel transaction recovery tried 引发的问题
2012-01-04 11:26 2339SMON: Parallel transaction rec ... -
ORA-00444，ORA-07446故障排查
2011-12-14 16:58 4579phenomenon startup ORA-00 ...
相关推荐
2.4.4 Oracle数据库的引导 91 2.4.5 系统对象与bootstrap$ 92 2.4.6 bootstrap$的重要性 94 2.4.7 BBED工具的简要介绍 95 2.4.8 坏块的处理与恢复 97 第3章 参数及参数文件 103 3.1 初始化参数的分类...
经典知识库：MySQL故障诊断常用方法手册 经典知识库：Oracle 19c X86下移经验分享 经典知识库：Oracle DBA的SQL编写技能提升宝典 经典知识库：Oracle PDB Refresh实战分享 经典知识库：Oracle数据库索引分裂详解 ...
针对数据库的启动和关闭、控制文件与数据库初始化、参数及参数文件、数据字典、内存管理、Buffer Cache与Shared Pool原理、重做、回滚与撤销、等待事件、性能诊断与SQL优化等几大Oracle热点主题，本书从基础知识...
针对数据库的启动和关闭、控制文件与数据库初始化、参数及参数文件、数据字典、内存管理、Buffer Cache与Shared Pool原理、重做、回滚与撤销、等待事件、性能诊断与SQL优化等几大Oracle热点主题，本书从基础知识...
针对数据库的启动和关闭、控制文件与数据库初始化、参数及参数文件、数据字典、内存管理、Buffer Cache与Shared Pool原理、重做、回滚与撤销、等待事件、性能诊断与SQL优化等几大Oracle热点主题，本书从基础知识...
对CRS的故障诊断和分析,参加本文档中RAC部分的MOS文档. 数据库响应慢 应急处理步骤： （1）找到占用CPU资源大的sql或者模块，然后停掉此应用模块。 （2）如果属于由于种种原因引起的数据库hang住情况，...
§1.1 Oracle数据库结构 23 §1.1.1 Oracle数据字典 23 §1.1.2 表空间与数据文件 24 §1.1.3 Oracle实例(Instance) 24 §1.2 Oracle文件 26 §1.2.1 数据文件 26 §1.2.2 控制文件 26 §1.2.3 重做日志文件 26 §...
Bob Bryla是Oracle 9i和10g的认证专家，他在数据库设计、数据库应用程序开发、培训和Oracle数据库管理等方面拥有20多年的工作经验,他也足Dodgeville的Land'End公司的首席Internet数据库设计师和Oracle DBA. ...
Bob Bryla是Oracle 9i和10g的认证专家，他在数据库设计、数据库应用程序开发、培训和Oracle数据库管理等方面拥有20多年的工作经验,他也足Dodgeville的Land'End公司的首席Internet数据库设计师和Oracle DBA. ...
《mysql管理之道：性能调优、高可用与监控》由资深mysql专家撰写，以最新的mysql版本为基础，以构建高性能mysql服务器为核心，从故障诊断、表设计、sql优化、性能参数调优、mydumper逻辑、xtrabackup热备份与恢复、...