SecureFiles - Ein kleiner Exkurs in die Niederungen der Oracle Datenbank

Vor kurzem wurde ich von einem Kunden gefragt, welche Empfehlungen es in Bezug auf die DB Block Size für das Speichern von Rasterdaten als Large Objects (LOBs) gibt.
Für die Beantwortung dieser Frage ist das Wissen um Kernfunktionalität der Oracle Datenbank unabdingbar. Daher möchte ich einige Überlegungen an dieser Stelle mit anderen Interessierten teilen.
Seit Freigabe der Version 11.1 gibt es einen neuen Datentyp für die Speicherung von grossen Objekten in der Datenbank, SecureFiles genannt.
Einen sehr guten Einstieg in die Nutzung von SecureFiles gibt dieser Tipp in der deutschsprachigen Oracle DBA Community.
Darüberhinaus möchte ich auch noch auf diesen Artikel im Database Journal verweisen. Hat man sich durch die ersten beiden Kapitel gearbeitet, finden sich einige Hinweise auf u.a. relevante DB Parameter oder Tabellen-Eigenschaften.
Wichtig ist zunächst einmal zu wissen, dass bis Version 11 für LOBs nicht so sehr die DB Block Size wichtig ist - hier braucht man eigentlich nur darauf zu achten, dass diese möchst nicht grösser als das LOB selbst ist - , sondern die Grösse der sogenannten CHUNKs (zu deutsch: Brocken, Klumpen, großes Stück).
Seit 11.1 und SecureFiles hat die DB Block Size nur minimalen Einfluss auf die Performanz und auch die CHUNK Grösse muss nicht explizit angegeben werden. Die DB übernimmt es, nach bestem "Wissen und Gewissen" die optimale CHUNK Grösse zu bestimmen. Die variiert zwischen der DB Block Size (Minimum) und 64 MB (Maximum). Unsere DB EntwicklerInnen nennen das "Super Chunk".
Möchte man trotzdem Einfluss nehmen, so bleibt die Möglichkeit, das Minimum durch Setzen einer entsprechenden DB Block Size pro Tablespace zu regulieren.
Das ist auch schon das Stichwort für einen anderen Hinweis: In jedem Falle empfehle ich, einen eigenen Tablespace für LOBs vorzusehen, ggf. mehrere für unterschiedliche Arten von LOBs oder verschiedene Datenstände dieser.
Dann gibt es beim Anlegen von Tablespaces den wichtigen Begriff der Extents, bei denen es sich um physisch zusammenhängende Speicherbereiche handelt, in welche die Datenbankobjekte gespeichert werden. Je näher die Daten in zusammenhängenden Plattenbereichen liegen, umso geringer sind natürlich die Zugriffszeiten beim Lesen.
Eine Empfehlung an dieser Stelle ist also, die Grösse der Extents so zu anzugeben, dass möglichst wenige solcher während eines Ladevorgangs neu angelegt werden müssen.
Wem es generell auf Geschwindigkeit beim Ladevorgang ankommt, sollte sich überlegen, die Daten mit NOLOGGING zu laden, um das Mitschreiben von ReDo-Informationen zu reduzieren.
Nach dem Laden kann man wieder auf LOGGING setzen und am Besten gleich noch ein Online-Backup ziehen.

ALTER TABLE my_lob_tab NOLOGGING;

ALTER TABLE my_lob_tab MODIFY (lob_col CLOB)
  LOB(lob_col) STORE AS SECUREFILE (
    NOCACHE NOLOGGING       -- NOCACHE muss zusammen mit NOLOGGING gesetzt werden
  );

... 

ALTER TABLE my_lob_tab MODIFY LOB (lob_col) (CACHE);
ALTER TABLE my_lob_tab LOGGING;

Weitere Hinweise dazu finden sich in der Online-Dokumentation SecureFiles and Large Objects Developer´s Guide.
Was ist noch wichtig?
Datenbank-Objekte werden als sogenannte Segmente gespeichert. Es gibt einige unterschiedliche davon, z.B. Tabellen-, Index- oder auch LOB-Segmente.
Letztere werden standardmässig erzeugt, wenn die Grösse des LOBs > 4000 Bytes ist. Das nennt man dann Outline-Speicherung. Das Gegenteil davon Inline speichert die ganze Tabellenzeile inklusive LOB in einem Tabellen-Segment und ist das Standardverhalten bei LOBs < 4000 Bytes.
Will man ausschliesslich Outline speichern, z.B. um LOBs und die sonstigen (relationalen) Daten in verschiedene Segmente (möglicherweise wegen unterschiedlicher Tablespaces) aufzuteilen, so kann man in der Storage-Klausel der Tabellendefinition DISABLE STORAGE IN ROW spezifizieren.
Aber Achtung: Das muss man am zum Zeitpunkt des Anlegens der Tabelle bereits tun, da es sich nachträlglich nicht ändern lässt.

Und was hat das alles jetzt eigentlich mit SDO_GEOMETRY, SDO_GEORASTER zu tun, den Oracle Objekttypen für Vektor- und Rasterdaten zu tun? Beide und dazu auch SDO_PC (für Point Clouds) können SecureFiles verwenden. Bei einer Rasterdatentabelle sieht das dann z.B. so aus:

CREATE TABLE city_images_rdt OF SDO_RASTER (
  PRIMARY KEY (
    rasterID, 
    pyramidLevel, 
    bandBlockNumber,
    rowBlockNumber, 
    columnBlockNumber))
  TABLESPACE raster_im_tbs
  LOB(rasterBlock) STORE AS SECUREFILE lobseg(
    NOCACHE NOLOGGING)
/ 

Bei Vektordaten werden sowohl Stützpunkte (SDO_ORDINATE_ARRAY) als auch SDO_ELEM_INFO in VARRAYs gespeichert. Und auch diese können mit der Storage-Klausel STORE AS SECUREFILE angegeben werden. Die Syntax sieht beispielhaft so aus:

CREATE TABLE my_geom_tab (
  feature_name VARCHAR2(4000),
  geometry     SDO_GEOMETRY
)
VARRAY geometry.SDO_ORDINATES STORE AS SECUREFILE lob geom_ord
VARRAY geometry.SDO_ELEM_INFO STORE AS SECUREFILE lob geom_elem
/

Bevor dieser Blog-Eintrag jetzt zu lang wird und niemand mehr Lust hat, ihn bis zum Ende zu lesen, hebe ich mir das Thema Komprimieren von den als SecureFiles gespeicherten Stützpunkten für einen neuen Eintrag auf.