数据库性能优化方法 oracle性能调优总结( 二 )


这个现象称为”绑定变量偷窥现象” 。一条SQL语句适合采用何种解析方式需要衡量硬解析带来的资源开销和查询计划不准带来的资源开销 , 从而确定是否采用绑定变量 。两种解析适用场景总结如下:
1.2连接池
经常收到一些”怎么查看应用到Oracle连接池是否够用” , ”系统tps很低 , SQL也简单 , 为啥数据库服务器cpu>10%?”
除了根据服务器连接数或利用第三方工具 , 可从以下4个方面间接判断连接池是否够用:
1. 参考AWR报告中Load Profile–>Logons /Sec , 参考值:< 2 or 10 。
2. 参考ADDM中出现Session Connect and Disconnect–> Percent of Activity > 10 。
3. top命令中cpu消耗排在前10位进程中含tnslsnr , 或该进程消耗cpu > 10% 。
4. alert.log中出现连接频繁建立或断开的告警 。
若出现上述现象 , 应考虑适当增加连接池或检查应用是否用到连接池 。
1.3并行模式PARALLEL
并行模式适用于针对大数据量的操作 , 应用得当能大大缩短计算时间 。但其劣势在于:资源调度、合并结果集等比较消耗资源 , 不建议在系统超负荷运行的情况下使用 。并行模式使用应注意以下几项:
1.联机交易往往并发较高 , 应避免使用并行 。
2.联机交易高峰时段 , 避免批量或报表使用并行 。
3.并行查询的优先级为语句提示(hint)、表级定义、数据库初始化参数 。后两者易造成响应时间慢、表扫描、会话阻塞等异常 , 不建议在应用运行时使用 。
4.对于较大的数据量的查询 , 可以使用提示(hint)来强制Oracle使用并行查询 。
5.建表、索引时如需使用PARALLEL , 完成后切记关闭并行度 , 否则会造成后续使用该表、索引的SQL启用了并行,占用过多资源 , 导致其它会话等待 , 影响系统整体性能 。
6.任务并行度不应大于服务器CPU数 , 建议单个任务并行度应小于CPU数/2 。
1.4统计信息缺乏或陈旧
开发测试环境往往缺乏统计信息更新机制 , 统计信息陈旧可能造成SQL查询计划有误 , 查询效率低下 。大量的数据加载或更新后应及时收集统计信息 。
1.5物化视图
物化视图是一种特殊的物理表 , 占用实际的存储空间 , 可用于读写分离 , 或者预先计算并保存表连接、嵌套或聚集等耗时较多的操作结果 , 在执行查询时能避免这些耗时操作 , 从而快速得到结果 。物化视图主要用于数据仓库和决策支持系统 , 使用物化视图需注意:
1.对于高并发的联机系统、基表数据频繁更新且对数据实时性要求高的交易避免访问物化视图 。
2.基表数据变更频繁 , 一般不建议使用ON COMMIT数据刷新模式 , 推荐使用默认的ON DEMAND手工模式 。
3. ON DEMAND模式下用到FAST增量刷新时 , 必须在创建有物化视图日志的情况下才能使用 。
4.物化视图日志的大小直接会影响刷新速度 。物化视图长时间不刷新 , 或者基表的一次批量数据变更均会导致物化视图日志变得很大 。
5.物化视图日志的高水位达到较高位置 , 即使物化视图日志中记录很少甚至没有 , 仍然会影响物化视图的刷新速度 。
2. SQL效率类
不合理的数据结构设计 , SQL书写不规范会导致笛卡尔积操作、全表扫描、索引跳扫、索引全扫、filter低效过滤等低效操作 , 从而导致SQL效率甚至应用性能大打折扣 。本章节列出了常见的导致SQL低效的条例 , 实际开发测试过程中可能需要结合查询计划、统计信息、V$_*等进行调优验证 。


以上关于本文的内容,仅作参考!温馨提示:如遇健康、疾病相关的问题,请您及时就医或请专业人士给予相关指导!

「四川龙网」www.sichuanlong.com小编还为您精选了以下内容,希望对您有所帮助: