¿Cómo rastrear las consultas SQL enviadas por ArcGIS Server (ArcSDE) a la base de datos Oracle?

12

Me gustaría generar un archivo de registro que contenga todas las consultas SQL enviadas por ArcGIS Server (ArcSDE) a la base de datos Oracle. ¿Hay una manera de hacerlo? Estoy usando Oracle 11g y ArcGIS Server 10.0 en Windows. ArcSDE se utiliza en conexión directa.

arcgis-10.0 arcgis-server sql oracle-11g log yo_haha
fuente
3
Puede usar el rastreo y la auditoría de Oracle. Eche un vistazo a esta pregunta: stackoverflow.com/questions/7914354/oracle-sql-query-logging
Devdatta Tengshe
Puede usar Toad Quest para el registro de seguimiento en tiempo real.

Respuestas:

13

En realidad, hay varias formas de rastrear cualquier conexión de ArcSDE. Las llamadas entre la aplicación cliente y el cliente ArcSDE se registran en el archivo SDE Trace, entre el cliente ArcSDE y el servidor en el archivo SDE Intercept, el servidor ArcSDE registrará ciertos eventos en el servicio o el registro de conexión directa, y las llamadas a la base de datos se registran. los archivos de registro 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
|                |  
------------------

Los archivos de ArcSDE Trace registran todas las llamadas realizadas al cliente de ArcSDE. Estos archivos suelen ser grandes y ruidosos. Mire SDETraceLoc y SDETraceMode en la ayuda de dbinit . Estos valores también se pueden establecer como variables de entorno antes de iniciar la aplicación, esto funciona para aplicaciones y conexiones directas.

Los archivos de ArcSDE Intercept suelen ser más útiles. Le mostrarán qué tiempo se pasa en cada llamada. Sin embargo, una advertencia: SDE funciona a partir de un concepto de flujos. Ciertos comandos (como inserciones, actualizaciones y eliminaciones) establecen información en la secuencia y luego ejecutan el comando. Por lo general, el número de secuencia es el primer entero después del comando en el archivo de intercepción. Esto puede ser confuso si tiene muchas transmisiones (he visto hasta 26 transmisiones). Puede consultar SDEIntercept y SDEInterceptLoc en la ayuda de dbinit o en este artículo de KB sobre archivos SDE Intercept para obtener más información y ejemplos.

Los archivos de registro del servicio ArcSDE, en la carpeta% SDE_HOME% \ etc, o los archivos de registro de conexión directa, en las carpetas% SDE_HOME% \ etc o% TEMP%, contienen información general sobre lo que sucede con el servicio o la conexión. La cantidad de información que se registra puede aumentarse con la variable SDEVerbose ( ayuda de dbinit ).

Los archivos de registro y rastros DBMS son muy útiles. Pero solo te dan una parte de la imagen. Además, algunas bases de datos (como Oracle) en realidad no incluyen todos los tipos de errores en el rastreo DBMS. Hay muchas formas de habilitar el seguimiento de SQL, el comentario anterior de Devdatta enlaza con más información.

Otros enlaces: Excavando más profundo - Solucionando errores de geoprocesamiento al usar datos de ArcSDE

travis
fuente
Las ubicaciones de Rastreo e Intercepción en este diagrama son incorrectas (el rastreo está dentro de la API entre el cliente de ArcSDE y el servidor de ArcSDE, y las intercepciones están entre el Servidor y RDBMS). El registro de aplicaciones, como la salida de ArcGIS Server, se encuentra entre la aplicación cliente y la API de ArcSDE.
Vince
@ Vince, creo que hay algo de confusión aquí. Actualicé el diagrama en un intento de ilustrar mejor mi punto. El comando Rastreo de listas que se emite al Cliente SDE (a través de la API SDE) pero no necesariamente al Servidor SDE (por ejemplo, SE_coordref_free, SE_shape_get_binary_size). Intercept contiene comandos que activan un viaje de ida y vuelta al servidor SDE, pero no necesariamente el DBMS (por ejemplo, QueryWithInfo, StreamSetState). El registro entre SDE y el DBMS depende del DBMS y del tipo de conexión (OCI, OleDB, ODBC).
travis
De acuerdo, ASCII no es la mejor manera de diagramar esto, pero ayudaría si los dos "ArcSDE Client" estuvieran marcados como "ArcSDE Client API" y "ArcSDE Server". El SDETRACE se captura en la interfaz entre la aplicación cliente y la API (haciendo eco de los parámetros cuando cruzan la API en cualquier dirección). Creo que SDEINTERCEPT vive en ambos lados de la interfaz de la función SES en la DLL gsrvr (como lo manifiesta el servidor de aplicaciones o Direct Connect), e incluye tanto los mensajes recibidos de la API como las llamadas realizadas al DBMS (mover la intercepción en el cliente superior al fondo de la parte inferior).
Vince
Sí, los dos clientes SDE fueron un error de copiar y pegar. Durante el tiempo de ejecución, no hay realmente una API ... solo el cliente (hilo (s) y memoria) y el servidor (hilo (s) y memoria). Pero estoy de acuerdo en que los parámetros de eco SDETRACE al cruzar eso. Estoy bastante seguro de que, por defecto, el SDEINTERCEPT no registra nada que ver directamente con el DBMS (por ejemplo, SQL). Puede haber otros parámetros que permitieron el registro de SQL, pero se implementarían de forma independiente para cada DBMS. Y no sé lo que son.
travis
Generalmente no miro la salida de intercepción, pero simplemente ejecuté un conjunto simple de llamadas API ('sdelist -o capas') con el rastreo y la intercepción habilitados, y parece generar dos archivos de intercepción (sin la interacción SQL I recordado), por lo que parece que podemos estar de acuerdo en esto :)
Vince