Come tracciare le query SQL inviate da ArcGIS Server (ArcSDE) al database Oracle?

Vorrei generare un file di registro contenente tutte le query SQL inviate da ArcGIS Server (ArcSDE) al database Oracle. c'è un modo per farlo? Sto usando Oracle 11g e ArcGIS Server 10.0 su Windows. ArcSDE viene utilizzato in connessione diretta.

— yo_haha
fonte

È possibile utilizzare la traccia e il controllo di Oracle. Date un'occhiata a questa domanda: stackoverflow.com/questions/7914354/oracle-sql-query-logging

— Devdatta Tengshe

Puoi utilizzare Toad Quest per il registro di tracciamento in tempo reale.

Esistono in realtà diversi modi per tracciare qualsiasi connessione ArcSDE. Le chiamate tra l'applicazione client e il client ArcSDE vengono registrate nel file di traccia SDE, tra il client ArcSDE e il server nel file Intercettazione SDE, il server ArcSDE registra determinati eventi nel servizio o registra la connessione diretta e le chiamate al database vengono registrate i file di 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
|                |  
------------------

I file di traccia ArcSDE registrano ogni chiamata effettuata al client ArcSDE. Questi file sono generalmente grandi e rumorosi. Guarda SDETraceLoc e SDETraceMode nella guida di dbinit . Questi valori possono anche essere impostati come variabili di ambiente prima di avviare l'applicazione, questo funziona per applicazioni e connessioni dirette.

I file di ArcSDE Intercept sono generalmente più utili. Mostreranno a che ora si trascorre in quella chiamata. Un avvertimento, però, SDE elabora un concetto di flussi. Alcuni comandi (come inserimenti, aggiornamenti ed eliminazioni) impostano le informazioni sullo stream, quindi eseguono il comando. Di solito il numero di flusso è il primo numero intero dopo il comando nel file di intercettazione. Questo può creare confusione se hai molti stream (ho visto fino a 26 stream). Puoi consultare SDEIntercept e SDEInterceptLoc nella guida di dbinit o in questo articolo KB sui file di intercettazione SDE per ulteriori informazioni ed esempi.

I file di registro del servizio ArcSDE, nella cartella% SDE_HOME% \ etc, oi file di registro a connessione diretta, nelle cartelle% SDE_HOME% \ etc o% TEMP%, contengono informazioni generali su ciò che accade con il servizio o sulla connessione. La quantità di informazioni registrate può essere aumentata con la variabile SDEVerbose (guida di dbinit ).

I file di registro e le tracce DBMS sono molto utili. Ma ti danno solo una parte dell'immagine. Inoltre, alcuni database (come Oracle) in realtà non includono tutti i tipi di errori nella traccia DBMS. Esistono molti modi per abilitare la traccia SQL, il commento di Devdatta sopra collega a maggiori informazioni.

Altri collegamenti: Scavare più a fondo - Risolvere gli errori di geoprocessing durante l'utilizzo dei dati ArcSDE

— travis
fonte

Le posizioni di Traccia e Intercetta in questo diagramma sono errate (la traccia si trova all'interno dell'API tra il client ArcSDE e il server ArcSDE e le intercettazioni sono tra il Server e RDBMS). La registrazione dell'applicazione come l'output di ArcGIS Server si trova tra l'applicazione client e l'API ArcSDE.

— Vince,

@Vince, penso che ci sia un po 'di confusione qui. Ho aggiornato il diagramma nel tentativo di illustrare meglio il mio punto. Il comando elenchi di tracce che vengono emessi al client SDE (tramite l'API SDE) ma non necessariamente al server SDE (ad es. SE_coordref_free, SE_shape_get_binary_size). L'Intercept contiene comandi che attivano un round trip al server SDE, ma non necessariamente al DBMS (ad es. QueryWithInfo, StreamSetState). La registrazione tra SDE e DBMS dipende dal DBMS e dal tipo di connessione (OCI, OleDB, ODBC).

— travis,

Certo, ASCII non è il modo migliore per rappresentarlo, ma sarebbe utile se i due "client ArcSDE" fossero contrassegnati come "API client ArcSDE" e "Server ArcSDE". SDETRACE viene acquisito nell'interfaccia tra l'app client e l'API (facendo eco ai parametri mentre attraversano l'API in entrambe le direzioni). Credo che SDEINTERCEPT risieda su entrambi i lati dell'interfaccia della funzione SES nella DLL gsrvr (come manifestata dal server delle applicazioni o da Direct Connect) e include sia i messaggi ricevuti dall'API che le chiamate effettuate al DBMS (sposta l'intercettazione sul client superiore in fondo alla parte inferiore).

— Vince,

Sì, i due client SDE erano un errore di copia incolla. Durante il runtime, in realtà non esiste un'API ... solo il client (thread (s) e memoria) e il server (thread (s) e memoria). Ma sono d'accordo sul fatto che SDETRACE echo i parametri quando li attraversano. Sono abbastanza certo che, per impostazione predefinita, SDEINTERCEPT non registra nulla che abbia a che fare direttamente con il DBMS (ad es. SQL). Potrebbero esserci stati altri parametri che hanno abilitato la registrazione SQL, ma sarebbero stati implementati in modo indipendente per ciascun DBMS. E non so cosa siano.

— Travis,

In genere non guardo l'output di intercettazione, ma ho appena eseguito un semplice set di chiamate API ('sdelist -o layers') con sia trace che intercettazione abilitate, e sembra generare due file di intercettazione (senza l'interazione SQL I ricordato), quindi sembra che possiamo essere d'accordo su questo :)

— Vince il