性能调优常见的那些事儿-ORACLE上篇

Posted 2021-04-05 ABC心系

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了性能调优常见的那些事儿-ORACLE上篇相关的知识，希望对你有一定的参考价值。

文/施学勤、陈飞云

近期，有同事反映能不能分享一下性能调优的经验，小系和诸君一起探讨在性能测试过程中经历的性能调优的那些事儿。本期内容主要介绍ORACLE中硬解析、连接池、并行模式、物化视图等配置类内容。

硬解析(Hard Parse)

首先，什么叫做硬解析呢？

答：如果sql语句的hash值在library cache中存在，而且sql语句与cache中的相同，则Oracle利用已有的解析树与执行计划，对sql语句进行解析，这个过程称之为软解析。反之，上述一个任何条件不成立，优化器都将进行创建解析树、生成执行划。这个过程就叫硬解析。

硬解析高可能引发数据库资源瓶颈，怎样发现系统是否有硬解析问题呢？

测试数据多样化，一定不要仅使用几条数据进行性能测试。

采集AWR报告硬解析指标（Load Profile-->Hard Parse/Sec参考值：<2 or <10），如果发现硬解析指标大于1时，笔者一般会用以下脚本查找需要使用硬解析的SQL

脚本如下：

1、利用force_matching_signature查询可以使用绑定变量的语句数量

select v.force_matching_signature ,count(*) from v$sql v where FORCE_MATCHING_SIGNATURE <> EXACT_MATCHING_SIGNATURE and PARSING_SCHEMA_NAME <> 'SYS' group by v.force_matching_signature having count(*)>&a order by 2;

2、查出疑似可使用绑定变量的SQL语句

select PARSING_SCHEMA_NAME,sql_text,sql_id from v$sql where force_matching_signature='force_matching_signature_IDinStep1';

3、根据查询结果与开发人员沟通，确认是否可用绑定变量的方式对SQL语句进行优化。

Q 如何减少硬解析呢？

A 绑定变量来帮忙！

在联机交易系统中，对于频繁执行的SQL语句，如果所查数据分布较均匀、分区较均衡，建议使用绑定变量代替常量，以避免多次重复硬解析，节省时间、资源成本。

正例：

b1=1;

select * from user where userid= :b1;

b1=2;

select * from user where userid= :b1;

反例：

select * from user where userid=1；

select * from user where userid=2；

绑定变量一定能优化性能吗？

——小心“绑定偷窥”！

T1表(100万条记录） status字段

Status=‘A’ 99万9990条

Status=‘C’ 10条

SQL1：Select * from T1 where status=:b1

:b1 =‘A’，则单表访问路径走全表扫描

SQL2：Select * from T1 where status=:b1

:b1 =‘C’，则单表访问路径走索引范围扫描

理想情况下，传入不同变量的值，应该走不一样的单表访问路径，但是Oracle做不到。Oracle在第一次做硬解析（内存中没有缓存执行计划）的时候，会先“偷窥”一眼，变量的值传入的是什么，如果传入的是“A”,则走全表扫描；并且把执行计划缓存。下一次执行的时候，由于执行计划已经缓存，就不再“偷窥”变量的值了，而是直接沿用全表扫描的执行计划。这个时候即使传入的status变量为C，也走不上索引了。这个现象称为“绑定变量偷窥现象”。

绑定变量使用场景注意事项
适用场景	不适用场景
数据分布较均匀、分区较均衡	数据分布非常不均匀、分区不均衡时经常时快时慢
绑定变量适合短平快执行次数多的SQL	执行次数少，数据分布不均，要求执行计划准确的复杂SQL（例如批量、报表）