Benutzer-Werkzeuge

Webseiten-Werkzeuge


dba:oracle_secure_file_lob

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.

Update ( 07.10.2017):

According to Oracle Database documentation and Oracle Database Licensing information you need license only for:

  • Compression - Advanced Compression option
  • Deduplication - Advanced Compression option
  • Encryption - Advanced Security option

see http://ivan.kartik.sk/index.php?controller=post&action=view&id_post=54


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
  • PREFERRED - All LOBs are created as SecureFiles unless BASICFILE is explicitly specified in the LOB storage clause

siehe ⇒ https://docs.oracle.com/database/121/REFRN/GUID-6F7C5E21-3929-4AB1-9C72-1BB9BDDB011F.htm#REFRN10290

LOB Speicher Parameter

Beispiel der Storage Klausel beim Anlegen eines Secure Files (falls Advanced Compression option vorliegt .-) ):

CREATE TABLE documents ( id         NUMBER(11)
                       , TEXT_FELD  BLOB
                       )                       
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 ( auch falls kleiner angegeben) - bzw. dann auf mehrfaches der Blockgröße setzen.

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

Quellen

Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
"Autor: Gunther Pipperr"
dba/oracle_secure_file_lob.txt · Zuletzt geändert: 2017/10/07 11:39 von gpipperr