Oracle通过分区键值发现性能问题(一)

2014-11-24 17:14:11 · 作者: · 浏览: 0

在很多应用中如果数据量少有规模,都会有大量的分区表存在,使用比较多的是range partition.


一般的range partition都一时间为键值,或者根据业务绑定的关键id值。


虽然已经做了一些大数据量的数据迁移,但是不管是按照分区抽取,还是根据数据条数抽取,发现有一个表比较奇怪,一个100G左右的分区表,80%以上的数据都分布在一个分区里面,而这个大分区表却有180多个分区表。


如下所示,对于表charge,如果分区的大小在200M以内,就标记为1,如果大于200M,则按照200M为单位进行统计,可以看到,如下的分区 P120_C10占用了大量的空间,其他的分区却小的可怜。很明显从业务规划的角度存在一定的问题。



CHARGE P120_C100 1
CHARGE P120_C10 438
CHARGE P120_C20 1
CHARGE P120_C30 1
CHARGE P120_C40 1
CHARGE P120_C50 1
CHARGE P120_C60 1
CHARGE P120_C70 1
CHARGE P120_C80 1
CHARGE P120_C90 1
CHARGE P25_C100 1
CHARGE P25_C10 2
CHARGE P25_C20 1
CHARGE P25_C30 1
CHARGE P25_C40 1
CHARGE P25_C50 1
CHARGE P25_C60 1
CHARGE P25_C70 1
CHARGE P25_C80 1
CHARGE P25_C90 1
CHARGE P26_C100 1
CHARGE P26_C10 1
CHARGE P26_C20 1
CHARGE P26_C30 1
CHARGE P26_C40 1
CHARGE P26_C50 1
CHARGE P26_C60 1
CHARGE P26_C70 1
CHARGE P26_C80 1
CHARGE P26_C90 1
CHARGE P27_C100 1
CHARGE P27_C10 1
CHARGE P27_C20 1
CHARGE P27_C30 1
CHARGE P27_C40 1
CHARGE P27_C50 1



带着这个疑问,和对应的开发人员进行了沟通,因为这个表已经使用很长时间了,他们想让我们提供一些关键的信息,比如分区的逻辑等,简单抽取了一些信息如下,
对于最大的分区P120_C10来说,High_value是120,10 直接看也看不出来什么问题。


PARTITION_NAME HIGH_VALUE TS_NAME INI_TRANS LOGGING COMPRESS GLO LAST_ANAL
------------------------- --------------- ---------- ---------- ------- -------- --- ---------
.......
P41_C90 41, 90 DATAH01 8 NO DISABLED YES 15-AUG-14
P41_C100 41, 100 DATAH01 8 NO DISABLED YES 15-AUG-14
P120_C10 120, 10 DATAH01 8 NO DISABLED YES 15-AUG-14
P120_C20 120, 20 DATAH01 8 NO DISABLED YES 12-AUG-14
P120_C30 120, 30 DATAH01 8 NO DISABLED YES 12-AUG-14
P120_C40 120, 40 DATAH01 8 NO DISABLED YES 12-AUG-14
P120_C50