Jak śledzić zapytania SQL wysłane przez ArcGIS Server (ArcSDE) do bazy danych Oracle?

12

Chciałbym wygenerować plik dziennika zawierający wszystkie zapytania SQL wysłane przez ArcGIS Server (ArcSDE) do bazy danych Oracle. Czy jest na to sposób? Używam Oracle 11g i ArcGIS Server 10.0 w systemie Windows. ArcSDE jest używany w połączeniu bezpośrednim.

arcgis-10.0 arcgis-server sql oracle-11g log yo_haha
źródło
3
Możesz korzystać ze śledzenia i kontroli Oracle. Spójrz na to pytanie: stackoverflow.com/questions/7914354/oracle-sql-query-logging
Devdatta Tengshe
Możesz użyć Toad Quest do dziennika śledzenia w czasie rzeczywistym.

Odpowiedzi:

13

Istnieje wiele sposobów śledzenia dowolnego połączenia ArcSDE. Połączenia między aplikacją kliencką a klientem ArcSDE są rejestrowane w pliku śledzenia SDE, między klientem ArcSDE a serwerem w pliku przechwytywania SDE, serwer ArcSDE rejestruje określone zdarzenia w usłudze lub dziennik bezpośrednich połączeń, a połączenia z bazą danych są rejestrowane pliki dziennika 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
|                |  
------------------

Pliki śledzenia ArcSDE rejestrują każde wywołanie klienta ArcSDE. Te pliki są zwykle duże i głośne. Spójrz na SDETraceLoc i SDETraceMode w pomocy dbinit . Wartości te można również ustawić jako zmienne środowiskowe przed uruchomieniem aplikacji, działa to w przypadku aplikacji i bezpośrednich połączeń.

Pliki ArcSDE Intercept są zwykle bardziej pomocne. Pokażą, ile czasu spędza w jakim połączeniu. Uwaga: SDE działa na zasadzie strumieni. Niektóre polecenia (takie jak wstawianie, aktualizacje i usuwanie) ustawiają informacje w strumieniu, a następnie wykonują polecenie. Zwykle numer strumienia jest pierwszą liczbą całkowitą po poleceniu w pliku przechwytującym. Może to być mylące, jeśli masz wiele strumieni (widziałem do 26 strumieni). Możesz spojrzeć na SDEIntercept i SDEInterceptLoc w pomocy dbinit lub w tym artykule KB na temat plików SDE Intercept, aby uzyskać więcej informacji i przykładów.

Pliki dziennika usługi ArcSDE w folderze% SDE_HOME% \ etc lub pliki dziennika bezpośredniego połączenia w folderach% SDE_HOME% \ etc lub% TEMP% zawierają ogólne informacje o tym, co dzieje się z usługą lub połączeniem. Ilość rejestrowanych informacji można zwiększyć za pomocą zmiennej SDEVerbose ( pomoc dbinit ).

Pliki logów i śladów DBMS są bardzo przydatne. Ale dają tylko część obrazu. Ponadto niektóre bazy danych (np. Oracle) w rzeczywistości nie uwzględniają wszystkich typów błędów w śledzeniu DBMS. Istnieje wiele sposobów włączenia śledzenia SQL. Komentarz Devdatty powyżej prowadzi do dodatkowych informacji.

Inne linki: Głębsze kopanie - Rozwiązywanie problemów z błędami geoprzetwarzania podczas korzystania z danych ArcSDE

Travis
źródło
Lokalizacje śledzenia i przechwytywania na tym diagramie są niepoprawne (śledzenie znajduje się w interfejsie API między klientem ArcSDE a serwerem ArcSDE, a przechwytywanie znajduje się między serwerem a RDBMS). Rejestrowanie aplikacji, takie jak dane wyjściowe ArcGIS Server, znajduje się między aplikacją kliencką a interfejsem API ArcSDE.
Vince
@Vince, myślę, że jest tu trochę zamieszania. Zaktualizowałem schemat, próbując lepiej zilustrować mój punkt widzenia. Polecenie Trace list, które jest wydawane klientowi SDE (za pośrednictwem interfejsu API SDE), ale niekoniecznie serwerowi SDE (np. SE_coordref_free, SE_shape_get_binary_size). Przechwytywanie zawiera polecenia, które wyzwalają podróż powrotną do serwera SDE, ale niekoniecznie do DBMS (np. QueryWithInfo, StreamSetState). Rejestrowanie między SDE a DBMS zależy od DBMS i typu połączenia (OCI, OleDB, ODBC).
travis
To prawda, że ​​ASCII nie jest najlepszym sposobem na zilustrowanie tego, ale pomogłoby, gdyby dwa „Klient ArcSDE” były oznaczone jako „ArcSDE Client API” i „ArcSDE Server”. SDETRACE jest przechwytywany na interfejsie między aplikacją kliencką a interfejsem API (parametry echa, gdy przekraczają interfejs API w dowolnym kierunku). Wierzę, że SDEINTERCEPT żyje po obu stronach interfejsu funkcji SES w bibliotece DLL gsrvr (co manifestuje się albo na serwerze aplikacji, albo na Direct Connect), i obejmuje zarówno wiadomości otrzymane z interfejsu API, jak i wywołania wykonane do DBMS (przenieś przechwytywanie na górnym kliencie na dole dolnej).
Vince
Tak, dwa klienty SDE były błędem kopiowania wklejanego. W czasie wykonywania nie ma tak naprawdę interfejsu API ... tylko klient (wątki i pamięć) oraz serwer (wątki i pamięć). Ale zgadzam się, że parametry echa SDETRACE przechodzą przez to. Jestem całkiem pewien, że domyślnie SDEINTERCEPT nie rejestruje nic związanego bezpośrednio z DBMS (np. SQL). Mogły istnieć inne parametry, które włączały rejestrowanie SQL, ale byłyby one implementowane niezależnie dla każdego DBMS. I nie wiem co to jest.
travis
Zasadniczo nie patrzę na dane wyjściowe przechwytywania, ale właśnie uruchomiłem prosty zestaw wywołań API („sdelist -o layer”) z włączoną funkcją śledzenia i przechwytywania, i wydaje się, że generuje dwa pliki przechwytywania (bez interakcji SQL I zapamiętane), więc wygląda na to, że możemy się z tym zgodzić :)
Vince