dba:oracle_secure_file

Inhaltsverzeichnis

LOB und Oracle Secure Files

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

⇒ lob.sql
⇒ lob_detail.sql

Quellen

Oracle:

Andere: