Almacenamiento de datos BLOB en geodatabases de Oracle

BLOB es un acrónimo industrial del sistema de administración de bases de datos (DBMS) para objeto binario grande. Las columnas BLOB se implementaron hace varios años por parte de Oracle Corporation para reemplazar la tecnología LONG RAW para el almacenamiento de datos binarios.

La arquitectura del tipo de datos BLOB se divide en tres componentes básicos: la columna BLOB, el segmento LOB y el índice LOB. La columna BLOB almacena el localizador LOB (36 bytes) y los datos binarios en fila si son inferiores a 3.965 bytes y el almacenamiento en filas no se ha deshabilitado para la columna.

Nota:

Las pruebas realizadas por Esri demuestran que permitir un almacenamiento en filas ofrece un mejor rendimiento, por lo que se le recomienda que no deshabilite el almacenamiento en filas.

Si los datos binarios superan los 3.964 bytes, no se asigna el espacio de almacenamiento en filas de la columna BLOB y el localizador LOB se basa en los datos binarios almacenados en el segmento LOB.

Por lo tanto, el valor almacenado en una columna BLOB con el almacenamiento en filas habilitado es siempre de 36 bytes como mínimo (el espacio asignado al localizador LOB) y deberá tener el tamaño de 4.000 bytes (el espacio combinado asignado al localizador LOB y el espacio máximo que puede asignarse a los datos binarios almacenados en filas).

El segmento LOB se divide en dos tramos. Los tramos deben ser un múltiple del tamaño de bloque de datos de Oracle. Por ejemplo, si el tamaño de bloque de datos es de 8K, el segmento LOB puede crearse con un tamaño mínimo de trama de 8K. Si la longitud de los datos almacenados en el segmento LOB es de 5.000 bytes, se almacenan en el segmento LOB puesto que supera los 3.964 bytes y el tamaño de la trama es de 8K ó 8.192 bytes. En este caso, 3.192 bytes de la trama del segmento LOB permanece sin utilizar. La transferencia de datos de LONG RAW a BLOB puede provocar que se requiera más espacio—quizás hasta un incremento del 30 por ciento debido al espacio sin utilizar en el segmento LOB. Esto resulta inevitable si sus datos superan el umbral de almacenamiento en filas de 3.964 bytes de la columna BLOB.

El tamaño de trama de 8K experimenta el mejor rendimiento de E/S a la vez que ocupa el mínimo espacio. El tamaño de trama de 16K ocupa más espacio que el tamaño de trama de 8K. Por lo tanto, para evitar la pérdida de espacio, se recomienda que vuelva a crear la base de datos que actualmente tiene un tamaño de bloque de datos de 16K por un tamaño de bloque de datos de 8K o, si esto no es posible, que cree segmentos LOB en espacios de tabla que se han creado con un tamaño de bloque de 8K. Para hacerlo, deberá asignar una memoria caché en búfer de 8K en el Área Global del Sistema de Oracle (SGA).

Se ha demostrado que los tamaños de trama de 4K y 2K ocupan menos espacio, pero el aumento del coste de E/S no garantiza su uso.

El índice LOB sólo se utiliza si el número de tramas tratados por el localizador LOC supera 12; de lo contrario, las primeras 12 tramas son tratadas por el localizador LOB.

Las tres siguientes figuras ilustran los tres casos posibles de almacenamiento de datos binarios almacenados en una columna BLOB. En el primer caso, 3.000 bytes de datos binarios se almacenan en fila, ya que 3.000 bytes es inferior al umbral de almacenamiento en filas de 3.965 bytes. Si no está deshabilitado el almacenamiento en filas para la columna BLOB, no se utilizará el segmento LOB ni el índice LOB. Normalmente, esto origina una recuperación más rápida de los datos BLOB debido al reducido número de operaciones de E/S, puesto que Oracle no tiene que acceder al segmento LOB ni al índice LOB.

Datos BLOB más pequeños que 3.965 bytes de tamaño almacenados en filas

La siguiente figura ilustra el segundo caso, en el cual los datos binarios son superiores a 3.964 bytes (en este caso, los datos son de 81.920 bytes) y no pueden encajar en la fila. Por lo tanto, el localizador LOB hace referencia a los datos binarios que están almacenados en el segmento LOB. Como los datos binarios no ocupan más de 12 tramas en el segmento LOB, el localizador LOB almacena sus direcciones. En este caso no hay ningún índice LOB en uso.

Datos BLOB más grandes que 3.964 bytes de tamaño almacenados fuera de filas Un localizador LOB en la tabla apunta hacia el segmento LOB en el cual se almacenan los datos.

En la ilustración final, los datos binarios son tan grandes (106.496 bytes) que se requiere el índice LOB. En este caso, los datos binarios superan el almacenamiento en filas y además requiere más de 12 tramas en el segmento LOB para almacenarlos. Para datos de este tamaño, el localizador LOB se basa en el índice LOB para obtener la ubicación de las tramas en el segmento LOB. Se trata de un caso extremadamente raro para datos vectoriales y puede evitarse para datos ráster.

Datos BLOB almacenados fuera de filas, que requieren un índice LOB

Establecer los parámetros DBTUNE para almacenar columnas BLOB

Los parámetros de almacenamiento de la tabla DBTUNE controlan cómo ArcGIS crea tablas e índices en Oracle. Algunos de los parámetros de almacenamiento también determinan qué tipo de datos se utilizan cuando se crea una tabla. Para obtener más información acerca de la tabla DBTUNE, consulte ¿Qué es la tabla DBTUNE? Para obtener información general acerca de los parámetros de almacenamiento de DBTUNE, consulte ¿Qué son los parámetros y palabras clave de la configuración de DBTUNE?

Los parámetros de almacenamiento de DBTUNE, GEOMETRY_STORAGE, RASTER_STORAGE y ATTRIBUTE_BINARY, determinan qué tipo de datos de Oracle se utilizan para almacenar datos.

El parámetro GEOMETRY_STORAGE controla cómo se almacenan los datos vectoriales en una clase de entidad. El parámetros RASTER_STORAGE controla cómo se almacenan los datos ráster en un dataset ráster, catálogo ráster o atributo ráster. Finalmente, el parámetro ATTRIBUTE_BINARY controla el almacenamiento de todos los demás datos binarios que no son vectoriales ni ráster.

Para crear columnas BLOB, los parámetros deben establecerse tal y como se describe a continuación en una palabra clave DBTUNE determinada:

GEOMETRY_STORAGE SDELOB RASTER_STORAGE BLOB ATTRIBUTE_BINARY BLOB

Esri recomienda los siguientes parámetros de almacenamiento LOB para datos vectoriales y ráster:

• Habilite siempre el almacenamiento en filas porque la mayoría de datos del sistema de información geográfica (GIS) encaja dentro del umbral en filas de 3.964 bytes. El rendimiento se mejora cuando los datos se almacenan en filas.
• Habilite la memoria caché puesto que los datos de geodatabase se leen con frecuencia.
• Como ArcGIS no realiza actualizaciones de los datos BLOB y, en su lugar, solo realiza inserciones y borrados, establezca el PCT_VERSION en 0 puesto que no hay necesidad de mantener versiones anteriores de los datos en el segmento LOB.
• Deberá utilizar un tamaño de trama inferior a 8K. Los tamaños de trama de 2K y 4K incrementan la cantidad de E/S porque el proceso del servidor de Oracle debe recuperar más tramas. Es posible que descubra que un tamaño de trama de 8K ocupa menos espacio que uno de 16K. Si utiliza un tamaño de trama de 2K ó 4K, descubrirá que ocupa menos espacio, pero las pruebas demuestran que el tiempo de visualización para la mayoría de datos vectoriales y ráster aumenta enormemente frente a almacenar en un tamaño de trama de 8K. Como el tamaño de trama debe ser siempre un múltiples del tamaño de bloque de datos, el mejor tamaño de bloque de datos para almacenar datos GIS en BLOB es de 8K.

Los siguientes ejemplos muestran cómo los parámetros de almacenamiento DBTUNE ráster se han modificado para alojar la tabla de bloques ráster almacenada como un tipo de datos BLOB:

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)"

Si los datos de píxeles del bloque ráster es inferior a 3.965 bytes, se almacenan en la columna BLOCK_DATA en la tabla de espacio RASTER. No obstante, si supera este umbral, se almacenan en el segmento LOB en la tabla de espacio RASTER_LOB_SEGMENT. El índice LOB solo se utiliza si el número de tramas supera las 12. No es posible que ocurra para los datos de geodatabase. Considere un segmento LOB con un tamaño de trama de 8K. Antes de que se utilice el índice LOB, los datos binarios de ArcSDE deben superar los 96K.

Los siguientes ejemplos muestran cómo los parámetros de almacenamiento DBTUNE vectoriales se han modificado para alojar la tabla de entidades almacenada como un tipo de datos BLOB:

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"

Si los datos binarios de la entidad son inferiores a 3.965 bytes, se almacenan en la columna POINTS del espacio de tabla VECTOR. No obstante, si supera este umbral, se almacenan en el segmento LOB en la tabla de espacio VECTOR_LOB_SEGMENT.

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)"

En este ejemplo, si los datos binarios de la tabla de negocios es inferior a 3.965 bytes, se almacenan en la columna BLOB de la tabla de negocios en el espacio de tabla BIZZTABS. No obstante, si supera este umbral, se almacenan en el segmento LOB en la tabla de espacio BIZZ_LOB_SEGMENT. En este ejemplo, la columna BLOB es DOCUMENT. Si el anterior parámetro B_STORAGE DBTUNE se utiliza para crear una tabla que no tenga una columna DOCUMENT, Oracle devuelve el siguiente error:

ORA-00904: "DOCUMENT": invalid identifier

Por lo tanto, no se recomienda añadir los parámetros B_STORAGE or A_STORAGE que hacen referencia a una columna BLOB específica a la palabra clave DEFAULTS, puesto que la tabla de negocio debe contener estas columnas. En su lugar, cree palabras separadas de DBTUNE y añada estos parámetros de almacenamiento a las palabras clave. La palabra clave que contiene el parámetro de almacenamiento es referenciada durante la creación de la tabla. También tiene que tenerse en cuenta que se utilizan los parámetros de almacenamiento de la palabra clave DEFAULTS si no se incluyen con una palabra específica. Debido a ello, no es necesario añadir un parámetro de almacenamiento específico en una palabra clave si su cadena de configuración es idéntica al parámetro de almacenamiento bajo la palabra clave DEFAULTS. Por ejemplo, si todos los parámetros de almacenamiento salvo B_STORAGE y A_STORAGE de una palabra clave nueva, ROADS, tienen la misma cadena de configuración que los de la palabra clave DEFAULTS, sólo tendrá que crear los parámetros B_STORAGE y A_STORAGE bajo la palabra clave ROADS. Todos los demás parámetros de almacenamiento son leídos a partir de la palabra DEFAULTS, puesto que no se encuentran en la palabra clave ROADS.