您的位置:首页 > 数据库 > Oracle

ORACLE实际执行计划与预估执行计划不一致性能优化案例

2017-08-19 16:16 1301 查看
在一台ORACLE服务器上做巡检时,使用下面SQL找出DISK_READ最高的TOPSQL分析时,分析过程中,有一条SQL语句的一些反常现象,让人觉得很奇怪:

SELECTSQL_ID,
SQL_TEXT,
DISK_READS,
BUFFER_GETS,
PARSING_SCHEMA_NAME,
EXECUTIONS
FROMV$SQLAREA
ORDERBYDISK_READSDESC;


在SQLDeveloper中查看SQL的预估执行计划,发现执行计划走INDEXUNIQUESCAN,而且IOCOST其实不高。如下所示,而且执行次数也不是非常多,那么推断:很有可能这个SQL的实际执行计划跟预估的执行计划有很大偏差。

SELECT
"Extent1"."SC_NO"AS"SC_NO",
"Extent1"."CUSTOMER_CD"AS"CUSTOMER_CD",
"Extent1"."FACTORY_CD"AS"FACTORY_CD",
"Extent1"."REQ_USER_ID"AS"REQ_USER_ID",
"Extent1"."REQ_USER_GRP_ID"AS"REQ_USER_GRP_ID"
FROM"SC_HD""Extent1"
WHERE("Extent1"."SC_NO"=:p__linq__0)AND(ROWNUM<=(1))






于是根据SQL_ID生成了对应SQL的awrsqrpt报表,如下截图所示,实际执行计划确实是全表扫描,BufferGets与DiskReads也很高





在sqltrpt.sql里面分析查看该SQL时,如下所示,可以发现其绑定变量存在隐式转换(implicitdatatypeconversion),导致执行计划走全表扫描





于是分析了一下绑定变量的类型,发现:P__LINQ__0的类型为NVARCHAR(32)而实际上字段SC_NO为VARCHAR(16),所以肯定是应用程序里面给该绑定变量赋值出现了问题。

SQL>COLNAMEFORA32;
SQL>COLDATATYPE_STRINGFORA20;
SQL>COLVALUE_STRINGFORA20;
SQL>SELECTNAME,DATATYPE_STRING,VALUE_STRING
2FROMv$sql_bind_capture
3WHERESQL_ID='&SQL_ID';
Entervalueforsql_id:dhg6qnxv9c4nz
old3:WHERESQL_ID='&SQL_ID'
new3:WHERESQL_ID='dhg6qnxv9c4nz'
NAMEDATATYPE_STRINGVALUE_STRING
------------------------------------------------------------------------
:P__LINQ__0NARCHAR2(32)GS17K16005
SQL>


后面开发人员协助检查发现,因为这个SQL是代码中Lambda表达式自动生成,后面在Property中设置了字段类型以及长度,问题解决。

//表SC_HD

modelBuilder.Entity<SC_HD>().ToTable("SC_HD",OracleSchema);

modelBuilder.Entity<SC_HD>().HasKey(x=>x.SC_NO);



内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: