Dies ist eine alte Version des Dokuments!
Inhaltsverzeichnis
LOB und Oracle Secure Files
Ab der Version 11g kann ein Lob in der Datenbank auch als „Secure File“ abgelegt werden. Das Standard Lob Handling wurde erweitert, ein Eintrag in ein Lob kann ähnlich einer Datei behandelt werden.
D.h. es können erweiterte Sicherheitseinstellungen getätigt und ein Komprimierung auf das gesamte Lob kann verwendet werden. Doppelte Daten können bei Bedarf auch nur einmal gespeichert werden.
Globale DB Einstellungen prüfen
Mit dem DB Parameter db_securefile, wird eingestellt, ob ein Lob per default klassisch oder als Secure File angelegt werden soll.
SHOW parameter db_securefile NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_securefile string PERMITTED
- NEVER - niemals verwenden - Schlüsselwort erzeugt Exception
- ALWAYS - immer verwenden
- PERMITTED - bei Bedarf kann mit dem Schlüsselwort SECUREFILE als Secure File gespeichert werden, ansonsten Standard Lob
- IGNORE - SECUREFILE Schlüsselwort ignorieren
siehe ⇒ http://docs.oracle.com/cd/E11882_01/server.112/e24448/initparams068.htm
LOB Speicher Parameter
Beispiel der Storage Klausel beim Anlegen eines Secure Files:
LOB (TEXT_FELD) STORE AS SECUREFILE (CHUNK 4096 CACHE DISABLE STORAGE IN ROW COMPRESS HIGH TABLESPACE GPI_DATA_FILES KEEP_DUPLICATES )
Speicher Möglichkeiten
Inline Lob: (ENABLE STORAGE IN ROW)
- Speicher im Block bis 3964 Byte Datenvolumen beim Anlegen, ab 3965 Byte speichern des Locators im Block und speichern der Daten in einem LOB Segement.
- Für die LOB Daten werden UNDO Einträge beim Ändern erzeugt.
- Gefahr von Row Changing recht hoch
External Lob: (DISABLE STORAGE IN ROW)
- Lob Locator (20 Byte) wird Tabellen Block gespeichert und zeigt auf Lob Segment
- Mehr Aufwand für die Verwaltung des Lob Segments und des dazugehörigen Indexes
- Undo wird nur für den Lob Locator erzeugt
- DML Operationen können auffällig viel Redo Erzeugen da die eingestellte Chunk Größe und nicht das aktuelle Datenvolumen geschrieben wird ( z.B. Storage Parameter DISABLE STORAGE IN ROW CHUNK 64k ⇒ auch für einen 5K Datensatz werden 64K geschrieben!)
- Für Konsistent Read auf ältere Versionen des Lobs kann über RETENTION auf Zeitbasis oder über PCVERSION auf % Platzbedarf im Lob Segment zugegriffen werden (Falls nichts definiert wird RETENTION auf den DB Default von UNDO_ RETENTION gesetzt)
Chunk size
Default = Blockgröße ? In meine Testumgebung hat es gepasst.
Idealle Chunk Size über die Bestandsdaten ermitteln:
SELECT MIN(dbms_lob.getlength(my_text))"min" ,MAX(dbms_lob.getlength(my_text))"max" ,avg(dbms_lob.getlength(my_text))"avg" FROM GPI.MY_SEC_LOB_TEST_TAB /
Logging / Cache Einstellung
Inline Lob (ENABLE STORAGE IN ROW) Cache Parameter wird nicht angewandt
CACHE
- ⇒ Lobs werden in den Block Buffer Cache geladen ⇒ Wait Event „db file sequential read“
- ⇒ Bessere Read/Write Performace ABER große Dateien können den Buffer Cache „fluten“
- ⇒ Daten werden IMMER über die Redo Logs „geschoben“
NOCACHE
- ⇒ Lobs werden immer aus dem DB File gelesen
- ⇒ Wait Event „direct read path read (lob) / direct read path write (lob)“
LOGGING
- ⇒ Daten werden über die Redos „geschoben“
NOLOGGING
- ⇒ Weniger Redo, Gefahr eines defekten Lobsegmentes bei einem Restore
Deduplizierung
KEEP_DUPLICATES
- ⇒ Doppelte Lob behalten
DEDUPLICATE
- ⇒ Doppelte Daten werden nur verpointert und damit das Datenvolumen reduziert
Überwachung mit
Welche Lob Typen gibt es unter dem User?
SELECT l.table_name , l.column_name , l.tablespace_name , l.segment_name , substr(s.PARTITION_NAME,1,6)||'..' AS PARTITION_NAME , round(decode(nvl(s.bytes,0),0,0,(s.bytes/1024/1024)),2) AS mb , l.in_row , l.securefile FROM dba_lobs l , dba_segments s WHERE l.segment_name = s.segment_name(+) AND UPPER(l.owner)=UPPER('&&OWNER.') ORDER BY l.table_name /
Vollständiges Script siehe hier
- ⇒ lob.sql
Quellen
Oracle:
Andere: