===== 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.


<code sql>
show parameter db_securefile

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_securefile                        string      PERMITTED 

</code>

  * 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 .-) ):

<code sql>
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
		                    ) 
</code>



===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:
<code sql>
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
/
</code>



**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?
<code sql>

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
/
</code>

Vollständiges Script siehe hier
  *  => [[http://orapowershell.codeplex.com/SourceControl/latest#sql/lob.sql|lob.sql]] 
  *  => [[http://orapowershell.codeplex.com/SourceControl/latest#sql/lob_detail.sql|lob_detail.sql]]


====Quellen====
 

Oracle:
  * http://docs.oracle.com/cd/E11882_01/appdev.112/e18294/adlob_tables.htm#ADLOB45310
  * http://www.oracle.com/technetwork/articles/sql/11g-securefiles-084075.html
  * http://www.oracle.com/technetwork/database/options/compression/overview/securefiles-131281.pdf

Andere:

  * http://www.trivadis.com/uploads/tx_cabagdownloadarea/LOB_Komprimierung_mit_Oracle_11g.pdf
  * http://www.juliandyke.com/Presentations/Presentations.html