Mais

Erro ao selecionar geometria do banco de dados Oracle com ArcSDE

Erro ao selecionar geometria do banco de dados Oracle com ArcSDE


Estou tentando selecionar uma coluna de geometria como texto conhecido de uma classe de recurso em um geodatabase Oracle 11g / ArcSDE 10.1. (Isso está em um script Python usandopypyodbccomo motorista). Este é o meu SQL:

SELECIONE SDE.ST_AsText (SHAPE) DE OWNER.FEAT_CLASS

Quando executo isso, recebo alguns erros do Oracle:

ORA-29900: ligação de operador não existe  nORA-06553: PLS-306: número ou tipos de argumentos errados na chamada para 'ST_ASTEXT

Encontrei este artigo de suporte que diz para qualificar totalmente todas as referências aST_GEOMETRIAoperadores, mas eu tenho oSDEprefixo, então não tenho certeza do que está faltando. Alguém tem alguma ideia a respeito disso?

ATUALIZAR: Se eu apenas selecionar oFORMAcampo sem nenhuma função SDE que receboDecimal ('214'). Curiosamente, esse também é o ID do objeto.


A fim de descobrir a Tabela Fn onde os pontos reais são armazenados, você pode

selecione object_id de sde.column_registry onde table_name = 'MYTABLE' e column_name = 'SHAPE';

A geometria será armazenada na tabela Fxxxx com xxxx = object_id.


Opções da ferramenta de refatoração de banco de dados ArcSDE

Estamos usando o liquibase como ferramenta de gerenciamento de mudança de banco de dados evolucionária em nossos aplicativos, ele funciona muito bem quando o usamos em esquemas de banco de dados "comuns".

Mas também trabalhamos com aplicativos GIS usando a plataforma esri arcSDE 9.3 sobre Oracle e, neste caso, todas (ou quase todas) as tabelas (GIS e tabelas 'alfanuméricas') no esquema são gerenciadas (criar tabela, concessões, etc.) através de arcSDE. Então, quando queremos criar uma nova classe de recurso, agora usamos arcCatalog e, dessa forma, não é possível gerenciar as alterações das classes de recurso diretamente por meio de SQL usando liquibase ou outra ferramenta de refatoração automática.

Portanto, se não podemos usar o liquibase para gerenciar mudanças, pelo menos queremos executar as operações de gerenciamento sobre nossos recursos por meio da linha de comando. Começamos a procurar ferramentas que evitam o uso de arcCatalog, e então tentamos automatizar as mudanças usando scripts, estamos investigando estas possibilidades:

Tente capturar o SQL que arcCatalog / arcSDE está executando cada vez que fazemos uma alteração em uma classe de recurso monitorando a conexão do oracle. Isso nos resulta em um conjunto muito complexo de instruções SQL que envolve índices, tabelas de controle de versão etc., então desistimos dessa maneira.

Use os comandos admin sdelayer e sdetable instalados no servidor arcSDE.

Use a ferramenta de gerenciamento de dados: uma biblioteca baseada em python para gerenciar as classes de recursos, mas deve ser executada a partir de uma máquina com a versão desktop instalada.

Essas duas últimas opções fornecerão uma maneira de gerenciar recursos a partir da linha de comando, mas nosso objetivo é encontrar / desenvolver uma ferramenta para gerenciar mudanças semelhante à do liquibase. Mas, com essas ferramentas, teremos que encontrar uma ferramenta que nos permita mapear cada operação SQL DDL para um comando arcSDE, e atualmente nenhuma ferramenta de refatoração de banco de dados fornece isso (atualmente temos check liquibase, dbdeploy, flyway).

Alguém resolveu esse problema de gerenciamento de mudanças evolucionárias com arcSDE? Alguma ideia de outra maneira de enfrentar esse problema?


Como ST_Geometry armazena dados espaciais

A seguir está a descrição do Oracle de ST_Geometry:

Nome Modelo
ENTIDADE NÚMERO (38)
NUMPTS NÚMERO (38)
SIRIGAITA FLOAT (64)
MINY FLOAT (64)
MAXX FLOAT (64)
MAXY FLOAT (64)
MINZ FLOAT (64)
MAXZ FLOAT (64)
MINM FLOAT (64)
MAXM FLOAT (64)
ÁREA FLOAT (64)
LEN FLOAT (64)
SRID NÚMERO (38)
PONTOS BLOB

Os atributos do tipo espacial representam as seguintes informações:

    Entidade & # 8212O tipo de elemento geométrico armazenado na coluna espacial (cadeia de linha, cadeia multilinha, multiponto, multipolígono, ponto ou polígono), cujo valor é uma máscara de bits derivada do procedimento armazenado st_geom_util

Como outros tipos de objetos, o tipo de dados ST_Geometry contém um método construtor e funções. Um método construtor é uma função que retorna uma nova instância (objeto) do tipo de dados e configura os valores de seus atributos.

O nome do construtor é igual ao tipo (ST_Geometry). Ao instanciar um objeto do tipo ST_Geometry, você chama o método construtor. Por exemplo:

A seguir estão as funções do acessador ST_Geometry que usam um único ST_Geometry como entrada e retornam o valor da propriedade solicitada como um número.

    A função de membro ST_Area retorna a área de uma geometria.

Por exemplo, a consulta a seguir retorna o nome e a área dos estados individuais nos Estados Unidos.

ST_LineString, ST_MultiLineString, ST_MultiPoint, ST_MultiPolygon, ST_Point e ST_Polygon são todos subtipos (ou subclasses) de ST_Geometry. ST_Geometry e seus subtipos compartilham atributos e funções comuns. A definição do construtor para ST_LineString, ST_MultiLineString, ST_MultiPoint, ST_MultiPolygon, ST_Point e ST_Polygon é a mesma. O nome do construtor é igual ao tipo que ele constrói.

Como ST_Point é um objeto finito (um valor de ponto único), ele também pode ser criado usando um dos seguintes métodos.

Este método utiliza pontos de coordenadas e um SRID.

Este método permite que um usuário especifique pontos de coordenadas e um valor de elevação para cada ponto.

Este último método para ST_Point permite, adicionalmente, que um valor de medida seja especificado como parte do objeto de ponto criado.

SP_Grid_Info é usado como o tipo de dados para o campo GRID na tabela ST_Geometry_Index. Ele contém as informações em nível de grade para índices espaciais.

Para instalar o ArcSDE e usar o tipo ST_Geometry e o índice de domínio no Oracle DBMS, o usuário administrador do ArcSDE deve receber os privilégios de sistema adequados para instanciar tipos, operadores e procedimentos armazenados. Consulte Permissões do usuário para bancos de dados geográficos no Oracle para obter informações sobre as permissões necessárias.

Esquema de metadados

O tipo espacial para tipos Oracle e tabelas de metadados são de propriedade do esquema SDE. A definição do esquema é a descrição da tabela base para tabelas de metadados usadas para definir e descrever o tipo de coluna / tabela, índice espacial e informações de referências espaciais. O termo tipo refere-se ao tipo espacial ST_Geometry. O índice espacial refere-se ao índice do domínio ST_Spatial_Index. Todas as definições de tipo e tipo de índice de domínio, pacotes e tabelas de metadados são criados no esquema SDE.

As visualizações também terão o prefixo ST_, incluindo as visualizações OpenGIS em GEOMETRY_COLUMNS e SPATIAL_REFERENCES.

Como as definições de ST_Geometry pertencem ao usuário SDE, você nunca deve excluir o usuário SDE do banco de dados se ainda tiver tabelas no banco de dados que contenham colunas ST_Geometry. Isso fará com que essas tabelas fiquem inacessíveis.

Conforme mencionado no Guia do desenvolvedor de aplicativos da Oracle, quando um usuário é retirado do banco de dados, uma das instruções drop executadas é DROP TYPE com a opção FORCE. Esta instrução remove todos os tipos pertencentes a esse usuário, para que o usuário possa ser removido do banco de dados. DROP TYPE FORCE faz com que os tipos sejam eliminados mesmo se eles tiverem tipos dependentes ou tabelas associadas a eles. Quando isso acontece, as tabelas associadas são marcadas como inválidas, tornando os dados nas tabelas inacessíveis.

Para obter uma descrição de cada tabela, consulte as tabelas listadas em Tabelas do sistema de um geodatabase armazenado no Oracle. As tabelas são as seguintes:


O Oracle Spatial é uma opção para o banco de dados Oracle que fornece recursos espaciais avançados para suportar sistemas de informações geográficas (GIS) de ponta e soluções de business intelligence habilitadas para localização (LBS).

O Oracle Spatial é um cartucho de dados opcional que permite gravar consultas e visualizações do Oracle CQL que interagem perfeitamente com as classes do Oracle Spatial em seu aplicativo Oracle CEP.

Usando o Oracle Spatial, você pode configurar consultas Oracle CQL que realizam as operações de domínio geográfico mais importantes, como armazenamento de dados espaciais, realização de comparações de proximidade e sobreposição em dados espaciais e integração de dados espaciais com o servidor Oracle CEP, fornecendo a capacidade de indexar no espaço dados.

Para usar o Oracle Spatial, você precisa de um conhecimento prático da API Oracle Spatial. Para obter mais informações sobre o Oracle Spatial, consulte:

16.1.1 Nome do cartucho de dados

O Oracle Spatial usa o ID do cartucho com.oracle.cep.cartrdiges.spatial e registra o nome do link reservado no escopo do servidor espacial.

Use o nome do link espacial para associar uma chamada de método Oracle Spatial ao contexto de aplicativo Oracle Spatial.

16.1.2 Escopo

O Oracle Spatial é baseado na API Oracle Spatial Java. O Oracle Spatial expõe a funcionalidade do Oracle Spatial na classe com.oracle.cep.cartridge.spatial.Geometry. A funcionalidade do Oracle Spatial que não está na API do Oracle Spatial Java não pode ser acessada pelo Oracle Spatial.

Usando o Oracle Spatial, suas consultas Oracle CQL podem acessar a funcionalidade do Oracle Spatial que a Tabela 16-1 descreve.

Tabela 16-1 Oracle Spatial Scope

Os seguintes tipos de geometria da API Oracle Spatial Java:

As seguintes operações de geometria:

Acessando funções de membro público de tipo de geometria e campos públicos

Coordenadas geodésicas cartesianas e WGS84 (padrão)

Especificando o sistema de coordenadas padrão por meio de SRID

Usando outras coordenadas geodésicas

Operadores de relação geométrica

Operadores de filtro geométrico

Para obter uma lista completa dos métodos fornecidos com.oracle.cep.cartridge.spatial.Geometry, consulte a Seção 16.1.2.7, "API Geometria".

Para obter mais informações sobre como acessar esses recursos do Oracle Spatial usando o Oracle Spatial, consulte a Seção 16.2, "Usando o Oracle Spatial".

16.1.2.1 Tipos de geometria

O modelo de dados Oracle Spatial consiste em geometrias. Uma geometria é uma sequência ordenada de vértices. A semântica da geometria é determinada por seu tipo.

O Oracle Spatial permite que você acesse os seguintes tipos do Oracle Spatial diretamente nas consultas e visualizações do Oracle CQL:

SDO_GTYPES: Oracle Spatial suporta os seguintes tipos de geometria:

A Tabela 16-2 descreve os tipos de geometria da classe com.oracle.cep.cartridge.spatial.Geometry que você pode usar.

Tabela 16-2 Tipos de geometria espacial do Oracle

Tipo de geometria de ponto que contém um ponto.

Tipo de geometria de polígono que contém um polígono.

SDO_ELEMENT_INFO: Você pode criar a matriz de informações do elemento usando:

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

ORDENADAS: Você pode criar as ordenadas usando a função ordsgenerator do Oracle Spatial.

16.1.2.2 Matriz de informações do elemento

O atributo Element Info é definido usando uma matriz de números de comprimento variável. Este atributo especifica como interpretar as ordenadas armazenadas no atributo Ordenadas.

O Oracle Spatial fornece a seguinte função auxiliar para gerar valores de atributos de informações do elemento:

Você também pode usar a função einfogenerator.

16.1.2.3 Sistemas de Ordenadas e Coordenadas e o SDO_SRID

A Tabela 16-3 lista os sistemas de coordenadas que o Oracle Spatial suporta por padrão e o valor SDO_SRID que identifica cada sistema de coordenadas.

Tabela 16-3 Sistemas de Coordenadas Espaciais Oracle

Coordenadas cartesianas são coordenadas que medem a posição de um ponto de uma origem definida ao longo de eixos perpendiculares no espaço representado.

As coordenadas geodésicas (às vezes chamadas de coordenadas geográficas) são coordenadas angulares (longitude e latitude), intimamente relacionadas às coordenadas polares esféricas, e são definidas em relação a um determinado datum geodésico da Terra.

Este é o sistema de coordenadas padrão no Oracle Spatial.

Você pode especificar o valor SDO_SRID como um argumento para cada método e construtor Oracle Spatial que você chamar ou pode configurar o SDO_SRID no contexto do aplicativo Oracle Spatial uma vez e usar os métodos com.oracle.cep.cartridge.spatial.Geometry sem precisar definir o SDO_SRID como um argumento a cada vez. Usando o contexto do aplicativo, você também pode especificar qualquer sistema de coordenadas compatível com o Oracle Spatial.

Se você usar um método com.oracle.cep.cartridge.spatial.Geometry que não use um valor SDO_SRID, deverá usar o contexto de aplicativo Oracle Spatial. Por exemplo, a seguinte chamada de método causará uma exceção de tempo de execução:

Em vez disso, você deve usar o nome do link espacial para associar a chamada do método ao contexto do aplicativo Oracle Spatial:

Se você usar um método de geometria que usa um valor SDO_SRID, o uso do nome do link espacial é opcional. Por exemplo, as duas chamadas de método a seguir são válidas:

As ordenadas definem a matriz de coordenadas para uma geometria usando uma matriz dupla. O Oracle Spatial fornece a função auxiliar ordsgenerator para gerar a matriz de coordenadas. Para sintaxe, consulte "ordsgenerator".

"Coordinate Systems (Spatial Reference Systems)" no Oracle Spatial Developer's Guide

16.1.2.4 Índice Geométrico

O Oracle Spatial usa um índice espacial para implementar o filtro primário. O objetivo do índice espacial é criar rapidamente um subconjunto dos dados e reduzir a carga de processamento no filtro secundário.

Um índice espacial, como qualquer outro índice, fornece um mecanismo para limitar as pesquisas, mas, neste caso, o mecanismo é baseado em critérios espaciais como interseção e contenção.

O Oracle Spatial usa a indexação R-Tree para o mecanismo de indexação padrão. Um índice de árvore R espacial pode indexar dados espaciais de até quatro dimensões. Um índice R-tree aproxima cada geometria por um único retângulo que minimamente envolve a geometria (chamado de Retângulo Mínimo Limitador, ou MBR)

16.1.2.5 Operadores de relação geométrica

O Oracle Spatial oferece suporte aos seguintes operadores de relação geométrica do Oracle Spatial:

Você pode usar qualquer um desses operadores na cláusula de projeção da consulta Oracle CQL ou na cláusula where.

Quando você usa um operador de relação geométrica na cláusula where de uma consulta Oracle CQL, o Oracle Spatial ativa a indexação Rtree na relação especificada na cláusula where.

O Oracle Spatial oferece suporte apenas a relações geométricas entre pontos e outros tipos de geometria.

16.1.2.6 Operadores de filtro geométrico

O Oracle Spatial oferece suporte aos seguintes operadores de filtro geométrico do Oracle Spatial:

Esses operadores de filtro executam a filtragem primária e, portanto, podem aparecer apenas em uma cláusula where de consulta CQL do Oracle.

Esses operadores de filtro usam o índice espacial para identificar o conjunto de objetos espaciais que provavelmente interagirão espacialmente com o objeto fornecido.

16.1.2.7 API Geometria

O Oracle Spatial é baseado na API Oracle Spatial Java. O Oracle Spatial expõe a funcionalidade do Oracle Spatial na classe com.oracle.cep.cartridge.spatial.Geometry. Esta classe de geometria também estende oracle.spatial.geometry.J3D_Geometry.

Embora o Oracle Spatial suporte apenas geometrias 2D, para eficiência, a classe Geometria usa alguns métodos J3D_Geometry. A classe Geometria automaticamente zera as coordenadas Z para os métodos J3D_Geometry.

A funcionalidade do Oracle Spatial inacessível da classe Geometria (ou não conforme o escopo e os tipos de geometria que o Oracle Spatial suporta) é inacessível do Oracle Spatial.

Para simplificar os nomes de tipo Oracle Spatial, você pode usar aliases conforme a Seção 2.8.2, "Definindo aliases usando o elemento Aliases".


Parâmetros de configuração Oracle DBTUNE

Os parâmetros de configuração, que são armazenados na coluna parameter_name da tabela DBTUNE, identificam o objeto de banco de dados a ser configurado ou denotam uma configuração específica. Seus valores correspondentes, que são armazenados na coluna config_string do DBTUNE, identificam como o objeto ou configuração será configurado. Os parâmetros e suas strings de configuração são agrupados na tabela DBTUNE por palavras-chave de configuração. As combinações de palavra-chave / nome_do_parâmetro são exclusivas, mas a maioria dos nomes_do_parâmetro não são e são reutilizados sob várias palavras-chave diferentes em toda a tabela DBTUNE.

Os valores válidos para a coluna parameter_names são fixos e você não pode inventar novos parameter_names. Da mesma forma, os config_strings aceitam apenas determinados valores numéricos ou strings SQL. Na maioria dos casos, essas strings são anexadas às instruções SQL CREATE TABLE e CREATE INDEX.

Em bancos de dados geográficos armazenados em um banco de dados Oracle, o nome do parâmetro & # 8211 pares de strings de configuração são usados ​​pelo ArcSDE para as seguintes finalidades:

    Estabelecer as características de armazenamento de tabelas e índices

Por padrão, o Oracle armazena tabelas e índices no espaço de tabela padrão do usuário usando os parâmetros de armazenamento padrão do espaço de tabela. Você pode determinar o espaço de tabela padrão de um usuário consultando o campo DEFAULT_TABLESPACE da tabela de sistema USER_USERS Oracle quando conectado como esse usuário. Como administrador do banco de dados Oracle (DBA), consulte o campo DEFAULT_TABLESPACE da tabela DBA_USERS usando uma cláusula WHERE para especificar o usuário.

Obtenha uma lista de parâmetros de armazenamento padrão para um espaço de tabela consultando USER_TABLESPACES:

Para especificar diferentes espaços de tabela usando palavras-chave de configuração, você precisa remover o comentário de alguns parâmetros em DEFAULTS e outras palavras-chave de configuração no arquivo dbtune e editar as sequências de configuração associadas para especificar um nome de espaço de tabela. As linhas comentadas são precedidas de um único sinal de sustenido (#). Remova este sinal de sustenido e substitua & lttext & gt pelo nome do espaço de tabela correto. Em seguida, importe o arquivo dbtune para a tabela DBTUNE. Os usuários podem então especificar essa palavra-chave (ou aceitar os DEFAULTS) e as tabelas e índices dos conjuntos de dados que eles criam serão armazenados no espaço de tabela especificado no arquivo dbtune.

Consulte O arquivo dbtune e a tabela DBTUNE para obter detalhes sobre a edição do arquivo dbtune e da tabela.

A tabela a seguir é uma lista alfabética de todos os parâmetros de configuração possíveis que podem ser usados ​​em um geodatabase no Oracle. A seguir, há uma explicação mais aprofundada dos parâmetros agrupados por sua funcionalidade, seguida por uma lista de parâmetros que são específicos para os bancos de dados geográficos ArcSDE armazenados no Oracle Spatial.

    A distância de duas ordenadas podem estar afastadas na dimensão dada e ainda ser considerada a mesma

    Limite de dimensão superior para tipo de geometria Oracle Spatial

    NENHUMA & # 8212 Atualização manual executando o pacote Oracle Text (padrão)

NOTA: Para os parâmetros XML, & ltn & gt se refere ao xml_column_id associado a uma coluna XML específica.

Descrições funcionais de parâmetros

    Tabela de negócios e parâmetros de armazenamento de índice

Uma tabela de negócios é qualquer tabela Oracle criada por um cliente ArcSDE, o comando de administração sdetable ou a função SE_table_create da interface de programação de aplicativos (API) ArcSDE C.

Use o parâmetro B_STORAGE da tabela DBTUNE para definir a configuração de armazenamento de uma tabela de negócios.

Existem cinco parâmetros de armazenamento de índice para oferecer suporte à criação de índices de tabelas de negócios.

O parâmetro B_INDEX_USER contém a configuração de armazenamento para índices definidos pelo usuário criados com a função da API C SE_table_create_index e a operação create_index do comando sdetable.

O parâmetro B_INDEX_ROWID contém a configuração de armazenamento do índice que ArcSDE cria em uma coluna de ID de objeto da tabela de registro, comumente referido como ROWID ou OBJECTID.

NOTA: ArcSDE registra todas as tabelas que cria. As tabelas não criadas pelo ArcSDE também podem ser registradas com os comandos sdetable ou sdelayer. A tabela de sistema TABLE_REGISTRY mantém uma lista das tabelas registradas atualmente.

O parâmetro B_INDEX_SHAPE contém a configuração de armazenamento do índice da coluna espacial que ArcSDE cria quando uma coluna espacial é incluída em uma tabela de negócios. Este índice é criado pela função SE_layer_create do ArcSDE C API. Esta função é chamada pelo ArcGIS quando ele cria uma classe de recurso e pela operação add do comando sdelayer.

O parâmetro B_INDEX_RASTER mantém a configuração de armazenamento do índice da coluna raster que ArcSDE cria quando uma coluna raster é adicionada a uma tabela de negócios. Este índice é criado pela função SE_rastercolumn_create do ArcSDE C API. Esta função é chamada pelo ArcGIS quando ele cria uma classe de recurso e pelas operações de adicionar, copiar e importar do comando sderaster.

O parâmetro B_INDEX_TO_DATE especifica o armazenamento para o índice R & ltregistration_id & gt_sde_todate. Este índice é criado quando o arquivamento é habilitado em uma tabela de negócios e é usado ao atualizar a tabela de histórico durante uma operação de arquivamento.

O registro de uma tabela de negócios com versão permite que vários usuários mantenham e editem um objeto. Em intervalos apropriados, os usuários mesclam as alterações feitas com as alterações feitas por outros usuários e reconciliam quaisquer conflitos que surjam quando as mesmas linhas são modificadas.

ArcSDE cria duas tabelas & # 8212 a tabela de adição e a tabela de exclusão & # 8212 para cada tabela que é registrada como versionada.

O parâmetro A_STORAGE mantém a configuração de armazenamento da tabela de adição. Quatro outros parâmetros de armazenamento mantêm a configuração de armazenamento dos índices da tabela de adição. A tabela de adição é denominada A & ltn & gt, onde & ltn & gt é o ID de registro listado na tabela de sistema TABLE_REGISTRY. Por exemplo, se a tabela de negócios ROADS estiver listada com um ID de registro de 10, ArcSDE cria a tabela de adição como A10.

O parâmetro A_INDEX_RASTER especifica a configuração de armazenamento do índice que é criado em uma coluna raster na tabela de inclusões. O índice é denominado SDE_RIX_ & ltN & gt_A. & ltN & gt é o ID da coluna raster.

O parâmetro A_INDEX_ROWID contém a configuração de armazenamento do índice que ArcSDE cria na coluna de ID de objeto com várias versões, também conhecido como ROWID. O índice ROWID da tabela de adições é denominado A & ltn & gt_ROWID_IX1, onde & ltn & gt é o ID de registro da tabela de negócios com o qual a tabela de adições está associada.

O parâmetro A_INDEX_STATEID contém a configuração de armazenamento do índice que ArcSDE cria na coluna SDE_STATE_ID da tabela de adição. O índice da coluna SDE_STATE_ID é chamado de A & ltn & gt_STATE_IX2, onde & ltn & gt é o ID de registro da tabela de negócios com o qual a tabela de adição está associada.

O parâmetro A_INDEX_SHAPE contém a configuração de armazenamento do índice que ArcSDE cria na coluna espacial da tabela de adição. Se a tabela de negócios contiver uma coluna espacial, a coluna e o índice nela serão duplicados na tabela de inclusões. O índice de coluna espacial da tabela de adição é denominado A & ltn & gt_IX1_A, onde & ltn & gt é o ID da camada da classe de feição, conforme listado na tabela LAYERS.

O parâmetro A_INDEX_USER contém a configuração de armazenamento de índices definidos pelo usuário que ArcSDE cria na tabela de adição. Os índices definidos pelo usuário nas tabelas de negócios são duplicados na tabela de adições.

O parâmetro D_STORAGE contém a configuração de armazenamento da tabela de exclusões. Dois outros parâmetros de armazenamento mantêm a configuração de armazenamento dos índices que ArcSDE cria na tabela de exclusões. A tabela de exclusões é denominada D & ltn & gt, onde & ltn & gt é o ID de registro listado na tabela de sistema TABLE_REGISTRY. Por exemplo, se a tabela de negócios ROADS estiver listada com um ID de registro de 10, ArcSDE cria a tabela de exclusões como D10.

O parâmetro D_INDEX_STATE_ROWID contém a configuração de armazenamento do índice D & ltn & gt_IDX1 que ArcSDE cria nas colunas SDE_STATE_ID e SDE_DELETES_ROW_ID da tabela de exclusões.

O parâmetro D_INDEX_DELETED_AT contém a configuração de armazenamento do índice D & ltn & gt_IDX2 que ArcSDE cria na coluna SDE_DELETED_AT da tabela de exclusões.

Para obter mais informações sobre a estrutura de tabelas de adições e exclusões e como elas são usadas, consulte Tabelas com versão em um geodatabase no Oracle.

Uma classe de recurso criada com armazenamento ST_Geometry adiciona uma tabela de índice espacial ao banco de dados Oracle. Esta tabela de índice espacial é denominada S & ltn & gt_IDX $, onde & ltn & gt é o valor do índice de geometria. Esta tabela é uma Oracle Indexed Organized Table (IOT).

Se você criar tabelas de negócios particionadas que contêm uma coluna ST_Geometry, também desejará que o índice espacial seja particionado. Existem dois tipos de métodos de particionamento: global e local. Por padrão, os índices particionados globais são criados em tabelas de negócios particionadas. Em vez disso, para criar um índice particionado local, você deve adicionar a palavra-chave LOCAL ao final da instrução CREATE INDEX. Para permitir que o ArcGIS adicione LOCAL ao final da instrução CREATE INDEX para o índice espacial, defina o parâmetro ST_INDEX_PARTITION_LOCAL como TRUE sob a palavra-chave DEFAULTS.

Se a tabela de negócios com a coluna ST_Geometry não estiver particionada, no entanto, e você definir ST_INDEX_PARTITION_LOCAL como TRUE, receberá a seguinte mensagem de erro:

Uma classe de recursos criada com um formato de armazenamento binário compactado ArcSDE (tipo de dados LONGRAW ou BLOB) adiciona duas tabelas ao banco de dados Oracle & # 8212a tabela de recursos e a tabela de índice espacial. A tabela de índice espacial é criada como S_ & ltn & gt, em que & ltn & gt é o ID da camada da classe de recursos da tabela de índice espacial, conforme encontrado na tabela CAMADAS. Três índices são criados na tabela de recursos e dois índices são criados na tabela de índices espaciais.

Os parâmetros de configuração que se aplicam a índices espaciais geralmente começam com S_. Os parâmetros de armazenamento para essas tabelas e índices seguem o mesmo padrão que os parâmetros de armazenamento B_STORAGE e B_INDEX_ * da tabela de negócios.

O parâmetro S_STORAGE contém a configuração de armazenamento Oracle CREATE TABLE da tabela de índice espacial e seus índices para ST_Geometry e armazenamento binário.

O parâmetro S_INDEX_ALL se aplica apenas ao armazenamento binário e contém a configuração de armazenamento Oracle CREATE INDEX do primeiro índice da tabela espacial. A tabela de índice espacial é criada como S_ & ltn & gt_IX1, onde & ltn & gt é o ID da camada da classe de recurso do índice encontrada na tabela LAYERS.

O parâmetro S_INDEX_SP_FID contém a configuração de armazenamento Oracle CREATE INDEX do segundo índice da tabela espacial se o armazenamento binário foi usado para a classe de recurso. A tabela de índice espacial é criada como S_ & ltn & gt_IX2, onde & ltn & gt é o ID da camada da classe de recurso do índice encontrada na tabela LAYERS.

Os parâmetros de classe de recurso se aplicam apenas ao usar armazenamento binário. Esses parâmetros começam com F_

O parâmetro F_STORAGE contém a string de configuração de armazenamento Oracle CREATE TABLE da tabela de recursos. A tabela de recursos é criada como F_ & ltn & gt, onde & ltn & gt é o ID da camada da classe de recursos da tabela, conforme encontrado na tabela LAYERS.

O parâmetro F_INDEX_FID contém a string de configuração de armazenamento Oracle CREATE INDEX do índice de coluna espacial da tabela de recursos. A coluna espacial é criada como F & ltn & gt_UK1, onde & ltn & gt é o ID da camada da classe de recurso do índice, conforme encontrado na tabela CAMADAS.

O parâmetro F_INDEX_AREA contém a configuração de armazenamento Oracle CREATE INDEX do índice de coluna de área da tabela de recursos. A coluna espacial é criada como F & ltn & gt_AREA_IX2, onde & ltn & gt é o ID da camada da classe de recurso do índice, conforme encontrado na tabela LAYERS.

O parâmetro F_INDEX_LEN contém a configuração de armazenamento Oracle CREATE INDEX do índice de coluna de comprimento da tabela de recursos. A coluna espacial é criada como F & ltn & gt_LEN_IX3, onde & ltn & gt é o ID da camada da classe de recurso do índice, conforme encontrado na tabela LAYERS.

Para obter informações sobre a estrutura das tabelas F e S de classes de recursos binários no Oracle, consulte Classes de recursos em um geodatabase no Oracle na seção "Armazenamento e esquema de dados de geodatabase" da ajuda.

Para obter informações sobre as opções disponíveis para armazenamento de geometria de classe de recurso, consulte a seção neste tópico "Parâmetro de armazenamento de geometria" e o tópico Sobre tipos de armazenamento de geometria.

Uma coluna raster adicionada a uma tabela de negócios é na verdade uma referência de chave estrangeira para dados raster armazenados em um esquema que consiste em quatro tabelas e cinco índices de suporte. Os parâmetros da tabela raster definem a configuração das tabelas e índices raster.

O parâmetro RAS_STORAGE contém a configuração de armazenamento Oracle CREATE TABLE da tabela RAS.

O parâmetro RAS_INDEX_ID contém a configuração de armazenamento Oracle CREATE INDEX do índice da tabela RAS.

O parâmetro BND_STORAGE contém a configuração de armazenamento Oracle CREATE TABLE da tabela BND.

O parâmetro BND_INDEX_COMPOSITE contém a configuração de armazenamento Oracle CREATE INDEX do índice de coluna composta da tabela BND.

O armazenamento BND_INDEX_ID contém a configuração de armazenamento Oracle CREATE INDEX do índice de coluna de ID de linha (RID) da tabela BND.

O parâmetro AUX_STORAGE contém a configuração de armazenamento Oracle CREATE TABLE da tabela AUX.

O parâmetro AUX_INDEX_COMPOSITE contém a configuração de armazenamento Oracle CREATE INDEX do índice da tabela AUX.

O parâmetro BLK_STORAGE contém a configuração de armazenamento Oracle CREATE TABLE da tabela BLK.

O parâmetro BLK_INDEX_COMPOSITE contém a configuração de armazenamento Oracle CREATE TABLE do índice da tabela BLK.

O parâmetro RASTER_STORAGE define que tipo de dados é usado para armazenar dados raster. ArcSDE oferece três formatos de armazenamento raster para Oracle. O parâmetro RASTER_STORAGE indica qual método de armazenamento de geometria deve ser usado. O parâmetro RASTER_STORAGE possui os seguintes valores:

    ArcSDE raster armazenado como um tipo de dados BLOB & # 8212 Este é o método de armazenamento raster padrão do ArcSDE para Oracle.

Defina o parâmetro RASTER_STORAGE como BLOB se quiser armazenar seus dados raster neste formato. Se desejar tornar esse formato o padrão, defina o parâmetro RASTER_STORAGE como BLOB na palavra-chave de configuração DEFAULTS. Se o parâmetro RASTER_STORAGE não for definido, o formato BLOB será assumido.

Defina o parâmetro RASTER_STORAGE como LONGRAW se desejar armazenar seus dados raster neste formato.

NOTA: Não é recomendável usar o armazenamento LONGRAW porque o Oracle suspendeu o suporte para este tipo de dados a partir da versão 11g.

Se você deseja que a maioria das colunas raster em seu banco de dados use o mesmo formato de armazenamento raster, defina o parâmetro RASTER_STORAGE uma vez na palavra-chave de configuração DEFAULTS. Por exemplo, para alterar o RASTER_STORAGE padrão de BLOB para SDO_GEORASTER, a seguinte alteração é feita:

O parâmetro RASTER_STORAGE substitui o RASTER_BINARY_TYPE, que continua a funcionar, mas não é mais suportado.

NOTA: Se você especificar SDO_GEORASTER para o parâmetro RASTER_STORAGE, não poderá definir GEOMETRY_STORAGE para SDO_GEOMETRY ou ST_GEOMETRY.

Para obter mais informações sobre armazenamento raster no geodatabase, consulte Conjuntos de dados raster e catálogos raster em um geodatabase armazenado no Oracle na seção "Armazenamento de dados geodatabase e esquema" da ajuda.

Existe um tipo adicional de tabela raster & # 8212a tabela de atributos raster. Essas tabelas armazenam valores de atributos com base em valores de células no raster. O parâmetro B_STORAGE define o armazenamento dessas tabelas. Se você precisar definir um local de armazenamento diferente para essas tabelas do que para outras tabelas de negócios de classe de recurso, certifique-se de criar uma palavra-chave raster que possa usar ao criar conjuntos de dados raster e catálogos raster que especifiquem diferentes informações de armazenamento para as tabelas de atributos raster.

Para saber mais sobre as tabelas de atributos raster, consulte Tabelas de atributos do conjunto de dados raster na seção "Gerenciamento de imagem e dados raster" da ajuda. Para saber como criar palavras-chave de configuração personalizadas, consulte Palavras-chave de configuração DBTUNE.

ArcSDE for Oracle oferece cinco formatos de armazenamento de dados espaciais. O parâmetro GEOMETRY_STORAGE indica qual método de armazenamento de geometria deve ser usado. Você deve definir o parâmetro GEOMETRY_STORAGE na palavra-chave de configuração DEFAULTS para refletir o tipo de armazenamento de geometria com o qual a maioria de suas classes de recursos será criada.

O parâmetro GEOMETRY_STORAGE tem os seguintes valores possíveis:

    ST_Geometry for Oracle & # 8212Este tipo estende o banco de dados para incluir um tipo de dados 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 10g, Oracle does not recommend the use of the manual undo method. See the documentation provided with your Oracle 10g 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. Por exemplo:

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 respostas 2

Thanks for the comment. 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.

Relacionado

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.


Assista o vídeo: Tratamento exceções erros Exception. banco de dados. PLSQL ORACLE