Más

Error al seleccionar geometría de Oracle DB con ArcSDE

Error al seleccionar geometría de Oracle DB con ArcSDE


Estoy tratando de seleccionar una columna de geometría como texto conocido de una clase de entidad en una geodatabase de Oracle 11g / ArcSDE 10.1. (Esto está en un script de Python usandopypyodbccomo conductor). Este es mi SQL:

SELECCIONE SDE.ST_AsText (SHAPE) FROM OWNER.FEAT_CLASS

Cuando ejecuto esto, obtengo algunos errores de Oracle:

ORA-29900: el enlace del operador no existe  nORA-06553: PLS-306: número o tipos de argumentos incorrectos en la llamada a 'ST_ASTEXT

Encontré este artículo de soporte que dice calificar completamente todas las referencias aST_GEOMETRYoperadores, pero tengo elSDEprefijo, así que no estoy seguro de lo que falta. ¿Alguien tiene alguna idea al respecto?

ACTUALIZAR: Si solo selecciono elFORMAcampo sin ninguna función SDE obtengoDecimal ('214'). Curiosamente, ese también es el ID del objeto.


Para encontrar la tabla Fn donde se almacenan los puntos reales, puede

seleccione object_id de sde.column_registry donde table_name = 'MYTABLE' y column_name = 'SHAPE';

La geometría se almacenará en la tabla Fxxxx con xxxx = object_id.


Opciones de la herramienta de refactorización de base de datos de ArcSDE

Estamos usando liquibase como una herramienta de gestión de cambios de base de datos evolutiva en nuestras aplicaciones, funciona muy bien cuando lo usamos en esquemas de bases de datos "comunes".

Pero también trabajamos con aplicaciones GIS usando la plataforma esri arcSDE 9.3 sobre Oracle y en este caso, todas (o casi todas) las tablas (tanto GIS como tablas 'alfanuméricas') en el esquema se administran (crear tabla, concesiones, etc.) a través de arcSDE. Entonces, cuando queremos crear una nueva clase de características, ahora usamos arcCatalog, y de esta manera, no es posible administrar los cambios de las clases de características directamente a través de SQL usando liquibase u otra herramienta de refactorización automática.

Entonces, si no podemos usar liquibase para administrar los cambios, al menos queremos ejecutar las operaciones de administración sobre nuestras funciones a través de la línea de comandos. Comenzamos a buscar herramientas que eviten el uso de arcCatalog y luego intentamos automatizar los cambios usando scripts, estamos investigando estas posibilidades:

Intente capturar el SQL que arcCatalog / arcSDE está ejecutando cada vez que hacemos un cambio en una Clase de Característica que monitorea la conexión de Oracle. Nos da como resultado un conjunto demasiado complejo de instrucciones SQL que involucra índices, tablas de versiones, etc., por lo que nos rendimos de esta manera.

Utilice los comandos de administración sdelayer y sdetable instalados en el servidor arcSDE.

Use la herramienta de administración de datos: una biblioteca basada en Python para administrar las clases de entidades, pero debe ejecutarse desde una máquina con la versión de escritorio instalada.

Estas dos últimas opciones proporcionarán una forma de administrar funciones desde la línea de comandos, pero nuestro objetivo es encontrar / desarrollar una herramienta para administrar cambios similar a la forma en que lo hace liquibase. Pero con estas herramientas tendremos que encontrar una herramienta que nos permita mapear cada operación SQL DDL a un comando arcSDE, y actualmente ninguna herramienta de refactorización db proporciona esto (actualmente tenemos check liquibase, dbdeploy, flyway).

¿Alguien había resuelto este problema de la gestión del cambio evolutivo con arcSDE? ¿Alguna idea de otra forma de afrontar este problema?


Cómo almacena ST_Geometry datos espaciales

La siguiente es la descripción de Oracle de ST_Geometry:

Nombre Escribe
ENTIDAD NÚMERO (38)
NUMPTOS NÚMERO (38)
MARTA FLOTADOR (64)
MINY FLOTADOR (64)
MAXX FLOTADOR (64)
MAXY FLOTADOR (64)
MINZ FLOTADOR (64)
MAXZ FLOTADOR (64)
MINM FLOTADOR (64)
MAXM FLOTADOR (64)
ZONA FLOTADOR (64)
LEN FLOTADOR (64)
SRID NÚMERO (38)
PUNTOS GOTA

Los atributos del tipo espacial representan la siguiente información:

    Entidad & # 8212 El tipo de característica geométrica almacenada en la columna espacial (cadena lineal, multilínea, multipunto, multipolígono, punto o polígono), cuyo valor es una máscara de bits derivada del procedimiento almacenado st_geom_util

Como otros tipos de objetos, el tipo de datos ST_Geometry contiene un método constructor y funciones. Un método constructor es una función que devuelve una nueva instancia (objeto) del tipo de datos y establece los valores de sus atributos.

El nombre del constructor es el mismo que el del tipo (ST_Geometry). Cuando crea una instancia de un objeto del tipo ST_Geometry, invoca el método constructor. Por ejemplo:

Las siguientes son funciones de acceso de ST_Geometry que toman un solo ST_Geometry como entrada y devuelven el valor de propiedad solicitado como un número.

    La función miembro ST_Area devuelve el área de una geometría.

Por ejemplo, la siguiente consulta devuelve el nombre y el área de los estados individuales de Estados Unidos.

ST_LineString, ST_MultiLineString, ST_MultiPoint, ST_MultiPolygon, ST_Point y ST_Polygon son todos subtipos (o subclases) de ST_Geometry. ST_Geometry y sus subtipos comparten atributos y funciones comunes. La definición del constructor para ST_LineString, ST_MultiLineString, ST_MultiPoint, ST_MultiPolygon, ST_Point y ST_Polygon es la misma. El nombre del constructor es el mismo que el tipo que construye.

Dado que ST_Point es un objeto finito (un valor de un solo punto), también se puede crear utilizando uno de los siguientes métodos.

Este método utiliza puntos de coordenadas y un SRID.

Este método permite al usuario especificar puntos de coordenadas y un valor de elevación para cada punto.

Este último método para ST_Point permite además especificar un valor de medida como parte del objeto puntual creado.

SP_Grid_Info se utiliza como tipo de datos para el campo GRID en la tabla ST_Geometry_Index. Contiene la información a nivel de cuadrícula para índices espaciales.

Para instalar ArcSDE y usar el tipo ST_Geometry y el índice de dominio en el DBMS de Oracle, el usuario administrador de ArcSDE debe tener los privilegios de sistema adecuados para crear instancias de tipos, operadores y procedimientos almacenados. Consulte Permisos de usuario para geodatabases en Oracle para obtener información sobre los permisos necesarios.

Esquema de metadatos

El tipo espacial para los tipos de Oracle y las tablas de metadatos son propiedad del esquema SDE. La definición del esquema es la descripción de la tabla base para las tablas de metadatos que se utilizan para definir y describir el tipo de columna / tabla, índice espacial e información de referencias espaciales. El término tipo se refiere al tipo espacial ST_Geometry. El índice espacial se refiere al índice de dominio ST_Spatial_Index. Todas las definiciones de tipo y tipo de índice de dominio, paquetes y tablas de metadatos se crean en el esquema SDE.

Las vistas también tendrán el prefijo ST_, incluidas las vistas de OpenGIS en GEOMETRY_COLUMNS y SPATIAL_REFERENCES.

Debido a que las definiciones de ST_Geometry pertenecen al usuario de SDE, nunca debe eliminar el usuario de SDE de la base de datos si todavía tiene tablas en la base de datos que contienen columnas ST_Geometry. Hacerlo hará que esas tablas sean inaccesibles.

Como se menciona en la Guía para desarrolladores de aplicaciones de Oracle, cuando un usuario se elimina de la base de datos, una de las sentencias de eliminación ejecutadas es DROP TYPE con la opción FORCE. Esta declaración elimina todos los tipos que pertenecen a ese usuario, de modo que el usuario puede eliminarse de la base de datos. DROP TYPE FORCE hace que los tipos se descarten incluso si tienen tipos dependientes o tablas asociadas. Una vez que eso sucede, las tablas asociadas se marcan como inválidas, lo que hace que los datos de las tablas sean inaccesibles.

Para obtener una descripción de cada tabla, consulte las tablas enumeradas en Tablas del sistema de una geodatabase almacenada en Oracle. Las tablas son las siguientes:


Oracle Spatial es una opción para Oracle Database que proporciona funciones espaciales avanzadas para admitir sistemas de información geográfica (GIS) de alta gama y soluciones de inteligencia empresarial (LBS) habilitadas para la ubicación.

Oracle Spatial es un cartucho de datos opcional que le permite escribir consultas y vistas de Oracle CQL que interactúan sin problemas con las clases de Oracle Spatial en su aplicación de Oracle CEP.

Con Oracle Spatial, puede configurar consultas de Oracle CQL que realizan las operaciones de dominio geográfico más importantes, como almacenar datos espaciales, realizar comparaciones de proximidad y superposición en datos espaciales e integrar datos espaciales con el servidor de Oracle CEP al proporcionar la capacidad de indexar datos espaciales. datos.

Para utilizar Oracle Spatial, necesita un conocimiento práctico de la API de Oracle Spatial. Para obtener más información sobre Oracle Spatial, consulte:

16.1.1 Nombre del cartucho de datos

Oracle Spatial utiliza el ID de cartucho com.oracle.cep.cartrdiges.spatial y registra el nombre de enlace reservado en el ámbito del servidor espacial.

Utilice el nombre del enlace espacial para asociar una llamada al método Oracle Spatial con el contexto de la aplicación Oracle Spatial.

16.1.2 Alcance

Oracle Spatial se basa en la API de Oracle Spatial Java. Oracle Spatial expone la funcionalidad de Oracle Spatial en la clase com.oracle.cep.cartridge.spatial.Geometry. La funcionalidad de Oracle Spatial que no está en la API de Oracle Spatial Java no es accesible desde Oracle Spatial.

Con Oracle Spatial, sus consultas de Oracle CQL pueden acceder a la funcionalidad de Oracle Spatial que describe la Tabla 16-1.

Tabla 16-1 Alcance espacial de Oracle

Los siguientes tipos de geometría de la API de Oracle Spatial Java:

Las siguientes operaciones de geometría:

Acceder a las funciones de miembros públicos de tipo geometría y a los campos públicos

Coordenadas geodésicas cartesianas y WGS84 (por defecto)

Especificar el sistema de coordenadas predeterminado a través de SRID

Usando otras coordenadas geodésicas

Operadores de relaciones geométricas

Operadores de filtros geométricos

Para obtener una lista completa de los métodos que proporciona com.oracle.cep.cartridge.spatial.Geometry, consulte la Sección 16.1.2.7, "API de geometría".

Para obtener más información sobre cómo acceder a estas funciones de Oracle Spatial mediante Oracle Spatial, consulte la Sección 16.2, "Utilización de Oracle Spatial".

16.1.2.1 Tipos de geometría

El modelo de datos de Oracle Spatial consta de geometrías. Una geometría es una secuencia ordenada de vértices. La semántica de la geometría está determinada por su tipo.

Oracle Spatial le permite acceder a los siguientes tipos de Oracle Spatial directamente en consultas y vistas de Oracle CQL:

SDO_GTYPES: Oracle Spatial admite los siguientes tipos de geometría:

La Tabla 16-2 describe los tipos de geometría de la clase com.oracle.cep.cartridge.spatial.Geometry que puede utilizar.

Tabla 16-2 Tipos de geometría espacial de Oracle

Tipo de geometría de punto que contiene un punto.

Tipo de geometría de polígono que contiene un polígono.

SDO_ELEMENT_INFO: Puede crear la matriz de información del elemento usando:

método estático com.oracle.cep.cartridge.spatial.Geometry.createElemInfo

ORDENADAS: Puede crear las ordenadas utilizando la función ordsgenerator de Oracle Spatial.

16.1.2.2 Matriz de información de elementos

El atributo de información del elemento se define mediante una matriz de números de longitud variable. Este atributo especifica cómo interpretar las ordenadas almacenadas en el atributo Ordinates.

Oracle Spatial proporciona la siguiente función auxiliar para generar valores de atributo de información de elemento:

También puede utilizar la función einfogenerator.

16.1.2.3 Ordenadas y sistemas de coordenadas y SDO_SRID

La Tabla 16-3 enumera los sistemas de coordenadas que Oracle Spatial admite de forma predeterminada y el valor SDO_SRID que identifica cada sistema de coordenadas.

Tabla 16-3 Sistemas de coordenadas espaciales de Oracle

Las coordenadas cartesianas son coordenadas que miden la posición de un punto desde un origen definido a lo largo de ejes que son perpendiculares en el espacio representado.

Las coordenadas geodésicas (a veces llamadas coordenadas geográficas) son coordenadas angulares (longitud y latitud), estrechamente relacionadas con las coordenadas polares esféricas, y se definen en relación con un datum geodésico de la Tierra en particular.

Este es el sistema de coordenadas predeterminado en Oracle Spatial.

Puede especificar el valor SDO_SRID como un argumento para cada método y constructor de Oracle Spatial que llame o puede configurar SDO_SRID en el contexto de la aplicación de Oracle Spatial una vez y usar los métodos com.oracle.cep.cartridge.spatial.Geometry sin tener que configurar el SDO_SRID como argumento cada vez. Utilizando el contexto de la aplicación, también puede especificar cualquier sistema de coordenadas que admita Oracle Spatial.

Si usa un método com.oracle.cep.cartridge.spatial.Geometry que no toma un valor SDO_SRID, entonces debe usar el contexto de la aplicación Oracle Spatial. Por ejemplo, la siguiente llamada al método provocará una excepción en tiempo de ejecución:

En su lugar, debe utilizar el nombre del enlace espacial para asociar la llamada al método con el contexto de la aplicación Oracle Spatial:

Si usa un método de geometría que toma un valor SDO_SRID, entonces el uso del nombre del enlace espacial es opcional. Por ejemplo, las dos llamadas a métodos siguientes son válidas:

Las ordenadas definen la matriz de coordenadas de una geometría mediante una matriz doble. Oracle Spatial proporciona la función auxiliar ordsgenerator para generar la matriz de coordenadas. Para conocer la sintaxis, consulte "ordsgenerator".

"Sistemas de coordenadas (sistemas de referencia espacial)" en la Guía del desarrollador espacial de Oracle

16.1.2.4 Índice geométrico

Oracle Spatial utiliza un índice espacial para implementar el filtro principal. El propósito del índice espacial es crear rápidamente un subconjunto de datos y reducir la carga de procesamiento en el filtro secundario.

Un índice espacial, como cualquier otro índice, proporciona un mecanismo para limitar las búsquedas, pero en este caso el mecanismo se basa en criterios espaciales como la intersección y la contención.

Oracle Spatial utiliza la indexación R-Tree para el mecanismo de indexación predeterminado. Un índice de árbol R espacial puede indexar datos espaciales de hasta cuatro dimensiones. Un índice de árbol R aproxima cada geometría por un solo rectángulo que encierra mínimamente la geometría (llamado Rectángulo de Límite Mínimo, o MBR)

16.1.2.5 Operadores de relaciones geométricas

Oracle Spatial admite los siguientes operadores de relaciones geométricas de Oracle Spatial:

Puede utilizar cualquiera de estos operadores en la cláusula de proyección de consultas de Oracle CQL o en la cláusula where.

Cuando utiliza un operador de relación geométrica en la cláusula where de una consulta CQL de Oracle, Oracle Spatial habilita la indexación de Rtree en la relación especificada en la cláusula where.

Oracle Spatial solo admite relaciones geométricas entre puntos y otros tipos de geometría.

16.1.2.6 Operadores de filtros geométricos

Oracle Spatial admite los siguientes operadores de filtros geométricos de Oracle Spatial:

Estos operadores de filtro realizan un filtrado primario y, por lo tanto, solo pueden aparecer en una cláusula where de consulta de Oracle CQL.

Estos operadores de filtro utilizan el índice espacial para identificar el conjunto de objetos espaciales que es probable que interactúen espacialmente con el objeto dado.

16.1.2.7 API de geometría

Oracle Spatial se basa en la API de Oracle Spatial Java. Oracle Spatial expone la funcionalidad de Oracle Spatial en la clase com.oracle.cep.cartridge.spatial.Geometry. Esta clase de geometría también amplía oracle.spatial.geometry.J3D_Geometry.

Aunque Oracle Spatial solo admite geometrías 2D, para mayor eficiencia, la clase Geometry usa algunos métodos J3D_Geometry. La clase Geometry pone automáticamente en cero las coordenadas Z para los métodos J3D_Geometry.

La funcionalidad de Oracle Spatial inaccesible desde la clase Geometry (o que no cumple con los tipos de alcance y geometría que admite Oracle Spatial) es inaccesible desde Oracle Spatial.

Para simplificar los nombres de tipos de Oracle Spatial, puede utilizar alias como se describe en la Sección 2.8.2, "Definición de alias mediante el elemento Aliases".


Parámetros de configuración de Oracle DBTUNE

Los parámetros de configuración, que se almacenan en la columna nombre_parámetro de la tabla DBTUNE, identifican el objeto de la base de datos que se va a configurar o denotan una configuración específica. Sus valores correspondientes, que se almacenan en la columna config_string de DBTUNE, identifican cómo se configurará el objeto o la configuración. Los parámetros y sus cadenas de configuración se agrupan en la tabla DBTUNE por palabras clave de configuración. Las combinaciones de palabra clave / nombre de parámetro son únicas, pero la mayoría de los nombres de parámetro no lo son y se reutilizan bajo varias palabras clave diferentes en toda la tabla DBTUNE.

Los valores válidos para la columna nombre_parámetros son fijos; no puede inventar nuevos nombres_parámetros. Asimismo, config_strings acepta solo ciertos valores numéricos o cadenas SQL. En la mayoría de los casos, estas cadenas se añaden a las sentencias CREATE TABLE y CREATE INDEX de SQL.

En las geodatabases almacenadas en una base de datos de Oracle, ArcSDE utiliza el nombre de parámetro y los pares de cadenas de configuración # 8211 para los siguientes propósitos:

    Establecer las características de almacenamiento de tablas e índices.

De forma predeterminada, Oracle almacena tablas e índices en el espacio de tabla predeterminado del usuario utilizando los parámetros de almacenamiento predeterminados del espacio de tabla. Puede determinar el espacio de tabla predeterminado de un usuario consultando el campo DEFAULT_TABLESPACE de la tabla del sistema de Oracle USER_USERS cuando está conectado como ese usuario. Como administrador de la base de datos de Oracle (DBA), consulte el campo DEFAULT_TABLESPACE de la tabla DBA_USERS utilizando una cláusula WHERE para especificar el usuario.

Obtenga una lista de parámetros de almacenamiento predeterminados para un espacio de tabla consultando USER_TABLESPACES:

Para especificar diferentes espacios de tabla mediante palabras clave de configuración, debe descomentar algunos parámetros en DEFAULTS y otras palabras clave de configuración en el archivo dbtune y editar las cadenas de configuración asociadas para especificar un nombre de espacio de tabla. Las líneas comentadas están precedidas por un único signo de almohadilla (#). Elimine este signo de almohadilla y reemplace & lttext & gt con el nombre del espacio de tabla correcto. Luego importe el archivo dbtune a la tabla DBTUNE. Luego, los usuarios pueden especificar esa palabra clave (o aceptar los DEFAULTS) y las tablas e índices de los conjuntos de datos que crean se almacenarán en el espacio de tabla que especificó en el archivo dbtune.

Consulte El archivo dbtune y la tabla DBTUNE para obtener información específica sobre cómo editar el archivo y la tabla dbtune.

La siguiente tabla es una lista alfabética de todos los posibles parámetros de configuración que se pueden usar en una geodatabase en Oracle. A continuación, encontrará una explicación más detallada de los parámetros agrupados por su funcionalidad, seguida de una lista de parámetros que son específicos de las geodatabases de ArcSDE almacenadas en Oracle Spatial.

    La distancia entre dos ordenadas puede estar separada en la dimensión dada y aún así considerarse la misma

    Límite de dimensión superior para el tipo de geometría espacial de Oracle

    NINGUNO & # 8212 Actualización manual ejecutando el paquete de texto de Oracle (predeterminado)

NOTA: Para los parámetros XML, & ltn & gt se refiere al xml_column_id asociado con una columna XML específica.

Descripciones funcionales de parámetros

    Parámetros de almacenamiento de índices y tablas de negocios

Una tabla de negocios es cualquier tabla de Oracle creada por un cliente de ArcSDE, el comando de administración sdetable o la función SE_table_create de la interfaz de programación de aplicaciones (API) de ArcSDE C.

Utilice el parámetro B_STORAGE de la tabla DBTUNE para definir la configuración de almacenamiento de una tabla de negocios.

Existen cinco parámetros de almacenamiento de índices para admitir la creación de índices de tablas de negocios.

El parámetro B_INDEX_USER contiene la configuración de almacenamiento para los índices definidos por el usuario creados con la función de API C SE_table_create_index y la operación create_index del comando sdetable.

El parámetro B_INDEX_ROWID contiene la configuración de almacenamiento del índice que ArcSDE crea en la columna de ID de objeto de una tabla de registro, comúnmente conocida como ROWID u OBJECTID.

NOTA: ArcSDE registra todas las tablas que crea. Las tablas no creadas por ArcSDE también se pueden registrar con los comandos sdetable o sdelayer. La tabla del sistema TABLE_REGISTRY mantiene una lista de las tablas registradas actualmente.

El parámetro B_INDEX_SHAPE contiene la configuración de almacenamiento del índice de columna espacial que ArcSDE crea cuando se agrega una columna espacial a una tabla de negocios. Este índice es creado por la función SE_layer_create de la API de ArcSDE C. ArcGIS llama a esta función cuando crea una clase de entidad y mediante la operación de adición del comando sdelayer.

El parámetro B_INDEX_RASTER contiene la configuración de almacenamiento del índice de columna ráster que ArcSDE crea cuando se agrega una columna ráster a una tabla de negocios. Este índice es creado por la función SE_rastercolumn_create de la API de ArcSDE C. ArcGIS llama a esta función cuando crea una clase de entidad y las operaciones de agregar, copiar e importar del comando sderaster.

El parámetro B_INDEX_TO_DATE especifica el almacenamiento del índice R & ltregistration_id & gt_sde_todate. Este índice se crea cuando el archivado está habilitado en una tabla de negocios y se utiliza al actualizar la tabla del historial durante una operación de archivado.

El registro de una tabla de negocios como versionada permite a varios usuarios mantener y editar un objeto. A intervalos apropiados, los usuarios fusionan los cambios que han realizado con los cambios realizados por otros usuarios y concilian cualquier conflicto que surja cuando se modifican las mismas filas.

ArcSDE crea dos tablas & # 8212la tabla de adiciones y la tabla de eliminaciones & # 8212 para cada tabla que se registra como versionada.

El parámetro A_STORAGE mantiene la configuración de almacenamiento de la tabla de adiciones. Otros cuatro parámetros de almacenamiento contienen la configuración de almacenamiento de los índices de la tabla de adiciones. La tabla de adiciones se llama A & ltn & gt, donde & ltn & gt es el ID de registro que aparece en la tabla del sistema TABLE_REGISTRY. Por ejemplo, si la tabla de negocios ROADS aparece con un ID de registro de 10, ArcSDE crea la tabla de adiciones como A10.

El parámetro A_INDEX_RASTER especifica la configuración de almacenamiento del índice que se crea en una columna ráster en la tabla de adiciones. El índice se llama SDE_RIX_ & ltN & gt_A. & ltN & gt es el ID de la columna ráster.

El parámetro A_INDEX_ROWID contiene la configuración de almacenamiento del índice que ArcSDE crea en la columna de ID de objeto multiversionado, también conocida como ROWID. El índice ROWID de la tabla de adiciones se denomina A & ltn & gt_ROWID_IX1, donde & ltn & gt es el ID de registro de la tabla de negocios con el que está asociada la tabla de adiciones.

El parámetro A_INDEX_STATEID contiene la configuración de almacenamiento del índice que ArcSDE crea en la columna SDE_STATE_ID de la tabla de adiciones. El índice de la columna SDE_STATE_ID se denomina A & ltn & gt_STATE_IX2, donde & ltn & gt es el ID de registro de la tabla de negocios con el que está asociada la tabla de adiciones.

El parámetro A_INDEX_SHAPE contiene la configuración de almacenamiento del índice que ArcSDE crea en la columna espacial de la tabla de adiciones. Si la tabla de negocios contiene una columna espacial, la columna y el índice que contiene se duplican en la tabla de adiciones. El índice de columna espacial de la tabla de adiciones se llama A & ltn & gt_IX1_A, donde & ltn & gt es el ID de capa de la clase de entidad tal como aparece en la tabla LAYERS.

El parámetro A_INDEX_USER contiene la configuración de almacenamiento de índices definidos por el usuario que ArcSDE crea en la tabla de adiciones. Los índices definidos por el usuario en las tablas de negocios están duplicados en la tabla de adiciones.

El parámetro D_STORAGE contiene la configuración de almacenamiento de la tabla de eliminaciones. Otros dos parámetros de almacenamiento contienen la configuración de almacenamiento de los índices que ArcSDE crea en la tabla de eliminaciones. La tabla de eliminaciones se denomina D & ltn & gt, donde & ltn & gt es el ID de registro que aparece en la tabla del sistema TABLE_REGISTRY. Por ejemplo, si la tabla de negocios ROADS aparece con un ID de registro de 10, ArcSDE crea la tabla de eliminaciones como D10.

El parámetro D_INDEX_STATE_ROWID contiene la configuración de almacenamiento del índice D & ltn & gt_IDX1 que ArcSDE crea en las columnas SDE_STATE_ID y SDE_DELETES_ROW_ID de la tabla de eliminaciones.

El parámetro D_INDEX_DELETED_AT contiene la configuración de almacenamiento del índice D & ltn & gt_IDX2 que ArcSDE crea en la columna SDE_DELETED_AT de la tabla de eliminaciones.

Para obtener más información sobre la estructura de las tablas agregadas y eliminadas y cómo se utilizan, consulte Tablas con versiones en una geodatabase en Oracle.

Una clase de entidad creada con el almacenamiento ST_Geometry agrega una tabla de índice espacial a la base de datos de Oracle. Esta tabla de índice espacial se denomina S & ltn & gt_IDX $, donde & ltn & gt es el valor del índice de geometría. Esta tabla es una tabla organizada indexada de Oracle (IOT).

Si crea tablas de negocios particionadas que contienen una columna ST_Geometry, también querrá particionar el índice espacial. Hay dos tipos de métodos de particionamiento: global y local. De forma predeterminada, los índices particionados globales se crean en tablas de negocios particionadas. Para crear un índice particionado local en su lugar, debe agregar la palabra clave LOCAL al final de la instrucción CREATE INDEX. Para permitir que ArcGIS agregue LOCAL al final de la declaración CREATE INDEX para el índice espacial, establezca el parámetro ST_INDEX_PARTITION_LOCAL en TRUE bajo la palabra clave DEFAULTS.

Sin embargo, si la tabla de negocios con la columna ST_Geometry no está particionada y establece ST_INDEX_PARTITION_LOCAL en TRUE, obtendrá el siguiente mensaje de error:

Una clase de entidad creada con un formato de almacenamiento binario comprimido de ArcSDE (tipo de datos LONGRAW o BLOB) agrega dos tablas a la base de datos de Oracle: la tabla de entidades y la tabla de índice espacial. La tabla de índice espacial se crea como S_ & ltn & gt, donde & ltn & gt es el ID de capa de la clase de entidad de la tabla de índice espacial como se encuentra en la tabla LAYERS. Se crean tres índices en la tabla de características y se crean dos índices en la tabla de índice espacial.

Los parámetros de configuración que se aplican a los índices espaciales generalmente comienzan con S_. Los parámetros de almacenamiento para estas tablas e índices siguen el mismo patrón que los parámetros de almacenamiento B_STORAGE y B_INDEX_ * de la tabla de negocios.

El parámetro S_STORAGE contiene la configuración de almacenamiento de Oracle CREATE TABLE de la tabla de índice espacial y sus índices para ST_Geometry y almacenamiento binario.

El parámetro S_INDEX_ALL solo se aplica al almacenamiento binario y contiene la configuración de almacenamiento de Oracle CREATE INDEX del primer índice de la tabla espacial. La tabla de índice espacial se crea como S_ & ltn & gt_IX1, donde & ltn & gt es el ID de capa de la clase de entidad del índice que se encuentra en la tabla LAYERS.

El parámetro S_INDEX_SP_FID contiene la configuración de almacenamiento CREATE INDEX de Oracle del segundo índice de la tabla espacial si se utilizó almacenamiento binario para la clase de entidad. La tabla de índice espacial se crea como S_ & ltn & gt_IX2, donde & ltn & gt es el ID de capa de la clase de entidad del índice que se encuentra en la tabla LAYERS.

Los parámetros de la clase de entidad solo se aplican cuando se usa almacenamiento binario. Estos parámetros comienzan con F_

El parámetro F_STORAGE contiene la cadena de configuración de almacenamiento Oracle CREATE TABLE de la tabla de características. La tabla de entidades se crea como F_ & ltn & gt, donde & ltn & gt es el ID de capa de la clase de entidad de la tabla como se encuentra en la tabla LAYERS.

El parámetro F_INDEX_FID contiene la cadena de configuración de almacenamiento de Oracle CREATE INDEX del índice de columna espacial de la tabla de características. La columna espacial se crea como F & ltn & gt_UK1, donde & ltn & gt es el ID de capa de la clase de entidad del índice como se encuentra en la tabla LAYERS.

El parámetro F_INDEX_AREA contiene la configuración de almacenamiento de Oracle CREATE INDEX del índice de la columna del área de la tabla de características. La columna espacial se crea como F & ltn & gt_AREA_IX2, donde & ltn & gt es el ID de capa de la clase de entidad del índice como se encuentra en la tabla LAYERS.

El parámetro F_INDEX_LEN contiene la configuración de almacenamiento de Oracle CREATE INDEX del índice de columna de longitud de la tabla de características. La columna espacial se crea como F & ltn & gt_LEN_IX3, donde & ltn & gt es el ID de capa de la clase de entidad del índice como se encuentra en la tabla LAYERS.

Para obtener información sobre las tablas de estructura F y S de clases de entidad binaria en Oracle, consulte Clases de entidad en una geodatabase en Oracle en la sección "Esquema y almacenamiento de datos de geodatabase" de la ayuda.

Para obtener información sobre las opciones disponibles para el almacenamiento de geometría de clase de entidad, consulte la sección de este tema "Parámetro de almacenamiento de geometría" y el tema Acerca de los tipos de almacenamiento de geometría.

Una columna ráster agregada a una tabla de negocios es en realidad una referencia de clave externa a los datos ráster almacenados en un esquema que consta de cuatro tablas y cinco índices de soporte. Los parámetros de la tabla ráster definen la configuración de las tablas e índices ráster.

El parámetro RAS_STORAGE contiene la configuración de almacenamiento de Oracle CREATE TABLE de la tabla RAS.

El parámetro RAS_INDEX_ID contiene la configuración de almacenamiento de Oracle CREATE INDEX del índice de la tabla RAS.

El parámetro BND_STORAGE contiene la configuración de almacenamiento de Oracle CREATE TABLE de la tabla BND.

El parámetro BND_INDEX_COMPOSITE contiene la configuración de almacenamiento de Oracle CREATE INDEX del índice de columna compuesta de la tabla BND.

El almacenamiento BND_INDEX_ID contiene la configuración de almacenamiento de Oracle CREATE INDEX del índice de columna de ID de fila (RID) de la tabla BND.

El parámetro AUX_STORAGE contiene la configuración de almacenamiento de Oracle CREATE TABLE de la tabla AUX.

El parámetro AUX_INDEX_COMPOSITE contiene la configuración de almacenamiento de Oracle CREATE INDEX del índice de la tabla AUX.

El parámetro BLK_STORAGE contiene la configuración de almacenamiento de Oracle CREATE TABLE de la tabla BLK.

El parámetro BLK_INDEX_COMPOSITE contiene la configuración de almacenamiento de Oracle CREATE TABLE del índice de la tabla BLK.

El parámetro RASTER_STORAGE define qué tipo de datos se utiliza para almacenar datos ráster. ArcSDE proporciona tres formatos de almacenamiento ráster para Oracle. El parámetro RASTER_STORAGE indica qué método de almacenamiento de geometría se utilizará. El parámetro RASTER_STORAGE tiene los siguientes valores:

    Ráster de ArcSDE almacenado como un tipo de datos BLOB & # 8212 Este es el método de almacenamiento de ráster predeterminado de ArcSDE para Oracle.

Establezca el parámetro RASTER_STORAGE en BLOB si desea almacenar sus datos ráster en este formato. Si desea que este formato sea el predeterminado, establezca el parámetro RASTER_STORAGE en BLOB en la palabra clave de configuración DEFAULTS. Si no se establece el parámetro RASTER_STORAGE, se asume el formato BLOB.

Establezca el parámetro RASTER_STORAGE en LONGRAW si desea almacenar sus datos ráster en este formato.

NOTA: No se recomienda utilizar el almacenamiento LONGRAW porque Oracle ha dejado de admitir este tipo de datos a partir de la versión 11g.

Si desea que la mayoría de las columnas ráster de su base de datos utilicen el mismo formato de almacenamiento ráster, configure el parámetro RASTER_STORAGE una vez en la palabra clave de configuración DEFAULTS. Por ejemplo, para cambiar el RASTER_STORAGE predeterminado de BLOB a SDO_GEORASTER, se realiza el siguiente cambio:

El parámetro RASTER_STORAGE reemplaza al RASTER_BINARY_TYPE, que continúa funcionando pero ya no es compatible.

NOTA: Si especifica SDO_GEORASTER para el parámetro RASTER_STORAGE, no puede establecer GEOMETRY_STORAGE en SDO_GEOMETRY o ST_GEOMETRY.

Para obtener más información sobre el almacenamiento de ráster en la geodatabase, consulte Datasets ráster y catálogos de ráster en una geodatabase almacenada en Oracle en la sección "Esquema y almacenamiento de datos de geodatabase" de la ayuda.

Hay un tipo adicional de tabla ráster & # 8212la tabla de atributos ráster. Estas tablas almacenan valores de atributos basados ​​en valores de celda en el ráster. El parámetro B_STORAGE define el almacenamiento de estas tablas. Si necesita definir una ubicación de almacenamiento diferente para estas tablas que para otras tablas de negocios de clase de entidad, asegúrese de crear una palabra clave ráster que pueda usar al crear datasets ráster y catálogos ráster que especifique diferente información de almacenamiento para las tablas de atributos ráster.

Para obtener más información sobre las tablas de atributos de ráster, consulte Tablas de atributos de dataset ráster en la sección "Administración de datos de imágenes y ráster" de la ayuda. Para aprender a crear palabras clave de configuración personalizadas, consulte Palabras clave de configuración DBTUNE.

ArcSDE para Oracle proporciona cinco formatos de almacenamiento de datos espaciales. El parámetro GEOMETRY_STORAGE indica qué método de almacenamiento de geometría se utilizará. Debe establecer el parámetro GEOMETRY_STORAGE en la palabra clave de configuración DEFAULTS para reflejar el tipo de almacenamiento de geometría con el que se crearán la mayoría de sus clases de entidad.

El parámetro GEOMETRY_STORAGE tiene los siguientes valores posibles:

    ST_Geometry para Oracle & # 8212 Este tipo extiende la base de datos para incluir un tipo de datos ST_GEOMETRY. Set the GEOMETRY_STORAGE parameter to ST_GEOMETRY if you want to store your spatial data in this format. (Beginning with ArcSDE 9.3, if the GEOMETRY_STORAGE parameter is not set, ST_GEOMETRY format is assumed.)

Set the GEOMETRY_STORAGE parameter to SDELOB if you want to store your spatial data in this format. If you want to make this format the default, set the GEOMETRY_STORAGE parameter to SDELOB in the DEFAULTS configuration keyword.

NOTE: Oracle has deprecated the LONG RAW storage type. For this reason, it is recommended you not use SDEBINARY storage for new feature classes. To migrate existing feature classes from LONG RAW to BLOB or ST_GEOMETRY, see Migrating Oracle data from one storage type to another in the "Geodatabase data storage and schema" section of the help.

Set the GEOMETRY_STORAGE parameter to SDO_GEOMETRY if you want to store your spatial data in this format. If you want to make this format the default, set the GEOMETRY_STORAGE parameter to SDO_GEOMETRY in the DEFAULTS configuration keyword.

Set the GEOMETRY_STORAGE parameter to OGCWKB if you want to store your spatial data in this format. If you want to make this format the default, set the GEOMETRY_STORAGE parameter to OGCWKB in the DEFAULTS configuration keyword.

See About geometry storage types for more information on geometry storage types in Oracle.

NOTE: The ArcSDE for Oracle Windows installation includes several versions of the dbtune file each specifies a different geometry storage in the DEFAULTS keyword. If you are performing a new installation of ArcSDE for Oracle (not upgrading the database), you can use one of the alternate versions of the file to populate your DBTUNE table during the postinstallation setup if you want your default geometry storage to be a type other than ST_GEOMETRY.

NOTE: If you do not use XML columns and XML documents in your geodatabase, you don't need to configure these parameters.

An XML column may have two text indexes associated with it: one for the XML document table and one for the XML index table.

To successfully create an XML column, the XML_IDX_INDEX_TEXT parameter must have an appropriate value. This value is used in the PARAMETERS clause when creating the XML column's context text indexes. An appropriate value for the XML_IDX_INDEX_TEXT parameter is not the same as the values that are used for other DBTUNE parameters used to create other types of indexes.

The value in the PARAMETERS clause controls the storage parameters for the text indexes, the language of linguistic analysis for indexing and searching text in the XML documents, the schedule with which the text indexes are updated, and other settings that are specific to text indexes.

XML documents are stored in as large objects (LOBs) in the XML document table in the XML_DOC and XML_DOC_VAL columns and in the XML index table in the TEXT_TAG column. It is important to configure these columns accurately to achieve the best possible search performance.

LOBs are stored in line if the LOB data is stored in the same block as the rest of the data in the row. However, in-line storage is only possible if the LOB data is less than 4 KB in size. With out-of-line storage, the data is stored in the LOB segment and only the LOB locator is stored with the rest of the data in the row.

You can specify whether LOB data associated with an XML column is stored in line or out of line using the ArcSDE DBTUNE parameters XML_DOC_LOB_STORAGE and XML_DOC_VAL_LOB_STORAGE and XML_IDX_TEXT_TAG_STORAGE. Append the value "DISABLE STORAGE IN ROW" to store the data out of line, or "ENABLE STORAGE IN ROW" to store the data in line.

When LOB data is stored out of line for an XML column, by default, ArcSDE places that data in the same tablespace as the XML document table. The LOB data may be moved to a different tablespace than the one containing the XML document table.

A typical XML document that contains metadata describing a GIS resource will be greater than 4 KB in size. Tests show XML columns associated with ArcIMS Metadata Services perform best when the LOB data is stored out of line in a separate tablespace from the XML document table. However, a metadata service may contain gazetteer data instead of typical metadata XML documents. Gazetteer data is very small, typically less than 100 bytes in size. Metadata services containing gazetteer data will perform best when the LOB data is stored in line.

See Configuring an Oracle database to support XML columns for information on using XML columns in your geodatabase.

Log file tables are used by ArcSDE to maintain sets of selected records.

Log file parameters affect log file data tables and indexes. They begin with the letter L or SESSION. The parameters are as follows:

LF_STORAGE defines the configuration for the LOGFILES table.

LF_INDEXES configures creation of indexes logfiles_pk and logfiles_uk on the LOGFILES table.

LD_STORAGE defines configuration for the LOGFILE_DATA and LOGPOOL_<SDE_ID> tables.

LD_INDEX_ROWID configures creation of the index LOGFILE_DATA_idx1 on the LOGFILE_DATA table and the index LOGPOOL_<SDE_ID>_idx1 on the LOGPOOL_<SDE_ID> pools table.

LD_INDEX_DATA_ID configures the creation of the LOGFILE_DATA_idx2 index on the LOGFILE_DATA table and of the LOGPOOL_<SDE_ID>_idx1 index on the LOGPOOL_<SDE_ID>.

SESSION_STORAGE defines configuration for the LOGDATA_<SDE_ID>_<Current_standalone_id> stand-alone log table and SESSION_<sde_id> session table.

SESSION_INDEX configures the creation of the LOGDATA_<SDE_ID>_<sde_id>_<Current_standalone_id>_idx1 index for the stand-alone log table and the LOGSESSION_<SDE_ID>_idx1 index on the session table.

SESSION_TEMP_TABLE isn't used in Oracle databases.

For more information on how log file tables are used in the geodatabase, see Log file configuration options.

User interface parameters begin with UI and indicate whether or not their associated configuration keyword will be available through the ArcGIS user interface.

UI_TEXT is used for noncomposite configuration keywords.

UI_TOPOLOGY_TEXT is used for topology keywords.

UI_TERRAIN_TEXT is used for terrain keywords.

UI_NETWORK_TEXT is used for network keywords.

See Making configuration keywords available in ArcGIS for more information on how to use UI parameters.

Periodically compressing the versioned database’s state tree is a required maintenance procedure.

The transactions of the compress operation tend to be large if you are using the Oracle manual undo method, ESRI recommends that you create a separate, large rollback segment to contain the changes. The COMPRESS_ROLLBACK_SEGMENT storage parameter stores the name of a rollback segment that you have created for this purpose. Add the COMPRESS_ROLLBACK_SEGMENT storage parameter to the DEFAULTS configuration keyword.

Beginning with Oracle 10gramo, Oracle does not recommend the use of the manual undo method. See the documentation provided with your Oracle 10gramo installation for details.

ArcSDE defines attribute columns used to store binary data as LONGRAW or as BLOB. The default and recommended setting is BLOB.

If the storage parameter is not set in the DEFAULTS configuration keyword when a dbtune file is imported by the sdedbtune administration tool, ArcSDE inserts the ATTRIBUTE_BINARY storage parameter under the DEFAULTS configuration keyword with a configuration string set to BLOB.

NOTE: Prior to ArcSDE 9.2, LONGRAW was the default value for the ATTRIBUTE_BINARY parameter. When you upgrade an existing ArcSDE geodatabase to a 9.2 or later release, this value is not changed in the DBTUNE table. To make BLOB the default data type for binary attribute columns, you need to manually alter the DEFAULTS ATTRIBUTE_BINARY parameter to BLOB. After you make this change, new feature classes created with the DEFAULTS keyword will use BLOB for binary columns. To migrate the attribute columns in existing data from LONG RAW to BLOB, see Migrating Oracle data from one storage type to another in the "Geodatabase data storage and schema" section of the help.

If you are using feature class representations, you must create the feature class with a configuration keyword that has the ATTRIBUTE_BINARY parameter set to BLOB. If you have your DEFAULTS ATTRIBUTE_BINARY value set to LONGRAW, you will need to create another configuration keyword users can specify when they create feature classes that will contain representation classes.

For example, you could add the following configuration keyword REPRESENTATIONS as follows:

For more information on creating custom keywords, see DBTUNE configuration keywords.

If a feature class is created with a configuration keyword that contains an ATTRIBUTE_BINARY parameter set to LONGRAW and multiple representations are created, an error message will be returned:

This happens because each time a new representation class is added, two new fields are added to the business table of the feature class—one LONGRAW and one BLOB. Tables in Oracle cannot contain more than one LONGRAW field, so when the second LONGRAW field is added, it fails.

The UNICODE_STRING parameter specifies whether or not text columns will be stored as VARCHAR2 (nonUnicode) or NVARCHAR2 (Unicode) data types.

For a discussion of Unicode data, see An overview of Unicode in the "Defining the properties of a geodatabase" section of the help.

You can add a COMMENT parameter in the dbtune.sde file if you like by adding a line beginning with a single pound sign (#). You might do this if you create your own custom keywords and want to add comments on how or when the keyword should be used.

For example, you could add a comment to a user's log file keyword:

Configuration parameters specific to geodatabases in Oracle Spatial

Oracle Spatial feature classes are ArcSDE feature classes with Oracle's SDO_GEOMETRY data type to store feature geometry in a column in the business table. Many of the storage parameters used for ArcSDE compressed binary feature classes apply to Oracle Spatial feature classes. Also, some storage parameters exist solely to establish how Oracle Spatial feature classes are stored, indexed, and accessed.

For a description of Oracle Spatial, consult the Oracle Spatial User's Guide and Reference.

    Creating new business tables

ArcSDE uses the B_STORAGE, B_INDEX_ROWID, and B_INDEX_USER storage parameters to store the business table and the nonspatial indexes on the business table.

The database view USER_SDO_GEOM_METADATA is part of Oracle Spatial, not ArcSDE. It contains metadata about SDO_GEOMETRY columns in existing tables owned by the user. Each user has its own USER_SDO_GEOM_METADATA view. To be indexed and queried, the owner of the table must record metadata for each SDO_GEOMETRY column in USER_SDO_GEOM_METADATA. The ArcSDE clients that create a feature class will choose the metadata for the feature class. Often, these clients accept a configuration keyword corresponding to a parameter group in the DBTUNE table.

The storage parameters that control the metadata for new Oracle Spatial feature classes are the following:

NOTE: If a coordinate reference system is provided during the creation of a feature class, the SDO_SRID parameter is ignored and not written to the USER_SDO_GEOM_METADATA view.

Oracle Spatial permits feature geometries of two, three, or four dimensions in the combinations x/y, x/y/z, x/y/z (measure), or x/y/z/m. Through these storage parameters, ArcSDE allows you to specify metadata for each dimension. The <n> in some parameter names should be replaced by one of the digits 1, 2, 3, or 4, corresponding to the dimension number. If you do not supply these storage parameters, the ArcSDE client application that creates the feature class will determine the name, upper and lower bound (extent), and tolerance of each dimension.

The DBTUNE parameter SDO_INDEX_SHAPE determines how Oracle Spatial creates the spatial index. ArcSDE appends the contents of this parameter (the configuration string) to the CREATE INDEX statement before submitting the statement to Oracle. The configuration string is inserted into the SQL statement after the PARAMETERS keyword. For example:

The configuration string is a quoted string containing a list of parameter = value elements. There are many parameters that you can specify in the configuration string. To understand the Oracle Spatial index parameters and how they interact, read the applicable sections of the Oracle Spatial User's Guide and Reference.

Notice the differences between the physical storage parameters in the spatial index configuration string and in a business table configuration string (as specified in B_STORAGE). One difference is due to the way Oracle expects these parameters to appear in SQL statements. The Oracle statements are formatted differently, so the configuration strings are formatted differently. Also, not every physical storage parameter used for creating tables is available for creating spatial indexes.

Both ArcSDE and Oracle Spatial expect that exterior polygon boundaries are stored in counterclockwise rotation and that inner boundaries are stored clockwise. If the rotation polygon boundary is not stored with this rotation, the polygon will fail the ArcSDE topographic validation test and will not be sent to the ArcSDE client.

This section presents DBTUNE parameter groups that apply to several common scenarios. These samples emphasize the storage parameters for Oracle Spatial feature classes. When designing your own parameter groups, you may want to add parameters to support other needs, such as geometric networks or log files. You could also satisfy these requirements via parameters in the DEFAULTS parameter group.

If you are not using Oracle Spatial by default, you can create a simple parameter group to create Oracle Spatial feature classes with mostly default settings. The tables and indexes will be created in the user's default tablespace using default physical storage parameters, unless specified otherwise in the DEFAULTS parameter group. The spatial index will be a two dimensional R-tree.

With Oracle Spatial, if data is often loaded using a specific spatial reference identifier (SRID), such as the geodetic SRID 8307 (latitude/longitude WGS 84), you can create an expanded version of the previous parameter group. You don't have to specify the upper and lower bounds and tolerance, but you can if you want all your feature classes to have the same metadata for the X and Y dimensions. This is useful if you want to use the feature classes in the same feature dataset. Also, this case specifies that any polygon boundaries with reversed rotation will be reordered before sending them to ArcSDE clients.

NOTE: For geodetic data, the extents are specified in decimal degrees and the tolerances are specified in meters.

The following example can be used to load a feature class with an R-tree spatial index into the tablespace ORSPBIZ. The R-tree spatial index will be created in the tablespace ORSPIDX. The ArcSDE client that is loading the data will decide the values for the metadata.

The following example can be used to load a feature class with a quadtree spatial index having a fixed-size tiling level (tessellation level) of 6. The spatial index will be created in the tablespace ORSPIDX. Commit interval is important for quadtree indexes. It indicates the number of business table records that will be processed before committing the index data. Without it, all the records of the business table are processed before committing the index data. This will cause problems when indexing tables with many records.

NOTE: The parameter sdo_commit_interval is so important that ArcSDE automatically includes it in SQL indexing statements for Oracle Spatial tables even if you do not specify it as part of the SDO_INDEX_SHAPE parameter. It is set to 1,000.


ST_Geometry in Oracle

The Esri ST_Geometry spatial data type can be used in Oracle databases that contain a geodatabase and those that do not. It allows you to integrate spatial data with other types of business data, so your multiuser database gains the advantage of adding a geographic component to your analyses and data products. Keeping your spatial data together with other business objects also simplifies multiuser access, management, and security of your data, because you will have to manage fewer data storage resources.

The Esri ST_Geometry spatial data type is the default geometry storage type for geodatabases in Oracle. You can also install the ST_Geometry type in Oracle databases using the Create Spatial Type geoprocessing tool.

The ST_Geometry type is not supported with Oracle XA transactions.

To create a geodatabase and use the ST_Geometry type and domain index in the Oracle DBMS, the geodatabase administrator user (sde) must be granted the proper system privileges to instantiate types, operators, and stored procedures. See Privileges for geodatabases in Oracle for information on permissions needed. To install the ST_Geometry type in an Oracle database, there must also be an sde user present, and it must be granted specific privileges to instantiate types, operators, and stored procedures. See Add the ST_Geometry type to an Oracle database for more information.

Using the Esri ST_Geometry spatial type in a geodatabase in Oracle or an Oracle database, you can access your spatial data through SQL functions that implement the ISO SQL/MM Spatial Standard and to the Simple Feature Specification of the OGC. You can use SQL commands to store, retrieve, and manipulate spatial features as you would any other type of data. You can use a long list of standards-based functions with SQL commands and stored procedures to retrieve and analyze spatial data. Having SQL access to the data makes it possible for you to use other applications to access data that was created in Oracle.

The ST_Geometry libraries must be installed on the same server as the Oracle instance to access spatial features with SQL. Be sure the operating system of your Oracle server is supported for the ST_Geometry libraries.

You must also configure the Oracle extproc to use SQL to access tables that contain the ST_Geometry spatial type.


Why would I migrate data?

  • To access your spatial or raster data using structured query language (SQL)
  • To move from a data type that may not be supported in a future to one that is supported

Access data using SQL

Accessing the information in a geodatabase via SQL allows external applications (those not developed in an ArcObjects environment) to work with the tabular data managed by the geodatabase. If these applications need to access spatial or raster data in the geodatabase, you must store your spatial or raster data in data types that allow SQL access. For example, using the ST_Raster storage type allows you to access your raster data with SQL, something that you cannot do easily if your raster data is stored in a BLOB, LONG RAW, IMAGE, BINARY, or BYTEA field.

Move from types that may not be supported in future releases

Oracle is recommending the use of BLOB or BFILE data types instead of LONG RAW data types in its databases. Although LONG RAW columns are still supported, if you have LONG RAW attribute, geometry, or raster fields in your current geodatabase in Oracle, you should migrate them to a different format in preparation for when they are not supported.

The storage for the attribute, geometry, and raster columns in a geodatabase is controlled by the DBTUNE parameters ATTRIBUTE_BINARY, GEOMETRY_STORAGE, and RASTER_STORAGE, respectively. The defaults for these parameters under the DBTUNE DEFAULTS configuration keyword are different depending on which release of ArcGIS you were using when you created your geodatabase. The following table shows the default setting under the DEFAULTS keyword in the DBTUNE table of geodatabases in Oracle.

Data created in new (not upgraded) 9.3 or later release geodatabases using the default parameter settings do not use the LONG RAW storage type. However, any existing data created with any or all of these parameters set to LONG RAW or any new data in upgraded geodatabases that have these parameters set to LONG RAW will still contain LONG RAW columns. To change the data types for these columns, you must alter your DBTUNE settings and migrate the data.

Beginning with ArcGIS 10.1, feature classes created in geodatabases in SQL Server use the Microsoft geometry type be default. To move your existing feature classes to the geometry storage type, use the Migrate Storage geoprocessing tool or a Python script.


Can someone explain ORA-29861 error in plain english and its possible cause?

I have an application implemented in Grails framework using underlying Hibernate. After it runs for a while, I got an Oracle DB error and resolved it by rebuilding the offending index. I wonder if anyone can propose the possible cause(s) and ways to prevent it from happening.

Caused by: org.springframework.jdbc.UncategorizedSQLException:

Hibernate operation: Could not execute JDBC batch update uncategorized SQLException for SQL [update RSS_ITEM set guid=?, pubdate=?, link=?, rss_source_id=?, title=?, description=?, rating_raw=?, rating_tuned=?, date_created=?, date_locked=? where RSS_ITEM_ID=?] SQL state [99999] error code [29861] ORA-29861: domain index is marked LOADING/FAILED/UNUSABLE

nested exception is java.sql.BatchUpdateException: ORA-29861: domain index is marked LOADING/FAILED/UNUSABLE


2 respuestas 2

Gracias por el comentario. I just found that this problem is due to the fetch size that I am setting on the Oracle command object from which I am creating Oracle Data Adaptor. As soon as I stopped setting the command fetch size, it started working fine without any issues.

Cause

The cause of the error is an internal Oracle error which neither ArcGIS nor ArcSDE can control. The error is encountered when the application generates a SQL statement using an asterisk in the SELECT list (SELECT * FROM. ).

For further information on the Oracle error please see Oracle's Metalink Note:49375.1.

Workaround

There are two possible workarounds for this issue. Ensure there is a spatial index present for the feature class and/or add an additional attribute after the ST_Geometry attribute.

To verify if a spatial index is present, using ArcCatalog, connect to the ArcSDE instance as the feature class owner. Select the feature class. Open the properties dialog box. Select the indexes tab and verify that the spatial index is present.

To add a new attribute to a feature class in ArcCatalog, open the feature class properties. Select the fields tab and add the new attribute.

Once the ST_Geometry attribute is no longer in the last position of the SELECT * list, the internal ORA-21500 error is no longer encountered.

Relacionada

Hot Network Questions


Archive views

An archive view is a database view defined on a nonversioned, archive-enabled table or feature class. Archive views also include triggers that keep the archiving tables up-to-date when edits are made through the archive view. An archive view is created when you enable the dataset for archiving or when you enable SQL access on a nonversioned, archive-enabled dataset.

Reasons to have archive views include the following:

  • Archive views allow you to see the data in an archive-enabled table's history table.
  • Archive views allow you to use SQL to edit tables and feature classes that have archiving enabled.

Archive views only work with an individual table or feature class. You cannot use a where clause to join multiple tables together or restrict which rows or columns are included in an archive view.