Como rastrear consultas SQL enviadas pelo ArcGIS Server (ArcSDE) para o banco de dados Oracle?

Eu gostaria de gerar um arquivo de log contendo todas as consultas SQL enviadas pelo ArcGIS Server (ArcSDE) ao banco de dados Oracle. Tem algum jeito de fazer isso? Estou usando o Oracle 11g e o ArcGIS Server 10.0 no Windows. ArcSDE é usado em conexão direta.

— yo_haha
fonte

Você pode usar o rastreamento e auditoria da Oracle. Ter um olhar para esta questão: stackoverflow.com/questions/7914354/oracle-sql-query-logging

— Devdatta Tengshe

Você pode usar o Toad Quest para o log de rastreamento em tempo real.

Na verdade, existem várias maneiras de rastrear qualquer conexão ArcSDE. As chamadas entre o aplicativo cliente e o cliente ArcSDE são registradas no arquivo SDE Trace, entre o cliente e o servidor ArcSDE no arquivo SDE Intercept, o servidor ArcSDE registra certos eventos no serviço ou no log de conexão direta e as chamadas do banco de dados são registradas os arquivos de log do DBMS.

-------------------------------------------------------------
|                                                           |
|  Client (ArcObject, ArcCatalog, ArcGIS Server, ArcIMS...) |
|                                                           |
-------------------------------------------------------------
      |
      |
     \|/
------------------ --------> SDE Trace
|                |  
|  ArcSDE Client |
|                |  
------------------ --------> SDE Intercept
      |
      |
     \|/
------------------- --------> SDE Intercept
|                 | 
|  ArcSDE Server  | --------> ArcSDE Service Logfile, or direct connect log
|                 |  
------------------- 
      |
      |
     \|/
------------------
|                |  
|  DBMS          | -----------> DBMS logfiles or trace
|                |  
------------------

Os arquivos do ArcSDE Trace registram todas as chamadas feitas para o cliente ArcSDE. Esses arquivos geralmente são grandes e barulhentos. Veja o SDETraceLoc e SDETraceMode na ajuda do dbinit . Esses valores também podem ser definidos como variáveis de ambiente antes de você iniciar o aplicativo, isso funciona para aplicativos e conexões diretas.

Os arquivos do ArcSDE Intercept são geralmente mais úteis. Eles mostrarão quanto tempo está sendo gasto em que chamada. Uma palavra de cautela, porém, a SDE elabora um conceito de fluxos. Certos comandos (como inserções, atualizações e exclusões) configuram informações no fluxo e, em seguida, execute o comando. Normalmente, o número do fluxo é o primeiro número inteiro após o comando no arquivo de interceptação. Isso pode ficar confuso se você tiver muitos fluxos (eu já vi até 26 fluxos). Você pode consultar SDEIntercept e SDEInterceptLoc na ajuda do dbinit ou este artigo da KB nos arquivos SDE Intercept para obter mais informações e exemplos.

Os arquivos de log do serviço ArcSDE, na pasta% SDE_HOME% \ etc, ou os arquivos de log de conexão direta, nas pastas% SDE_HOME% \ etc ou% TEMP%, contêm informações gerais sobre o que está acontecendo com o serviço ou a conexão. A quantidade de informações registradas pode ser aumentada com a variável SDEVerbose ( ajuda do dbinit ).

Arquivos de log e rastreamentos do DBMS são muito úteis. Mas eles fornecem apenas parte da imagem. Além disso, alguns bancos de dados (como Oracle), na verdade, não incluem todos os tipos de erros no rastreamento do DBMS. Existem várias maneiras de ativar o rastreamento SQL, o comentário de Devdatta acima contém links para mais informações.

Outros links: Aprofundando - Solucionando problemas de erros de geoprocessamento ao usar dados do ArcSDE

— travis
fonte

Os locais de Rastreamento e Interceptação neste diagrama estão incorretos (o rastreamento está dentro da API entre o cliente ArcSDE e o servidor ArcSDE e as interceptações estão entre o Servidor e o RDBMS). O registro de aplicativos, como a saída do ArcGIS Server, fica entre o aplicativo cliente e a API do ArcSDE.

— Vince

@Vince, acho que há alguma confusão aqui. Atualizei o diagrama em uma tentativa de ilustrar melhor meu argumento. O rastreamento lista o comando emitido para o cliente SDE (por meio da API SDE), mas não necessariamente para o servidor SDE (por exemplo, SE_coordref_free, SE_shape_get_binary_size). O Intercept contém comandos que acionam uma ida e volta ao servidor SDE, mas não necessariamente o DBMS (por exemplo, QueryWithInfo, StreamSetState). O log entre o SDE e o DBMS depende do DBMS e do tipo de conexão (OCI, OleDB, ODBC).

— Travis 28/10

Concedido, o ASCII não é a melhor maneira de fazer um diagrama disso, mas ajudaria se os dois "ArcSDE Client" estivessem marcados como "ArcSDE Client API" e "ArcSDE Server". O SDETRACE é capturado na interface entre o aplicativo cliente e a API (ecoando parâmetros à medida que eles atravessam a API em qualquer direção). Acredito que o SDEINTERCEPT mora nos dois lados da interface da função SES na DLL gsrvr (como manifestada pelo servidor de aplicativos ou pelo Direct Connect) e inclui mensagens recebidas da API e chamadas feitas ao DBMS (mova a interceptação no cliente superior para baixo da parte inferior).

— Vince

Sim, os dois clientes SDE foram um erro de copiar e colar. Durante o tempo de execução, não há realmente uma API ... apenas o cliente (thread (s) e memória) e o servidor (thread (s) e memória). Mas eu concordo que os SDETRACE ecoam parâmetros à medida que cruzam isso. Estou bastante certo de que, por padrão, o SDEINTERCEPT não registra nada a ver com o DBMS diretamente (por exemplo, SQL). Pode ter havido outros parâmetros que ativaram o log do SQL, mas eles seriam implementados independentemente para cada DBMS. E eu não sei o que são.

— travis 28/10

Geralmente, não vejo a saída de interceptação, mas apenas executei um conjunto simples de chamadas de API ('sdelist -o layers') com o rastreamento e a interceptação ativados, e parece gerar dois arquivos de interceptação (sem a interação SQL lembrado), então parece que nós podemos concordar com este :)

— Vince