比如说存在一个用户数据表,并且这个表没有添加索引。这个表里的数据每天都要进行归档操作,把用户数据表里的数据转移到另外一个表,然后delete以前的数据。时间一长这就可能造成查询速度慢。
原因是数据库碎片引起的,那什么是数据库碎片。了解数据库碎片之前,先要了解一个词:水位线。
什么是水线(High Water Mark)?
所有的Oracle段(segments,在此,为了理解方便,建议把segment作为表的一个同义词) 都有一个在段内容纳数据的上限,我们把这个上限称为"high water mark"或HWM。这个HWM是一个标记,用来说明已经有多少没有使用的数据块分配给这个segment。HWM通常增长的幅度为一次5个数据块,原则上HWM只会增大,不会缩小,即使将表中的数据全部删除,HWM还是为原值,由于这个特点,使HWM很象一个水库的历史最高水位,这也就是HWM的原始含义,当然不能说一个水库没水了,就说该水库的历史最高水位为0。但是如果我们在表上使用了truncate命令,则该表的HWM会被重新置为0。
HWM数据库的操作有如下影响:
a) 全表扫描通常要读出直到HWM标记的所有的属于该表数据库块,即使该表中没有任何数据。
b) 即使HWM以下有空闲的数据库块,键入在插入数据时使用了append关键字,则在插入时使用HWM以上的数据块,此时HWM会自动增大
如何查一个表的水线呢?
ANALYZE TABLE T_TEMP_USER_TABLE COMPUTE STATISTICS;
SELECT BLOCKS, EMPTY_BLOCKS, NUM_ROWS
FROM USER_TABLES
WHERE TABLE_NAME = 'T_TEMP_USER';
BLOCKS 列代表该表中曾经使用过得数据库块的数目,即水线。
EMPTY_BLOCKS 代表分配给该表,但是在水线以上的数据库块,即从来没有使用的数据块。
通过上面的理论知识,其实问题已经可以定位到了:
因为索引不存在,所以造成了全表扫描,而每天大量日志归档使用的delete造成HWM并没有降低,而且越来越高。导致全表扫描的时间越来越长,造成查询越来越慢。所以根本原因是索引没有建立,而高水位放大了索引的影响。
补充一点:delete操作不会降低HWM,truncate会重置HWM。
问题分析出来了,那如何解决呢?
1.归档使用truncate删除数据
2.针对查询条件增加索引
3.对于已经处于高水位的表,可以通过shrink收缩表,脚本如下
--允许表行能被移动
ALTER TABLE T_TEMP_USER ENABLE ROW MOVEMENT;
--收缩表
ALTER TABLE T_TEMP_USER SHRINK SPACE CASCADE;
通过shrink去收缩表存在以下风险:
1.shrink会对数据进行物理移动,消耗资源大
2.操作时由于rowid会发生变化,所以会锁表
3.如果碎片的产生不可避免,那需要定期去进行shrink收缩表