正文

SQL性能调优基础教材

IP云
IP云V管理员/1 阅读
11/30
小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

一、数据库体系结构

1.       Oracle数据库和实例

数据库：物理操作系统文件或磁盘的集合。

实例：一组Oracle后台进程/线程以及一个共享内存区，这些内存由同一个计算机上运行的线程/进程所共享。

2.       文件

参数文件

跟踪文件

警告文件

临时文件

控制文件

重做日志文件

密码文件

3.  内存结构和进程

SGA

PGA

PMON

SMON

RECO

CKPT

DBWn

LGWR

ARCn

4.  Redo和undo

Undo和redo的作用及如何协作

Undo(撤销信息)是oracle在undo段中记录的信息，用于取消或回滚事务。Undo在数据库内存储在一组特殊的段中，叫undo段。对于每个insert，oracle会完成一个delete，对每个delete，oracle会执行一个insert。对于每个update，oracle会执行一个“反update”，或者执行；另一个upate将修改前的行放回去。

Redo(重做日志)是oracle在在线（或归档）重做日志文件中记录的信息，万一出现失败时可以利用这些数据来“重放”（或重做）事务。

Undo和redo如何协作

如何测量undo和redo--实验

  • 为什么要测量 undo 和 redo ？
  • 在进行大规模数据操作时，有可能会造成数据库慢甚至挂起。如果事先能对日志进行测量，能够预防此类事件的发生。
  • 本会话测量方法：

select name, value
from v$mystat, v$statname
where v$mystat.statistic# = v$statname.statistic#
and (v$statname.name = 'redo size' or
v$statname.name = 'undo change vector size');

  • 对一张表进行 insert 、 update 、 delete 操作 , 生成 undo 、 redo 大小排序

Delete > update > insert

  • Commit做了什么

  • 如何减少产生redo，使用Nologging吗—实验

二、数据库逻辑和物理存储结构

1.      目标

能让大家对oracle数据存储逻辑结构和物理结构有一个认识，研究数据库存储最小单元block。围绕着block做一些实验，解决大家在日常工作中遇到的困惑。

2.      概念

数据库逻辑结构为数据块（Data Block）、数据扩展（Extent）、和段（Segment）; 物理结构为数据文件。

Block是最精细的数据存储粒度，一个数据块相当于磁盘上一段连续的物理存储空间，oracle每次访问数据的单位是block。

Extent是为存储数据而分配的一组连续的block。

Segment则是由一个或多个Extent。一张表可以看做是一个段，一个索引可以做作是一个段。查看段的分类select distinct segment_type from user_segments 。

数据逻辑上存储表空间（Tablespace）中，而物理上则存储于属于表空间的数据文件（data file）中。

3.      如何查看表和索引的大小

查看表dba_segments、user_segments

4.      Block结构

数据块头 ：包含了此数据块的概要信息，如块地址（block address）及数据块所属的段的类型。

表目录区： 如果一张表在此数据块中存储了数据行，那么这张表的信息将被记录在数据块的表目录区中。

行目录区： 此区域包含数据块中存储的数据行的信息。

可用空间区： 在插入新数据行，或在更新数据行需要空间时，将使用此区域。

行数据区： 包含表和索引的实际数据。一个数据行可以跨多个数据库。

5.      Dump block（在内存中的结构）--实验

SQL> create table test(name varchar2(10));

SQL> insert into test values('中国');

SQL> insert into test values('美国');

SQL> commit;

SQL> set serveroutput on

SQL> exec show_space1('TEST','auto','table');

Total Blocks............................8

Total Bytes.............................65536

Unused Blocks...........................0

Unused Bytes............................0

Last Used Ext FileId....................6

Last Used Ext BlockId...................124225

Last Used Block.........................8

Last Used Ext BlockId + Last Used Block -1 = 段中扩展最后一个块使用的blockId

124225+8-1=124232;

SQL> alter system dump datafile 6 block 124232;

*** 2013-03-06 08:28:58.181

Start dump data blocks tsn: 7 file#: 6 minblk 124232 maxblk 124232

buffer tsn: 7 rdba: 0x0181e548 (6/124232)

scn: 0x095a.e56f14ce seq: 0x01 flg: 0x06 tail: 0x14ce0601

frmt: 0x02 chkval: 0x8092 type: 0x06=trans data

Hex dump of block: st=0, typ_found=1

Dump of memory from 0x08D52A00 to 0x08D54A00

8D52A00 0000A206 0181E548 E56F14CE 0601095A  [....H.....o.Z...]

8D52A10 00008092 00000001 000180A2 E56F14C6  [..............o.]

8D52A20 0000095A 00320002 0181E541 00020002  [Z.....2.A.......]

8D52A30 000072BB 0081FA06 00261E1C 00002002  [.r........&.. ..]

8D52A40 E56F14CE 00000000 00000000 00000000  [..o.............]

8D52A50 00000000 00000000 00000000 00000000  [................]

8D52A60 00000000 00020100 0016FFFF 1F701F88  [..............p.]

8D52A70 00001F70 1F900002 00001F88 00000000  [p...............]

8D52A80 00000000 00000000 00000000 00000000  [................]

Repeat 501 times

8D549E0 00000000 00000000 00000000 0401012C  [............,...]

8D549F0 FAB9C0C3 0401012C FAB9D0D6 14CE0601  [....,...........]

Block header dump:  0x0181e548

Object id on Block? Y

seg/obj: 0x180a2  csc: 0x95a.e56f14c6  itc: 2  flg: E  typ: 1 - DATA

brn: 0  bdba: 0x181e541 ver: 0x01 opc: 0

inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0002.002.000072bb  0x0081fa06.1e1c.26  --U-    2  fsc 0x0000.e56f14ce

0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000

data_block_dump,data header at 0x8d52a64

===============

tsiz: 0x1f98

hsiz: 0x16

pbl: 0x08d52a64

bdba: 0x0181e548

76543210

flag=--------

ntab=1

nrow=2

frre=-1

fsbo=0x16

fseo=0x1f88

avsp=0x1f70

tosp=0x1f70

0xe:pti[0]   nrow=2  offs=0

0x12:pri[0]       offs=0x1f90

0x14:pri[1]       offs=0x1f88

block_row_dump:

tab 0, row 0, @0x1f90

tl: 8 fb: --H-FL-- lb: 0x1  cc: 1

col  0: [ 4]  d6 d0 b9 fa

tab 0, row 1, @0x1f88

tl: 8 fb: --H-FL-- lb: 0x1  cc: 1

col  0: [ 4]  c3 c0 b9 fa

end_of_block_dump

End dump data blocks tsn: 7 file#: 6 minblk 124232 maxblk 124232

seg/obj: 0x180a2

select pkg_number_trans.f_hex_to_dec('180a2') from dual;

select * from user_objects where object_id=98466;

解析字段内容

select to_number('d6d0','xxxx')from dual;--54992

select chr(54992)from dual;--中

select to_number('b9fa','xxxx')from dual;--47610

select chr(47610)from dual;--国

6.      Oracle如何实现行锁--实验

通过数据库的物理结构实现行锁。

SQL> insert into test values('韩国');

SQL> insert into test values('朝鲜');

SQL> insert into test values('越南');

SQL> commit;

SQL>  alter system dump datafile 6 block 124232;

第一次dump:

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0007.002.0000485b  0x00803738.1615.20  --U-    2  fsc 0x0000.e56fe278

0x02 0x0008.021.00007172  0x00801255.1683.1d  --U-    2  fsc 0x0000.e56fe26dfsc

block_row_dump:

tab 0, row 0, @0x1f90

tl: 8 fb: --H-FL-- lb: 0x2  cc: 1

col  0: [ 4]  d6 d0 b9 fa

tab 0, row 1, @0x1f88

tl: 8 fb: --H-FL-- lb: 0x2  cc: 1

col  0: [ 4]  c3 c0 b9 fa

tab 0, row 2, @0x1f80

tl: 8 fb: --H-FL-- lb: 0x0  cc: 1

col  0: [ 4]  ba ab b9 fa

tab 0, row 3, @0x1f78

tl: 8 fb: --H-FL-- lb: 0x1  cc: 1

col  0: [ 4]  b3 af cf ca

tab 0, row 4, @0x1f70

tl: 8 fb: --H-FL-- lb: 0x1  cc: 1

col  0: [ 4]  d4 bd c4 cf

end_of_block_dump

SQL> select * from test where name='中国' for update;

SQL> alter system dump datafile 6 block 124232;

第二次dump:

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0004.02d.00004869  0x00800ff7.1290.1f  C---    0  scn 0x095a.e56fe16c

0x02   0x0008.021.00007172  0x00801255.1683.1c  ----    1  fsc 0x0000.00000000

block_row_dump:

tab 0, row 0, @0x1f90

tl: 8 fb: --H-FL-- lb: 0x2  cc: 1

col  0: [ 4]  d6 d0 b9 fa

tab 0, row 1, @0x1f88

tl: 8 fb: --H-FL-- lb: 0x2  cc: 1

col  0: [ 4]  c3 c0 b9 fa

tab 0, row 2, @0x1f80

tl: 8 fb: --H-FL-- lb: 0x0  cc: 1

col  0: [ 4]  ba ab b9 fa

tab 0, row 3, @0x1f78

tl: 8 fb: --H-FL-- lb: 0x1  cc: 1

col  0: [ 4]  b3 af cf ca

tab 0, row 4, @0x1f70

tl: 8 fb: --H-FL-- lb: 0x1  cc: 1

col  0: [ 4]  d4 bd c4 cf

end_of_block_dump

SQL> select * from test where name='美国' for update;

SQL> alter system dump datafile 6 block 124232;

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0007.002.0000485b  0x00803738.1615.20  C---    0  scn 0x095a.e56fe278

0x02   0x0003.00d.000060b0  0x00809898.176b.0e  ----    2  fsc 0x0000.00000000

block_row_dump:

tab 0, row 0, @0x1f90

tl: 8 fb: --H-FL-- lb: 0x2  cc: 1

col  0: [ 4]  d6 d0 b9 fa

tab 0, row 1, @0x1f88

tl: 8 fb: --H-FL-- lb: 0x2  cc: 1

col  0: [ 4]  c3 c0 b9 fa

tab 0, row 2, @0x1f80

tl: 8 fb: --H-FL-- lb: 0x0  cc: 1

col  0: [ 4]  ba ab b9 fa

tab 0, row 3, @0x1f78

tl: 8 fb: --H-FL-- lb: 0x0  cc: 1

col  0: [ 4]  b3 af cf ca

tab 0, row 4, @0x1f70

tl: 8 fb: --H-FL-- lb: 0x0  cc: 1

col  0: [ 4]  d4 bd c4 cf

end_of_block_dump

重新开一个 session:

SQL> select * from test where name='韩国' for update;

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0006.015.0000600e  0x008037b9.18b7.1d  ----    1  fsc 0x0000.00000000

0x02   0x0003.00d.000060b0  0x00809898.176b.0e  ----    2  fsc 0x0000.00000000

block_row_dump:

tab 0, row 0, @0x1f90

tl: 8 fb: --H-FL-- lb: 0x2  cc: 1

col  0: [ 4]  d6 d0 b9 fa

tab 0, row 1, @0x1f88

tl: 8 fb: --H-FL-- lb: 0x2  cc: 1

col  0: [ 4]  c3 c0 b9 fa

tab 0, row 2, @0x1f80

tl: 8 fb: --H-FL-- lb: 0x1  cc: 1

col  0: [ 4]  ba ab b9 fa

tab 0, row 3, @0x1f78

tl: 8 fb: --H-FL-- lb: 0x0  cc: 1

col  0: [ 4]  b3 af cf ca

tab 0, row 4, @0x1f70

tl: 8 fb: --H-FL-- lb: 0x0  cc: 1

col  0: [ 4]  d4 bd c4 cf

end_of_block_dump

重新开一个 session:

SQL> select * from test where name='韩国' for update;

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0006.015.0000600e  0x008037b9.18b7.1d  ----    1  fsc 0x0000.00000000

0x02   0x0003.00d.000060b0  0x00809898.176b.0e  ----    2  fsc 0x0000.00000000

0x03   0x0009.02c.00005fda  0x00803853.1868.04  ----    1  fsc 0x0000.00000000

block_row_dump:

tab 0, row 0, @0x1f78

tl: 8 fb: --H-FL-- lb: 0x2  cc: 1

col  0: [ 4]  d6 d0 b9 fa

tab 0, row 1, @0x1f70

tl: 8 fb: --H-FL-- lb: 0x2  cc: 1

col  0: [ 4]  c3 c0 b9 fa

tab 0, row 2, @0x1f68

tl: 8 fb: --H-FL-- lb: 0x1  cc: 1

col  0: [ 4]  ba ab b9 fa

tab 0, row 3, @0x1f60

tl: 8 fb: --H-FL-- lb: 0x3  cc: 1

col  0: [ 4]  b3 af cf ca

tab 0, row 4, @0x1f58

tl: 8 fb: --H-FL-- lb: 0x0  cc: 1

col  0: [ 4]  d4 bd c4 cf

end_of_block_dump

7.      Block参数PCTFREE、PCTUSED

PCTFREE：为一个块保留的空间百分比，表示数据块在什么情况下可以被insert，默认是10，表示当数据块的可用空间低于10%后，就不可以被insert了，只能被用于update；即：当使用一个block时，在达到pctfree之前，该block是一直可以被插入的，这个时候处在上升期。

PCTUSED：是指当块里的数据低于多少百分比时，又可以重新被insert，一般默认是40,即40%，即：当数据低于40%时，又可以写入新的数据，这个时候处在下降期。

注意：如果表空间上启用了ASSM，在建立表的时候，只能指定PCTFREE，否则可用指定PCTFREE和PCTUSED。

8.      行迁移和行链接

有两种情况会导致表中某行数据过大，一个数据块无法容纳。
第一种情况： 当一行数据被插入时一个数据块就无法容纳，在这种情况下oracle将这行数据存储在段内的一个数据块链中。在插入数据量大的行时常会发生行链接(row 　　chaining)。例如一个包含数据类型为long或long raw列的数据行，此时行链接不可避免。
第二种情况： 原本存储在一个数据块内的数据行，因为更新操作导致长度增长，而所在数据块的可用空间也不能容纳增长后的数据行。在这种情况下，oracle将此行数据迁移　　到新的数据块中，oracle在被迁移数据行原本所在位置保存一个指向新数据块的指针。被迁移数据行的rowid保持不变。当数据行发生链接或迁移时，对其访问将会造成I/O性能降低，因为oracle为获取这些数据行的数据时，必须访问更多的数据块。

可以看到行迁移发生在update,有一部分数据放在当前块，有一部分数据放在链接的块中。行链接在当前块只放一个地址，内容全部在链接的块中，且可能有多个链接块。

行迁移和行链接的危害？

会引起额外的I/O操作。

如何检测出行迁移？

SQL> @?\RDBMS\ADMIN\utlchain.sql

SQL> analyze table 【table_name】 list chained rows into chained_rows;

SQL> select owner_name,table_name,head_rowid from chained_rows;

如何避免和消除行迁移和行链接？

不要插入一行数据，而一行带有大量NULL的列，更合适的是，从一开始插入数据就要填满行。

使用增大block size的表空间。

增大pctfree。

重建表或索引。

9.      解释表上参数含义

create table TEST

(

ID NUMBER

)

tablespace DFWMS

pctfree 10

initrans 1

maxtrans 255

storage

(

initial 64

minextents 1

maxextents unlimited

);

10.Rowid的理解--实验

rowid是伪列（pseudocolumn），伪劣的意思是实际上这一列本身在数据字典中并不存在，在查询结果输出时它被构造出来的。  rowid并不会真正存在于表的data block中,但是他会存在于index当中，用来通过rowid来寻找表中的行数据。rowid的组成：数据对象号+相对文件号+数据块号+在数据块中的行号。

select t.rowid,t.* from test t; --AAAMimAAFAAAAAMAAC

64进制  A-Z(0-25)a-z(26-51)0-9(52-61)+/(62-63)

select 12*64*64+34*64+38 from dual; --51366

select rowid,dbms_rowid.rowid_object(rowid) object_id,--51366(AAAMim)AAFAAAAAMAAC 数据对象号

dbms_rowid.rowid_relative_fno(rowid) file_id, --5 AAAMim(AAF)AAAAAMAAC 相对文件号

dbms_rowid.rowid_block_number(rowid) block_id, --12 AAAMimAAF(AAAAAM)AAC 在第几个块

dbms_rowid.rowid_row_number(rowid) num  --2  AAAMimAAFAAAAAM(AAC)在block中的行数

from test where object_id =51350;

11.高水位线--实验

drop table test1 purge;

create table test1 as select * from dba_objects;

begin

for i in 1 .. 100 loop

execute immediate 'insert into test1 select * from dba_objects';

end loop;

end;

exec dbms_stats.gather_table_stats(user,'TEST1');

select count(*) from test1;

delete from test1;

select count(*) from test1;

ORACLE用HWM来界定 一个段中 使用的块和未使用的块。 HWM在插入数据时,当现有空间不足而进行空间的扩展时会向上移,但 删除数据时不会往下移 。这就好比是水库的水位,当涨水时,水位往上移,当水退出后,最高水位的痕迹还是清淅可见。 ORACLE的全表扫描是读取高水位标记(HWM)以下的所有块 。

高水位线带来的问题：如果在执行删除操作后不降低高水位线标记，则将导致查询语句的性能低下。

如何修正ORACLE表的高水位线：

1.执行表重建指令 alter table table_name move;

(在线转移表空间ALTER TABLE … MOVE TABLESPACE …ALTER TABLE … MOVE 后面不跟参数也行，不跟参数表还是在原来的表空间，move后记住重建索引。如果以后还要继续向这个表增加数据，没有必要move，只是释放出来的空间，只能这个表用，其他的表或者segment无法使用该空间)；

2.执行alter table table_name shrink space; 注意，此命令为Oracle 10g新增功能，再执行该指令之前必须允许行移动alter table table_name enable row movement;

3.复制要保留的数据到临时表t，drop原表，然后rename临时表t为原表；

4.emp/imp；

5.alter   table  table_name  deallocate   unused ；

6.尽量truncate 。

12.Drop、Truncate 和delete区别--实验

语句类型上来区分：

delete语句是dml,这个操作会放到rollback segement中,事务提交之后才生效;如果有相应的trigger,执行的时候将被触发。
truncate是ddl, 操作立即生效,原数据不放到rollback segment中,不能回滚. 操作不触发trigger。

Drop是ddl.

Truncate 和 drop 的区别

通过观察redo和执行时间对比。

对表空间的影响来区分：

delete语句不影响表所占用的extent, 高水线(high watermark)保持原位置不动。

truncate 语句缺省情况下将空间释放到 minextents个extent,除非使用reuse storage（TRUNCATE TABLE big_emp1 REUSE STORAGE）;而且truncate会将高水线复位(回到最开始)。

安全性考虑：

如果没有备份，尽量不要用truncate。

想保留表而将所有数据删除。如果和事务无关，用truncate即可。如果和事务有关，或者想触发trigger，还是用delete。

想删除部分数据行用delete，注意带上where子句，回滚段要足够大。用delete误删数据后如何恢复。

SELECT count(*) from pub_department AS OF TIMESTAMP TO_TIMESTAMP('2012-08-26 15:29:00', 'YYYY-MM-DD HH24:MI:SS');

三、SQL诊断、跟踪

1.      autotrace

autotrace是SQL*Plus中的一个工具，可以显示所执行查询的解释计划以及所用的资源。安装autotrace的步骤：

  1. 以sys登录sql*plus
  2. 运行@?rdbms/admin/utlxplan
  3. 运行create public synonym plan_table for plan_table
  4. 运行grant all on plan_table to public
  5. 运行@?rdbms/admin/plustrce
  6. 运行grant plustrace to public

Set autotrace off：不生成autotrace报告。这是默认设置。

Set autotrace on exp：autotrace报告只显示优化器执行路径。

Set autotrace on stat：autotrace报告只显示SQL语句的执行统计信息。

Set autotrace on：autotrace报告即包括优化器执行路径，也包括统计信息。

Set autotrace traceonly：与Set autotrace on类似，但不显示用户的查询输出

SQL> set autotrace traceonly

SQL> set timing on

SQL> select * from employee;

已选择9行。

已用时间:  00: 00: 00.01

执行计划

----------------------------------------------------------------------------------------------------

| Id  | Operation         | Name     | Rows  | Bytes | Cost (%CPU)|

---------------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |          |     9 |    81 |     3 (0)|

|   1 |  TABLE ACCESS FULL| EMPLOYEE |     9 |    81 |     3 (0)|

---------------------------------------------------------------------------------------------------

统计信息

----------------------------------------------------------

0  recursive calls

0  db block gets

8  consistent gets

0  physical reads

0  redo size

583  bytes sent via SQL*Net to client

350  bytes received via SQL*Net from client

2  SQL*Net roundtrips to/from client

0  sorts (memory)

0  sorts (disk)

9  rows processed

recursive calls :递归调用。一般原因：dictionary cache未命中；动态存储扩展；PL/SQL语句

db block gets ： 从buffer cache中读取的block的数量(多为update)

consistent gets： 从buffer cache中读取的block的数量(多为select)

physical reads： 从磁盘读取的block的数量

redo size： DML生成的redo的大小

BYTES SENT VIA SQL*NET TO CLIENT：服务器通过SQL*NET向客户端发送的字节数

BYTES RECEIVED VIA SQL*NET FROM CLIENT：客户端向SQL*NET 发送的字节数

SQL*NET ROUNDTRIPS TO/FROM CLIENT：服务器与CLIENT通信的次数

sorts (memory) ：在内存执行的排序量

sorts (disk) ：在磁盘上执行的排序量

rows processed ：返回记录数

在理想情况下，要度量资源的消耗应该考虑数据库引擎使用的所有资源类型，包括：CPU、内存、磁盘以及网络。当然，这是能做到的。不过遗憾的是，得到并评估所有的数据要花费大量时间和努力，且通常只能对一个调优会话中有限的SQL语句这么做。还应该考虑当处理一行的时候，CPU处理的时间依赖于处理器的速度，很明显这在不同系统中是不一样的。此外，内存的使用量和返回的行数大致成正比，而磁盘和网络资源并不总是会用到。实际上，常看到长时间运行的SQL语句使用了不大的内存，但却没有产生磁盘和网络访问。

幸运的是，存在一个针对单一数据库的易于收集的度量，能够告诉我们许多关于数据库引擎工作量的信息：逻辑读数量，即，在执行 SQL 语句的时候从高速缓存中读取的块数。

2.      10046事件--实验

10046事件并不是oracle官方提供给用户的使用命令，在官方文档中找不到这个事件的说明信息，但是目前已经使用得非常广泛，它比sql_trace能够获得更多的信息。

10046事件按照收集的信息内容，可以分为4个级别：

Level 1 等同于sql_trace的功能。

Level 4 在Level 1的基础上增加收集绑定变量的信息。

Level 8 在Level 1的基础上增加等待事件的信息。

Level 12 等同于Level 4+ Level 8,即同时收集绑定变量和等待事件的时间信息。

实验：

create table test as select * from dba_objects;

exec  dbms_stats.gather_table_stats(user,'TEST');

var x number;

var y varchar2;

exec :x:= 20;

exec :y:='TEST';

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

select object_id,object_name from test where object_id=:x or object_name=:y;

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

trace 出来的文件可读性差，这个时候会使用tkprof工具处理这个trace文件。Tkprof的命令为：

D:\admin\oracle\udump>tkprof oracle_ora_3004.trc 3004.txt

Tkprof有很多参数，介绍几个常用的：

Explain=username/password ，在trace文件中输入SQL的执行计划，如果不使用explain，在trace文件中看到的是SQL实际的执行路径。

Sys=(yes/no) ，如果设置为yes，在trace文件中将输入所有的SYS用户的操作（也包括用户SQL语句引发的递归SQL），如果为no，则不输入这些信息。默认情况下是yes，实际上设置成no后trace文件更具有可读性。

Aggragate=(yes/no) ，默认情况下，tkprof工具将所有相同的SQL在输入文件中做合并，如果设置为no，则分别列出每个SQL的信息。

任何一条SQL，包含3个步骤（对应的call列）。

分析（ parse ） : SQL的分析阶段。

执行（ execute ） : SQL的执行阶段。

数据提取（ fetch ） : 数据的提取阶段。

Count: 计数器，表示当前操作被执行了多少次。

CPU: 当前的操作消耗CPU的时间（单位秒）

Elapsed: 当前的操作一共用时多少（包括CPU时间和等待时间）。

Disk-: 当前操作的物理读（磁盘I/O次数）。

Query: 当前操作的一致性读方式读取的数据块数（通常的查询使用的方式）。

Current: 当前操作的current的方式读取的数据块数（通常是修改数据使用的方式）。

Rows: 当前操作处理的数据记录数。

3.      10053事件（待写）

四、表的存储结构和特征（包括分区）

堆表的最大特征就是数据的存储独立性，即数据的存储与数据值没有任何关联地被存储在磁盘的任意位置上（允许数据被存储在磁盘的任意位置上）。从另一个角度看，随机存储方式就是数据所占用的位置分散到不同的数据块上。由于数据被分散地存储在多个数据块上，数据的读取效率也同样的会随着它们的分散程度的不同而不同，即分散程度越高，数据读取效率越低；分散程度越低，数据读取效率越高。

五、索引

索引的类型，索引的高度和碎片是日常维护要做的

索引占空间吗？

b-tree索引的结构。

索引dump的结果，

表中的数据删除后，索引会相应删除吗。

表数据修改时，原索引会删除吗？

  1. 索引访问的方式（常见的是这几种，不限于这几种）

索引唯一扫描(Index unique Scan): 在大部分情况下该扫描方式主要被使用在检索唯一Rowid的查询中，为了进行索引唯一扫描而必须基于主键创建索引，或者创建唯一索引，且在SQL语句必须为索引列使用“=”比较运算符。否则即使基于具有唯一值的列创建了索引，在执行时优化器也不可能选择索引唯一扫描，而会选择范围扫描。

索引范围扫描(Index Range Scan):

索引全扫描(Index full scan)

索引快速全扫描(Index fast full scan)

索引跳跃式扫描(Index Skip Scan)

2.哪些情况下用不到索引

3. 聚簇因子是指，按照索引列值进行了排序的索引行序和对应表中数据行序的相似程度。

六、锁

七、Latch

八、优化器

九、Hints

十一、等待事件

十二、分析及动态采样

十三、变量绑定

优点

缺点

运用场景

十四、性能视图和性能参数

v$session

v$session_wait

十五、SQL执行过程

十六、执行计划

索引的访问方式：

索引唯一扫描（index unique scan)

索引范围扫描（index range scan)

索引全扫描（index full scan)

索引快速扫描（index fast full scan)

索引跳跃式扫描（index skip scan)

表的连接方式：

笛卡尔连接(Merge join Cartesian)

嵌套循环连接(Nested loops)

哈希连接(Hash Join)

半连接(semi Join)

排序合并连接 (Sort Merge Join)

外连接(Outer Join)

索引连接(Index Join)

其他运算方式的执行计划：

迭代执行计划(IN-list)执行计划

连锁(Concatenation)执行计划

排序操作执行计划

并集(union , union-all) 执行计划

交集(Itersection) 执行计划

差集执行计划

COUNT(STOPKEY)执行计划

十七、性能报告分析（AWR，ASH）

十八、软件过程各阶段管控性能

相关阅读

目录[+]