Un escenario donde puede ver un LOB en user_objects pero la unión a user_lobs no encuentra nada si la tabla ya se ha eliminado, pero está en la papelera de reciclaje
.
create table t42 (my_clob clob);
table T42 created.
Como era de esperar, la consulta de Justin muestra la columna:
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.
Ahora la consulta de Justin no encuentra nada:
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
Pero todavía está en 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
Y puedes verlo en la papelera de reciclaje:
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
El LOB todavía existe en el disco y está usando almacenamiento, lo que supongo que es lo que le preocupa. Entonces, para responder a su pregunta, para eliminar realmente el LOB y liberar su almacenamiento, debe purgar toda la tabla:
purge table t42;
table purged.
select object_name, object_type, status from user_objects
where object_type like 'LOB%';
no rows selected
Curiosamente, no ve este efecto si nombra el segmento LOB:
create table t42 (my_clob clob)
lob (my_clob) store as my_clob_segment;
Repitiendo los pasos anteriores, la entrada ha pasado de user_objects después del 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
El almacenamiento todavía se está utilizando, por supuesto, y aún necesita purgarlo para liberarlo, solo se ve un poco más consistente en el diccionario de datos. Entonces, esto parece un error (muy menor), tal vez, como mucho. Puede estar relacionado con el comportamiento mencionado en la nota de soporte 394442.1.
