遇到这个问题第一反应就是表空间是否不足了?
执行下面的语句进行检查
SELECT A.FILE_ID "FileNo",
A.FILE_NAME,
A.TABLESPACE_NAME "Tablespace_name",
ROUND(A.BYTES / 1024 / 1024 / 1024, 4) "Total MB",
ROUND((A.BYTES - SUM(NVL(B.BYTES, 0))) / 1024 / 1024 / 1024, 4) || 'G' "Used G",
ROUND(SUM(NVL(B.BYTES, 0)) / 1024 / 1024 / 1024, 4) || 'G' "Free G",
ROUND(SUM(NVL(B.BYTES, 0)) / A.BYTES * 100, 4) || '%' "%Free"
FROM DBA_DATA_FILES A, DBA_FREE_SPACE B
WHERE A.FILE_ID = B.FILE_ID(+)
AND A.TABLESPACE_NAME = /*name of tableplace*/
GROUP BY A.TABLESPACE_NAME, A.FILE_ID, A.FILE_NAME, A.BYTES
ORDER BY A.TABLESPACE_NAME
果然如此,这样就看到了表空间的使用情况,于是开始下一步查询,为了节约时间,先找找那些没用的且耗去很大存储空间的表,笔者自己通常用的两个办法
第一种,执行下面的语句进行查看,前提条件是得搞清楚自己要处理的表的属主以及表空间 --这个大家应该都比较清楚吧
SELECT *
FROM DBA_SEGMENTS S
WHERE S.OWNER = /*the owner of table or index or other*/
好吧,如果有充分的证据,继续增加条件
SELECT *
FROM DBA_SEGMENTS S
WHERE S.OWNER = /*the owner of table or index or other*/
AND S.SEGMENT_NAME = /*the object which you doubt*/
ORDER BY S.BYTES DESC
好了,执行完了看看结果吧
把那种大家伙干掉,如果数据确实不是很重要的话,直接Truncate比较好
第二种,辅助工具,TOAD是个好同志,看看下面的截图就明白了
剩下的操作,各位根据情况自行解决吧
一个小小的问题,经常会遇到,习惯了就好