1、识别占用资源较多的语句的方法(4种方法)
1.
测试组和最终用户反馈的与反应缓慢有关的问题。
2.
利用V_$SQLAREA视图提供了执行的细节。(执行、读取磁盘和读取缓冲区的次数)
•
数据列
EXECUTIONS
:执行次数
DISK_READS
:读盘次数
COMMAND_TYPE
:命令类型(3:select,2:insert;6:update;7delete;47:pl/sql程序单元)
OPTIMIZER_MODE
:优化方式
SQL_TEXT
:Sql语句
SHARABLE_MEM
:占用shared pool的内存多少
BUFFER_GETS
:读取缓冲区的次数
•
用途
1
、帮忙找出性能较差的SQL语句
2
、帮忙找出最高频率的SQL
3
、帮忙分析是否须要索引或改善联接
3.
监控当前Oracle的session,如出现时钟的标志,表示此进程中的sql运行时间较长。
4.Trace
工具:
a)
查看数据库服务的初始参数:timed_statistics、user_dump_dest和max_dump_file_size
b)
Step 1: alter session set sql_trace=true
c)Step 2: run sql
;
d)
Step 3: alter session set sql_trace=false
e)Step 4:
使用 “TKPROF”转换跟踪文件
f)Parse
,解析数量大一般代表须要增长数据库服务器的共享池大小,
query
或current提取数量大代表若是没有索引,语句可能会运行得更有效,
disk
提取数量代表索引有可能改进性能,
library cache
中多于一次的错过代表须要一个更大的共享池大小
2、如何管理语句处理和选项
•
基于成本(Cost Based)和基于规则(Rule Based) 两种优化器, 简称为CBO 和RBO
•
Optimizer Mode
参数值:
Choose
:若是存在访问过的任何表的统计数据 ,则使用基于成本的Optimizer,目标是得到最优的经过量。若是一些表没有统计数据,则使用估计值。若是没有可用的统计数据,则将使用基于规则的Optimizer
All_rows
:老是使用基于成本的Optimizer,目标是得到最优的经过量
First_rows_n
:老是使用基于成本的Optimizer,目标是对返回前N行(“n”能够是1,10,100或者1000)得到最优的响应时间
First_rows
:用于向后兼容。使用成本与试探性方法的结合,以便快速传递前几行
RULE
:老是使用基于规则的Optimizer
3、使用数据库特性来得到有助于查看性能的处理统计信息(解释计划和AUTOTRACE)
No1: Explain Plan
A)
使用Explain工具须要建立Explain_plan表,这必须先进入相关应用表、视图和索引的全部者的账户内. (@D:\oracle\ora92\rdbms\admin\utlxplan)
B)
表结构:
STATEMENT_ID
:为一条指定的SQL语句肯定特定的执行计划名称。若是在EXPLAN PLAN语句中没有使用SET STATEMENT_ID,那么此值会被设为NULL。
OPERATION:在计划的某一步骤执行的操做名称,例如:Filters,Index,Table,Marge Joins and Table等。
OPTION:对OPERATION操做的补充,例如:对一个表的操做,OPERATION多是TABLE ACCESS,但OPTION可能为by ROWID或FULL。
Object_Owner:拥有此database Object的Schema名或Oracle账户名。
Object_name:Database Object名
Object_type:类型,例如:表、视图、索引等等
ID:指明某一步骤在执行计划中的位置。
PARENT_ID:指明从某一操做中取得信息的前一个操做。经过对与ID和PARENT_ID使用Connect By操做,咱们能够查询整个执行计划树。
C)
EXPLAIN
搜索路径解释
•
全表扫描(Full Table Scans)(
无可用索引,大量数据,小表 ,全表扫描hints,HWM(High Water Mark), Rowid扫描)
•
索引扫描
索引惟一扫描(Index Unique Scans)
索引范围扫描(Index Range Scans)
索引降序范围扫描(Index Range Scans Descending)
索引跳跃扫描(Index Skip Scans)
全索引扫描(Full Scans)
快速全索引扫描(Fast Full Index Scans)
索引链接(Index Joins)
位图链接(Bitmap Joins)
•
如何选择访问路径:
CBO
首先检查WHERE子句中的条件以及FROM子句,肯定有哪些访问路径是可用的。而后CBO使用这个访问路径产生一组可能的执行计划,再经过索引、表的统计信息评估每一个计划的成本,最后优化器选择成本最低的一个。
•
表的链接方式:
Nested Loops会循环外表(驱动表),逐个比对和内表的链接是否符合条件。在驱动表比较小,内表比较大,并且内外表的链接列有索引的时候比较好。当SORT_AREA空间不足的时候,Oracle也会选择使用NL。基于Cost的Oracle优化器(CBO)会自动选择较小的表作外表。(优势:嵌套循环链接比其余链接方法有优点,它能够快速地从结果集中提取第一批记录,而不用等待整个结果集彻底肯定下来。缺点:若是内部行源表(读取的第二张表(内表)已链接的列上不包含索引,或者索引不是高度可选时, 嵌套循环链接效率是很低的。若是驱动行源表(从驱动表中提取的记录)很是庞大时,其余的链接方法可能更加有效。)
SORT-
merge JOIN
,
将两表的链接列各自排序而后合并,只能用于链接列相等的状况,适合两表大小相若的状况(在缺少数据的选择性或者可用的索引时,或者两个源表都过于庞大(超过记录数的5%)时,排序合并链接将比嵌套循环连更加高效。可是,排列合并链接只能用于等价链接(WHERE D.deptno=E.dejptno,而不是WHERE D.deptno>=E.deptno)。排列合并链接须要临时的内存块,以用于排序(若是SORT_AREA_SIZE设置得过小的话)。这将致使在临时表空间占用更多的内存和磁盘I/O。)
HASH JOIN
在其中一表的链接列上做散列,所以只有另一个表作排序合并,理论上比SORT JOIN会快些,须要有足够的内存,并且打开了SORT_JOIN_ENABLE参数。(
当缺乏有用的索引时,哈希链接比嵌套循环链接更加有效。哈希链接可能比排序合并链接更快,由于在这种状况下只有一张源表须要排序。哈希链接也可能比嵌套循环链接更快,由于处理内存中的哈希表比检索B_树索引更加迅速。和排序合并链接、群集链接同样,哈希链接只能用于等价链接。和排序合并链接同样,哈希链接使用内存资源,而且当用于排序内存不足时,会增长临时表空间的I/O(这将使这种链接方法速度变得极慢)。最后,只有基于代价的优化器才可使用哈希链接。
)
索引链接:
No2: AUTOTRACE
•
set autotrace
使用步骤:
1
、以system登陆
2
、建立plustrace角色; <your_oracle_home>\sqlplus\admin\plustrce.sql
3
、向常规用户授予权限:grant plustrace to <user id>
4
、若是没有plan_table也要建立: <your_oracle_home>\rdbms\admin\utlxplan.sql
•
set autotrace
选项
on
|
显示查询结果,执行计划,统计数据
|
on statistics
|
显示查询结果,统计数据,不显示执行计划
|
on explain
|
显示查询结果,执行计划,不显示统计数据
|
traceonly
|
显示执行计划和统计结果,但不包括查询结果
|
traceonly statistics
|
仅显示统计数据
|
recursive calls
|
在用户级别和系统级别上生成的递归调用的数量。Oracle维护了一些用于内部处理的表。当oracle须要对这些表进行更改时,它就会在内部生成一个SQL语句,而后这个语句再生成一个递归调用。
|
db block gets
|
请求一个CURRENT块的次数
|
consistent gets
|
为一块请求consistent read的次数
|
physical reads
|
从磁盘读取得数据块总数。这个数量等于“直接物理读取”的值加上读入缓冲区的全部数据块
|
redo size
|
生成的重作的总数量(以字节为单位)
|
bytes sent via SQL * Net to client
|
从前台进程发送给客户的总字节数
|
bytes received via SQL * Net from client
|
经过Oracle Net从客户接收的总字节数
|
SQL*Net roundtrips to/from client
|
发送给客户和从客户接收的Oracle Net消息的总数
|
sorts (memory)
|
彻底在内存中执行而且不须要任何磁盘写入的排序操做的数量
|
sorts (disk)
|
至少须要一个磁盘写入的排序操做的数量
|
rows processed
|
在操做过程当中处理的行数
|
4、最后,使用计时特性来测量和比较处理时间
Set timing onsql