oracle直查和call哪个更快,让oracle跑的更快1读书笔记二

当前位置:我的异常网» 数据库 » <>读书笔记二

<>读书笔记二

www.myexceptions.net  网友分享于：2013-08-23  浏览：9次

<>读书笔记2

1 绑定变量

1)硬分析和软分析

硬分析需要判断是否已经在共享池中，如果有的话，则直接拿出来，马上可以执行，速度快，

为软分析；否则需要语法解析，语义分析，生成操作计划等，为硬分析。

2) 绑定变量的话

比如select * from xx where account_name=:x

好处在于只要对每一种SQL一次硬分析，因为谓词不同而已。

3)OLTP必须绑定变量而OLAP不应该绑定，因为OLAP中，硬分析的

代价基本可以忽略，但必须确切知道谓词的数值

4)bind peaking，就是在硬分析时，ORACLE会看一下

当前谓词的值，以便生成最佳执行计划，但也只是第一次执行时生成，

以后不会执行。因为OLTP相同的SQL重复频率高，如果反复

解析SQL，必然很大消耗系统资源，执行的计划都很一致，bing peeking

第一次获得了正确的计划后，以后的SQL都会按这个计划执行

2 SQLTRACE的使用

1)alter session set tracefile_identifier='mytest';

设置生成trace的文件标识，可以方便追踪

2)alter session set sql_trace=true;//启用sqltrace

3) 执行SQL语句后，再停止sqltrace,可以在admin/sid/udmup下找到相关的trace文件

4) 使用tkprof工具

tkprof xxxx.trac out.txt 后加各种参数

A explain=username/password,输入SQL的执行计划，如果不用explain,则看到的

是执行路径

B SYS=NO,可以过滤SYS用户的操作建议使用

C aggragate=yes,把相同的SQL在输入文件中作合拼，如果为NO，则分别输出每个SQL

的信息

D sql的3个步骤：分析，执行，数据提取

E 各参数的意义

cpu:单位秒

elapsed:当前的操作一共用时多少(包括CPU事件和等待时间)

disk:磁盘物理读

query:当前的操作一致性读方式读取的数据块数(通常为查询使用的)

current:当前操作的current的方式读取数据块数(通常为修改的)

rows:行数

Misses in library cache during parse:1 为硬分析，为0为软分析

OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS ：递归SQL语句的分析

3 10046事件

1)level=4:等同于sql_trace功能

alter session set events '10046 trace name context forever,level 4';

2)level=8 ：没有绑定变量的值，但它比sql_trace增加了等待事件的信息

3)level=12,等于level=4+level=8

4 10053事件

解决的是为什么CBO会选择这个方式，将列出其执行过程。

1) 设置

alter session set events '10053 trace name context forever,level 1';

2)取消

alter session set events '10053 trace name context off';

3)tkprof不能阅读10053事件，只能读10046事件

4)10053事件中，比较重要的CLUF索引聚合因子，它表示索引上的键值和原表上的

数据分布的一种关系，当索引键值和表中数据的排列顺序大致相同时，它意味着索引

键指向的数据块越集中，这个因子越小，越有利于索引的使用；相反，当索引键指向的

数据快越多时(数据排序和索引相差越大)时，这个因子就越大，越不利索引的使用。

可以使用alter table t1 minimize records_per_block;

5 性能视图和性能参数

1)v$sql

可以查到这个用户正在执行的SQL语句及这条SQL运行了多长，有什么等待

事件

先查询当前用户连接的sid,然后执行

select a.sql_text,b.status,b.last_call_et,b.event from v$sql a,v$session b

where a.sql_id=b.sql_id and b.sid=xxxx; //只能10G用，9I不行

不是所有的sql语句都能在该视图中找到，可以用手工清空共享池的信息，比如

alter system flush shared pool;

select sql_text,parse_calls,executions from v$sql where sql_text like 'select * from xxxx';

可以找出语句分析和执行了多少次

2)v$session

select  machine,username,program,module from v$session;

v$session里面有个字段last_call_et(秒)

active:从session变成active到现在的时间

inactive:从session状态变为incative到现在的时间

select sid from v$mystat where rownum=1 //获得当前用户的sid

select sid,blocking_session from v$session where blocking_session is not null //查看当前哪些会话被

阻塞

同样,$vlock中也可以获得阻塞的信息

select sid,request,block from v$lock where request<>0 and block<>0;

3) 具体参数

cursor_sharing:告诉 oracle在什么情况下共享游标，即SQL重用

默认情况下，设置为exact,即SQL必须完全一样才行，所以最好进行变量绑定；

cursor_sharing=similar:将谓词条件用同一个名称变量替代，让不同的SQL

语句看起来一样，但依然分开两条SQL处理；

cursor_sharing=force:将不同语句的谓词，用一个变量代替，看作同一个语句处理

cursor_sharing跟cursor_force的区别：

其中，比如cursor_sharing:

假设有语句：

SELECT * from t where id=1 and owner='sys';

SELECT * from t where id=2 and owner='sys111';

如果在id列上做了索引，则CBO会检查每个SQL的ID的值，如果有改变，则产生一个新的硬分析，而且不会管owner

列，因为该列没有做索引。

而FORCE的区别在，会把所有的谓词用变量代替，且不管变量的值如何，一律用

第一条SQL语句，而similar会根据不同，重新选择SQL执行计划。

4)db_file_multiblock_read_count:

对于OLTP来说，每次用户读取的记录数少，可以设置的小点；但对于OLAP，因为

查询量大，可以设置的大些应该。

6  AWR性能报告

1 AWR，采集周期1个小时

2 到$oracle_home/rdbms/admin目录下，执行

sqlplus / as sysdba @awrrpt.sql

输入默认的HTML格式，选择时间段，生成路径即可

3 sqlplus sys/xxx@oracl as sysdba  @awrrpti.sql

可以生成其他实例中的AWR报告

4 OLTP的AWR中，应该关注library hit,共享池命中率低则说明SQL不能被重用，

buffer hit越接近100，表明越多在内存中进行，

参数解析：

1)sessions:采集实例连接的会话数，可以了解并发用户数大概情况

2)curror/session:每个会话平均打开的游标数

3)DB TIME：表示用户操作的花费的累计时间，包括CPU时间和等待事件，用户占的

时间比例越高，说明越繁忙。

4)在load profile段中，比较重要的是：

parse:每秒分析次数

hardparases:硬分析次数

logons:每秒登陆数据库的次数

executes:每秒SQL的次数

INSTNACE efficiency percentages:

in-memory sort %:数据块在内存中排序的百分比(包括内存排序和磁盘排序)

，       soft parse %:软分析在总分析数中的百分比

buffer nowait:非等待方式获得数据块百分比，如果太小，说明SQL访问数据块时，数据库正在被别的会话读

入到内存中，有热块

5) TOP 5事件

db file sequential read:指oracle在访问索引数据块时以db file dequential

read方式来将数据读入内存，如果占比例很大，肯定是存在大的查询。

CPU TIME：主要要除以CPU的个数

latch:row cache objects,为共享池争用的等待事件

read by  other session:一个会话在等待另外一个会话将数据块读入内存中，如果等待事件过长，则说明数据

有热块存在。但对于OLAP系统来说，也不一定是出了问题，

因为OLAP中，本身就运行着一些执行时间非常长的SQL，他们要扫描很多数据块，因此

等待是合理的。

如果SQL语句在采样时间点之后还没结束，则可能无法反映其消耗情况

TIME MODEL STATISTICS部分：列出了各种操作占用的数据库时间比例，其中

sql execute elapsed time为SQL占DB的时间。而parse time elapsed和

hard parse elasped time如果相等，表示都为硬解析了。

SQL ORDERED BY ELAPSED TIME：根据执行时间长短排序

sql order by gets:sql获取内存数据块的数量，由大到小顺序排列

其中Buffer gets列：SQL执行获得的内存数据块数量

executions:sql执行的次数

gets per exec:每次执行获得的内存数据块数量

sql ordered by reads:SQL物理读的次数

sql orderd by executions:sql执行次数的信息

sql orded by parse calls:sql 被分析次数的信息，从高到低排列。

sql orderd by cluster wait time:列出了实例之间共享内存数据时发生的等待。

instance activity stats部分为实例的信息统计部分，重点的有：

1)cpu used by this session:说明在当前的性能采集区间里面，oracle消耗的CPU

单位，一个CPU单位是1/100秒。

可以从TOP 5报告中找到CPU TIME为多少秒，而cpu used by this session

比如为476317个CPU单位，每秒消耗132个CPU单位，每秒实际为132/100=1.32秒，

即每秒CPU处理的时间为1.32秒，如果有8个CPU，则132/8=16.5个CPU单位，

即0。16秒/每个CPU处理时间，为低负载。

tablespace io stats:针对表空间的性能统计，其中关注av rs(ms)，即平均一次物理读的时间(毫秒)

buffer pool advisory:为oracle给出关于内存的建议

其中，size for est(M):oracle 估算buffer pool的大小

size factor:估算值和实际值的一个比例，比如0.9，为估算值是实际值大小的90%,1.0表示buffer pool

实际的大小

buffers for estimate:估算的buffer的大小(数量)

est phys read factor:估算的物理读的影响因子，是估算物理读和实际物理读的一个比例

estimated physical reads:估算的物理读次数

可以看到当内存增大时，不一定物理读次数就一定下降快，要找到适合的因子才行。

Pga memory advisory:

PGA内存大小的建议，其中关注size factor的点，要找出该点对应的物理读写数量稳定时对应的点(

即ested extra w/a mb read written to disk)，此时对应的PGA内存在最佳。

shared pool advisory:主要考虑est lc time saved factr,表示每一个模拟的shared pool大小对

重新将对象读入共享池的影响情况，当这个值得变化很小或者不变时，则增加shard pool内存大小意义不大

7  statspack 性能报告

可以抓取半个小时或15分钟，灵活性更大

1) 安装

sqlplus / as sysdba  @c:\ddxxx\spcreate.sql(使用用户perfstat和密码perfstat)

2) 使用

conn perfstat/perfstat

exec statspack.snap;

exec statspack.snap;

8  ASH性能报告(只是10.2.gXXX 10GR2后才支持)

ASH为AWR的一个部分，ASH侧重当前数据中活动会话的分析，oracle每秒对数据库中的活动会话信息采样，这些

信息会被存放在SGA去，循环使用。

运行方法

sqlplus /  as sysdba @ashrpt.sql

然后输入起始时间，比如-30，即30分钟前。

文章评论