Как и любая другая сложная функциональность Oracle нижнего уровня, FGA может время от времени работать неожиданным образом. В этом разделе будут описаны наиболее часто встречающиеся ошибки, связанные с FGA, и способы их обработки. Я не буду говорить о дефектах собственно FGA - опубликованных или неопубликованных, которые могут влиять на его поведение. Они обычно зависят от выбора платформы и имеют преходящий характер. Поэтому мы сосредоточимся на ошибках, возникающих при типичном использовании FGA.
При возникновении какой-то проблемы с FGA в каталоге, определенном параметром инициализации базы данных USER_DUMP_DEST, формируется файл трассировки. Этот файл содержит важную информацию о точном условии возникновения ошибки и предлагает подсказки для ее дальнейшей диагностики. Рассмотрим фрагмент такого файла трассировки:
Две последние (выделенные жирным шрифтом) строки сообщают два важных факта:
• Имя политики - в данном случае EMP_DML.
• Ошибка - в данном случае FGA поддерживает только простые предикаты.
Ошибка возникла, когда пользователь обновлял таблицу. Чтобы увидеть условие аудита, выполним такой оператор:
Условие аудита в этой политике, SALARY >= 1500 or EMPID=304, включает в себя несколько условий и не является простым предикатом. Сообщение об ошибке подтверждает наши наблюдения. Решение чрезвычайно просто: следует пересоздать политику с простым предикатом, таким как SALARY >= 1500 или EMPID=304, но не с обоими условиями одновременно. Политики со сложными предикатами работают для операторов SELECT, но не для операторов DML.
В некоторых случаях FGA генерирует ошибки «молча», то есть не информируя пользователя о возникновении ошибок. Рассмотрим следующий пример: модуль обработки (если он определен) завершается с ошибкой для некоторых строк. В этом случае пользователь не получает никаких данных об ошибке. Кроме того, строки, для которых модуль обработки не выполнился, не возвращаются в результате пользовательского запроса, а пользователь и не подозревает о том, что какие- то строки не возвращены. В подобном случае запись в журнале трассировки является единственным свидетельством возникновения ошибки. Приведем фрагмент файла трассировки:
Фрагмент состоит из двух частей. Первая идет от начала и заканчивается второй строкой дат *** 2005-07-12 17:52:32.891, указывающей момент первого возникновения ошибки. Строки второй части отображают истинную ошибку. Обратите внимание на выделенную жирным шрифтом строку: Error Number 2: 1438. Эта ошибка является истинной причиной того, что операция не была выполнена успешно. Код ошибки можно найти при помощи утилиты oerr:
Теперь причина ошибки ясна: модуль обработки пытался вставить в столбец значение, превышающее допустимое для данного столбца. Изменение значения приведет к исчезновению ошибки.
Последняя ошибка убеждает нас в следующем: если вы включаете детальный аудит для какой-то таблицы базы данных, обязательно просматривайте файлы трассировки (которые хранятся в каталоге, определенном параметром инициализации базы данных USER_DUMP_DEST) для отлавливания «безмолвных» ошибок. Возможно, вы и так уже просматриваете файлы трассировки, но теперь появляется дополнительная причина не забывать об этом.
| < Предыдущая | Следующая > |
|---|
