数据从11.2.0.3迁移到12.2.0.1,使用数据泵迁移,迁移后发现数据库DBTime很高,并且部分SQL执行时间过长,这个是一个核心系统需要尽快定位问题,我们直接从ASH找出最大的等待SQL以及等待事件。发现都是涉及一条SQL,这条SQL并发,一个小时执行了近700次。而在之前库则没有这个问题 关注图片中的水印获取 。

SQL> select sql_id ,event,count(*) from v$active_session_history group by sql_id,event order by count(*);
1a3svb46kv8x9 direct path write temp 10449
1a3svb46kv8x9 latch: cache buffers chains 10605
1a3svb46kv8x9 db file sequential read 27013
1a3svb46kv8x9 db file parallel read 45292
1a3svb46kv8x9 read by other session 90551
1a3svb46kv8x9 166732
这些等待事件都说明该SQL的执行计划不是最优,之前跑地好好的,为什么迁移后就变得这么慢,且如此的耗费资源拉高DBTime,下面是执行计划
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID 1a3svb46kv8x9, child number 0
-------------------------------------
SELECT T.STUDS_ID, T.TCR_STUDSID, T.TEST_ID, T.TEST_STUDS_ID,
T.TEST_TCR_STUDSID, T.BANK_ID, T.CHANNEL_ID, T.STUDSTYPE_ID,
T.STUDS_TIME, T.STUDS_AMOUNT, DECODE(T.STUDS_STATUS, '2', '1',
T.STUDS_STATUS) AS STUDS_STATUS FROM MAY_STUDS_WEB T WHERE T.TEST_ID =
:B1 AND T.STUDSTYPE_ID NOT IN ( '06','09','10','11') AND EXISTS (SELECT
* FROM TABLE(CAST(:B2 AS TB_MAY_QRY_PLAT)) R WHERE R.STUDS_ID =
T.TCR_STUDSID)
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/69979862/viewspace-2748735/ ,如需转载,请注明出处,否则将追究法律责任。