Как отследить SQL-запросы, отправленные ArcGIS Server (ArcSDE) к базе данных Oracle?

Я хотел бы создать файл журнала, содержащий все запросы SQL, отправленные ArcGIS Server (ArcSDE) в базу данных Oracle. Есть ли способ сделать это? Я использую Oracle 11g и ArcGIS Server 10.0 в Windows. ArcSDE используется в прямом соединении.

— yo_haha
источник

Вы можете использовать Oracle отслеживания и аудита. Посмотрите на этот вопрос: stackoverflow.com/questions/7914354/oracle-sql-query-logging

— Devdatta Tengshe

Вы можете использовать Toad Quest для журнала отслеживания в реальном времени.

На самом деле существует несколько способов отслеживания любого соединения ArcSDE. Вызовы между клиентским приложением и клиентом ArcSDE регистрируются в файле трассировки SDE, между клиентом ArcSDE и сервером в файле перехвата SDE, сервер ArcSDE регистрирует определенные события в журнале сервиса или прямого подключения, а вызовы базы данных регистрируются в системе. файлы журналов СУБД.

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

Файлы трассировки ArcSDE регистрируют каждый вызов, сделанный клиенту ArcSDE. Эти файлы обычно большие и шумные. Посмотрите на SDETraceLoc и SDETraceMode в справке по dbinit . Эти значения также могут быть установлены как переменные среды перед запуском приложения, это работает для приложения и прямых подключений.

Файлы ArcSDE Intercept обычно более полезны. Они покажут, сколько времени тратится на какой звонок. Однако, предупреждая, SDE работает над концепцией потоков. Некоторые команды (например, вставки, обновления и удаления) устанавливают информацию о потоке, а затем выполняют команду. Обычно номер потока является первым целым числом после команды в файле перехвата. Это может сбить с толку, если у вас много потоков (я видел до 26 потоков). Вы можете посмотреть SDEIntercept и SDEInterceptLoc в справке dbinit или этой статье базы знаний о файлах перехвата SDE для получения дополнительной информации и примеров.

Файлы журналов сервиса ArcSDE в папке% SDE_HOME% \ etc или файлы журналов прямого подключения в папках% SDE_HOME% \ etc или% TEMP% содержат общую информацию о том, что происходит с сервисом или соединением. Количество регистрируемой информации может быть увеличено с помощью переменной SDEVerbose ( dbinit help ).

Лог-файлы и трассировки СУБД очень полезны. Но они только дают вам часть картины. Кроме того, некоторые базы данных (например, Oracle) фактически не включают все типы ошибок в трассировку СУБД. Есть много способов включить трассировку SQL, комментарий Devdatta выше ссылается на дополнительную информацию.

Другие ссылки: Копаем глубже - Устранение ошибок геообработки при использовании данных ArcSDE

— Трэвис
источник

Местоположения трассировки и перехвата на этой диаграмме неверны (трассировка находится внутри API между клиентом ArcSDE и сервером ArcSDE, а перехваты находятся между сервером и RDBMS). Ведение журнала приложения, такого как вывод ArcGIS Server, находится между клиентским приложением и ArcSDE API.

— Винс

@ Винс, я думаю, здесь какая-то путаница. Я обновил диаграмму в попытке лучше проиллюстрировать мою точку зрения. Команда Trace lists, которая выдается клиенту SDE (через API SDE), но не обязательно серверу SDE (например, SE_coordref_free, SE_shape_get_binary_size). Перехват содержит команды, которые запускают двустороннюю передачу на сервер SDE, но не обязательно СУБД (например, QueryWithInfo, StreamSetState). Ведение журнала между SDE и СУБД зависит от СУБД и типа соединения (OCI, OleDB, ODBC).

— Трэвис

Конечно, ASCII - не лучший способ представить это, но было бы полезно, если бы два «клиента ArcSDE» были помечены как «ArcSDE Client API» и «ArcSDE Server». SDETRACE фиксируется на интерфейсе между клиентским приложением и API (повторяя параметры, когда они пересекают API в любом направлении). Я полагаю, что SDEINTERCEPT находится по обе стороны от интерфейса функции SES в DLL-библиотеке gsrvr (как проявляется либо сервером приложений, либо Direct Connect), и включает в себя как сообщения, полученные от API, так и вызовы, сделанные в СУБД (переместить перехват на верхнем клиенте к нижней части ниже).

— Винс

Да, два клиента SDE были ошибкой копирования-вставки. Во время выполнения на самом деле не существует API ... только клиент (поток (ы) и память) и сервер (поток (ы) и память). Но я согласен, что SDETRACE отражает параметры, когда они пересекают это. Я совершенно уверен, что по умолчанию SDEINTERCEPT не регистрирует ничего, связанного с СУБД напрямую (например, SQL). Возможно, были другие параметры, которые включали ведение журнала SQL, но они были бы реализованы независимо для каждой СУБД. И я не знаю кто они.

— Трэвис

Обычно я не смотрю на выходные данные перехвата, но я просто выполнил простой набор вызовов API ('sdelist -o layer') с включенными трассировкой и перехватом, и, похоже, он генерирует два файла перехвата (без взаимодействия с SQL, которое я вспомнил), так что похоже, мы можем договориться об этом :)

— Винс