Comment suivre les requêtes SQL envoyées par ArcGIS Server (ArcSDE) à la base de données Oracle?

Je souhaite générer un fichier journal contenant toutes les requêtes SQL envoyées par ArcGIS Server (ArcSDE) à la base de données Oracle. Y a-t-il un moyen de le faire? J'utilise Oracle 11g et ArcGIS Server 10.0 sous Windows. ArcSDE est utilisé en connexion directe.

— yo_haha
source

Vous pouvez utiliser le traçage et l'audit d'Oracle. Jetez un coup d'œil à cette question: stackoverflow.com/questions/7914354/oracle-sql-query-logging

— Devdatta Tengshe

Vous pouvez utiliser Toad Quest pour le journal de suivi en temps réel.

Il existe en fait un certain nombre de façons de tracer une connexion ArcSDE. Les appels entre l'application cliente et le client ArcSDE sont enregistrés dans le fichier de trace SDE, entre le client ArcSDE et le serveur dans le fichier d'interception SDE, le serveur ArcSDE enregistre certains événements dans le service ou le journal de connexion directe, et les appels de base de données sont connectés les fichiers journaux du SGBD.

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

Les fichiers de trace ArcSDE enregistrent chaque appel effectué vers le client ArcSDE. Ces fichiers sont généralement volumineux et bruyants. Regardez SDETraceLoc et SDETraceMode dans l' aide dbinit . Ces valeurs peuvent également être définies en tant que variables d'environnement avant de démarrer l'application, cela fonctionne pour l'application et les connexions directes.

Les fichiers ArcSDE Intercept sont généralement plus utiles. Ils montreront le temps passé dans quel appel. Un mot d'avertissement cependant, SDE fonctionne sur un concept de flux. Certaines commandes (comme les insertions, les mises à jour et les suppressions) définissent des informations sur le flux, puis exécutent la commande. Habituellement, le numéro de flux est le premier entier après la commande dans le fichier d'interception. Cela peut devenir déroutant si vous avez plusieurs flux (j'ai vu jusqu'à 26 flux). Vous pouvez consulter SDEIntercept et SDEInterceptLoc dans l' aide dbinit ou cet article de la base de connaissances sur les fichiers SDE Intercept pour plus d'informations et d'exemples.

Les fichiers journaux du service ArcSDE, dans le dossier% SDE_HOME% \ etc, ou les fichiers journaux de connexion directe, dans les dossiers% SDE_HOME% \ etc ou% TEMP%, contiennent des informations générales sur ce qui se passe avec le service ou la connexion. La quantité d'informations enregistrées peut être augmentée avec la variable SDEVerbose ( aide dbinit ).

Les fichiers journaux et les traces du SGBD sont très utiles. Mais ils ne vous donnent qu'une partie de l'image. De plus, certaines bases de données (comme Oracle) n'incluent pas réellement tous les types d'erreurs dans la trace du SGBD. Il existe de nombreuses façons d'activer le traçage SQL, le commentaire de Devdatta ci-dessus renvoie à des informations supplémentaires.

Autres liens: creuser plus profondément - Résolution des erreurs de géotraitement lors de l'utilisation des données ArcSDE

— travis
source

Les emplacements de trace et d'interception dans ce diagramme sont incorrects (la trace se trouve à l'intérieur de l'API entre le client ArcSDE et le serveur ArcSDE, et les interceptions se trouvent entre le serveur et le SGBDR). La journalisation des applications, comme la sortie d'ArcGIS Server, se situe entre l'application cliente et l'API ArcSDE.

— Vince

@Vince, je pense qu'il y a une certaine confusion ici. J'ai mis à jour le diagramme dans le but de mieux illustrer mon propos. La commande Trace lists qui est émise vers le client SDE (via l'API SDE) mais pas nécessairement vers le serveur SDE (par exemple SE_coordref_free, SE_shape_get_binary_size). L'interception contient des commandes qui déclenchent un aller-retour vers le serveur SDE, mais pas nécessairement le SGBD (par exemple, QueryWithInfo, StreamSetState). La journalisation entre SDE et le SGBD dépend du SGBD et du type de connexion (OCI, OleDB, ODBC).

— travis

Certes, l'ASCII n'est pas le meilleur moyen de schématiser cela, mais cela aiderait si les deux «clients ArcSDE» étaient marqués «API client ArcSDE» et «serveur ArcSDE». Le SDETRACE est capturé à l'interface entre l'application cliente et l'API (faisant écho aux paramètres lorsqu'ils traversent l'API dans les deux sens). Je crois que SDEINTERCEPT vit des deux côtés de l'interface de la fonction SES dans la DLL gsrvr (tel que manifesté par le serveur d'applications ou Direct Connect), et comprend à la fois les messages reçus de l'API et les appels effectués au SGBD (déplacer l'interception sur le client supérieur au bas du bas).

— Vince

Oui, les deux clients SDE étaient une erreur de copier-coller. Pendant l'exécution, il n'y a pas vraiment d'API ... juste le client (thread (s) et mémoire) et le serveur (thread (s) et mémoire). Mais je suis d'accord pour dire que les paramètres SDETRACE font écho lorsqu'ils traversent cela. Je suis assez certain que par défaut, le SDEINTERCEPT n'enregistre rien à voir directement avec le SGBD (par exemple SQL). Il se peut que d'autres paramètres aient activé la journalisation SQL, mais ils seraient implémentés indépendamment pour chaque SGBD. Et je ne sais pas ce que c'est.

— travis

Je ne regarde généralement pas la sortie d'interception, mais je viens de lancer un simple ensemble d'appels d'API ('sdelist -o couches') avec à la fois la trace et l'interception activées, et il semble générer deux fichiers d'interception (sans l'interaction SQL I souvenu), il semble donc que nous pouvons nous mettre d'accord sur ce point :)

— Vince