Ein Szenario, in dem Sie ein LOB in user_objects sehen können, aber der Join zu user_lobs nichts findet, wenn die Tabelle bereits gelöscht wurde, aber befindet sich im Papierkorb .
Wie erwartet, zeigt Justins Abfrage die Spalte:
%Vor%Nun findet Justins Abfrage nichts:
%Vor% Aber es ist immer noch in user_objects :
Und Sie können es im Papierkorb sehen:
%Vor%Das LOB ist immer noch auf der Festplatte vorhanden und verwendet Speicher, was Ihrer Meinung nach das Problem ist. Um Ihre Frage zu beantworten, müssen Sie die gesamte Tabelle löschen, um den LOB wirklich fallen zu lassen und seinen Speicher freizugeben:
%Vor%Interessanterweise sehen Sie diesen Effekt nicht, wenn Sie das LOB-Segment benennen:
%Vor% Wenn Sie die obigen Schritte wiederholt haben, ist der Eintrag von user_objects nach drop verschwunden.
Der Speicher wird immer noch verwendet und Sie müssen ihn immer noch löschen, um ihn freizugeben, er sieht im Datenwörterbuch etwas konsistenter aus. Das sieht also höchstens wie ein (sehr kleiner) Fehler aus. Es könnte sich auf das Verhalten beziehen, auf das in Support-Notiz 394442.1 verwiesen wird.
Das LOB-Objekt wird gelöscht, wenn Sie die Tabelle mit der verknüpften LOB-Spalte löschen oder die LOB-Spalte aus dieser Tabelle löschen. Sie können sehen, welche Spalte ein bestimmtes LOB-Objekt unterstützt, indem Sie abhängig von Ihren Berechtigungen DBA_LOBS , ALL_LOBS oder USER_LOBS abfragen.
Zum Beispiel
%Vor% zeigt Ihnen, welche Tabelle und welche Spalte jedes der LOB -Objekte in Ihrem Schema unterstützt.