Ein Szenario, in dem Sie ein LOB in user_objects sehen können aber der Join zu user_lobs findet nichts, wenn die Tabelle bereits gelöscht wurde, aber befindet sich im Papierkorb
.
create table t42 (my_clob clob);
table T42 created.
Wie erwartet zeigt Ihnen Justins Abfrage die Spalte:
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.
Jetzt findet Justins Abfrage nichts:
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
Aber es ist immer noch in 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
Und Sie können es im Papierkorb sehen:
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
Das LOB ist immer noch auf der Festplatte vorhanden und verwendet Speicher, was meiner Meinung nach das ist, worüber Sie sich Sorgen machen. Um Ihre Frage zu beantworten, müssen Sie die gesamte Tabelle löschen, um das LOB wirklich zu löschen und seinen Speicher freizugeben:
purge table t42;
table purged.
select object_name, object_type, status from user_objects
where object_type like 'LOB%';
no rows selected
Interessanterweise sehen Sie diesen Effekt nicht, wenn Sie das LOB-Segment benennen:
create table t42 (my_clob clob)
lob (my_clob) store as my_clob_segment;
Wenn Sie die obigen Schritte wiederholen, ist der Eintrag von user_objects verschwunden nach dem 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
Der Speicher wird natürlich immer noch verwendet und Sie müssen ihn noch löschen, um ihn freizugeben, er sieht im Datenwörterbuch nur etwas konsistenter aus. Das sieht also höchstens nach einem (sehr kleinen) Fehler aus. Es könnte mit dem Verhalten zusammenhängen, auf das im Support-Hinweis 394442.1.
Bezug genommen wird
