BLOB-Datenspeicherung in Geodatabases in Oracle

BLOB ist ein branchenübliches Akronym, das im Zusammenhang mit Datenbankmanagementsystemen (DBMS) für große Binärobjekte (Binary Large Object) verwendet wird. BLOB-Spalten wurden vor mehreren Jahre von Oracle implementiert, um die LONG RAW-Technologie zur Speicherung von Binärdaten zu ersetzen.

Die Architektur des BLOB-Datentyps ist in drei grundlegende Komponenten unterteilt: die BLOB-Spalte, das LOB-Segment und der LOB-Index. In der BLOB-Spalte werde der LOB-Locator (36 Byte) und Binärdaten in der Zeile gespeichert, wenn diese kleiner als 3.965 Byte sind und der Speicher innerhalb der Zeile nicht für die Spalte deaktiviert wurde.

Hinweis:

Tests von Esri haben gezeigt, dass die Speicherung in der Zeile die höchste Performance liefert. Es wird daher empfohlen, die Speicherung in der Zeile nicht zu deaktivieren.

Wenn die Binärdaten 3.964 Byte überschreiten, wird der Speicherplatz innerhalb der Zeile der BLOB-Spalte nicht zugeordnet, und der LOB-Locator verweist auf die im LOB-Segment gespeicherten Binärdaten.

Daher beläuft sich ein Wert, der in einer BLOB-Spalte mit aktiviertem Speicher innerhalb der Zeile gespeichert ist, immer mindestens 36 Byte (der dem LOB-Locator zugewiesene Speicherplatz) und kann bis zu 4.000 Byte groß sein (der Speicherplatz, der dem LOB-Locator zugewiesen wurde, zuzüglich dem maximalen Speicherplatz für in der Zeile gespeicherte Binärdaten).

Das LOB-Segment ist in Chunks unterteilt. Chunks müssen ein Vielfaches der Oracle-Datenblockgröße sein. Wenn die Datenblockgröße beispielsweise 8K beträgt, kann das LOB-Segment mit einer minimalen Chunk-Größe von 8K erstellt werden. Beträgt die Länge der Daten, die innerhalb des LOB-Segments gespeichert sind, 5.000 Byte, werden sie im LOB-Segment gespeichert, da sie 3.964 Byte überschreiten, und die Chunk-Größe 8K bzw. 8.192 Byte beträgt. In diesem Fall werden 3.192 Byte des LOB-Segment-Chunks nicht verwendet. Bei der Übertragung von Daten von LONG RAW in BLOB kann aufgrund des nicht belegten Speicherplatzes im LOB-Segment bis zu 30 Prozent mehr Speicherplatz benötigt werden. Dies ist unvermeidlich, wenn die Daten den Schwellenwert für die Speicherung in der Zeile der BLOB-Spalte von 3.964 Byte überschreiten.

Die Chunk-Größe von 8K liefert die beste E/A-Performance, wenn möglichst wenig Speicherplatz verloren geht. Bei einer Chunk-Größe von 16K geht mehr Speicherplatz verloren als bei einer Chunk-Größe von 8K. Daher wird zur Vermeidung von Speicherplatzverluste empfohlen, eine Datenbank mit einer aktuellen Datenblockgröße von 16K mit einer Datenblockgröße von 8K erneut zu erstellen, oder, falls möglich, LOB-Segmente in Tablespaces zu erstellen, die mit einer Blockgröße von 8K erzeugt wurden. Hierzu müssen Sie in Oracle System Global Area (SGA) einen Puffer-Cache mit 8K zuordnen.

Bei Chunk-Größen von 4K und 2K geht am wenigsten Speicherplatz verloren, hierdurch können die höheren E/A-Kosten jedoch nicht kompensiert werden.

Der LOB-Index wird nur verwendet, wenn die Anzahl der im LOB-Locator enthaltenen Chunks 12 überschreitet. Andernfalls werden die ersten 12 Chunks vom LOB-Locator abgedeckt.

Die folgenden drei Abbildungen veranschaulichen die drei möglichen Speicherfälle für Binärdaten in einer BLOB-Spalte. Im ersten Fall werden 3.000 Byte Binärdaten in der Zeile gespeichert, da die Größe mit 3.000 Byte kleiner ist als der Schwellenwert für die Speicherung innerhalb der Zeile von 3.965 Byte. Wenn die Speicherung innerhalb der Zeile für die BLOB-Spalte nicht deaktiviert ist, werden das LOB-Segment und der LOB-Index nicht verwendet. In der Regel führt dies durch die geringere Anzahl von E/A-Vorgängen zu einem schnelleren Abruf der BLOB-Daten, da Oracle nicht auf das LOB-Segment oder den LOB-Index zugreifen muss.

BLOB-Daten mit weniger als 3.965 Byte, die innerhalb der Zeile gespeichert werden

Die nächste Abbildung veranschaulicht den zweiten Fall, in dem die Binärdaten größer als 3.964 Byte sind (in diesem Fall sind die Daten 81.920 Byte groß) und nicht in der Zeile gespeichert werden können. Daher verweist der LOB-Locator auf die Binärdaten, die im LOB-Segment gespeichert sind. Da die Binärdaten weniger als 12 Chunks im LOB-Segment beanspruchen, werden im dem LOB-Locator die zugehörigen Adressen gespeichert. In diesem Fall wird der LOB-Index nicht verwendet.

BLOB-Daten mit mehr als 3.964 Byte, die außerhalb der Zeile gespeichert werden Ein LOB-Locator in der Tabelle verweist auf das LOB-Segment, in dem die Daten gespeichert sind.

In der letzten Abbildung sind die Binärdaten so groß (106.496 Byte), dass der LOB-Index benötigt wird. In diesem Fall überschreiten die Binärdaten nicht nur den Speicher innerhalb der Zeile, sie erfordern auch mehr als 12 Chunks im LOB-Segment. Bei Daten dieser Größe verweist der LOB-Locator auf den LOB-Index, um die Position der Chunks innerhalb des SOB-Segments abzurufen. Dieser Fall tritt sehr selten bei Vektordaten ein und kann für Raster-Daten vermieden werden.

BLOB-Daten, die außerhalb der Zeile gespeichert werden und einen LOB-Index erfordern

Festlegen der DBTUNE-Parameter für die Speicherung von BLOB-Spalten

Die Speicherparameter der DBTUNE-Tabelle steuern, wie ArcGIS Tabellen und Indizes in Oracle erstellt. Zudem bestimmen einige Speicherparameter, welcher Datentyp beim Erstellen einer Tabelle verwendet wird. Weitere Informationen zur DBTUNE-Tabelle finden Sie unter Was ist die Tabelle DBTUNE? Allgemeine Informationen zu DBTUNE-Speicherparametern finden Sie unter Was sind DBTUNE-Konfigurationsschlüsselwörter und -Parameter?

Die DBTUNE-Speicherparameter GEOMETRY_STORAGE, RASTER_STORAGE und ATTRIBUTE_BINARY bestimmen, welcher Oracle-Datentyp zur Datenspeicherung verwendet wird.

Der Parameter GEOMETRY_STORAGE steuert, wie Vektordaten in einer Feature-Class gespeichert werden. Der Parameter RASTER_STORAGE steuert, wie Raster-Daten in einem Raster-Dataset, einem Raster-Katalog oder einem Raster-Attribut gespeichert werden. Der letzte Parameter ATTRIBUTE_BINARY steuert die Speicherung aller anderen Binärdaten, bei denen es sich weder um Vektordaten noch um Raster-Daten handelt.

Um BLOB-Spalten zu erstellen, müssen die Parameter innerhalb eines DBTUNE-Schlüsselworts wie folgt festgelegt werden:

GEOMETRY_STORAGE SDELOB
RASTER_STORAGE BLOB
ATTRIBUTE_BINARY BLOB

Esri empfiehlt die folgenden LOB-Speicherparameter für Vektor- und Raster-Daten:

• Aktivieren Sie stets die Speicherung innerhalb der Zeile, da die meisten GIS-Daten (geographisches Informationssystem) in den Schwellenwert von 3.964 Byte für die Speicherung innerhalb der Zeile fallen. Die Performance ist am besten, wenn Daten in der Zeile gespeichert werden.
• Aktivieren Sie den Cache, da Geodatabase-Daten häufig gelesen werden.
• Da ArcGIS keine Aktualisierung der BLOB-Daten vornimmt, sondern stattdessen nur Daten einfügt und löscht, legen Sie PCT_VERSION auf 0 fest. Es ist nicht notwendig, ältere Versionen der Daten innerhalb des LOB-Segments zu speichern.
• Sie sollten keine Chunk-Größe unter 8K verwenden. Chunk-Größen von 2K oder 4K erhöhen die Anzahl der E/A, da der Oracle-Serverprozess mehr Chunks abrufen muss. Bei einer Chunk-Größe von 8K geht vermutlich weniger Speicherplatz verloren als bei 16K. Bei Verwendung einer Chunk-Größe von 2K oder 4K werden Sie vermutlich feststellen, dass hierdurch zwar weniger Speicherplatz verloren geht, dass die Anzeigezeit für die meisten Raster-Daten und Vektordaten im Vergleich zu einer Chunk-Größe von 8K jedoch drastisch ansteigt. Da die Chunk-Größe immer ein Vielfaches der Datenblockgröße sein muss, beträgt die optimale Datenblockgröße zum Speichern von GIS-Daten in BLOBs 8K.

In den folgenden Beispielen wird gezeigt, wie die DBTUNE-Speicherparameter für Raster-Daten geändert wurden, um eine als BLOB-Datentyp gespeicherte Raster-Blocktabelle aufzunehmen:

RASTER_STORAGE "BLOB"
BLK_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE RASTER 
             LOB (BLOCK_DATA) STORE AS 
             (TABLESPACE RASTER_LOB_SEGMENT 
              CACHE PCTVERSION 0)" 

AUX_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE RASTER 
             LOB (OBJECT) STORE AS 
             (TABLESPACE RASTER 
              CACHE PCTVERSION 0)"

RASTER_STORAGE "ST_RASTER"
BLK_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE RASTER 
             LOB (BLOCK_DATA) STORE AS 
             (TABLESPACE RASTER_LOB_SEGMENT 
              CACHE PCTVERSION 0)"

Wenn die Pixeldaten des Raster-Blocks weniger als 3.965 Byte haben, werden sie innerhalb der Spalte BLOCK_DATA im Tablespace RASTER gespeichert. Wenn sie diesen Schwellenwert jedoch überschreitet, werden die im LOB-Segment im Tablespace RASTER_LOB_SEGMENT gespeichert. Der LOB-Index wird nur verwendet, wenn die Anzahl der Chunks 12 überschreitet, was bei Geodatabase-Daten sehr unwahrscheinlich ist. Angenommen Sie verwenden ein LOB-Segment mit einer Chunk-Größe von 8K. Damit der LOB-Index verwendet wird, müssen die ArcSDE-Binärdaten 96K überschreiten.

In den folgenden Beispielen wird gezeigt, wie die DBTUNE-Speicherparameter für Vektordaten geändert wurden, um eine als BLOB-Datentyp gespeicherte Feature-Tabelle aufzunehmen:

GEOMETRY_STORAGE "SDELOB"

F_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE VECTOR 
             LOB (POINTS) STORE AS 
             (TABLESPACE VECTOR_LOB_SEGMENT 
              CACHE PCTVERSION 0)"

GEOMETRY_STORAGE  "ST_GEOMETRY"

Wenn die Binärdaten des Features weniger als 3.965 Byte haben, werden sie innerhalb der Spalte POINTS im Tablespace VECTOR gespeichert. Wenn sie diesen Schwellenwert jedoch überschreitet, werden die im LOB-Segment im Tablespace VECTOR_LOB_SEGMENT gespeichert.

ATTRIBUTE_BINARY "BLOB"

B_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE BIZZTABS 
             LOB (DOCUMENT) STORE AS 
             (TABLESPACE BIZZ_LOB_SEGMENT 
              CACHE PCTVERSION 0)"

A_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE BIZZTABS 
             LOB (DOCUMENT) STORE AS 
             (TABLESPACE BIZZ_LOB_SEGMENT 
              CACHE PCTVERSION 0)"

Wenn in diesem Beispiel die Binärdaten der Business-Tabelle weniger als 3.965 Bytes betragen, werden sie innerhalb der BLOB-Spalte der Business-Tabelle im Tablespace BIZZTABS gespeichert. Wenn sie diesen Schwellenwert jedoch überschreitet, werden die im LOB-Segment im Tablespace BIZZ_LOB_SEGMENT gespeichert. Die BLOB-Spalte in diesem Beispiel ist DOCUMENT. Wenn der oben erwähnte DBTUNE-Parameter B_STORAGE verwendet wird, um eine Tabelle ohne die Spalte DOCUMENT zu erstellen, wird von Oracle der folgende Fehler zurückgegeben:

ORA-00904: "DOCUMENT": invalid identifier

Es wird daher davon abgeraten, den Parameter B_STORAGE oder A_STORAGE zum Schlüsselwort DEFAULTS hinzuzufügen, wenn dieser auf eine spezifische BLOB-Spalte verweist, da die Business-Tabelle diese Spalte enthalten muss. Erstellen Sie stattdessen separate DBTUNE-Schlüsselwörter, und fügen Sie den Schlüsselwörtern diese Speicherparameter hinzu. Das Schlüsselwort, das den Speicherparameter enthält, wird während der Erstellung der Tabelle referenziert. Beachten Sie außerdem, dass die Speicherparameter des Schlüsselworts DEFAULTS verwendet werden, wenn sie nicht in einem bestimmten Schlüsselwort enthalten sind. Es ist daher nicht notwendig, einen bestimmten Speicherparameter innerhalb eines Schlüsselworts hinzuzufügen, wenn dessen Konfigurationszeichenfolge mit dem Speicherparameter im Schlüsselwort DEFAULTS identisch ist. Wenn zum Beispiel alle Speicherparameter mit Ausnahme von B_STORAGE und A_STORAGE eines neuen Schlüsselworts ROADS die gleiche Konfigurationszeichenfolge wie das Schlüsselwort DEFAULTS enthalten, müssen Sie nur die Parameter B_STORAGE und A_STORAGE unter dem Schlüsselwort ROADS erstellen. Alle anderen Speicherparameter werden aus dem Schlüsselwort DEFAULTS gelesen, da sie im Schlüsselwort ROADS nicht gefunden werden.