Verfolgen von SQL-Abfragen, die von ArcGIS Server (ArcSDE) an die Oracle-Datenbank gesendet wurden

Ich möchte eine Protokolldatei generieren, die alle SQL-Abfragen enthält, die von ArcGIS Server (ArcSDE) an die Oracle-Datenbank gesendet wurden. Gibt es einen Weg, dies zu tun? Ich verwende Oracle 11g und ArcGIS Server 10.0 unter Windows. ArcSDE wird in direkter Verbindung verwendet.

— yo_haha
quelle

Sie können das Tracing & Auditing von Oracle verwenden. Schauen Sie sich diese Frage an: stackoverflow.com/questions/7914354/oracle-sql-query-logging

— Devdatta Tengshe

Sie können Toad Quest für das Echtzeit-Tracking-Protokoll verwenden.

Tatsächlich gibt es verschiedene Möglichkeiten, eine ArcSDE-Verbindung zu verfolgen. Anrufe zwischen der Client-Anwendung und dem ArcSDE-Client werden in der SDE-Trace-Datei protokolliert, zwischen dem ArcSDE-Client und dem Server in der SDE-Intercept-Datei protokolliert der ArcSDE-Server bestimmte Ereignisse im Dienst- oder Direktverbindungsprotokoll, und Datenbankaufrufe werden protokolliert die DBMS-Logdateien.

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

Die ArcSDE-Trace-Dateien protokollieren jeden an den ArcSDE-Client gerichteten Anruf. Diese Dateien sind normalerweise groß und laut. Sehen Sie sich SDETraceLoc und SDETraceMode in der dbinit-Hilfe an . Diese Werte können auch als Umgebungsvariablen festgelegt werden, bevor Sie die Anwendung starten. Dies funktioniert für Anwendungs- und Direktverbindungen.

ArcSDE Intercept-Dateien sind normalerweise hilfreicher. Sie zeigen, welche Zeit in welchem Gespräch verbracht wird. Ein Wort der Vorsicht, SDE arbeitet ein Konzept von Streams ab. Bestimmte Befehle (wie Einfügen, Aktualisieren und Löschen) stellen Informationen in den Stream ein und führen dann den Befehl aus. Normalerweise ist die Stream-Nummer die erste Ganzzahl nach dem Befehl in der Intercept-Datei. Dies kann verwirrend werden, wenn Sie viele Streams haben (ich habe bis zu 26 Streams gesehen). Weitere Informationen und Beispiele finden Sie in SDEIntercept und SDEInterceptLoc in der dbinit-Hilfe oder in diesem KB-Artikel zu SDE Intercept-Dateien .

Die ArcSDE-Dienst-Protokolldateien im Ordner "% SDE_HOME% \ etc" oder die Direktverbindungs-Protokolldateien im Ordner "% SDE_HOME% \ etc" oder "% TEMP%" enthalten allgemeine Informationen zu den Vorgängen mit dem Dienst oder der Verbindung. Die Menge der zu protokollierenden Informationen kann mit der Variablen SDEVerbose ( dbinit help ) erhöht werden .

DBMS-Protokolldateien und Traces sind sehr nützlich. Aber sie geben Ihnen nur einen Teil des Bildes. Darüber hinaus enthalten einige Datenbanken (wie Oracle) nicht alle Arten von Fehlern im DBMS-Trace. Es gibt viele Möglichkeiten, die SQL-Ablaufverfolgung zu aktivieren. In Devdattas Kommentar oben finden Sie Links zu weiteren Informationen.

Weitere Links: Tiefer graben - Beheben von Geoverarbeitungsfehlern bei Verwendung von ArcSDE-Daten

— Travis
quelle

Die Positionen für Trace und Intercept in diesem Diagramm sind falsch (Trace befindet sich in der API zwischen ArcSDE-Client und ArcSDE-Server und Intercepts zwischen Server und RDBMS). Anwendungsprotokollierung wie die Ausgabe von ArcGIS Server befindet sich zwischen der Clientanwendung und der ArcSDE-API.

— Vince

@Vince, ich denke es gibt hier einige Verwirrung. Ich habe das Diagramm aktualisiert, um meinen Standpunkt besser darzustellen. Der Befehl Trace-Listen, der an den SDE-Client (über die SDE-API), aber nicht unbedingt an den SDE-Server (z. B. SE_coordref_free, SE_shape_get_binary_size) ausgegeben wird. Der Intercept enthält Befehle, die einen Roundtrip zum SDE-Server auslösen, jedoch nicht unbedingt zum DBMS (z. B. QueryWithInfo, StreamSetState). Die Protokollierung zwischen SDE und DBMS ist abhängig vom DBMS und Verbindungstyp (OCI, OleDB, ODBC).

— Travis

Zugegeben, ASCII ist nicht die beste Methode, um dies zu veranschaulichen. Es wäre jedoch hilfreich, wenn die beiden "ArcSDE-Clients" als "ArcSDE-Client-API" und "ArcSDE-Server" gekennzeichnet wären. Der SDETRACE wird an der Schnittstelle zwischen der Client-App und der API erfasst (es werden Parameter zurückgemeldet, wenn sie die API in eine der beiden Richtungen durchlaufen). Ich glaube, SDEINTERCEPT befindet sich auf beiden Seiten der SES-Funktionsschnittstelle in der gsrvr-DLL (wie entweder vom Anwendungsserver oder von Direct Connect angegeben) und enthält sowohl Nachrichten, die von der API empfangen wurden, als auch Aufrufe an das DBMS (Verschieben des Abschnitts auf dem oberen Client) nach unten).

— Vince

Ja, die beiden SDE-Clients hatten einen Kopier- / Einfügefehler. Zur Laufzeit gibt es eigentlich keine API ... nur den Client (Thread (s) und den Speicher) und den Server (Thread (s) und den Speicher). Aber ich bin damit einverstanden, dass die SDETRACE-Echoparameter diesen Parameter überschreiten. Ich bin mir ziemlich sicher, dass das SDEINTERCEPT standardmäßig nichts mit dem DBMS direkt zu tun hat (zB SQL). Möglicherweise gab es andere Parameter, die die SQL-Protokollierung aktivierten, diese wurden jedoch für jedes DBMS unabhängig implementiert. Und ich weiß nicht was sie sind.

— Travis

Im Allgemeinen beschäftige ich mich nicht mit der Intercept-Ausgabe, sondern habe lediglich eine Reihe von API-Aufrufen ('sdelist -o levels') mit aktiviertem Trace und Intercept ausgeführt, und es scheint zwei Intercept-Dateien zu generieren (ohne die SQL-Interaktion I) Erinnert), so wie es aussieht, können wir uns darauf einigen :)

— Vince