数据库调优的一个重要方面就是SQL调优.SQ调优包含3个基本的步骤
1.定位系统中那些耗资源的SQL
2.找出这些不好的语句后查看他们的执行计划
3.采取积极措施让这些语句的执行计划变得良好或者说是符合要求
以上3个步骤需要重复直到系统达到一定满意程度或者没有其它语句可以调整
调优的目的是什么呢?
目的就是为了使响应时间缩短,处理同样的工作系统暂用的资源更少,以下的一些方法能够达到这个目的
1.readuce the workload 缩小工作量
sql调节通常需要找更有效的方法去完成同样的工作,对于需要调整的语句,在不改变原有语句功能的情况下,调整执行计划,以缩小资源消耗
两个例子说明资源消耗能被减少:
(1).如果经常执行的查询访问表的数据的比率小,那么可以通过使用索引使查询更有效率。这里通过创建索引,减少的资源的使用.
(2).如果一个用户在查看一个有10000条记录的表的前20条,返回的数据是按一定条件排序的,又假如这个查询和索引都满足索引,那么这个用户并不需要去访问和排序这10000条记录就可以看到满足条件的前20条记录.
2.balance the workload 平衡工作量
系统在运行的过程中,白天通常表现出峰值,系统资源占用比较高。晚上系统的使用比较低。如果不是很关键的报表,批处理JOB,调度到晚上时间运行,这样在白天系统的并发性缩小,白天就会有更多的资源来满足那些关键的应用程序.
3.parallelize the workload 并行执行工作
查询访问大量数据(典型的数据仓库查询),通常需要并行执行。在低并发的数据仓库系统中这种并行执行对于缩小响应时间很有用。但是在OLTP环境下,它表现为高并发,通常会增加了系统总的资源消耗,影响到其他用户!
说了这些那么如何找到那些恶习的不良SQL呢?
有以下几个方法:
Automatic Database Diagnostic Monitor (ADDM)
Automatic Workload Repository (AWR)
V$SQL view
Custom Workload
SQL Trace
识别那些资源敏感的SQL
首先你要确定问题是出在一个程序上,还是一些程序都有问题,还是大部分程序都有类似的性能问题
(1)对于单独程序来说
如果是单个的程序有问题就没有什么必要去检查SQL代码了,OEM提供的工具能够找到所谓差的SQL,产生SQL执行计划,评估SQL性能
如果识别差的SQL不太紧急的话(例如SQL是动态产生的),那么使用SQL_TRACE生成trace文件,文件中包含执行的SQL,然后使用TKPROF产生输出文件.TKPROF产生的输出文件中的SQ会按照不同的参数排序展现出来,例如执行消耗的时间(exeela),这就可以帮助识别那些差的SQL,按消耗时间排序就可以看出来,一般最差的都在文件的前面
(2)如果整个应用需要适当调整,或者打算减少整个系统的CPU,IO消耗,那么找出这些敏感的SQL一般来说有以下步骤
#1.确定那个在白天的那个时间跨度里你想执行检查,通常白天都是数据库处理应用的高峰时间
#2.收集操作系统和ORACLE的统计信息在你执行检查的时间跨度期间,ORACLE的统计信息至少可以从以下性能相关视图中看出些眉目 I/O (V$FILESTAT), system statistics (V$SYSSTAT), and SQL statistics (V$SQLAREA, V$SQL or V$SQLSTATS, V$SQLTEXT, V$SQL_PLAN, and V$SQL_PLAN_STATISTICS).
#3.在第2步收集的数据中找那些最占资源的SQL。比较好的做法是查询v$sqlstats,这个视图包含共享池中所有SQL的资源使用情况。这个视图中最常用的一些资源情况有:
Buffer gets (V$SQLSTATS.BUFFER_GETS, for high CPU using statements)
Disk reads (V$SQLSTATS.DISK_READS, for high I/O statements)
Sorts (V$SQLSTATS.SORTS, for many sorts)