Як простежити SQL запити, надіслані сервером ArcGIS (ArcSDE) до бази даних Oracle?

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

— йо_хаха
джерело

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

— Devdatta Tengshe

Ви можете використовувати Toad Quest для журналу відстеження в реальному часі.

Насправді існує кілька способів відстеження будь-якого з'єднання ArcSDE. Виклики між клієнтською програмою та клієнтом ArcSDE реєструються у файлі відстеження SDE, між клієнтом ArcSDE та сервером у файлі SDE Intercept, сервер 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 зазвичай корисніші. Вони покажуть, який час витрачається на який дзвінок. Хоча слово обережності, SDE працює над концепцією потоків. Окремі команди (наприклад, вставки, оновлення та видалення) встановлюють інформацію в потоці, а потім виконують команду. Зазвичай номер потоку - це перше ціле число після команди у файлі перехоплення. Це може заплутатися, якщо у вас багато потоків (я бачив до 26 потоків). Ви можете переглянути SDEIntercept та SDEInterceptLoc у довідці про dbinit або цю статтю KB про файли SDE Intercept для отримання додаткової інформації та прикладів.

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

Журнали та сліди СУБД дуже корисні. Але вони дають вам лише частину картини. Крім того, деякі бази даних (наприклад, Oracle) насправді не включають всі типи помилок у трасі СУБД. Існує багато способів включити відстеження SQL, коментар Devdatta вище посилання на додаткову інформацію.

Інші посилання: Копати глибше - Усунення помилок геопроцедури при використанні даних ArcSDE

— травіс
джерело

Місця простеження та перехоплення на цій діаграмі неправильні (трасування знаходиться всередині API між клієнтом ArcSDE та сервером ArcSDE, а перехоплення - між сервером та RDBMS). Журнал додатків, такий як вихід сервера ArcGIS, знаходиться між клієнтською програмою та API ArcSDE.

— Вінс

@Вінсе, я думаю, тут є деяка плутанина. Я оновив діаграму, намагаючись краще проілюструвати свою думку. Команда списку слідів, яка видається клієнту SDE (через API SDE), але не обов'язково серверу SDE (наприклад, SE_coordref_free, SE_shape_get_binary_size). Intercept містить команди, які запускають зворотну поїздку до сервера SDE, але не обов'язково СУБД (наприклад, QueryWithInfo, StreamSetState). Журнал між SDE та СУБД залежить від СУБД та типу з'єднання (OCI, OleDB, ODBC).

— travis

Зрозуміло, ASCII - це не найкращий спосіб діаграми, але це допоможе, якщо два "клієнта ArcSDE" були позначені "ArcSDE Client API" і "ArcSDE Server". SDETRACE фіксується на інтерфейсі між клієнтською програмою та API (повторювані параметри, коли вони перетинають API в будь-якому напрямку). Я вважаю, що SDEINTERCEPT живе по обидва боки інтерфейсу функції SES в DLS gsrvr (як проявляється або сервером додатків або Direct Connect), і включає в себе як повідомлення, отримані з API, так і виклики до СУБД (переміщення перехоплення на верхньому клієнті донизу нижній).

— Вінс

Так, два клієнта SDE були помилкою копіювання вставки. Під час виконання, насправді не існує API ... просто клієнт (нитка (і) та пам'ять) та сервер (нитки (і) та пам'ять). Але я згоден, що параметри SDETRACE повторюються, коли вони перетинають це. Я цілком впевнений, що за замовчуванням SDEINTERCEPT не записує нічого спільного зі СУБД безпосередньо (наприклад, SQL). Можливо, були й інші параметри, які включали реєстрацію SQL, але вони будуть реалізовані незалежно для кожної СУБД. І я не знаю, що вони.

— travis

Я, як правило, не дивлюся на вихід перехоплення, але я просто запустив простий набір викликів API ('sdelist -o-шари') з включеними і слідами, і перехопленням, і, схоже, генерує два перехоплюючі файли (без взаємодії SQL I згадав), тож, схоже, ми можемо з цим погодитися :)

— Vince