<<让oracle跑的更快1>>读书笔记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分钟前。