执行计划查看，autotrace工具的使用
---测试一、开始使用工具
SQL> set autotrace traceonly;
SQL> select * from emp1 where deptno=10;
| Id | Operation 操作选择 | Name | Rows | Bytes | Cost (%CPU)| Time
| --------------------------------------------------------------------------
| 0 | SELECT STATEMENT 查询语句 | | 3 | 114 | 4 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL全表扫描| EMP1 | 3 | 114 | 4 (0)| 00:00:01 |
Predicate Information (identified by operation id): 谓词信息，操作标识
1 - filter("DEPTNO"=10) 关键信息-部门10
Statistics 统计
----------------------------------------------------------
0 recursive calls 递归调用
0 db block gets 数据块获取
7 consistent gets 一致性获取
0 physical reads 物理读
0 redo size 日志读
1150 bytes sent via SQL*Net to client 通过网络发送到客户端字节
523 bytes received via SQL*Net from client 通过网络接收到的字节
2 SQL*Net roundtrips to/from client 通过网络传输的往返次数
0 sorts (memory) 内存排序
0 sorts (disk) 磁盘排序
3 rows processed 结果行数
物理读=physical reads
逻辑度=db block gets 当前数据块获取 + consistent gets 一致性获取
什么
--------------------------------------------
-以上简单介绍完毕：具体分析，每个参数值的含义：
递归调用： 为了执行这条SQL语句，Oracle内部执行了几次的查询（权限，空间管理，结构）
SQL> select * from emp1; -- 0 recursive calls
操作:delete emp1 where rownum=1;
SQL> insert into emp1 select * from emp where rownum=1;
---以上做了两个测试，删除和插入一行新的数据，递归调用没有发生改变
SQL> alter table emp1 add abc date;
SQL> select * from emp1; 10 recursive calls
--还原环境=> alter table emp1 drop column abc;
--但是对表的结构发出改变后，递归调用发生改变=》
对表的结构发生改变，存入的是哪？数据字典，因此，递归调用的次数是查询数据字典；
什么操作会触发查询数据字典：空间管理，存储够不够，安全检查，权限够不够，表的结构是否发生改变；
db block gets 数据块获取
SQL> insert into emp1 select * from emp;
| LOAD TABLE CONVENTIONAL
44 recursive calls
7 db block gets
43 consistent gets
SQL> select SEGMENT_NAME,BLOCKS from user_segments where segment_name='EMP1';
SEGMENT_NAME BLOCKS
-----------------------------------------
EMP1 8
--实验猜测，是否是插入增加了七个块的改变数据，导致的查询
SQL> drop table emp1 purge;
SQL> create table emp1 as select * from emp;
SQL> select SEGMENT_NAME,BLOCKS from user_segments where segment_name='EMP1';
--再次查询--不会变化，因为Oracle按照区分配块的数量，一次8个；
SQL> analyze table emp1 compute statistics; 对表进行分析
SQL> select blocks,empty_blocks,avg_space,num_freelist_blocks from user_tables where table_name='EMP1';
--使用的块数量 未使用的块数量 平均每个块存储量 空闲列表的块的数量
BLOCKS EMPTY_BLOCKS AVG_SPACE NUM_FREELIST_BLOCKS
4 4 7451 0
SQL> insert into emp1 select * from emp; | LOAD TABLE CONVENTIONAL
SQL> analyze table emp1 compute statistics;
SQL> select blocks,empty_blocks,avg_space,num_freelist_blocks from user_tables where table_name='EMP1';
BLOCKS EMPTY_BLOCKS AVG_SPACE NUM_FREELIST_BLOCKS
---------- ------------ ---------- -------------------
8 0 7830 0
----通过以上视图无法，insert 操作，导致表emp1的存储，多使用了四个块；
--我们开启追踪set autotrace traceonly工具，发现，DML操作（insert /update/delete）操作时，会有当前数据块读，
SQL> insert into emp1 select * from emp; | LOAD TABLE CONVENTIONAL
SQL> delete emp1 where rownum<14; | COUNT STOPKEY
SQL> update emp1 set deptno=40 where rownum<14; COUNT STOPKEY
14 recursive calls
22 db block gets
32 consistent gets
SQL> Alter system flush shared_pool; 插入操作，未提交，做一个清空共享池、buffer_cache操作，再次查询，还是无法查询到db block gets的变化
SQL> Alter system flush buffer_cache;
SQL> select * from emp1;
61 recursive calls
0 db block gets
60 consistent gets
19 physical reads
小结： db block gets:是当前读（用于，delete,update,insert的DML操作的时候，产生的逻辑读中的当前读操作)会先读数据，在进行DML操作；
逻辑读= DML操作导致的读取 + 一致性读
logical read =db block gets + consistent gets
---什么是一致性读
1.需要读取的数据，在Buffer_cache中，没有发生改变；
2.如果早上8点，发出发出查询操作，8:05分数据块发生了改变，未提交，查询操作读取数据块，发现事物未结束，会复制数据块的镜像，使用Undo进行还原，让Oracle读取的数据一致；
3.如果早上8点，发出的查询操作，8:05分数据块发生了改变，并且提交了，块头记录事物的SCN号，发现比查询的SCN大，不行，继续复制块镜像，使用UNDO还原块镜像，能还原最好，如果undo数据被覆盖了，不好意思，01555错误，快照过久，历史的数据无法查询到了；
补充：3的补充，在8:05分后的查询，拿着最新的SCN号，去找8：05分提交的数据，对比SCN，发现小或者=，直接提取就OK 了。
physical reads 物理读
SQL> Alter system flush buffer_cache; --清空buffer_cache中的所有数据块
select * from emp1;
8 consistent gets
6 physical reads
？物理读，把需要查找的数据，已块为单位提取到buffer_cache中，为啥还有逻辑读呢？逻辑读在Buffer_cache都是空的
解释说明：谁去提取数据，DBWR进程只提供写，不提供从磁盘数据文件，提取到内存的操作不干，谁做？
我们为客户，client 端，一般默认专有服务器模式（dedicated server），我们分配一个server process进行VIP客户体验，一对一服务；那么他的操作，也是server process进程提供提取数据，是直接提取到pga给用户吗？
NO，首先server process进程拿着shared pool里面拿着执行计划，到Buffer cache中寻找数据，发现没有，就根据块的地址去数据文件找，找到后，提取数据，放置在buffer cache中，然后通过内存传输数据非常快的交给客户去看。
小结： 物理读的产生，是数据所在的块在Buffer cache中没有，从数据文件提取，物理读的产生也伴随着逻辑读的产生，物理读数据块是读到内存的Buffer cache中，不是直接读取到pga用户手上；
redo size 执行的操作产生的redo日志大小:
redo size 480108
SQL> insert into emp1 select * from emp;
14 rows created.
SQL> select a.name,b.value from v$statname a,v$mystat b where a.statistic#=b.statistic# and a.name='redo size';
redo size 481024
SQL> select (481024-480108)/1024 from dual;
.89453125 --查询14行，产生了0.9k的日志量
3233 bytes sent via SQL*Net to client 通过SQL网络发送给客户端的字节
545 bytes received via SQL*Net from client通过网络接受客户端字节
4 SQL*Net roundtrips to/from client 通过SQL网络去客户端的往返次数
sorts (memory) 内存排序：排序在内存中进行，也就是在PGA中进行；
select * from emp a,emp b order by a.ename
2 sorts (memory)
Alter system flush buffer_cache; --清空Buffer_cache
set autotrace traceonly; -开启追踪
SQL> create global temporary table abc on commit preserve rows as select * from dba_objects; 创建全局会话临时表；
select * from abc order by object_id; ---显示结果，还是内存排序，并不是说，临时表，存储在临时表空间，排序的操作就在临时表空间内进行。还是优先在PGA中进行排序
SQL> show parameter pga PGA内存自动管理
NAME TYPE VALUE
--------------------------------------------------------------------
pga_aggregate_target big integer 0
SQL> select * from v$pgastat where name like 'maximum PGA used for auto workareas%';
NAME VALUE UNIT --查询PGA，的内存自动管理模式下分配的最大内存大小
-----------------------------------------------------------------------------
maximum PGA used for auto workareas 115332096 bytes
select 115332096/1024/1024 from dual;
109.989258 M
sorts (disk) : 磁盘排序
什么样的情况下会磁盘排序，首先什么时候会排序：
Order by ,distinct ,union 这些操作都会涉及到排序，排序优先在PGA中进行，因为在内存中排序很快；
然而，如果大量的排序，导致的后果就是内存迅速被填充满，最后不够用了，但是操作还是要继续，就在临时表空间内进行排序操作，也就是磁盘排序；
-------这种事要极力避免的，磁盘IO是瓶颈，内存速度是磁盘的千倍；
rows processed结果的记录数
