有一个Oracle8i的数据库，使用了近一年（每天24小时不停机），数据记录总共有300多万条。以前一直运行正常，最近（11月25日）突然速度大幅下降。检查发现是Tools表空间满了（已使用了99.99%的空间），随后给Tools表空间增加了2G空间，问题解决。
但使用了20天左右，12月18日，Tools表空间又满了（同上次情况一样），只得又增加2G空间。
为什么以前(11月25日之前）Tools表空间的增长速度一直比较缓慢，但最近却在疯长？难道和数据记录数量有关系吗？有什么好的解决方法？请各位高手指点。
但使用了20天左右，12月18日，Tools表空间又满了（同上次情况一样），只得又增加2G空间。
为什么以前(11月25日之前）Tools表空间的增长速度一直比较缓慢，但最近却在疯长？难道和数据记录数量有关系吗？有什么好的解决方法？请各位高手指点。
难道你的业务数据都放在这个表空间? 建议你检查一下日志文件,看看有没有什么异常的操作.
Tools表空间存放的不是业务数据，只是索引而已。我将所有业务表的索引Rebuild到另外一个新建的表空间，发现索引占用的空间有近3G，比业务数据大了10几倍！！！这是为什么？有什么方法可以在不减少索引的前提下，减少索引占用的表空间大小？
首先要看你建的索引是什么类型的？b_tree？b_map？还是？
你的数据存放？
什么性质的系统？oltp？dss?
会造成很严重的后果的！个人意见！
Tools表空间存放的不是业务数据，只是索引而已。我将所有业务表的索引Rebuild到另外一个新建的表空间，发现索引占用的空间有近3G，比业务数据大了10几倍
-------------------------------------------------------------- 索引如果建的不合理(返回的数据大于全表数据的30%)，
索引表空间初始化参数不合理(Initial,Next,storage等等)
索引表空间有碎片 都有可能导致表空间的膨胀。 可能需要重建索引,用下面的方法判断是否需要重建索引: Run the ANALYZE INDEX command on the index to validate its structure and
then calculate the ratio of LF_BLK_LEN/LF_BLK_LEN+BR_BLK_LEN. if it isn’t near 1.0 (i.e. greater than 0.7 or so) then the index should be
rebuilt.
Or if the ratio BR_BLK_LEN/ LF_BLK_LEN+BR_BLK_LEN is nearing 0.3