Oracle数据库服务器CPU持续100%之等待事件asynch descriptor resize

简介: 2017年5月11日下午13点,一地市技术反应服务器响应慢,CPU长时间100%如图: 经观察数据库服务器资源监视器,发现是oracle进程导致的,登录数据库查询数据库等待事件,发现asynch descriptor resize居高不下...
2017年5月11日下午13点,一地市技术反应服务器响应慢,CPU长时间100%如图:

经观察数据库服务器资源监视器,发现是oracle进程导致的,登录数据库查询数据库等待事件,发现 asynch descriptor resize居高不下

按照等待事件类型查询对应的会话信息如下,有30多个会话同时执行同一条sql语句: b7rng1bdrzzkq

查询sql语句 b7rng1bdrzzkq对应的sql文本如下:

b7rng1bdrzzkq的执行计划如下:
PLAN_TABLE_OUTPUT 
--------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID b7rng1bdrzzkq, child number 0 
------------------------------------- 
select zdb.HOSPITAL_ID, 
zdh.HOSPITAL_NAME, 
zdb.hisid, 
zdb.HS_PATIENT_NAME as 
PATIENT_NAME, 
hs_area_code as 
DEPTNAME, 
admission_disease_name as 
RULE_NAME, 
round(zdb.TOTAL_COST/10000,4) as Total_Costs 
from zk_dw_bill zdb, zk_dim_hospital zdh 
where zdb.HOSPITAL_ID = zdh.HOSPITAL_ID_SZ 
and exists 
(select 1 from 
zk_dw_billdetail zdbd where zdb.HISID = zdbd.pid 
AND zdbd.item_date >= 
to_date('2017/5/11 00:00:00', 'yyyy/mm/dd HH24:mi:ss') 
AND zdbd.item_date <= 
to_date('2017/5/11 23:59:59', 'yyyy/mm/dd HH24: 
Plan hash value: 32811706 
------------------------------------------------------------------------------------------------------------------------------- 
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | 
------------------------------------------------------------------------------------------------------------------------------- 
| 0 | SELECT STATEMENT | | | | 13 (100)| | | | 
| 1 | SORT ORDER BY | | 1 | 424 | 13 (24)| 00:00:01 | | | 
| 2 | NESTED LOOPS | | | | | | | | 
| 3 | NESTED LOOPS | | 1 | 424 | 12 (17)| 00:00:01 | | | 
| 4 | MERGE JOIN CARTESIAN | | 1 | 362 | 12 (17)| 00:00:01 | | | 
| 5 | MERGE JOIN CARTESIAN | | 1 | 296 | 6 (17)| 00:00:01 | | | 
| 6 | SORT UNIQUE | | 1 | 261 | 2 (0)| 00:00:01 | | | 
| 7 | PARTITION RANGE SINGLE | | 1 | 261 | 2 (0)| 00:00:01 | 862 | 862 | 
|* 8 | TABLE ACCESS FULL | CLAIMDETAILHOSPITAL | 1 | 261 | 2 (0)| 00:00:01 | 862 | 862 | 
| 9 | BUFFER SORT | | 31 | 1085 | 4 (25)| 00:00:01 | | | 
| 10 | TABLE ACCESS FULL | DW_ZD_HOSPITAL_YB | 31 | 1085 | 3 (0)| 00:00:01 | | | 
| 11 | BUFFER SORT | | 1 | 66 | 9 (23)| 00:00:01 | | | 
| 12 | VIEW | VW_SQ_1 | 1 | 66 | 6 (17)| 00:00:01 | | | 
| 13 | HASH UNIQUE | | 1 | 2083 | | | | | 
|* 14 | HASH JOIN | | 1 | 2083 | 6 (17)| 00:00:01 | | | 
| 15 | PARTITION RANGE SINGLE | | 1 | 2077 | 2 (0)| 00:00:01 | 862 | 862 | 
|* 16 | TABLE ACCESS FULL | AUDITRESULT4HOSPITAL | 1 | 2077 | 2 (0)| 00:00:01 | 862 | 862 | 
| 17 | TABLE ACCESS FULL | GZ_LIST | 29 | 174 | 3 (0)| 00:00:01 | | | 
|* 18 | INDEX UNIQUE SCAN | PK_CLAIMHOSPITAL_HISID | 1 | | 0 (0)| | | | 
|* 19 | TABLE ACCESS BY GLOBAL INDEX ROWID| CLAIMHOSPITAL | 1 | 62 | 0 (0)| | ROWID | ROWID | 
------------------------------------------------------------------------------------------------------------------------------- 
Query Block Name / Object Alias (identified by operation id): 
------------------------------------------------------------- 
1 - SEL817CBF028SEL817CBF02 / CLAIMDETAILHOSPITAL@SEL510SEL817CBF02 / DW_ZD_HOSPITAL_YB@SEL312SELA7D54A5B / VW_SQ_1@SELE4B1058313SELA7D54A5B 
16 - SELA7D54A5B/AA@SEL
17 - SELA7D54A5B/GL@SEL
18 - SEL817CBF02/CLAIMHOSPITAL@SEL
19 - SEL817CBF02/CLAIMHOSPITAL@SEL
Outline Data 
------------- 
/*+ 
BEGIN_OUTLINE_DATA 
IGNORE_OPTIM_EMBEDDED_HINTS 
OPTIMIZER_FEATURES_ENABLE('11.2.0.1') 
DB_VERSION('11.2.0.1') 
OPT_PARAM('_optimizer_use_feedback' 'false') 
ALL_ROWS 
OUTLINE_LEAF(@"SELA7D54A5B")OUTLINELEAF(@"SEL817CBF02") 
UNNEST(@"SEL68B588A0")UNNEST(@"SEL7286615E") 
OUTLINE(@"SEL68B588A0")MERGE(@"SEL7") 
OUTLINE(@"SELE4B10583")OUTLINE(@"SEL7286615E") 
MERGE(@"SEL5")OUTLINE(@"SEL6") 
OUTLINE(@"SEL7")OUTLINE(@"SEL5428C7F1") 
MERGE(@"SEL2")MERGE(@"SEL3") 
OUTLINE(@"SEL4")OUTLINE(@"SEL5") 
OUTLINE(@"SEL1")OUTLINE(@"SEL2") 
OUTLINE(@"SEL3")FULL(@"SEL817CBF02" "CLAIMDETAILHOSPITAL"@"SEL5")FULL(@"SEL817CBF02" "DW_ZD_HOSPITAL_YB"@"SEL3")NOACCESS(@"SEL817CBF02" "VW_SQ_1"@"SELE4B10583")INDEX(@"SEL817CBF02" "CLAIMHOSPITAL"@"SEL2"("CLAIMHOSPITAL"."HISID"))LEADING(@"SEL817CBF02" "CLAIMDETAILHOSPITAL"@"SEL5""DWZDHOSPITALYB"@"SEL3" "VW_SQ_1"@"SELE4B10583""CLAIMHOSPITAL"@"SEL2") 
USE_MERGE_CARTESIAN(@"SEL817CBF02""DWZDHOSPITALYB"@"SEL3") 
USE_MERGE(@"SEL817CBF02""VWSQ1"@"SELE4B10583") 
USE_NL(@"SEL817CBF02""CLAIMHOSPITAL"@"SEL2") 
NLJ_BATCHING(@"SEL817CBF02""CLAIMHOSPITAL"@"SEL2") 
FULL(@"SELA7D54A5B""AA"@"SEL7") 
FULL(@"SELA7D54A5B""GL"@"SEL7") 
LEADING(@"SELA7D54A5B""AA"@"SEL7" "GL"@"SEL7")USEHASH(@"SELA7D54A5B" "GL"@"SEL7")USEHASHAGGREGATION(@"SELA7D54A5B") 
END_OUTLINE_DATA 
*/ 

Predicate Information (identified by operation id): 
--------------------------------------------------- 
8 - filter("ITEM_DATE"<=TO_DATE(' 2017-05-11 23:59:59', 'syyyy-mm-dd hh24:mi:ss')) 
14 - access("GL"."ID"=TO_NUMBER("AA"."RULECODE")) 
16 - filter("AA"."ITEM_DATE"<=TO_DATE(' 2017-05-11 23:59:59', 'syyyy-mm-dd hh24:mi:ss')) 
18 - access("HISID"="PID") 
filter("ITEM_1"="HISID") 
19 - filter("HOSPITAL_ID"="HOSPITAL_ID_SZ") 
Column Projection Information (identified by operation id): 
----------------------------------------------------------- 
1 - (#keys=1) INTERNAL_FUNCTION("SETTLE_DATE")[7], "HOSPITAL_ID"[VARCHAR2,128], "HOSPITAL_NAME"[VARCHAR2,128], 
"HISID"[VARCHAR2,128], "HS_PATIENT_NAME"[VARCHAR2,200], "HS_AREA_CODE"[VARCHAR2,100], 
"ADMISSION_DISEASE_NAME"[VARCHAR2,128], ROUND("TOTAL_COST"/10000,4)[22] 
2 - "HOSPITAL_NAME"[VARCHAR2,128], "HISID"[VARCHAR2,128], "HOSPITAL_ID"[VARCHAR2,128], 
"ADMISSION_DISEASE_NAME"[VARCHAR2,128], "HS_AREA_CODE"[VARCHAR2,100], "TOTAL_COST"[NUMBER,22], 
"HS_PATIENT_NAME"[VARCHAR2,200], "SETTLE_DATE"[DATE,7] 
3 - "HOSPITAL_ID_SZ"[VARCHAR2,128], "HOSPITAL_NAME"[VARCHAR2,128], "CLAIMHOSPITAL".ROWID[ROWID,10], 
"HISID"[VARCHAR2,128] 
4 - "PID"[VARCHAR2,500], "HOSPITAL_ID_SZ"[VARCHAR2,128], "HOSPITAL_NAME"[VARCHAR2,128], "ITEM_1"[VARCHAR2,128] 
5 - "PID"[VARCHAR2,500], "HOSPITAL_ID_SZ"[VARCHAR2,128], "HOSPITAL_NAME"[VARCHAR2,128] 
6 - (#keys=1) "PID"[VARCHAR2,500] 
7 - "PID"[VARCHAR2,500] 
8 - "PID"[VARCHAR2,500] 
9 - (#keys=0) "HOSPITAL_ID_SZ"[VARCHAR2,128], "HOSPITAL_NAME"[VARCHAR2,128] 
10 - "HOSPITAL_ID_SZ"[VARCHAR2,128], "HOSPITAL_NAME"[VARCHAR2,128] 
11 - (#keys=0) "ITEM_1"[VARCHAR2,128] 
12 - "ITEM_1"[VARCHAR2,128] 
13 - "AA"."CLAIM_ID"[VARCHAR2,128] 
14 - (#keys=1) "AA"."CLAIM_ID"[VARCHAR2,128] 
15 - "AA"."CLAIM_ID"[VARCHAR2,128], "AA"."RULECODE"[VARCHAR2,4000] 
16 - "AA"."CLAIM_ID"[VARCHAR2,128], "AA"."RULECODE"[VARCHAR2,4000] 
17 - "GL"."ID"[NUMBER,22] 
18 - "CLAIMHOSPITAL".ROWID[ROWID,10], "HISID"[VARCHAR2,128] 
19 - "HOSPITAL_ID"[VARCHAR2,128], "ADMISSION_DISEASE_NAME"[VARCHAR2,128], "HS_AREA_CODE"[VARCHAR2,100], 
"TOTAL_COST"[NUMBER,22], "HS_PATIENT_NAME"[VARCHAR2,200], "SETTLE_DATE"[DATE,7] 
已选择144行。
由于服务器CPU100%,响应极慢,由于是select查询语句,与地市技术人员沟通后,决定查杀等待事件 asynch descriptor resize对应的会话进程:

如图所示,会话查杀后,服务器CPU恢复正常水平。
目录
打赏
0
0
0
0
1
分享
相关文章
【赵渝强老师】Oracle的闪回数据库
Oracle闪回数据库功能类似于“倒带按钮”,可快速将数据库恢复至 earlier 状态,无需还原备份。本文介绍了闪回数据库的使用方法及实战案例:包括设置归档模式、开启闪回功能、记录SCN号、执行误操作后的恢复步骤等。通过具体 SQL 操作演示了如何利用闪回数据库恢复被误删的用户数据。注意,使用此功能前需确保数据库为归档模式。
【赵渝强老师】Oracle数据库的闪回表
本文介绍了Oracle数据库中的闪回表(Flashback Table)功能,它能够将表的数据快速恢复到特定时间点或系统改变号(SCN),无需备份。文章通过实战示例详细演示了如何使用闪回表恢复数据,包括授权、创建测试表、记录时间与SCN号、删除数据、启用行移动功能、执行闪回操作以及验证恢复结果等步骤。同时,还展示了如何通过触发器禁止插入操作,并在闪回过程中处理触发器的启用问题。文末附有视频讲解,帮助读者更好地理解闪回表的使用方法。
48 10
【赵渝强老师】Oracle数据库的闪回查询
本文介绍了Oracle数据库的闪回查询(Flashback Query)功能及其实际应用。闪回查询通过`AS OF`子句,结合时间戳或SCN号,可查询历史数据状态,帮助分析数据差异。文中通过具体示例演示了如何使用闪回查询:创建测试表、记录当前SCN号、更新数据并提交事务,最后通过闪回查询获取历史数据。附带的视频和代码块详细展示了操作步骤与结果。
崖山异构数据库迁移利器YMP初体验-Oracle迁移YashanDB
文章是作者小草对崖山异构数据库迁移利器 YMP 的初体验分享,包括背景、YMP 简介、体验环境说明、YMP 部署(含安装前准备、安装、卸载、启动与停止)、数据迁移及遇到的问题与解决过程。重点介绍了 YMP 功能、部署的诸多细节和数据迁移流程,还提到了安装和迁移中遇到的问题及解决办法。
解决Windows云服务器带宽和CPU利用率高的问题
本文针对Windows Server 2019 ×64系统,介绍如何排查云服务器带宽和CPU利用率过高的问题。通过任务管理器、性能监视器等工具定位高资源占用的进程,并根据进程是否正常采取相应措施。对于正常进程,建议优化或升级配置;对于异常进程,建议关闭进程并进行系统备份或还原。详细步骤包括使用“perfmon -res”查看资源使用情况,结合PID查找具体进程,分析处理后台任务、杀毒软件及应用程序的影响。
56 1
【赵渝强老师】Oracle数据库的闪回技术
在Oracle数据库操作中,难免会遇到误删表或提交错误事务等问题,可能导致数据丢失甚至数据库停止运行。传统解决方法依赖备份恢复,但需提前准备正确备份。为此,Oracle提供了闪回技术,无需备份即可快速恢复数据。它支持7种类型的操作,如闪回查询、版本查询、表恢复等,能有效应对逻辑损坏和用户错误。闪回技术基于还原(undo)数据管理,启用自动管理后可实现高效恢复。
【赵渝强老师】Oracle数据库的客户端工具
本文介绍了Oracle数据库的三种客户端工具:SQL*Plus、Oracle Enterprise Manager Database Express(EM)和SQL Developer的使用方法。首先通过命令行工具SQL*Plus登录数据库,创建用户并授权,建立部门与员工表,插入数据并查询;接着讲解了如何通过浏览器访问EM界面监控数据库及表空间状态;最后演示了SQL Developer的下载安装、连接配置以及执行查询的过程,帮助用户快速上手Oracle数据库管理与操作。
2025年阿里云服务器配置选择全攻略:CPU、内存、带宽与系统盘详解
在2025年,阿里云服务器以高性能、灵活扩展和稳定服务助力数字化转型,提供轻量应用服务器、通用型g8i实例等多样化配置,满足个人博客至企业级业务需求。针对不同场景(如计算密集型、内存密集型),推荐相应实例类型与带宽规划,强调成本优化策略,包括包年包月节省成本、ESSD云盘选择及地域部署建议。文中还提及安全设置、监控备份的重要性,并指出未来可关注第九代实例g9i支持的新技术。整体而言,阿里云致力于帮助用户实现性能与成本的最优平衡。 以上简介共计238个字符。
【YashanDB知识库】数据库获取时间和服务器时间不一致
【YashanDB知识库】数据库获取时间和服务器时间不一致
如何解决 MySQL 数据库服务器 CPU 飙升的情况
大家好,我是 V 哥。当 MySQL 数据库服务器 CPU 飙升时,如何快速定位和解决问题至关重要。本文整理了一套实用的排查和优化套路,包括使用系统监控工具、分析慢查询日志、优化 SQL 查询、调整 MySQL 配置参数、优化数据库架构及检查硬件资源等步骤。通过一个电商业务系统的案例,详细展示了从问题发现到解决的全过程,帮助你有效降低 CPU 使用率,提升系统性能。关注 V 哥,掌握更多技术干货。
234 0

热门文章

最新文章

推荐镜像

更多