Oracle 分区和性能

 

      理论上，我们进行表分区都是为了提升性能，加快查询速度。但是有的时候，不但不能加快查询速度，反而拖累的查询速度。下面举的一个例子就是这样的：

 

      假设某一个表是按照主键散列分区，创建表如下所示：

 

create table t
 ( OWNER, OBJECT_NAME, SUBOBJECT_NAME, OBJECT_ID, DATA_OBJECT_ID,
 OBJECT_TYPE, CREATED, LAST_DDL_TIME, TIMESTAMP, STATUS,
 TEMPORARY, GENERATED, SECONDARY )
 partition by hash(object_id)
 partitions 16
 as
 select * from all_objects;

      我们经常要在表上面，根据owner 或者 object_type,object_name 或者owner, object_type,object_name进行查询。于是我们想到在这三列上建立一个局部索引。如下所示：

 

 create index t_idx
 on t(owner,object_type,object_name)
 LOCAL

      运行一个存储过程收集cpu耗用等信息：

 

begin
 dbms_stats.gather_table_stats
 ( user, 'T', cascade=>true);
 end;
 /

 

      改变几个会话属性，便于允许TKPROF

 

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

      执行如下SQL语句：

 

 select * from t where owner='SCOTT' and object_type = 'TABLE' and object_name = 'EMP';
 select * from all_objects where owner='SCOTT' and object_type = 'TABLE' and object_name = 'EMP';

      查看TKPROF记录的性能日志位置：

 

select rtrim(c.value,'\') ||'\'||d.instance_name||
    '_ora_' ||ltrim(to_char(a.spid))||'.trc'
    from v$process a,v$session b,v$parameter c,v$instance d
    where a.addr=b.paddr
    and b.audsid =sys_context('userenv','sessionid')
    and c.name='user_dump_dest';

      假如看到这样的输出：D:\ORACLELWS\PRODUCT\10.2.0\ADMIN\ORCL\UDUMP\orcl_ora_5928.trc

      另外打开一个命令行，输入如下命令解析日志文件

 

tkprof D:\ORACLELWS\PRODUCT\10.2.0\ADMIN\ORCL\UDUMP\orcl_ora_5928.trc

      弹出一个output = 要你输入解析日志之后的文件存放的目录，可以填写c:\tk.prof ，必须prof后缀。

      这个时候我们可以用记事本打开tk.prof文件查看上述两条查询SQL语句的性能，我的机器上查看的结果如下

 

select * 
from
 t where owner='SCOTT' and object_type = 'TABLE' and object_name = 'EMP'


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00       0.00          0         34          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.00       0.00          0         34          0           1


select * 
from
 all_objects where owner='SCOTT' and object_type = 'TABLE' and object_name = 
  'EMP'


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.01       0.01          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00       0.00          0          8          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.01       0.01          0          8          0           1

     各个字段的意思可以百度一下，我们发现query字段分区是34，不分区是8。query代表I/O操作次数，分区反而增加了I/O操作次数，费力不讨好。这是因为查找条件字段没有包含分区表的分区键，导致每一个表分区都要扫描，也就是每一个索引分区都要扫描，还不如全表扫描来得快。

     如果不创建局部索引，而是建立一个全局索引。效率跟不分区差不多，创建局部分区的sql换成：

 

create index t_idx
 on t(owner,object_type,object_name)
 global
 partition by hash(owner)
 partitions 16
 

    其实，对于OLTP系统，分区对于获取数据没有什么正面影响（基本不能提高查询速度）。相反，我们还有非常小心避免产生负面影响，比如上面那个例子。但是对于高度并发修改的环境，分区则可能提供显著的效果，因为分区避免了数据的冲突，你修改这个分区，他修改那个分区，大大降低了发生冲突的可能性。因此，不要盲目使用分区，分区不一定能够提高性能。

 

评论

1 楼 dsfengzh 2012-12-10  

你建分区是用的是partition by hash(object_id)，而建的索引却是
2.on t(owner,object_type,object_name) 
3.LOCAL 
这就是本地非前缀索引，查询时会引用到每个分区的索引，对于查询系统是有影响，但是好处是当你要删除一个分区时，可以直接删除整个分区，而不用重建索引，对于生产环境相当有用。