Cargar datasets ráster grandes en ArcSDE

Este tema se aplica sólo a ArcEditor y ArcInfo.

Dada la naturaleza de los datos, los rásteres tienden a ser grandes. Los datasets ráster y los catálogos de ráster casi nunca tienen menos de unos gigabytes (GB) y pueden ocupar varios terabytes (TB) dentro del sistema de administración de bases de datos (DBMS). Hacerle frente al gran tamaño de los datos ráster desafía aún al administrador de base de datos (DBA) con más experiencia. Este tema le proporcionará los pasos básicos para cargar grandes cantidades de datos ráster en un dataset ráster o catálogo de ráster. Se supone que ya tomó la decisión de almacenar los rásteres en una geodatabase de ArcSDE.

Hay tres procesos principales para crear grandes bases de datos ráster: preparar para cargar los datos, cargar los datos y verificar y validar el producto final. Esto implica las siguientes tareas:

Preparar para cargar los datos

  1. Configurar el sistema
  2. Estimar el tamaño del espacio de almacenamiento DBMS
  3. Asignar el espacio de almacenamiento DBMS

Cargar los datos

  1. Preparar los datos de origen
  2. Crear el objeto ráster
  3. Cargar los datos ráster en el ráster
  4. Crear las estadísticas de BDMS
  5. Crear las estadísticas de ráster

Verificar y validar

  1. Visualizar el producto terminado

Configurar el sistema

La configuración del sistema consta de dos objetivos: configurar el DBMS y configurar ArcSDE.

Configurar los parámetros del DBMS

La configuración de cada DBMS compatible con Esri es única, pero el objetivo básico es el mismo: incrementar lo máximo posible el rendimiento de los datos en la base de datos. Para cargar vastas cantidades de datos ráster, el DBMS debe estar optimizado para el rendimiento de escritura; sin embargo, un sistema de DBMS que está optimizado para cargar varios cientos de gigabytes o más de datos ráster puede dificultar el rendimiento de otras aplicaciones que utilizan los mismos recursos para realizar otras tareas. Por lo tanto, se recomienda que si el DBMS no está dedicado a cargar datos ráster, es posible que deba considerar volver a configurar el sistema y cargar los datos ráster durante las horas no pico para evitar causar impacto en el trabajo de otros o crear una instancia separada del DBMS dedicado a cargar los datos ráster.

Hay guías para el almacenamiento de datos ráster en SQL Server, Oracle, DB2 e Informix. La información que se enumera a continuación resalta la información que se puede encontrar en cada una de estas guías.

Configurar los parámetros del DBMS de SQL Server

  • Determine los recursos que consume SQL Server sólo si hay otras aplicaciones que se ejecutan en el servidor.
  • Utilice una agrupación sencilla para reducir la cantidad de intercambios de contexto de subproceso.
  • Cuando sea posible, establezca el modelo de recuperación de base de datos en sencillo. Esto se debe a que la recuperación en un punto específico en el tiempo no es necesaria durante la carga de los datasets ráster, y al hacer que continúen todos los registros hace que los registros sean innecesariamente grandes.
  • Desactive autoclose y autoshrink, ya que éstos pueden tener un impacto negativo en el rendimiento.

Para obtener más información, consulte Datasets ráster y catálogos de ráster en una geodatabase en SQL Server.

Configurar los parámetros del DBMS de Oracle

  • Configure el intervalo de punto de control para que se produzca sólo durante un intercambio de registro de rehacer online. Cada DBA de Oracle establece los parámetros de inicialización de Oracle LOG_CHECKPOINT_INTERVAL y LOG_CHECKPOINT_TIMEOUT en 0. Al hacerlo, obliga a que el punto de control se produzca durante un intercambio de registro.
  • Incremente el tamaño de los archivos de registro de rehacer online en al menos 1 GB cada uno.
  • Incremente la caché de búfer del bloque de datos para que mantenga los bloques sin validar al incrementar el tamaño de DB_BUFFER_CACHE.
  • Cree la base de datos de Oracle con un tamaño de bloque de datos de 8 KB. Este es el tamaño de bloque de datos óptimo para almacenar datos BLOB, que se convirtió en el tipo de almacenamiento predeterminado subyacente de todos los datos binarios de ArcGIS. Utilizar un tamaño de bloque de datos grande de 16 KB ó 32 KB probablemente dará como resultado un desperdicio de espacio en los segmentos de registro BLOB. Para un entendimiento total del almacenamiento BLOB, consulte la documentación de Oracle.

Para obtener más información, consulte Datasets ráster y catálogos de ráster en una geodatabase almacenada en Oracle.

Configurar los parámetros del DBMS de DB2.

  • Cree grupos de búferes separados para los espacios de tabla de ráster.
  • Cree un grupo de búferes grande para el espacio de tabla que almacena la tabla de bloques ráster.
  • Si DB2 está instalado en una plataforma AIX, configure los siguientes parámetros:

  • db2set DB2_MMAP_READ=OFF
  • db2set DB2_MMAP_WRITE=OFF

Para obtener más información, consulte Datasets ráster y catálogos de ráster en una geodatabase en DB2.

Configurar los parámetros del DBMS de Informix

Configure los parámetros onconfig:

  • Configure BUFFERS lo suficientemente grandes para adelantarse a los limpiadores.
  • Configure LOGSIZE en 100000.
  • Asegúrese de que el registro físico no se cree en el rootdbs dbspace.
  • Configure LOG_BACKUP_MODE para que continuamente realice copias de seguridad de los registros lógicos.
  • Configure LOGSMAX en 100.
  • Configure RA_PAGES en 125.
  • Configure RA_THRESHOLD en 85.
  • Configure RESIDENT en -1.
  • Configure el parámetro NETTYPE para favorecer las conexiones remotas si intenta utilizar conexiones directas.

Para obtener más información, consulte Datasets ráster y catálogos de ráster en una geodatabase en Informix.

Configurar el servidor de ArcSDE

ArcSDE utiliza búferes de transporte para transferir los datos entre el cliente de ArcSDE y el servidor de ArcSDE. Durante una operación de escritura, cuando el búfer de datos de cliente alcanza el umbral, se ubica en el servidor de ArcSDE. Mientras el servidor de ArcSDE procesa ese búfer, el cliente de ArcSDE acepta más datos en el búfer. El cliente envía otra vez el búfer una vez que se alcanza el umbral, pero sólo si el servidor de ArcSDE está esperando. Para los datos ráster, el tamaño del búfer de transporte se controla mediante el parámetro del servidor RASTERBUFSIZE de ArcSDE. Por defecto, el parámetro se establece en 200 KB, que es adecuado para la mayoría de las operaciones de carga. ArcSDE asigna la cantidad de memoria especificada por RASTERBUFSIZE a los búferes dobles en el cliente y el servidor de ArcSDE. Por lo tanto, si utiliza el valor predeterminado 200 KB recomendado, 400 KB se asignan en el cliente y 400 KB se asignan en el servidor. Además de los búferes de transporte, ArcSDE también asigna otros tres búferes en el servidor para los datos leídos y escritos en y desde el DBMS. Esto incrementa la cantidad total de memoria asignada en el servidor a 1000 KB. Si utiliza una conexión directa, la funcionalidad del cliente y del servidor de ArcSDE opera en el equipo cliente; por lo tanto, la memoria asignada por una conexión directa es siete veces el tamaño especificado por RASTERBUFSIZE. Sólo debe cambiar el tamaño de RASTERBUFSIZE si el tamaño predeterminado no es lo suficientemente grande para que se ajuste al tamaño descomprimido de una tesela ráster. El tamaño descomprimido de una tesela ráster se puede determinar al multiplicar la anchura del entramado por la altura del entramado y al ajustar la profundidad de píxel. Por ejemplo, si utiliza los valores predeterminados de 128 por 128 para la anchura del entramado y la altura del entramado, el producto de estos dos valores es 16.384. Multiplique este producto por el factor profundidad de píxel de la tabla a continuación para obtener el tamaño descomprimido de la tesela ráster. Si la profundidad de píxel es 32, el tamaño descomprimido se calcularía como 65.536 bytes. Esto está por debajo del valor predeterminado de 200 KB. Sin embargo, si decide aumentar el tamaño de tesela a 256 por 256, aumentaría el tamaño descomprimido a 262.144 bytes. Sin aumentar el tamaño del parámetro RASTERBUFSIZE, correría el riego de obtener un error SE_RASTER_BUFFER_TOO_SMALL (-294). En este caso, debería aumentar el tamaño del parámetro RASTERBUFSIZE a aproximadamente 300 KB.

Profundidad de píxel

Factor profundidad de píxel

1 bit

0.125

4 bit

0.25

8 bit

1

16 bit

2

32 bit

4

64 bit

8

Lista del factor profundidad de píxel para las profundidades de píxel
Para cambiar la configuración del parámetro RASTERBUFSIZE, utilice la herramienta de administración sdeconfig de ArcSDE con la opción alterar: 

sdeconfig -o alter -v RASTERBUFSIZE=10240000 -u sde -p esri

El cambio se realiza en la tabla SDE.SERVER_CONFIG, que almacena el nuevo valor. El valor afecta todas las sesiones de ArcSDE que se conectan después de que se haya alterado el parámetro.

No debe aumentar el parámetro RASTERBUFSIZE más allá de lo que se requiere para mantener el tamaño descomprimido de una tesela ráster. Configurar el parámetro demasiado grande puede ser perjudicial para el flujo de los datos ráster a través del sistema.

Arquitectura de conexión

La construcción de la pirámide de resolución reducida es una operación intensiva de procesador multiproceso. Esta tarea se realiza mediante la funcionalidad del servidor de ArcSDE. Al posicionar la funcionalidad del servidor en el equipo con la mayoría de la potencia del CPU dentro de la arquitectura cliente/servidor, logrará un mayor rendimiento de los datos ráster en la base de datos. La potencia del CPU se determina al multiplicar la cantidad de CPU por la velocidad del procesador.

La funcionalidad del servidor se puede ejecutar de manera independiente como cuando se conecta a un servicio de ArcSDE o se puede incorporar en la aplicación cliente (por ejemplo, ArcCatalog), como cuando realiza una conexión directa.

La decisión de si debe utilizar o no una conexión directa cuando carga datos ráster depende de si la potencia del CPU es más grande en el equipo cliente o en el servidor que aloja el servicio de ArcSDE. Para crear las pirámides en el equipo cliente, si es más poderoso, utilice una conexión directa.

También debe considerar la capacidad del equipo del servidor que aloja el servicio de ArcSDE. Es posible que sea más poderoso que el equipo cliente, pero ya puede estar cerca del límite que sirve las solicitudes de otras aplicaciones. Si el equipo del servidor no alcanza el límite y es más poderoso que el equipo cliente, conéctese al servicio de ArcSDE.

Estimar el tamaño del espacio de almacenamiento DBMS

Se recomienda organizar el espacio de almacenamiento DBMS antes de comenzar un proyecto de carga de datos ráster grandes. Para eso, deberá obtener una estimación del espacio que se requiere para almacenar los datos ráster en la base de datos así como también cualquier espacio que se requiere para organizar los archivos de imágenes antes de que se carguen. Una vez que tenga una estimación del espacio en disco requerido, puede asignar el espacio DBMS, configurar los parámetros DBTUNE de ArcSDE y comenzar a cargar los datos ráster.

La tabla BLK de ráster es primordialmente la más grande de las tablas e índices de ráster. Por lo general, es 150 veces más grande que el próximo objeto DBMS más grande, que es el índice compuesto de la tabla de bloques ráster. El resto de las tablas e índices del objeto ráster son miles de veces más pequeñas y por lo general se agrupan con el índice compuesto de la tabla de bloques ráster en un único espacio de almacenamiento DBMS. Ya que la tabla de bloques ráster es mucho más grande que todos los demás objetos, la tarea de estimar el tamaño de los datos ráster se enfoca en ésta.

Para los datasets ráster y los catálogos de ráster, los datos de píxel se almacenan en el DBMS en la tabla BLK. Por otro lado, los datasets de mosaico hacen referencia a los datasets ráster y no almacenan los datos de píxel en la tabla BLK. La tabla BLK permanecerá vacía a menos que las vistas generales del dataset de mosaico se almacenen en el DBMS.

Hay dos métodos básicos para estimar la cantidad de espacio que ocupará una tabla de bloques ráster en la base de datos. Un método implica cargar algunas imágenes de muestra y extrapolar la cantidad total de espacio que se espera que ocupe la tabla de bloques ráster en la base de datos de la cantidad de espacio que ocupa la muestra. Otro método intenta calcular el espacio que se requiere basado en una fórmula que acepta como entrada las propiedades de los objetos ráster esperados. El primer método por lo general proporciona una mejor estimación que el último, pero el método de la fórmula es útil en casos donde los datos de origen no están disponibles antes de la construcción de la base de datos. Para estimar con precisión el tamaño de una tabla de bloques ráster, ya debe haber determinado las siguientes propiedades que afectarán el tamaño de almacenamiento de una tabla de bloques ráster:

Más información sobre cómo recopilar información básica sobre el dataset ráster

Estimar el tamaño de la tabla de bloques ráster basado en una muestra

Cree un objeto ráster pequeño al cargar una cantidad de datasets ráster de muestra con ArcCatalog. El objeto ráster debe tener el mismo tipo de compresión, calidad de compresión, profundidad de píxel, cantidad de bandas y tamaño de tesela que el objeto ráster final que representará. Estas propiedades de ráster afectan el tamaño de almacenamiento de un objeto ráster dentro de la base de datos.

Después de cargar datos ráster de muestra con ArcCatalog, determine cuánto espacio ocupó en la base de datos la tabla de bloques de objeto ráster de muestra.

Para Oracle, esto se hace al consultar la columna BLOQUES de la tabla del sistema USER_TABLES de Oracle para la tabla de bloques ráster del objeto ráster. Para hacer eso, primero deberá determinar el nombre de la tabla de bloques ráster del objeto ráster, que, a la vez, requiere que obtenga el rastercolumn_id de la tabla SDE.RASTER_COLUMN.

NotaNota:

Los siguientes ejemplos en este documento suponen que el nombre de la tabla de negocios del objeto ráster de muestra es TIERRA.

  1. Obtenga el rastercolumn_id para el objeto ráster. 
    SQL> select rastercolumn_id from sde.raster_columns where table_name = 'EARTH';  RASTERCOLUMN_ID  =---------------               14
  2. Obtenga el tamaño de la tabla de bloques ráster con la siguiente consulta. 
    SQL> exec dbms_stats.gather_table_stats (NULL,'EARTH');  SQL> select sum(length(rasterband_id))            + sum(length(rrd_factor))           + sum(length(row_nbr))           + sum(length(col_nbr))           + sum(length(block_data)) "total size"       from sde_blk_14;  total size  =-----------  762707968

    El tamaño total de la tabla de bloques ráster es 762.707.968 bytes, o aproximadamente 727 MB.

  3. Determine la relación del tamaño del dataset ráster de muestra con el tamaño total de todos los archivos de dataset ráster de origen que está por cargar. El tamaño de esta muestra es 2 GB, mientras que el proveedor de datos proporcionó un tamaño total de todos los archivos de dataset ráster de aproximadamente 3 TB.

    Primero, convierta los 3 terabytes del tamaño de archivo total a gigabytes:

    3 TB * 1024 = 3072 GB

    La relación del tamaño total del dataset ráster con el tamaño de muestra se calcula como

    total size of all rasters / sample raster size = total size to sample size

    Por ejemplo:

    3072 / 2 = 1536

  4. Multiplicar la relación del tamaño total del dataset ráster con el tamaño de muestra por el tamaño de la muestra almacenada en la base de datos proporciona una estimación aproximada de la cantidad total de espacio en disco que se requiere para almacenar todos los archivos de dataset ráster en el objeto ráster. 
    727 MB * 1536 = 1,116,672 MB = 1090 GB = 1.06 TB

Para determinar el tamaño de muestra en SQL Server, primero obtiene el tamaño de muestra, después pasa al paso 3 de arriba.

  1. Obtenga el rastercolumn_id para el ráster.
    1> select rastercolumn_id  2> from sde.sde_raster_columns  3> where table_name = 'EARTH';  rastercolumn_id  =--------------               3
  2. Utilice el ID para determinar el espacio utilizado por los datos de muestra. 
    1> exec sp_spaceused 'sde_blk_3';  2> go  name        rows   reserved   data       index_size  used =-------------------------------------------------------------- SDE_blk_3   4233   29712 KB   29632 KB   16 KB       64 KB

    En este caso, el tamaño original del dataset ráster era 50 MB, pero una vez cargado, la cantidad de espacio utilizado es 29.632 KB + 16 KB = 29.648 KB o aproximadamente 29 MB.

Estimar el tamaño de la tabla de bloques ráster basado en una fórmula

El método de la fórmula que sigue proporciona una estimación aproximada del tamaño de la tabla de bloques ráster. Si los datos de origen están disponibles en parte o en su totalidad, debe utilizar el método que se describió anteriormente para obtener una estimación de la tabla de bloques ráster, porque es un método más preciso.

  1. Obtenga una estimación aproximada de la extensión en metros o en pies. Para los datasets ráster con una resolución de píxel en metros (por ejemplo, 5 metros, 15 metros o 150 metros), obtenga la estimación en esas unidades. De la misma manera, si la resolución se expresa en pies o pulgadas, obtenga la extensión en esas unidades. Una buena forma de obtener la extensión es crear un contorno de polígono de la extensión de la imagen con ArcMap. Debe eliminar la mayor cantidad de espacio vacío posible, ya que la geodatabase no almacena bloques vacíos.

  2. Convierta la extensión a píxeles. 

    (Extent of raster in pixel units) / (pixel resolution) = Number of pixels

    Para los datasets ráster de origen con una resolución de 15 metros y la extensión de 450 kilómetros cuadrados, la conversión a píxeles se calcularía de la siguiente manera:

    (km2 to m2 conversion factor) / (the pixel resolution in m2) = pixels (450 km2 * 1,000,000) / (15 x 15) = 2,000,000 pixels

    Como otro ejemplo, considere 50 millas cuadradas de resolución de un pie. La extensión en píxel estimada es aproximadamente la siguiente:

    (mi2 to ft2 conversion factor) / (the pixel resolution in ft2) = pixels (50 mi2 * 52802)/ (1 x 1) = 1,393,920,000 pixels
  3. Multiplique por la cantidad de bandas. Si es un dataset ráster de escala de grises de banda única o en blanco y negro, puede omitir este paso. Para este ejemplo, supongamos que los datos de 15 metros del paso 2 tienen tres bandas (que representan RGB). 
    2,000,000 pixel extent * 3 bands = 6,000,000 pixels
  4. Convierta a bytes al aplicar el factor profundidad de píxel de la tabla.

    Profundidad de píxel

    Factor byte

    1 bit

    0.125

    4 bit

    0.25

    8 bit

    1

    16 bit

    2

    32 bit

    4

    64 bit

    8

    Lista de los factores byte de píxel para las profundidades de píxel
    8-bit data: 6,000,000 pixels * 1 = 6,000,000 Bytes / 10242 = 5.7 MB 16-bit data: 6,000,000 pixels * 2 = 12,000,000 Bytes / 10242 = 11.4 MB
  5. Agregue la pirámide de resolución reducida. La pirámide de resolución reducida incrementa el tamaño del ráster en un tercio. Por lo tanto, multiplique el número de byte del paso 4 por 1,33. 
    5.72 MB * 1.33 = 7.67 MB
  6. Aplique la compresión ráster. La siguiente tabla proporciona un ejemplo de los ahorros esperados para una compresión y calidad dadas. Los valores exactos variarán según los datos que se utilicen.

    Tipo de compresión

    Factor de compresión

    LZ77

    0.5

    JPEG 75%

    0.15

    JPEG 50%

    0.1

    JPEG 2000 80/100

    0.36

    JPEG 2000 60/100

    0.15

    JPEG 2000 55/100

    0.11

    JPEG 2000 50/100

    0.07

    JPEG 2000 45/100

    0.06

    Factores de compresión para los tipos de compresión
  7. Al extender el ejemplo en el paso 5 y aplicar una compresión JPEG con una calidad del 50 por ciento, multiplique la cantidad de byte por el factor de compresión 0,1. 
    7.67 MB * 0.1 = 0.77 MB
  8. Incremente la estimación de las columnas de enteros de la tabla de bloques ráster y de sobrecarga del DBMS. El valor del paso 7 es una estimación de la cantidad de espacio absoluto que requieren los datos de píxel almacenados en la tabla de bloques ráster. Los píxeles se dividen en bloques de acuerdo al tamaño de tesela que selecciona cuando crea el objeto ráster. Estos bloques de píxeles se almacenan en los bloques de datos de la base de datos. Los bloques ráster no se ajustarán perfectamente dada la variabilidad de compresión. Siempre habrá una cierta cantidad de espacio de bloque que no se utiliza. Además, la tabla de bloques ráster también almacena cuatro columnas de enteros, junto con la columna BLOB de píxel, para identificar únicamente cada bloque. Las columnas de enteros también agregan sobrecarga al almacenamiento. Incremente la estimación en el paso 7 en al menos un 10 por ciento para dar cuenta de las columnas de enteros de la tabla de bloques ráster y de sobrecarga del DBMS.

Asignar el espacio de almacenamiento DBMS

Cómo crea el espacio de almacenamiento DBMS depende de cómo debe administrarlo. Algunos DBMS le permiten mover los archivos de datos de una base de datos, por lo tanto es posible que desee almacenar todas las tablas ráster e índices en un único espacio. Si el transporte de los datos no es una preocupación, cree espacio de almacenamiento de acuerdo al tamaño: un espacio grande para la tabla de bloques y el índice, y un espacio más pequeño para las otras tablas ráster y los índices.

Algunos DBMS le permiten aumentar automáticamente el espacio DBMS; sin embargo, debe asignar previamente el espacio para asegurarse de que no encontrará problemas durante la carga. Ya que se tomó la molestia de estimar los requisitos de espacio de los datos, también puede asignar espacio para ellos.

Crear el espacio de almacenamiento DBMS de Oracle

Crear el espacio de almacenamiento DBMS de SQL Server

Crear el espacio de almacenamiento DBMS de DB2

Crear el espacio de almacenamiento DBMS de Informix

Configurar las palabras clave DBTUNE

La tabla SDE.DBTUNE contiene los parámetros de almacenamiento que utiliza ArcSDE para crear tablas e índices dentro de la base de datos. Los parámetros de almacenamiento se organizan por palabra clave. Al especificar una palabra clave DBTUNE durante la construcción de un objeto de geodatabase, como un ráster, especifica cómo desea que se creen las tablas e índices del objeto de geodatabase y en qué unidad de almacenamiento de base de datos se deben ubicar.

Hay un parámetro de almacenamiento DBTUNE para cada una de las combinaciones de tabla e índice del ráster. Editará el archivo SDEHOME/etc/dbtune.sde al incorporar una nueva palabra clave seguida de la especificación para cada parámetro de almacenamiento. A continuación se muestran algunos ejemplos de esto. Después, utilizará la operación de importación sdedbtune para actualizar la tabla SDE.DBTUNE.

Según el DBMS, los parámetros de almacenamiento pueden variar. Los 11 parámetros de almacenamiento DBTUNE de Oracle se enumeran a continuación; sin embargo, varios de éstos son comunes a los otros DBMS.

  • El parámetro de almacenamiento para la tabla de negocios es B_STORAGE, y si la tabla de negocios tiene una columna ID de fila registrada de ArcSDE, el parámetro de almacenamiento para ésta es B_INDEX_ROWID. La tabla de negocios para un dataset ráster contiene una única fila y, por lo tanto, es muy pequeña. La tabla de negocios para un catálogo de ráster por lo general es pequeña y contiene una fila para cada dataset ráster.

    Algunos ejemplos de los parámetros de almacenamiento B_STORAGE y B_INDEX_ROWID son los siguientes:

    B_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" B_INDEX_ROWID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"

  • El almacenamiento de la tabla del ráster se controla mediante el parámetro RAS_STORAGE, mientras que el almacenamiento del índice raster_id en esa tabla se controla mediante el parámetro RAS_INDEX_ID. La tabla del ráster de un dataset ráster contiene una única fila y es muy pequeña. La tabla del ráster para un catálogo de ráster por lo general es pequeña y almacena sólo una fila para cada dataset ráster.

    Algunos ejemplos de los parámetros de almacenamiento RAS_STORAGE y RAS_INDEX_ID son los siguientes: 

    RAS_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" RAS_INDEX_ID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"

  • La tabla de la banda de ráster se almacena de acuerdo con el parámetro de almacenamiento BND_STORAGE. El BND_INDEX_ID controla el almacenamiento del índice rasterband_id, y el parámetro de almacenamiento BND_INDEX_COMPOSITE controla el almacenamiento del índice compuesto en las columnas sequence_nbr y raster_id. La tabla de las bandas de ráster por lo general es pequeña y sólo un poco más grande que la tabla de negocios o ráster del objeto ráster; almacena un registro para cada banda de ráster. Para un catálogo de ráster que almacena 1.000 datasets ráster de tres bandas, la tabla de las bandas de ráster tendrá 3.000 registros.

    Algunos ejemplos de los parámetros de almacenamiento BND_STORAGE, BND_INDEX_COMPOSITE y BND_INDEX_ID son los siguientes: 

    BND_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" BND_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" BND_INDEX_ID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"

  • El parámetro de almacenamiento AUX_STORAGE controla el almacenamiento de la tabla auxiliar de ráster, mientras que el parámetro de almacenamiento AUX_INDEX_COMPOSITE controla el almacenamiento del índice compuesto de la tabla. La cantidad de registros en la tabla auxiliar de ráster varía según los datos de la banda de ráster opcional almacenados. Por motivos de efectividad, la máscara de bit NoData se almacena para cada banda de ráster, pero sólo si la máscara de bit es menor que 10 MB; de lo contrario, no se almacena y ArcSDE debe recuperar la máscara de bit NoData de los bloques de píxel almacenados en la tabla de bloques ráster. También almacena las estadísticas de ráster, si se calcularon, y el mapa de color, si existe. Es posible que para un objeto ráster determinado, la tabla auxiliar de ráster puede estar vacía o tener más registros que la tabla de las bandas de ráster. Por lo general tiene el mismo tamaño que la tabla de las bandas de ráster.

    Algunos ejemplos de los parámetros de almacenamiento AUX_STORAGE y AUX_INDEX_COMPOSITE son los siguientes: 

    AUX_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" AUX_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"

  • El BLK_STORAGE controla el almacenamiento de la tabla de bloques ráster, que es la más grande de la tabla e índice del objeto ráster. La tabla de bloques ráster almacena los datos de píxel definidos por el tamaño de tesela cuando se creó el objeto ráster. El BLK_INDEX_COMPOSITE controla el almacenamiento del índice compuesto de la tabla de bloques ráster, que indexa las cuatro columnas de enteros rasterband_id, row_nbr, col_nbr y rrd_factor. La tabla de bloques ráster es aproximadamente 150 veces más grande que el índice. Sin embargo, ya que la tabla de bloques ráster se puede volver muy grande, es práctico almacenar el índice de la tabla de bloques ráster en el mismo espacio de tabla que la tabla de bloques ráster.

    Algunos ejemplos de los parámetros de almacenamiento BLK_STORAGE y BLK_INDEX_COMPOSITE son los siguientes: 

    BLK_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH_BLOCKS STORAGE      (INITIAL 500M MINEXTENTS 10) LOB( BLOCK_DATA) STORE AS (ENABLE STORAGE        IN ROW CHUNK 8K RETENTION CACHE)" BLK_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE       EARTH_BLOCKS"

Las huellas del dataset ráster y catálogo de ráster se almacenan el la columna espacial. Si la columna espacial se crea como un tipo binario de ArcSDE, también deberá configurar los siguientes parámetros de almacenamiento DBTUNE:

  • S_STORAGE - La tabla de índice espacial
  • S_INDEX_ALL - El índice de cobertura, que enumera todas las columnas de la tabla de índice espacial
  • S_INDEX_SP_FID - El índice de columna fid de la tabla de índice espacial

A continuación se muestran algunos ejemplos de cómo aparecería la palabra clave DBTUNE en el archivo DBTUNE para cada DBMS. El signo numeral doble (##) significa el comienzo de la palabra clave EARTH DBTUNE, mientras que END significa el fin.

Ejemplo de palabras clave DBTUNE de SQL Server 

##EARTH_15M B_CLUSTER_ROWID 0  B_CLUSTER_SHAPE 1 B_CLUSTER_RASTER 0  B_INDEX_ROWID "WITH FILLFACTOR = 100" B_INDEX_SHAPE "WITH FILLFACTOR = 100" B_INDEX_RASTER "WITH FILLFACTOR = 100" B_STORAGE "" B_TEXT_IN_ROW 256 RAS_STORAGE "" RAS_CLUSTER_ID 1 RAS_INDEX_ID "WITH FILLFACTOR = 100" BND_STORAGE ""  BND_CLUSTER_ID 0 BND_INDEX_ID "WITH FILLFACTOR = 100" BND_CLUSTER_COMPOSITE 0 BND_INDEX_COMPOSITE "WITH FILLFACTOR = 100" AUX_STORAGE "" AUX_CLUSTER_COMPOSITE 1 AUX_INDEX_COMPOSITE "WITH FILLFACTOR = 100"  BLK_STORAGE ""  BLK_CLUSTER_COMPOSITE 1 BLK_INDEX_COMPOSITE "WITH FILLFACTOR = 100"  END

Ejemplo de palabras clave DBTUNE de Oracle 

##EARTH_15M  RAS_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"  RAS_INDEX_ID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" BND_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" BND_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" BND_INDEX_ID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" AUX_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"  AUX_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"  BLK_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH_BLOCKS STORAGE         (INITIAL 500M MINEXTENTS 10) LOB( BLOCK_DATA) STORE AS (ENABLE          STORAGE IN ROW CHUNK 8K RETENTION CACHE)" BLK_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH_BLOCKS"  END

Ejemplo de palabras clave DBTUNE de DB2 

##EARTH_15M  AUX_STORAGE "IN EARTH INDEX IN EARTH"  BLK_STORAGE "IN EARTH INDEX IN EARTH LONG IN EARTH_BLOCKS"  BND_STORAGE "IN EARTH INDEX IN EARTH"  RAS_STORAGE "IN EARTH INDEX IN EARTH" END

Ejemplo de palabras clave DBTUNE de Informix 

##EARTH_15M  RAS_STORAGE "EXTENT SIZE 16 NEXT SIZE 16 LOCK MODE ROW IN EARTH"  RAS_INDEX_ID "FILLFACTOR 90 IN EARTH" BND_STORAGE EXTENT SIZE 16 NEXT SIZE 16 LOCK MODE ROW IN EARTH" BND_INDEX_COMPOSITE "FILLFACTOR 90 IN EARTH"  BND_INDEX_ID "FILLFACTOR 90 IN EARTH"  AUX_STORAGE "EXTENT SIZE 16 NEXT SIZE 16 LOCK MODE ROW IN EARTH"  AUX_INDEX_COMPOSITE "FILLFACTOR 90 IN EARTH"  BLK_STORAGE "EXTENT SIZE 1000 NEXT SIZE 1000 LOCK MODE ROW IN EARTH_BLOCKS"  BLK_INDEX_COMPOSITE "FILLFACTOR 90 IN EARTH" END

Preparar los datos de origen

Ponga a disposición los archivos de origen del dataset ráster al presentarlos en unidades de disco accesibles a ArcCatalog o a las secuencias de comando de ArcObjects que se utilizan para cargar los datos en la geodatabase.

CD o DVD

Si los datasets ráster están en un CD o DVD, cópielos en un disco duro rápido. Se prefieren los discos duros locales antes que los discos duros de red. No se aconseja cargar los archivos directamente desde el CD o DVD, ya que el tiempo de acceso es mucho más lento que desde los discos duros.

Biblioteca de cintas

Si carga desde una biblioteca de cintas, los archivos de dataset ráster que se cargarán se deben presentar en la caché on-line antes de comenzar a cargarlos.

Organizar los datos de origen

Los archivos de imagen se deben agrupar en carpetas separadas para la operación de carga que los consumirá. Si lo hace, le permite a la herramienta de carga abrir todos los archivos dentro de una carpeta y cargarlos por lotes en lugar de cargar cada archivo en forma individual. Por ejemplo, puede crear mosaicos de varios datasets ráster en un único dataset ráster; cargar cada entrada del dataset ráster en un único dataset ráster independiente; agrupar los datasets ráster en un catálogo de ráster o crear un catálogo de ráster con múltiples datasets ráster en mosaico. Los sistemas operativos tienen distintos límites en la cantidad de archivos abiertos. Por lo tanto, si alcanza este límite, deberá crear carpetas adicionales y comenzar otro proceso de carga.

Aplicar una proyección a los datos de origen

Existen dos flujos de trabajo básicos para proyectar los datos ráster. Puede aplicar la proyección al crear otra copia del archivo de imágenes de origen o aplicar la proyección a medida que inserta el archivo de imágenes de origen en la geodatabase.

La prueba demostró que con mayor frecuencia, el mejor flujo de trabajo es aplicar la proyección a una copia del archivo de origen del dataset ráster e insertar el origen del dataset ráster proyectado en la geodatabase. Proyectar el archivo de origen del dataset ráster mientras carga puede ser un poco más rápido que crear un archivo de origen proyectado intermedio, pero si utiliza varios procesos para insertar varios orígenes del dataset ráster a la vez, es mejor presentar los archivos de origen del dataset ráster proyectados en el cliente, después cargarlos en el servidor debido a la gran cantidad de tiempo que requiere proyectar los datos ráster. Al tener varios procesos que crean los archivos de origen del dataset ráster proyectados y algunos procesos que insertan los archivos proyectados en la geodatabase, en realidad maximiza los recursos del cliente y los equipos del servidor en lugar de tener un servidor inactivo con actividades que ocasionalmente pueden abrumar los recursos del servidor.

Crear el objeto ráster y cargar los datos ráster

Cuando no almacena múltiples datasets ráster independientes, se recomienda que cree el catálogo de ráster o el dataset ráster que tendrá los datasets ráster que carga. Sin embargo, en todas las situaciones, debe tener en cuenta las propiedades del dataset ráster que cargará y las propiedades que tendrán una vez cargados.

Puede haber determinado estas propiedades cuando estimó los requisitos de tamaño de almacenamiento o cuando asignó el espacio de almacenamiento. También puede haber editado el dbtune para crear una palabra clave que especifica todos los parámetros de almacenamiento. De lo contrario, debe determinar estas propiedades en este punto.

Más información sobre las propiedades del dataset ráster

Hay cuatro configuraciones de geodatabase ráster que se deben considerar: pirámides, estadísticas de ráster, compresión y tamaño de tesela.

Las pirámides afectan el rendimiento de la visualización.

Más información acerca de las pirámides ráster

Las pirámides se pueden crear en un dataset ráster ya que se crean mosaicos de los datos ráster en el dataset ráster, o se pueden crear cuando la carga está completa. Crear las pirámides después de que se realiza un mosaico es el método más rápido. ArcGIS permite la construcción de pirámide parcial, que vuelve a construir solamente la parte de la pirámide superpuesta por los datos de origen durante una operación de mosaico. Esto ayuda cuando se actualiza un dataset ráster en mosaico, porque si se agrega un nuevo dataset ráster, el dataset ráster completo no debe volver a crear las pirámides. Sin embargo, si actualiza los datos en el origen del dataset ráster (punto de referencia de pirámides), la pirámide se debe volver a crear para el dataset ráster completo.

El origen del dataset ráster es la coordenada del extremo superior izquierdo del dataset ráster. La construcción de la pirámide comienza en esta coordenada y continúa a la derecha y hacia abajo. Crear mosaicos de los datos a la izquierda o hacia arriba del origen del dataset ráster requiere que ArcSDE convierta este punto para que permanezca en la coordenada del extremo superior izquierdo. Convertir el origen del dataset ráster existente requiere que ArcSDE vuelva a crear la pirámide. Volver a crear la pirámide puede ser una operación costosa, espacialmente si el dataset ráster se desarrolló debido a una cantidad de archivos de origen del dataset ráster (u otros datasets ráster) que ya se crearon en mosaico.

Debido a que la reconstrucción de la pirámide es una operación que tarda mucho tiempo, debe identificar la coordenada de ráster superior izquierda del dataset ráster a través del análisis de los datos de origen e introducirla cuando crea el dataset ráster. ArcSDE le permite establecer un punto de referencia de pirámides cuando se crea el objeto ráster en lugar de utilizar la coordenada superior izquierda del primer dataset ráster que se inserta. Por lo tanto, es posible evitar convertir el origen del dataset ráster al establecer un punto de referencia de pirámides cuando crea el dataset ráster.

Punto de referencia de pirámides

Las estadísticas son necesarias para que el dataset ráster realice algunas operaciones de geoprocesamiento o determinadas tareas en ArcMap o ArcCatalog como aplicar un aumento de contraste o clasificar datos.

Más información acerca de las estadísticas de ráster

La compresión se determina por el tipo de datos ráster junto con el uso planificado.

Más información acerca de la compresión ráster

ArcSDE subdivide los datasets ráster en una o más teselas para el almacenamiento. Cada tesela se almacena como datos binarios en la tabla de almacenamiento de ráster. Si un dataset ráster es multibanda, los píxeles de los bloques ráster coincidentes en distintas bandas se almacenan en sus propias filas en la tabla.

El ordenamiento en teselas de los datasets ráster mejora el rendimiento. Por ejemplo, si acerca una pequeña área que contiene sólo cuatro teselas, ArcSDE sólo debe capturar cuatro de las filas en la tabla de bloques ráster. Sin dividir el ráster en teselas, ArcSDE necesitaría capturar el dataset ráster completo.

El tamaño de las teselas se ajusta en términos de la cantidad de filas y columnas desde las que se crea cada tesela. Por ejemplo, un tamaño de tesela de 128 por 128 es realmente de 128 píxeles por 128 píxeles. Las teselas grandes dan como resultado campos BLOB grandes pero menos filas en la tabla, mientras que las teselas más pequeñas dan como resultado campos BLOB pequeños pero varias filas en la tabla. El tamaño de tesela se establece en 128 por 128 píxeles por defecto. Si los datos que se cargan no son imágenes en color de tres bandas, es posible que al modificar el tamaño de tesela se puedan reducir los requisitos de espacio de almacenamiento al ajustar de manera efectiva las teselas en los bloques de la base de datos. Para determinar el mejor tamaño posible, se requiere un banco de pruebas con rásteres representativos. En términos generales, los tamaños de tesela más grandes producen relaciones de compresión más altas y dan como resultado teselas más pequeñas que se almacenan en la base de datos.

Puede crear objetos ráster con una herramienta de geoprocesamiento (por ejemplo, en ArcCatalog), sderaster o ArcObjects. Los objetos ráster creados mediante las herramientas de geoprocesamiento están vacíos; tienen propiedades pero no contienen ningún dato de píxel, y tienen en cuenta la geodatabase. Para crear un dataset ráster, consulte Crear un dataset ráster en una geodatabase de ArcSDE. Para crear un catálogo de ráster, consulte Crear un catálogo de ráster en una geodatabase de ArcSDE.

Los objetos ráster creados por sderaster siempre contienen datos de píxel. No tienen en cuenta la geodatabase, carecen de la columna de huellas y, para la operación de mosaico, los archivos de georreferenciación se deben alinear perfectamente. Para obtener más información sobre cómo crear rásteres con ArcObjects, consulte la Red de desarrollo de Esri para obtener muestras del Intercambio de códigos para los datos ráster que puede modificar y usar. Por ejemplo, puede copiar y modificar la muestra Crear dataset ráster de geodatabase para crear un nuevo dataset ráster independiente. Las muestras Rásteres en mosaico en un directorio y subdirectorios a un ráster de ArcSDE le proporcionan el código de muestra para crear mosaicos de todos los orígenes del dataset ráster dentro de un directorio o carpeta a un dataset ráster independiente determinado. Un catálogo de ráster se puede crear con la muestra Crear catálogo de ráster de geodatabase. Puede combinar esta muestra con la muestra Cargar datasets ráster en un espacio de trabajo a un catálogo de ráster GDB, que inserta los archivos de origen del dataset ráster en un catálogo de ráster.

Aunque utilizar el software de ArcObjects requiere que usted o un usuario en su ubicación posea las habilidades para modificar y ejecutar el código de muestra, los posibles beneficios son los siguientes:

Los datos ráster se pueden cargar en una geodatabase de varias maneras: al utilizar Importar datasets ráster (menú contextual de la geodatabase), la herramienta Copiar ráster (herramientas de geoprocesamiento) o Cargar datos (menú contextual del dataset de ArcCatalog). Para obtener más información sobre cómo cargar datos ráster en una geodatabase, consulte Importar datasets ráster.

Para obtener más información sobre cómo cargar datos ráster con sderaster, consulte Cargar rásteres en ArcSDE con sderaster.

Crear estadísticas

Crear estadísticas en el DBMS y ráster puede mejorar el rendimiento y la apariencia de la visualización de ráster.

No siempre es necesario crear estadísticas DBMS; sin embargo, todos los DBMS de ArcSDE admitidos utilizan una optimización basada en coste. La optimización basada en coste utiliza estadísticas previamente recopiladas de los objetos de DBMS para determinar el mejor plan de ejecución. SQL Server recopila estadísticas automáticamente a medida que se cargan los datos, pero para todos los demás DBMS, debe generar estadísticas DBMS al menos en la tabla de bloques.

Para crear las estadísticas DBMS en ArcCatalog, haga lo siguiente:

  1. Haga clic con el botón derecho del ratón en el objeto ráster y, a continuación, haga clic en Analizar.
  2. En el cuadro de diálogo Analizar componentes, asegúrese de que el componente Tabla del ráster esté marcado.
  3. Haga clic en Aceptar.

Puede utilizar la operación sdetable update_dbms_stats para generar estadísticas, como se muestra en el siguiente ejemplo: 

c:\>sdetable -o update_dbms_stats -t earth -m estimate -u mark -p mark -i 9000

El siguiente es un ejemplo de Oracle que genera rápidamente las estadísticas en la tabla de bloques: 

SQL> select rastercolumn_id from sde.raster_columns 			where table_name = 'EARTH';  RASTERCOLUMN_ID -----------------------                       1  SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(NULL, 'SDE)BLK_1; NULL, 1);

Las estadísticas de ráster se pueden generar en los datasets ráster y se almacenan en la tabla AUX de ArcSDE. Las estadísticas de ráster incluyen el valor mínimo, máximo, medio y de desviación estándar. Generar las estadísticas de ráster en el nivel de pirámide básico puede requerir una cantidad significativa de tiempo para datasets ráster muy grandes.

Las estadísticas de ráster son necesarias para los datos que se deben extender estadísticamente antes de que los objetos capturados en el ráster se puedan visualizar.

Para obtener más información sobre cómo generar estadísticas de ráster, consulte Estadísticas de dataset ráster.

Visualizar los datos ráster

Los datos ráster se deben visualizar con la aplicación que se utilizará para el proyecto para el que se diseñó el ráster, como ArcMap, ArcCatalog, ArcGlobe o ArcScene. Si se construyó la pirámide y las estadísticas DBMS son actuales, el ráster se debe visualizar rápidamente.

Si tarda mucho tiempo en visualizarse, el problema por lo general son las estadísticas DBMS no actuales o inexistentes. Es especialmente importante que las estadísticas DBMS existan en la tabla de bloques. Consulte la sección anterior, Crear estadísticas, para obtener instrucciones sobre cómo crear estadísticas DBMS.

Con el advenimiento de la construcción de pirámide parcial, ahora es posible ver un dataset ráster durante una operación de mosaico grande. Sin embargo, mientras visualiza un dataset ráster durante una operación de mosaico, no se alarme si desaparece y reaparece periódicamente cuando se visualiza en baja resolución. Este comportamiento es producto de la construcción de pirámide parcial, como resultado de los niveles superiores actualizados de la pirámide que se elimina y vuelve a insertar.

Temas relacionados

Transferir datasets ráster grandes

Copyright © 1995-2012 Esri. Todos los derechos reservados.
7/11/2012