Един сценарий, при който можете да видите LOB в user_objects
но присъединяването към user_lobs
не намира нищо, ако таблицата вече е премахната, но е в кошчето
.
create table t42 (my_clob clob);
table T42 created.
Както се очаква, заявката на Джъстин ви показва колоната:
select l.table_name,
l.column_name,
l.segment_name lob_name
from user_lobs l
join user_objects o
on( o.object_name = l.segment_name );
TABLE_NAME COLUMN_NAME LOB_NAME
----------- ----------- ------------------------------
T42 MY_CLOB SYS_LOB0000133310C00001$$
drop table t42;
table T42 dropped.
Сега заявката на Джъстин не намира нищо:
select l.table_name,
l.column_name,
l.segment_name lob_name
from user_lobs l
join user_objects o
on( o.object_name = l.segment_name );
no rows selected
Но все още е в user_objects
:
select object_name, object_type, status from user_objects
where object_type like 'LOB%';
OBJECT_NAME OBJECT_TYPE STATUS
------------------------------ ------------------- -------
SYS_LOB0000133328C00001$$ LOB VALID
И можете да го видите в кошчето:
select * from user_recyclebin;
OBJECT_NAME ORIGINAL_NAME OPERATION TYPE TS_NAME CREATETIME DROPTIME DROPSCN PARTITION_NAME CAN_UNDROP CAN_PURGE RELATED BASE_OBJECT PURGE_OBJECT SPACE
------------------------------ -------------------------------- --------- ------------------------- ------------------------------ ------------------- ------------------- ---------- -------------------------------- ---------- --------- ---------- ----------- ------------ ----------
SYS_IL0000133310C00001$$ SYS_IL0000133310C00001$$ DROP LOB INDEX USERS 2013-08-22:08:33:21 2013-08-22:08:33:21 1.0E+13 NO NO 133310 133310 133310 0
SYS_LOB0000133310C00001$$ SYS_LOB0000133310C00001$$ DROP LOB USERS 2013-08-22:08:33:21 2013-08-22:08:33:21 1.0E+13 NO NO 133310 133310 133310 0
BIN$5IUNXtWkUXLgQwEAAH9TlQ==$0 T42 DROP TABLE USERS 2013-08-22:08:33:21 2013-08-22:08:33:21 1.0E+13 YES YES 133310 133310 133310 0
LOB все още съществува на диска и използва място за съхранение, което, предполагам, е това, за което се притеснявате. Така че, за да отговорите на въпроса си, за да премахнете наистина LOB и да освободите хранилището му, трябва да изчистите цялата таблица:
purge table t42;
table purged.
select object_name, object_type, status from user_objects
where object_type like 'LOB%';
no rows selected
Интересното е, че не виждате този ефект, ако наименувате LOB сегмента:
create table t42 (my_clob clob)
lob (my_clob) store as my_clob_segment;
Повтаряйки стъпките по-горе, записът е преминал от user_objects
след drop
.
drop table t42;
table T42 dropped.
select object_name, object_type, status from user_objects
where object_type like 'LOB%';
no rows selected
select * from user_recyclebin;
OBJECT_NAME ORIGINAL_NAME OPERATION TYPE TS_NAME CREATETIME DROPTIME DROPSCN PARTITION_NAME CAN_UNDROP CAN_PURGE RELATED BASE_OBJECT PURGE_OBJECT SPACE
------------------------------ -------------------------------- --------- ------------------------- ------------------------------ ------------------- ------------------- ---------- -------------------------------- ---------- --------- ---------- ----------- ------------ ----------
BIN$5IUNXtWnUXLgQwEAAH9TlQ==$0 MY_CLOB_SEGMENT DROP LOB USERS 2013-08-22:08:36:41 2013-08-22:08:36:41 1.0E+13 NO NO 133316 133316 133316 0
BIN$5IUNXtWoUXLgQwEAAH9TlQ==$0 T42 DROP TABLE USERS 2013-08-22:08:36:41 2013-08-22:08:36:41 1.0E+13 YES YES 133316 133316 133316 0
SYS_IL0000133316C00001$$ SYS_IL0000133316C00001$$ DROP LOB INDEX USERS 2013-08-22:08:36:41 2013-08-22:08:36:41 1.0E+13 NO NO 133316 133316 133316 0
Разбира се, хранилището все още се използва и все още трябва да го изчистите, за да го освободите, просто изглежда малко по-последователно в речника на данните. Така че това изглежда най-много като (много малка) грешка. Може да е свързано с поведението, посочено в бележка за поддръжка 394442.1.