Использование ODBC Trace или Oracle Trace для поиска причины ошибки?

Question

У меня есть сторонняя служба Windows, которая контролирует / контролирует оборудование и обновляет базу данных Oracle. Их службы иногда сообщают об ошибке, что строка / столбец в базе данных является «плохой», но не дают основной ошибки базы данных, и их службы должны быть перезапущены, и все в порядке. В настоящее время подозрение заключается в том, что что-то из наших приложений / сервисов, которые читают / пишут в те же самые таблицы / строки, мешает - то есть какая-то блокировка / блокировка. Я подозреваю, что в их системе есть какая-то утечка, так как это происходит примерно раз в неделю, но наши системы никогда не нуждаются в перезапуске, подобном этому.

Я попытался заставить администратора базы данных выполнить трассировку в Oracle (10g), но это не позволило нашим приложениям получить доступ к базе данных Oracle. Наши системы обращаются к Oracle в .NET либо через клиент Oracle ODP, либо через клиент Microsoft (старые программы) и на этом же сервере (веб-приложения или службы), либо с других рабочих станций управления. Сторонние сервисы подключаются к Oracle через ODBC на этом сервере. Я также попытался запустить трассировку ODBC (поскольку это было бы только из сторонней службы), но вообще ничего не получил в файле трассировки.

Итак, я пытаюсь найти способ заставить работать трассировку ODBC или то, что мне нужно, чтобы трассировка Oracle не убивала мой сервер.

Я ищу неоправданную ошибку, которую Oracle возвращает сторонней службе, чтобы я мог сказать, не вмешиваемся ли мы каким-либо образом в их доступ к данным.

Answer 1

Если блок в базе данных поврежден «Плохо», это должно отображаться в журналах предупреждений как ошибка ORA-01578. Я бы искал в архивном журнале ошибку ORA, а затем сравнил ее с отметкой времени на сообщаемой ошибке клиента. Это делает предположение об определении «плохо». Было бы лучше иметь точные сообщения об ошибках.

Общая трассировка в базе данных - сложная задача, поскольку она может повлиять на производительность всего приложения. И оставить его включенным на всю неделю может быть неосуществимо. Я также нашел в одном случае (не могу вспомнить точное обстоятельство), когда включение трассировки исправило ошибку.

Один метод, который я использовал в прошлом, - это добавление оператора sql для изменения сеанса и включения sqltrace. Это основано на способности каким-либо образом модифицировать код. В зависимости от применения это может или не может быть возможно.

Другим методом будет работа с администратором базы данных для определения сеанса и включения трассировки sql для этого сеанса. Кроме того, если вы сможете определить ошибочные операторы SQL и значения параметров, вы сможете повторить проблему за пределами службы.

Я обнаружил, что большинство ORM избегают передачи ошибки ORA. Однако обычно он регистрируется на уровне сервера приложений со связанной ошибкой ORM.

Я использовал этот метод и его варианты для устранения ошибок в приложении. Я надеюсь, что это полезно.