oracle优化参考

oracle优化参考

业务是否用最优的方式来运行。
如果不是最优的方式那就对SQL进行优化。
查看数据库的执行计划

技术方向上，应多考虑性能方面的问题
积极参与到业务层面，从业务角度思考问题。

导致性能问题的可能原因
1，表没有正确的创建索引－－－错误的执行计划
2，表没有及时的分析－－－错误的执行计划
3，热块－－－数据块的争用（反向索引？）
4，锁的阻塞－－－业务设计缺陷、
5，SQL解析消耗大量CPU－－－变量绑定
6，低效的SQL－－－SQL自身的问题
7，数据库整体负载过程－－－架构设计的问题

性能问题的定位
原则 尽可能从小范围分析问题
1，SQL层
如果能从定位到SQL，就不要从会话层面分析
已经定位到了某条SQL语句有问题，就针对该语句着手。使用工具 和 执行计划来分析该语句，如使用：10053，10046（查看某条语句资源消耗情况）

2，会话层
如果能定位到会话，就不要从系统层面分析：
V$SESSION,V$SESSTAT, V$SESSIO{N}_{W}AIT,V$SQL, V$LOCK SQL_TRACE

3，系统层
如果无法定位任何性能问题，从系统层面入手
AWR（STATSPACK）， OS tools（top, iostat）

锁
没有并发就没有锁
Oracle中锁的分类：
Enqueues–队列类型的锁，通常和业务相关的 简写: enq
Latches—系统资源方面的锁，比如内存结构，SQL解析

锁的原则：
1，只有被修改时，行才会被锁定，select操作不会在数据表中加锁。
2，当一条语句修改了一条记录，只有这条记录上被锁定，在Oracle数据库中不存在锁升级。
3，当某行被修改时，它将阻塞别人对它的修改。
4，当一个事务修改一行时，将在这个行上加上行锁（TX），用于阻止其它事务对相同行的修改。
5，读永远不会阻止写。
6，读不会阻塞写，但有唯一的一个例外，就是select … for update.
7，写永远不会阻塞读
8，当一行被修改后，Oracle通过回滚段提供给数据的一致性读。

查看Oracle的锁的类型：
select type, name from v$lock_type;

TM锁和TX锁：
TM表锁：发生在insert, update, delete以及select for update操作时，目的是保证操作能够正常进行，并且阻止其它人对表执行DDL操作。
TX锁 事务锁（行锁）对于正在修改的数据，阻止其它会话进行修改。

表锁的演示：
当未提交一个事务，另外一个相同的事务操作就会被阻塞。查看表的阻塞的详细情况：使用视图：v$lockselectsid,type,id1,id2,lmode,request,blockfromv$lock where type in (“TM”,“TX”) order by 1,2;

注1：TM锁所对应的 字段名：id1 返回的就是数据表的ID号，通过这个返回值可以查出被阻塞的表名，使用数据字典：dba_objects:
select object_name, from dba_objects where object_id =
注2：TX锁所对应的 字段名：id1 与 id2 之后就是对应着的回滚段的地址。
注3：request字段表示是否请求一个锁，值为0表示没有请求，非0说明有请求。
注4：BLOCK字段表示当前是不是有阻塞。值为0没有阻塞，非0表有阻塞。

查看当前会话的SID：
select distinct sid from v$mystat;

会话等待视图：v$sessio{n}_{w}aitselectsid,eventfromv$session_wait where sid in (sid1, sid2);

insert的阻塞与update的阻塞是不一样的。

TM锁的几种模式－－－lock mode
Row Share(RS)—2
Row Exclusive Table Lock (RX) — 3
Share Table Lock—4
Share Row Exclusive Table Lock(SRX) —5
Exclusive Lock(X) — 6

RI锁－－－基于引用关系的锁定
当于具有主外键关系的表做DML操作时，锁定不单单发生在操作表上，相应的引用表上也可能加上相应的锁定。

创建一个主表：
create table p(id int primary key);
创建一个辅表：
create table c(id references p(id));

在对主表进行insert操作的时候，从表也会被加表级锁。

在对主表进行update，delete操作时，不会对从表加表级锁定。

在对从表进行DML操作时，会对主表也会加表级锁。

要在外键上创建一个索引，以提高数据处理效率。

死锁
两个会话互相持有对方资源，遇到死锁时，Oracle会自行对其进行处理。

Latch的目的：
1，保证资源的串行访问：
保护SGA的资源方向
保护内存的分配
2，保证执行的串行化：
保护关键资源的串行执行
防止内存结构损坏

Latch不是队列性的。是数据库的资源层。
Lock是发生的数据库的业务层。

Latch在SGA中。
资源的请求和分配：
共享池
sql解析，sql重用
数据缓冲池
数据访问，数据写入磁盘，数据读入内存
修改数据块
数据段扩展

查看数据库中的Latch,使用的视图：v$latchname

Latch持有的时间非常短

Latch的获取：
1，wait 方式－－如期无法获取请求的Latch，则：
spin: 当一个会话无法获得需要的latch时，会继续使用CPU（CPU空转），达到一个间隔后，再次尝试申请latch，直到达到最大的重试次数。
sleep: 当一个会话无法获得需要的latch时，会等一段时间（sleep）,达到一个间隔后，再次尝试申请latch，如此反复，直到达到最大的重试次数。
2，No wait方式－－如果沅法获取请求的latch,则：
不会发生sleep或者spin
转而去获取其它可用的latch

shared pool里的latch争用－－绑定变量

用于标识trace文件标识：
alter session set tracefile_identifier=bind;
对执行的SQL语句做trace记录
alter session set sql_trace = true;

Buffer cache的机制
视图：v$bh
用于查看文件头。
NXT_HAST, PRV_HASH

Latch相关视图—V$LATCH
这个视图实际上是oracle对每个latch的统计信息的一个汇总，每一条记录表示一种latch.

select name, gets, misses, sleeps, immediate_gets, immediate_misses from v$latch where name like ‘cache%’;

注：NAME:latch名称
GETS：以Willing to wait请求模式latch的请求成功数
MISSES: 初次尝试请求不成功次数
SLEEPS：成功获取前sleeping次数
IMMEDIATE_GETS: 以Immediate模式latch请求数
IMMEDIATE_MISSES:以IMMEDIATE模式请求失败数

V$LATCHHOLDER
该视图用于显示当前的latch holders
PID 标明当前的哪个进程占用着latch
SID 标明当前哪个会话使用着latch
LADDR 标明latch地址
NAME 用于指定被占用的LATCH名
GETS 标明当前的LATCH被获取的次数

该视图包含了当前latch持有有的信息
通过视图中的PID和SID信息，关联视图V$SESSION,V$SESSION_WAIT，可以定位相应持有资源的会话信息。

V$LATC{H}_{C}HILDREN存储子latch信息的视图，在SGA中胡些资源使用多个latch保护，比如librarycache,这些多个latch保护同一个资源，成为子latchV$LATCH_CHILDREN和V$LATCH一样。

LATCH优化的思路：
LATCH导致的性能问题，通常是一个系统层面的问题，所以：
1，AWR报告是一个比较好的入口
2，通过动态视图V$LATCH，可以分析当前系统的LATCH资源情况
3，确定争用最大的LATCH
4，分析可能的原因
5，从应用层面和数据库层面考虑解决途径。

主要是使用绑定变量，减少热块，在数据库设计时决定这一切。

执行计划和优化器
执行计划
SQL语句访问和处理数据的方式
数据的访问：
1，直接访问
并行访问
多数据块
2，通过索引访问
index unique scan
index range scan
index full scan
index fast full scan
index skip scan

数据处理：
order by, group by, count, avg, sum

数据的关联处理
nested loop join, Merge join, hash join

如何产生执行计划：
set autotrace trace exp;
set linesize 120;

Oracle的优化器
CBO–Cost based optimizer
依据一套数据模型，计算数据访问和处理的成本，择最优成本为执行方案。

不同的版本产生的执行计划就不同。

CBO的工作依照：操作系统，磁盘IO系统，数据库实例的优化集，数据表等信息进行计算并生成执行计划。

CBO的工作模式：
all_rows ----以结果集的全部处理完毕为目的 适用于OLAP
select id,count(*) from t group by id, order by id;

first_rows(n) ----以最快返回n行为目的
select object_name
from
(
select rownum rn, object_name
from
(
select object_name from t order by object_name
)
where rownum <= 20
)
where rn >= 11;

优化器模式的设置方式：
1，参数设置：
optimizer_mode = ALL_ROWS | FIRST_ROWS
2，会话设置：
alter session set optimizer_mode = all_rows | first_rows
3，SQL设置 即 Hint模式
select /*+ all_rows | first_rows / count() from t;

什么样的SQL语句适用于优化器模式？

Cost — 代价
表的选择性：
select column_name, num_distinct from user_tab_col_statistics where table_name=‘’ order by 2 desc;

查看某个数据表和个字段的可选择性，NUM_DISTINCT值越高，该列越适用于做B-tree索引，对性能带来的性能提高越明显。

查看索引的选择性：
select index_name, distinct_keys from user_indexes where table_name=‘’;

查看某个数据表上建立的所有索引名，distinct_keys的值越高，可选择性越高，使用该索引对性能带来的提升越明显。

cardinality
在执行计划中表示每一步操作返加的记录数
CBO通过对这个值的权重计算，决定使用哪一种方式访问数据。

在Oracle 10G R2以前，执行计划显示为CARD
在Oracle 10G R2以后，执行计划显示为Rows

索引－－－clustering factor
select index_name, clustering_factor from user_indexes where table_name=‘’

集簇因子会影响到SQL语句执行时的成本评估。
集簇因子值越大，对SQL语句的性能影响越大。

成本的计算
1，数据访问的成本的估算：
I/O成本的估算
全表扫描（多数据块）
索引（单数据块，多数据块）
CPU成本的估算
2，数据处理的成本
CPU的成本估算

select num_rows, distinct_keys, blevel, leaf_blocks,
clustering_factor, avg_leaf_blocks_per_key,
avg_data_blocks_per_key
from user_indexes
where table_name = “”
and index_name = “”
;

直方图：
begin
dbms_stats.gather_table_stats (
user,
‘’,
cascade => true,
estimate_percent => null,
method_opt => ‘for all columns size 200’
);
end;
/

Hints
用来约束型优化器行为的一种技术
优化器模式：
all_rows
first_rows
数据访问路径：
基于表的数据访问
基于索引的数据访问
表关系的方式：
NL, MJ, HJ

HINTS的使用范畴

访问路径相关HINTS
/*+ full */ 全表扫描

create table t as select * from dba_objects;
create index indx_t on t(object_id);
exec dbms_stats.gather_table_stats(user,‘t’,cascade=>true);
set autotrace trace exp stat;
查看返回的执行计划
select * from t where object_id = 100;
设置Hints进行全表扫描的执行计划：
select /*+ full(t) */ * from t where object_id = 100;

INDEX（强制使用索引） 和 NO_INDEX（强制不使用索引）

INDEX_FFS FFS是fast full scan
用法：/*+ INDEX_FFS( ) */

index range scan 适用于一个范围扫描，而且范围不亦太大。
index fast full scan 适合于整个索引的扫描。

INDEX_SS index skip scan
用于替代全表扫描的一种数据访问方法。
对于前导重复率高的联合索引，有时候index skip scan 的性能要好一些。

用法：/*+ index_ss( ) */

表关联的Hints ---- NL
/*+ use_nl / – Nested Loop Joins 嵌套循环关联
用法：/+ use_nl(, */

NL的使用场景：
1，关联中有一个表比较小
2，被关联表的关联字段上有索引
3，索引的键值不应该重复率很高

HJ Hash join
/+ use_hash/
用法：/*+ use_hash(t,t1) */
使用场景：
1，一个大表，一个小表的关联
2，表上没有索引
3，返回结果集比较大

Merge Join
语法：/+ use_merge(,)/
先对两个表进行排序，然后再将结果集进行联接，这样的话，比较耗费时间，效率非常差。

leading
/*+ leading(,,…) */ 规定表连接的顺序

/*+ append */ 以直接加载的方式插入数据

修改数据表的属性为nologging
alter table nologging;

并行度设置：
/*+ parallel(,) */

/*+ driving_site() */
决定一个分布式事物中，操作在哪个节点上完成。

/*+ cardinality(,) */
用于模拟一个结果集的cardinality(rows)

等待事件：
性能是因为等待造成的，锁和latch，以及磁盘IO都会造成等待事件。

SQLNet message from client
这个是Oracle的通信协议。
只要与数据库产生一个会话，就会生成一个SQLNet空等待事件。

select sid, event, state from v$session where sid = ;

造成Oracle的等待－－－三种情况
1，请求的资源太忙，需要等待资源释放
2，会话处于空闲状态，等待新的任务
3，会话被阻塞，需要等待阻塞解除。

为了提高性能，尽量少的等待事件。

关于oracle的等待事件，应该知道的：
1，数据库处理数据，只要有时间的消耗，就会有等待时间
2，性能和等待是一个矛盾体
3，理解出现某种等待事件的原因
4，结合业务，主观的看待等待事件。
制定基线（baseline），发现异常等待事件
接受合理的等待事件

等待的定位方式－－SQL级别（思路）

alter session set sql_trace = true;

会话级别
如果某个会话非常慢,通过查看视图：v$session_wait

select sid, event from v$session_wait where sid = ;

系统级别
AWR报告（v$system_event）

select sid, event, wait_class from v$session_wait where sid=;
注：字段wait_class 就是等待事件的分类。

等待事件分类
1，Administrative
2, Application
3, Cluster
4, Commit
5, Concurrency
6, Configuration
7, Idle
8, Network
9, Queue
10, Scheduler
11, System I/O
12, User I/O
13, Other

如何查看等待事件
event(P1+P2+P3)
desc v$session_wait
一个等待事件由三个参数说明。P1，P2，P3
不同的等待事件这三个参数表示的意义是不一样的。

例如对于数据文件操作的等事件，这三个参数的意义如下：
P1:表示文件ID ，P2：表示数据块号，P3：已经读取的数据块号

查看数据文件ID对应的数据文件使用数据字典：dba_data_files
查看数据块号对应的信息，使用数据字典：dba_extents

select event, p1, p1text, p2, p2text, p3,p3text from v$session_wait where sid=;

最常见的等待事件－－－idle wait events
1，进程由于无事可做，等待分派任务
2，空等待意味着空闲
3，空闲，还意味着其它的事情
一个地方的繁忙，可能导致另外一个地方的空闲。
需要注意PX Idle Wait

CPU不属于等待事件，但是一个很重要的考核指标

select name, value from v$sysstat where name like ‘%CPU%’;

v$sysstat：中的值是累集的。

db file scattered read
当数据块以multiblock read的形式被读到SGA中时会发生散列读
FTS（full table scan）
IFFS(index fast full scan)
db_file_mutiblock_read_count 多块读通过该参数进行设置
如何更直观的查看等待事件，就是做一个10046的trace。

如果数据库中出现了“数据文件散列读”等待事件的话，如何解决：
1，无需解决（等待属于一种正常现象）
2，考虑索引（当等待事件已经达到了影响性能的程度）
3，考虑并行（如果设置了索引，该等待事件还是有，就要进行该操作）

db file sequential read
数据文件顺序读
一般是通过索引读时出现这样的情况。
索引是读单块，从索引中找到相应的键值，然后再到原表中查找。
1，当把一个数据块读入SGA时，发生db file sequential等待
2，单数据块的读，通常指索引的读取，但不绝对。
有些索引读取会发生’db file scattered read’等。
有时候表的读取会发生db file sequential等待
undo的读取，会使用db file sequential

如何解决db file sequential read
1，无需解决
2，SQL语句的效率
3，考虑其它方式的索引
复合索引
位图索引
全文索引
4，全表扫描+并行
5，改善磁盘I/O

Direct Path Read
直接路径读
1，数据被直接读取到PGA内存中时，发生的等待。
排序数据由于内存不足，被写到磁盘上（temp表空间数据文件），然后重新读取时。
并行操作的slave进程的数据读取。
其它的属于某个会话私有数据的读取操作。
2，参数说明
P1，读取的文件ID
P2，读取开始的数据块ID
P3，读取的数据块数量

如何解决：
1，无需解决
2，增大内存排序区（PGA）
3，调整操作的并行度
4，改善磁盘I/O

Direct Path Write
1，数据从PGA内存中直接写到磁盘上，发生的等待：
排序数据由于内存不足，被写到磁盘上（temp表空间数据文件）
并行操作的Slave进程向磁盘上写数据
其它的属于某个会话私有数据的读取操作。

参数说明，与direct path read是一样的。

Log File Sync
1，用户Commit(rollback)时，lgwr需要将log buffer的数据写到log file上面，发生的等待
出现这个等待事件，意味着数据提交太过频繁。

2，参数说明：
P1，写入文件的数据块

3，解决方式：
减少commit的频率（错误的频繁提交）。
提高I/O性能。

Buffer busy waits
1，内存中对相同的数据块有多个并发请求时，导致这个等待。
2，参数说明：
P1，读取数据块所在的文件ID
P2，读取的数据块ID
P3，等待类型（class ID）

可捍等待事件的视图：v$session

遇到这类的等待事件的解决办法：
1，查看该等待事件对应的文件ID号：
select row_wait_obj# from v$session where event = ‘buffer busy waits’;
2，通过文件ID号，找到该对象号：
select owner, object_name, subobject_name, object_type from dba_objects where dba_object_id = &row_wait_obj#;

处理buffer busy waits等待事件：
1，热块：
segment header —ASSM （auto segment storage management 自动段存储管理）
data block —ASSM，反向索引
undo header — automatic undo management
undo block — 增大回滚段。

free buffer waits
1，server process无法找到一个可用的内存空间
系统I/O成为瓶颈（或者性能不够）
等待资源latch争用
SGA太小
SGA太大，dbwr无法快速的把脏数据刷到磁盘上。
2，参数说明
P1，读取数据块所在的文件ID
P2，读取的数据块ID
P3，无

解决办法：
1，优化I/O
提高I/O通道的性能（换硬件，不太可取）
异步I/O
增加多个dbwr进程
2，增大SGA

v$session_wait 用于显示当前的会话的等待事件,无法查看之前的事件。

v$sessio{n}_{e}vent是一个累积的等待事件信息，selectevent,tota{l}_{e}ventsfromv$session_event where sid=;

v$syste{m}_{e}vent从实例层面上显示哪些等待事件是最多的。selectevent,tota{l}_{w}aitsfromv$system_event;

等待事件在性能定位的过程中是一个非常重要东西，当对一个数据库进行性能分析时，首先要知道数据库中有哪些事件消耗了最多的资源。重要工具有: AWR，v$sessio{n}_{e}vent,v$session_wait

索引与分区
索引的目的：
1，提高数据访问的效率
数据访问的两种方式：通过索引访问数据，直接访问数据
并非所有的索引总是好的，要看表中所创建的字段的选择率。
Oracle索引的类型：
B-tree索引 B树索引
Bitmap索引 位图索引
Text index 全文索引

B树索引：
数据的排列是非常严格的顺序。
当一个主键中内容没有重复的话，那进行等值搜索时跟数据量是没有太大关系的。

高效的场景：
索引字段有很高的selectivity或者结果集很小的时候
低效的场景：
索引字段有着很低的selectivity或者结果集很大的时候。

B树索引基本上适用于所有类型的数据库，没有太明显的缺点。

位图索引
把一个键值放在一个位置，将行做为一个状态。
位图索引跟记录数没有关系，跟键值的记录数有很大的关系

B树索引中直接包含了ROWID
位图索引不包含，而是经过一个函数运算来计算ROWID。

位图索引适合于OLAP，重复率很高的键值，不适合于OLTP和DML频繁操作和场景。

位图索引例子：
create table t as select * from dba_objects;
create table t1 as select * from dba_objects;

创建索引：
create index idx_t on t(owner);
create bitmap index idx_t1 on t1(owner);

对两个表进行分析：
exec dbms_stats.gather_table_stats(user,‘t’,cascade=>true);
exec dbms_stats.gather_table_stats(user,‘t1’,cascade=>true);

位图索引的运算的效率是非常高的。
位图索引适用于OR条件的查询操作。

位图索引的短板：位图索引的锁定
当对一个位图索引以同相键值进行修改，两个会话会有一个会话锁定
若对不同的键值进行修改的话，则不会锁定。

在有bitmap的表中修改数据会对所有受影响的键值关联的记录做锁定。

查看锁定信息：
select sid, type, lmode, id1, id2, request, block from v$lock where type in (‘TM’,‘TX’) order by 5 desc, 7 desc;

全文索引
适用于通配符条件查询。 “%”表示多个字符
在B树索引中，遇到这灯的查询，需要对整个表进行全表扫描。

创建全文索引：
create index idx_t on t(object_name) indextype is ctxsys.context;

全文搜索：
select count(*) from t where contains(object_name,‘TAB’)>0;

全文索引，不占存储空间，只是一个逻辑的名字。

B树索引与位图索引无法发挥作用的场景：like ‘%string%’
全文索引的缺点：
占用过大的磁盘空间，维护成本高，BUG多。

分区
分区表的几点注意：
1，表分区后，分区变成各自的段，而表表成一个逻辑名称
2，分区裁剪
一个段对应着一个数据表，一个表只能存放在一个表空间上。
将一个表分区，可以将不同的表分区放在不同的表空间上。
分区有易于管理，而不是性能。

创建分区表：
create table (col1 type1, col2 type2…)
partition by range(col_name)
(partition p1 values less than(100),
partition p2 values less than(200),
partition pn values less than(maxvalue));

分区－－－分类
List partition 列表分区
Range partition 范围分区
Hash Partition Hash分区

组全分区（子分区）
Oracle 10G提供两种分区组合
Range–hash
Range–List
Oracle 11G增加了四种组合
range – range
List – range
List – Hash
List – List

分区索引：
Local index
表的DML操作无需rebuild索引
可以非常方便的管理数据

Global Partition index
全局索引
表的DDL操作会导致索引无效

一个误区－－－分区索引性能好于全局索引？

一个分区表上如果经常有DDL操作，将会导致全局索引无效，需要对索引重建，此时创建分区索引更加适合。

数据分析：
CBO的数据来源
CBO是一个数据模型
需要准确的传入数据
通过精确的数据计算出精确的执行计划

分析的最终目的是让CBO理解数据！

引子－－当没有分析数据时
SQL> create table t as select * from dba_objects;
查看段对象的数据块：
SQL> select extents, blocks from user_segments where segment_name = ‘T’;
SQL> select num_rows, blocks from user_tables where table_name = ‘T’;

动态采样：
SQL> select /*+ dynamic_sampling(t 0) / count() from t;

Oracle在没有数据分析的前提下计算一个数据表的行数，使用如下算法：
cardinality = num_of_blocks*(block_size - cache_layer)/avg_row_len

cache_layer中存放的有:obj_id, SCN of last cleanout, no of ITL, free list rag, Block Type, ITL Freelist slot, DBA of next block on Freelist.

当分析信息不足时：
update t set object_id = 1 where object_id <1001;

exec dbms_stat.gather_table_stats(user,‘t’,method_opt=>‘for all columns size 1’);

注：mathod_opt=>‘for all columns size 1’ 意思是不做直方图。

当有足够的分析数据时：
exec dbms_stats.gather_table_stats(user,‘t’,method_opt=>‘for all columns size 254’);

CBO的数据来源：
1，初始化参数
优化参数，CPU，数据块大小，多块读的大小
2，数据字典：
user_tables, user_tab_partitions
user_indexes, user_ind_partitions
user_tab_col_statistics

DBMS_STATS包和analyze命令
从10G开始使用DBMS_STATS包。
analyze命令已经过时
无法提供灵活的分析选项
无法提供并行的分析
无法对分析数据进行管理

DBMS_STATS
专门为CBO提供信息来源
可以进行数据分析的多种组合
可以对分区进行分析
可以进行分析数据管理
备份、恢复、删除、设置

Oracle的自动信息收集：
1，Oracle 11G的一个默认设置
2，user_tab_modification跟踪表的修改
3，当分析对象的数据修改超过10%时，oracle会重新分析。
4，定时任务gather_stats_job负责重新定时收集过时数据的信息。

如何看Oracle自动分析的数据信息：
SQL> exec dbms_stats.flush_database_monitoring_info;
SQL> select inserts, updates, deletes, timestamp from user_tab_modifications where table_name = ‘T’;

SQL> select log_id, job_name, status, to_char(log_date, ‘DD-MON-YYYY HH24:MI’) log_date
from dba_scheduler_job_run_details
where job_name = ‘GATHER_STATS_JOB’;

是否完全依赖自动分析？
1，当数据执行计划保持不错的时候，可以依赖自动分析。比如，OLTP系统。
2，否则，需要手工介入。比如，OLAP系统
3，没有一个适合所有系统的数据分析方法。

DBMS_STATS包
Gathering Optimizer Statistics
Setting or Getting Statistics
Deleting Statistics
Transferring Statistics
Locking or Unlocking Statistics
Restoring and Purging Statistics History
User-Defined Statistics
Pending Statistics
Comparing Statistics
Extended Statistics

表数据的收集：
DBMS_STATS.GATHER_TABLE_STATS(
ownname varchar2,
tabname varchar2,
partname varchar2 default null,
estimate_percent number default null,
block_sample boolean default false,
method_opt varchar2 default ‘for all columns size 1’, //值最大为254
degree number default null,
granularity varchar2 default ‘default’,
cascade boolean default false,
stattab varchar2 default null,
statid varchar2 default null,
statown varchar2 default null,
no_invalidate boolean default false
);

索引数据的收集：
DBMS_STATS.GATHER_INDEX_STATS(
ownname varchar2,
indname varchar2,
partname varchar2 default null,
estiname_persent number default to_estiname_percent_type
(get_param(‘estinamte_percent’)),
stattab varchar2 default null,
statid varchar2 default null,
statown varchar2 default null,
degree number default to_degree_type(get_param(‘degree’)),
granularity varchar2 default get_param(‘granularity’),
no_invalidate boolean default to_no_invalidate_type
(get_param(‘no_invalidate’)),
force boolean default false
);

数据分析示例：
默认方式收集表信息
SQL> exec dbms_stats.gather_table_stats(user,‘t’);
默认方式收集索引信息
SQL> exec dbms_stats.gather_index_stats(user,‘idx_t’);
同时收集表、索引信息
SQL> exec dbms_stats.gather_table_stats(user,‘t’,cascade=>true);

表（索引）分析中几个重要的参数：
estimate_percent
表示对表（索引）的百分之多少的数据进行采样分析。
DBMS_STATS.AUTO_SAMPLE_SIZE 对于大表不设置该参数。

手工设置（范围 0.000001，100）
	超大表，大表，小表，的值设置由小到大。

granularity 数据分析的力度(级别）
global 分局
partition 分区
subpartition 子分区

当表上已经有全局统计信息时，单独对分区分析，不会更新全局信息。
当表上没有全局统计信息时，单独对分区分析，会更新全局信息
删除全局数据统计信息：
exec dbms_stats.delete_table_stats(user,‘t’,cascade_parts => false);

全局和全局信息
1，增量统计（Oracle 11G）
Oracle会增量的收集分区信息来更新全局信息
SQL> exec dbms_stats.set_table_prefs(user,‘t’,‘incremental’,‘true’);
SQL> exec dbms_stats.gather_table_stats(user,‘t’);

分区和全局信息
结论：如何设置这个参数：
1，在一个很大的分区表（OLAP），全局分析代价是非常昂贵的。
2，OLAP系统下，除了新加入的数据外，旧的数据基本上是没有变化的，全局分析很浪费资源
3，对于很大的分区表，将granulariy设置为partition(Oracle 10G)或者incremental(Oracle 11G)是很有意义的。
4，对于不大的分区表，可以使用默认设置。

method_opt 分析直方图选项
直方图概念：Oracle对列上的数据分布进行统计分析，对数据倾斜分布时很有用。
直方图收集方法：Frequency－－频率直方图
Height-Balanced–高度平衡直方图

直方图示例 — Height balanced
create table t as select object_id col1, trunc(rownum/1000) col2
from dba_objects where rownum<10000;

exec dbms_stats.gather_table_stats(user,‘t’, method_opt=>‘for all columns size 12’);

查看数据表是否使用了直方图数据搜集：
select column_name, num_distinct, num_buckets, histogram
from user_tab_col_statistics
where table_name = ‘T’ and column_name = ‘COL1’;

select endpoint_number, endpoint_value from user_tab_histograms
where table_name=‘T’ and column_name = ‘COL1’ order by 1;

直方图示例—FREQUENCY
select column_name, num_distinct, num_buckets, histogram
from user_tab_col_statistics
where table_name=‘T’ and column_name = ‘COL2’ order by 1;

参数说明：
for all columns:统计所有列的直方图
for all indexed columns:统计所有indexed列的histograms
for all hidden columns:统计你看不到的列histograms
for column SIZE | REPEAT | AUTO | SKEWONLY;
N的取值范围[1，254]
REPEAT 上次统计过的直方图
AUTO 由Oracle决定N的大小
SKEWONLY －size skewonly只收集非均匀分布的直方图，系统自动决定桶数（bucket）

extended Statistics 扩展统计
列的相关性
exec dbms_stats.gather_table_stats(‘user’,‘CUSTOMERS’,
method_opt=>'for all columns size skewonly
for columns(cust_state_province, cuntry_id) size skewonly);

动态采样：在进行硬解析时，进行随机的进行读取一些数据块。
当表上没有分析信息时，Oracle会使用动态采样技术。

动态采样的级别：
不同的级别，采样的数据块数量不同
level 1-10,采样数据量逐级递增
level10 对所有数据进行采样分析

oracle 10G下使用DBMS_STATS包检测不出两个列的相关性的。

set autotrace trace exp;

并行
将一件工作分成很多块，分别由不同的进程来执行，最后将结果合并。

并行的应用场景：
1，OLAP数据仓库
2，整块的数据读取操作
FTS（全表扫描），IFFS（Index Fast Full Scan）
3，并行执行高效的要素：
充足的系统资源:CPU、内存、I/O
待处理的数据分布均匀

OLAP是一个业务模型，支持这种业务模型的数据库就是数据仓库。数据块的操作比较多。

并行的机制
用户连接到数据库，数据库就会生成一个server process，当用户发出并行查询请求时，server process变成并行协调进程（QC），QC负责分发任务和接收整合数据。每一个并行进程负责自已分配的工作。

select /*+ parallel(c,2) */ * from customers c;
分配两个进程，对customers表进行查询。

select /*+ parallel(c,2) */ * from customers c
order by cust_last_name, cust_first_name;
分配两个进程进行查询操作，两个进程进行排序操作。

select /*+ parallel(c,2) / cust_last_name, count()
from customers c
group by cust_last_name
order by 2 desc;
该语句一共起了4个进程进行操作。

执行计划中看到 PX 就说明是并行执行。
PX Block Iterator 并行数据块迭代

IN—OUT
P－>S 并行转串行
P－〉P 并行进程之间传送
S－〉P 串行转并行（并是一种正常的行为）

PCWP：parallel combined with parent 当一个操作在一组进程中完成，即为PCWP
PCWC：parallel combined with child 当一个操作在另外一组并行进程中完成。

并行与性能
并行度：是Oracle在进行并行处理时，会启动几个并行进程来同时执行。

并行与当前的系统的资源情况是惜惜相关的。

当并行度设置到一定的程序的时候，性能的提高空间就达到饱和。

如何获得SQL的并行度：
v$p{x}_{s}ession.degree：是一个动态视图，是实时的，结果不好捕获v$pq_tqstat
select dfo_number, tq_id, server_type, process, num_rows, bytes
from v$pq_tqstat
order by dfo_number desc, tq_id, server_type desc, process

并行相关的初始化参数：
parallel_adaptive_multi_user
parallel_max_servers
parallel_min_servers
parallel_automatic_tuning

11G新的并行参数
parallel_degree_limit
parallel_degree_policy
parallel_force_local
parallel_min_time_threshold
parallel_servers_target
parallel_execution_message_size

这些参数尽量的保持默认，除非非常了解并行机制。

11GR2的自行并行机制
parallel_degree_policy
manual(default)
limited #对于某个数据对象已经设置好了的并行度不会改变，设置为默认的则并行度为0
auto #在RAC中自动启用In-Memory

查看某个数据表的并行度：
select table_name, degree from user_tables
where table_name in (,…);

注：degree 字段就是显示数据表的并行度。

select * from v$pq_sesstat where statistic=‘Allocation Height’;

并行其它的用途：
并行DDL操作：
create table … as select
alter table … move partition
alter table … split partition
alter table … coalesce partition

并行DML（分区表）
update
delete
merge

变量绑定
SQL语句的分析
SQL> var rm number;
SQL> exec :rm = 1;
SQL> select * from t where rm=:rm;
SQL> exec :rm = 3;
SQL> select * from t where rm=:rm;

SQL> begin
2 for i in 1…4 loop
3 execute immediate ‘select * from t where rm =:i’ using i
4 end loop;
5 end;
6 /
注：第3行，使用using i 向select中的where子句变量i传值。

查看语句的被解决次数：
select sql_text, parse_calls, loads, executions from v$sql where sql_text like ‘select * from t where %’ order by 1,2,3,4;

变量绑定的目的：
1,减少SQL硬解析的次数
2，减少系统资源开销
3，减少latch急用

变量绑定的应用场景：
1，适用于OLTP
用户高并发很高
表中有主键
操作的数据少
执行计划基本相同
SQL的重复率高
2，不适用于OLAP
执行计划多变
用户少
SQL解析对系统性能影响小。

硬解析步骤：
1，语法分析
2，语义分析

alter system flush share_pool;

会话对游标的缓存–softer_soft_parse
1, session_cached_cursor
对于已经关闭的cursor，可以把它的资源保留在pga中，用于后续对cursor的继续调用。
若该参数设置为0，Oracle将会对关闭的游标重新打开。

最好的效果－尽可能少的解析
一次硬解析，多次软解析：
declare
l_query varchar2(2000);
l_data varchar2(30);
begin
for i in 1 … 1000
loop
l_query := ‘select * from dual d’ || mod(i,2);
execute immediate l_query into 1_data;
end loop;
end;
/

一次硬解析，反复执行：
decare
l_query varchar2(2000);
l_data varchar2(30);
begin
for i in 1 … 1000
loop
l_query := ‘selec * from dual d’;
execute immediate l_query into l_data;
end loop;
end;
/

select sql_id, child_number, sql_text from v$sql
where sql_text = ‘select * from emp %’;

select sql_id, auth_check_mismatch from v$sql_shared_cursor
where sql_id = ‘’;

修改优化器：
alter session set optimizer_mode=first_rows;

select sql_id, optimizer_mode_mismatch from v$sql_shared_cursor
where sql_id = ‘sql_id’;

父子游标
v$sql_shared_cursor----提供游标共享的信息。

select sql_id, optimizer_mode_mismatch from v$sql_shared_cursor;

select sql_id, child_number, sql_text, parse_calls, plan_hash_value, loads
from v$sql
where sql_text = ‘’;

游标共享－－－cursor_sharing

使用同一个SQL的执行计划或信息来执行SQL语句。
cursor_sharing来决定是否共享游标
该参数有三个值：exact（绝对匹配SQL语句）, force（强制的变量绑定）, similar(相似)

bind peeking
1，从Oracle 9i开始，Oracle在第一次解析SQL（hard parse）时，若SQL上有变量绑定，会查看这个变量的值，以便于准确的指定执行计划；但在后续的分析中（soft parse）,瘵不会理会这个变量的值。
2，适用场景
执行计划几乎不改变（OLTP）
大量的并发
大量的除谓词外几乎相同的SQL
3，不适用场景：
执行计划会随变量值的变化而变化
少量的SQL（OLAP）

父子游标：
v$sql_shared_cursor—提供游标共享的信息。

alter session set cursort_sharing = exact/force/similar;

select address, child_address, sql_text from v$sql where sql_text like ‘’;

Oracle 11G开始有了adaptive cursor sharing(ACS)
Oracle 11G用于解决变量绑定带来的负面影响，通过不断观察bind的值，来决定新的SQL是否使用之前的执行计划，解决绑定变量导致后续执行计划不变的问题。
ACS的缺点：
1，更多的硬分析
2，产生更多的子游标，需要更多的内存
3，消耗更多的CPU

ACS是先看第一次SQL语句的执行结果，判断执行效果，如果效果不好，则改变执行计划。

清除共享池：
alter system flush shared_pool;

select sql_id, child_number, executions, loads, buffer_gets, bind_senst, bind_aware, bind_share from v$sql where sql_text = ‘’;

SQL_trace & 10046

SQL_trace
1,用以描述SQL的执行过程的trace输出
SQL是如何操作数据的
SQL执行过程中产生了哪些等待时间
SQL执行中消耗了多少资源
SQL的实际执行计划
SQL产生的递归语句

set autotrace trace only;
显示出来的执行计划，不见得就是实际的执行计划。

set auto trace (explain plan)
输出优化器的产生的执行计划（估算值）
并不会真正执行SQL语句
SQL_TRACE
SQL实际的执行情况
消耗的资源
产生的等待事件
数据的处理过程

set auto trace VS SQL_TRACE(10046)
1，当需要分析执行计划及CBO行为时，使用
set auto trace (explain plan)
2，当要看一条SQL的真实运行效果时，使用：
SQL_TRACE(10046)

产生一个SQL_TRACE
alter session set sql_trace=true;
alter session set sql_trace=false;

查看SQL_TRACE trace文件
select * from v$diag_info where name like ‘Default%’;

阅读原始的trace文件
parsing in cursor部分
len -------被分析SQL的长度
dep -------产生递归SQL的深度
uid -------user id
otc -------Oracle command type命令的类型
lid -------私有的用户id
tim -------时间戳
hv --------hash value
ad --------SQL address

parse, exec, fetch部分：
c ------- 消耗的cpu time
e ------- elapsed time操作的用时
p ------- physical reads物理读的次数
cr ------ consistent reads 一致性方式读取的数据块
cu ------ current方式读取的数据块
mis ----- cursor miss in cache硬分析次数
r ------- rows处理的行数
dep ----- depth递归SQL的深度
og ------ optimizer goal 优化器模式
tim ----- timestamp 时间戳

stats部分：
id ------ 执行计划的行源号
cnt ----- 当前行源返回的行数
pid ----- 当前行源号的父号
pos ----- 执行计划中的位置
obj ----- 当前操作的对象id（如果当前行源一个对象的话）
op ------ 当前行源的数据访问操作

tkprof–格式化trace文件的工具
tkprof sys=no

裸打tkprof命令查看帮助信息。

tkprof报告中的数据块的两种读取方式
1,query
2,current

一致性读，SCN号的关系

ORA-01555：回滚段太旧

跟踪其它会话的SQL
使用dbms_system包，对SQL_TRACE进行跟踪。
execute dbms_system.set_sql_trace_in_session(,,);

aux_stats$
MBRC: multiblock read count

SQL> exec dbms_stats.gather_system_stats(gathering_mode=>‘start’);
启动系统统计功能，用于搜集这段时间SQL执行的过程中，产生的IO和CPU的消耗来评估aux_stats$中的值。

IO_COST=(数据表数据块个数/MBRC)*（mreadtin/sreadtim）

cpu_count 显示的是逻辑CPU数量（thread）。
对并行度和代价有影响。

memory_target
oracle 9i引入pga_aggregate_target可以自动对PGA进行调整
oracle 10G 引入sga_target，可以自动对SGA进行调整
oracle 11G 则对这两部分进行综合，引入memory_target,可自动调整所有的内存，这就是新引入的自动内存管理特性。

Automatic Workload Repository(AWR)
MMON进程会每个小时从数据库系统中读取一个性能快照，存放在SYSAUX表空间。并且可以将这些历史信息更新到DBA_HIST%的视图中。

AWR报告－－的信息来源
select table_name from dict where table_name like ‘DBA_HIST%’;

dba_hist_snapshop 快照表。
dba_hist_event
dba_hist_sqlstat
dba_hist_time_mode

AWR基线
dbms_worload_repository.create_baseline(
start_snap_id => 2490,
end_snap_id => 2491,
baseline_name => ‘test_bl’,
expiration=>60
);

dbms_workload_repository.create_baseline(
start_time => to_date(‘09-jul-2008 17:00’,‘DD-MON-YYYY HH24:MI’),
end_time => to_date(‘09-jul-2008 18:00’, ‘DD-MON-YYYY HH24:MI’),
baseline_name => ‘test2_bl’,
expiration=> NULL
);

AWR报告的生成：
$ORACLE_HOME/rdbms/admin/awrrpt.sql
OLAP关注的是I/O
OLTP关注的是内存

db file squential read 是一个等待事件，原因是大量的查询语句走的索引造成的读。

v$sql查询执行时间最长的SQL语句。

IO一般来自于SQL语句。

如何查看IO出现了瓶颈，查看操作系统查看IO通道的百分比。

Foreground wait

Background wait
control file sequential read
control file parallel write
db file parallel write

v$sysstatv$sesstat
表空间的IO统计

ASH active session history
ASH报表间隔时间可以精确到分钟，因而ASH可以提供比AWR更详细的关于历史会话的信息，可以作为AWR的补充。
信息来源－－
v$activ{e}_{s}essio{n}_{h}istory---当前会话的采样数据（1秒钟一次快照）db{a}_{h}is{t}_{a}ctiv{e}_{s}es{s}_{h}istory(保留v$active_session_history再早的数据）

通过SQL查询性能差的SQL语句
select sum(a.time_waited) total_time
from v$activ{e}_{s}essio{n}_{h}istorya,v$event_name b
where a.event# = b.event# and sample_time > ‘21-NOV-04 12:00:00 AM’ and
sample_time < ‘21-NOV-04 05:00:00 AM’ and b.wait_class = ‘User I/O’;

生成ASH报告：
$ORACLE_HOME/rdbms/admin/ashrpt.sql

OWI分析的主要作用：
1，分析系统性能问题的根源
2，找到对系统性能影响最大的问题所在
3，找到TOP SQL
4，诊断系统故障的原因
5，分析BUG

OWI分析工具
1，OWI核心视图
2，AWK/STATSPACK报告
3，ASH报告
4，HANGANALYZE
5，ORACLE诊断事件DUMP工具
6，操作系统DEBUG/CALL STACK分析工具

v$syste{m}_{e}vent:总体性视图v$session_event:按照SESSION划分的总体性能视图
v$session_wait:明细信息，每三秒刷新一次等待事件

event:名称
total_waits:自从实例启动以来的等待次数
total_timeouts:事件被唤醒的总次数
time_waited:按照cs统计的总的等待时间
average_wait:平均每次等待的时间，单位是CS
SID： v$session_event session id number

v$session_wait
sid: session id
seq#: 等待次数统计
event:事件
p[1-3]:等待的详细参数
p[1-3]raw:参数的raw模式
p[1-3]text:参数的名字

vKaTeX parse error: Expected 'EOF', got '#' at position 69: …ct e.wait_class#̲, e.wait_class,…event_name e, v$system_event s
where e.name = s.event
group by e.wait_class#, e.wait_class
order by e.wait_class#;

事件分类：
idle wait
application:行锁，表锁，DDL锁等
Configuration:由于配置导致的
administrative:特权用户的某些维护操作导致的
Concurrency:由于并发量大引起的
Commit: log file sync
Network
User I/O waits:前台进程，SMON，MMON
System I/O Waits:除了SMON，MMON外的后台进程
Scheduler:资源管理引起的
Cluster: RAC
Other

LATCH等待的细分：
select event, p1, p2, p3 from v$session_wait
where event like ‘latch%’;

等待直方图：
v$even{t}_{h}istogramv$file_histogram
v$temp_histogram

v$system_wait_class
wait_class#
time_waited
time_waits
通过该视图可看系统目前主要的问题在哪儿。

v$session_wait_class
SID， serial#
wait_class#: 等待分类
time_waited
time_waits

新增v$session_wait_history视图
SID, SEQ#
event#
P1TEXT,p1
P2TEXT,p2
P3TEXT,p3

v$event_name中增加事件分类（wait_class）字段

新增v$sy{s}_{t}im{e}_{m}odel用于分析系统中DBTIME，DBCPU，及各事件的执行时间。新增v$sess_time_model 用于分析

osstat:操作系统统计视图：v$osstat

ASH: Active Session History
v$activ{e}_{s}essio{n}_{h}istorydb{a}_{h}is{t}_{a}ctiv{e}_{s}es{s}_{h}istoryAWR的一部分从v$session中每秒一次采样，除去IDLE事件，除去非active的session
除了存储在AWR中外，1/10的采样可以在视力中看到。

OWI诊断的方法：
1，从系统级开始
v$syste{m}_{e}ventv$session_wait
statspack/awr报告
关注存在较大等等时间和次数的事件
注意过滤掉IDLE事件
IDLE事件一般放在statspack报告的事件的尾部
STATS$IDL{E}_{E}VENT表对关键事件进行细致跟踪v$session_wait
statspack/awr报告
建立基线

性能分析的起点 等待事件/CPU开销
ALERT LOG 等日志
系统及SQL情况
PL/SQL情况 OWI及性能分析
SQL执行计划 Hanganalyze分析
系统调用

总体等待情况 通过AWR/Statspack
TOP 5 Timed Events

明细分析：查看db file scattered read等待事件的情况。
select sid, event, wait_time, state, p1, p2, p3 from v$session_wait
where event=‘db file scattered read’;

案例分析：
1，故障现象：查询select count(*) from org; 发现几乎HANG住：
2，分析思路：局部性故障，使用等待事件分析和HANGANALYZE结合的方法
3，分析方法：查看v$session_wait,做HANGANALYZE分析

局部变慢或者HANG信的分析方法
1，查看ALERT LOG中是否有报错
2，查看查关会话信息
3，通过v$session_wait查看等待事件
4，做ASH报告
5，检查长时间执行的SQL
6，通过HANGANALYZE分析查看是否有HANG住现象
7，查看操作系统资源。

OLAP相关的参数
1，parallel_min_servers 数据库并行服务启动最少个数
2，db_file_multiblock_read_count 多块读
3，optimizer_dynamic_sampling 动态采样
4，sga_target
5，pga_aggregate_target
6，optimizer_mode

OLTP相关的参数
1,cursor_sharing
2,sga_target
3,sessions
4,pga_aggregate_target
5,shared_pool_size

参数文件的作用：
1，设定数据库的限制
2，设定用户或进程的限制
3，设定数据库资源的限制
4，调整系统的性能

实例＝内存+进程
实例由参数文件来约束

几个常用的参数文件：
SGA_target
pga_aggregate_target PGA的使用内存总合

SGA大小 + PGA大小 ＝ Oracle的内存使用大小

db_cache_size 用于放数据块，指定大小。
db_files
log_archive_dest_n
user_dump_dest

控制文件中包含的信息：
1，数据名字
2，数据库建立时间
3，数据文件，在线日志文件，归档日志文件的信息
4，表空间信息
5，RMAN的备份信息

控制文件的作用：
1，它包含数据文件，在线日志文件，归档日志文件的信息，这些信息用于数据库OPEN时的文件验证
发数据库的架构改变时，比如增减，删除文件时，会更新控制文件
2，包含了数据库恢复时需要的一些信息，用于数据库的恢复。

控制文件的结构
1，空间允许重用区
这个区域的信息是可以被重用（覆盖的），当空间不足或者规则满足时，允许覆盖以前的信息，比如归档日志和RMAN备份集的信息
2，空间不允许重用区
这个区域的信息是不允许重用的，因为他们是数据库必须的信息如表空间，数据文件，在线日志文件等。

控制文件丢失怎么办？
1，备份控制文件
2，重建控制文件

alter database backup controlfile to trace;

日志文件的状态：
current: 表示当前系统正在使用的
inactive:表示如果进行实例恢复的时候，这个文件上的数据是不需要的
active: 表示如果实例宕机的话，这个日志文件上的数据在实例恢复的时候会用到。

重做日志的作用：
1，核心作用
保护数据的安全
恢复数据
2，附加作用－－数据同步和分析
data guard
streams
golden gate
log miner

日志文件往磁盘中写是以顺序的方式写的。

数据文件往磁盘上写的话，要先找磁盘上对应的数据块的位置；

重做日志文件损坏：
1，活动日志损坏
数据丢失，数据库损坏
2，非活动日志损坏
数据不会丢失，可以重建日志文件

数据文件
1，存放实际的数据
2，隶属于某个表空间
数据表空间
UNDO表空间
临时表空间
3，查看表空间及对应的数据文件信息：
select file_name, tablespace_name from dba_data_files;
select file_name, tablespace_name from dba_temp_files;

数据文件的损坏：
1，需用通过备份恢复
还原备份文件
用归档+在线redo恢复
2，使用REDO信息恢复
创建数据文件
用归档+在线REDO恢复