Вы можете получить доступ к журналам предупреждений Oracle, файлам аудита и файлам трассировки с помощью консоли Amazon RDS или API. Дополнительную информацию о просмотре, загрузке и просмотре журналов базы данных на основе файлов см. в разделе Мониторинг файлов журналов Amazon RDS.
Предоставленные файлы аудита Oracle являются стандартными файлами аудита Oracle. Amazon RDS поддерживает функцию детального аудита (FGA) Oracle. Однако доступ к журналу не обеспечивает доступ к событиям FGA, которые хранятся в таблице SYS.FGA_LOG$ и доступны через представление DBA_FGA_AUDIT_TRAIL.
Операция API DescribeDBLogFiles, в которой перечислены файлы журналов Oracle, доступные для экземпляра БД, игнорирует параметр MaxRecords и возвращает до 1000 записей. Вызов возвращает LastWritten как дату POSIX в миллисекундах.
Ядро базы данных Oracle может менять файлы журналов, если они становятся очень большими. Чтобы сохранить файлы аудита или трассировки, загрузите их. Если вы храните файлы локально, вы снижаете затраты на хранение данных в Amazon RDS и освобождаете больше места для своих данных.
В следующей таблице показано расписание хранения журналов предупреждений Oracle, файлов аудита и файлов трассировки в Amazon RDS.
Журнал текстовых оповещений обновляется ежедневно, а срок хранения составляет 30 дней, которым управляет Amazon RDS. Журнал оповещений XML хранится не менее семи дней. Вы можете получить доступ к этому журналу, используя представление ALERTLOG.
Срок хранения файлов аудита по умолчанию составляет семь дней. Amazon RDS может удалить файлы аудита старше семи дней.
Срок хранения файлов трассировки по умолчанию составляет семь дней. Amazon RDS может удалить файлы трассировки старше семи дней.
Срок хранения журналов прослушивателя по умолчанию составляет семь дней. Amazon RDS может удалять журналы прослушивателей старше семи дней.
Файлы аудита и файлы трассировки имеют одинаковую конфигурацию хранения.
Далее вы можете найти описания процедур Amazon RDS для создания, обновления, доступа и удаления файлов трассировки.
Вы можете использовать любую из двух процедур, чтобы разрешить доступ к любому файлу по пути background_dump_dest. Первая процедура обновляет представление, содержащее список всех файлов, находящихся в настоящее время в background_dump_dest .
После обновления представления запросите следующее представление, чтобы получить доступ к результатам.
Альтернативой предыдущему процессу является использование таблицы FROM для потоковой передачи нереляционных данных в табличном формате для отображения содержимого каталога базы данных.
Следующий запрос показывает текст файла журнала.
На реплике чтения получите имя каталога BDUMP, запросив V$DATABASE.DB_UNIQUE_NAME . Если уникальное имя — DATABASE_B, то каталог BDUMP — BDUMP_B. Следующий пример запрашивает имя BDUMP в реплике, а затем использует это имя для запроса содержимого alert_DATABASE.log.2020-06-23 .
Поскольку на ALTER SESSION нет ограничений, многие стандартные методы создания файлов трассировки в Oracle остаются доступными для инстанса БД Amazon RDS. Следующие процедуры предусмотрены для файлов трассировки, которым требуется расширенный доступ.
Можно использовать множество стандартных методов для отслеживания отдельных сеансов, подключенных к экземпляру БД Oracle в Amazon RDS. Чтобы включить трассировку для сеанса, вы можете запускать подпрограммы в пакетах PL/SQL, предоставляемых Oracle, таких как DBMS_SESSION и DBMS_MONITOR. Дополнительные сведения см. в разделе Включение трассировки сеанса в документации Oracle.
Вы можете получить любой файл трассировки в background_dump_dest с помощью стандартного SQL-запроса к внешней таблице, управляемой Amazon RDS. Чтобы использовать этот метод, вы должны выполнить процедуру, чтобы задать местоположение этой таблицы для определенного файла трассировки.
Например, вы можете использовать упомянутое выше представление rdsadmin.tracefile_listing для вывода списка всех файлов трассировки в системе. Затем вы можете настроить представление tracefile_table так, чтобы оно указывало на нужный файл трассировки, используя следующую процедуру.
В следующем примере создается внешняя таблица в текущей схеме с расположением в указанном файле. Вы можете извлечь содержимое в локальный файл с помощью SQL-запроса.
Файлы трассировки могут накапливаться и занимать место на диске. Amazon RDS по умолчанию удаляет файлы трассировки и файлы журналов старше семи дней. Вы можете просмотреть и установить срок хранения файла трассировки с помощью процедуры show_configuration. Вам следует запустить команду SET SERVEROUTPUT ON, чтобы просмотреть результаты настройки.
В следующем примере показан текущий срок хранения файла трассировки, а затем задается новый срок хранения файла трассировки.
Помимо процесса периодической очистки, вы можете вручную удалить файлы из background_dump_dest .В следующем примере показано, как удалить все файлы старше пяти минут.
Вы также можете удалить все файлы, соответствующие определенному шаблону (если вы это сделаете, не указывайте расширение файла, например .trc). В следующем примере показано, как очистить все файлы, начинающиеся с SCHPOC1_ora_5935 .
Вы можете настроить инстанс Amazon RDS для Oracle DB для публикации данных журнала в группе журналов в Amazon CloudWatch Logs. С помощью CloudWatch Logs вы можете анализировать данные журналов и использовать CloudWatch для создания сигналов тревоги и просмотра показателей. Вы можете использовать CloudWatch Logs для хранения записей журнала в надежном хранилище.
Amazon RDS публикует каждый журнал базы данных Oracle в виде отдельного потока базы данных в группе журналов. Например, если вы настроите функцию экспорта для включения журнала аудита, данные аудита будут храниться в потоке журнала аудита в группе журналов /aws/rds/instance/my_instance/audit. RDS для Oracle поддерживает следующие журналы:
Этот журнал агента управления Oracle состоит из потоков журналов, показанных в следующей таблице.
| Имя журнала | Поток журнала CloudWatch |
|---|
| emctl.log | oemagent -emctl |
| emdctlj.log | oemagent-emdctlj |
| gcagent.log | oemagent-gcagent |
| gcagent_errors.log | oemagent-gcagent-errors |
| emagent .nohup | oemagent-emagent-nohup |
| secure.log | oemagent-secure |
< /таблица>
Чтобы опубликовать журналы Oracle DB в журналах CloudWatch из Консоли управления AWS
На панели навигации выберите Базы данных, а затем выберите экземпляр БД, который вы хотите изменить.
Выберите «Изменить».
В разделе «Экспорт журналов» выберите журналы, которые вы хотите начать публиковать в CloudWatch Logs.
Нажмите «Продолжить», а затем выберите «Изменить экземпляр БД» на странице сводки.
Чтобы опубликовать журналы Oracle, вы можете использовать команду modify-db-instance со следующими параметрами:
Изменение параметра --cloudwatch-logs-export-configuration всегда применяется к экземпляру БД немедленно. Поэтому параметры --apply-immediately и --no-apply-immediately не действуют.
Вы также можете публиковать журналы Oracle, используя следующие команды:
В следующем примере создается экземпляр Oracle DB с включенной публикацией CloudWatch Logs. Значение --cloudwatch-logs-export-configuration представляет собой массив строк JSON. Строки могут представлять собой любую комбинацию предупреждений, аудита, прослушивателя и трассировки.
Для Linux, macOS или Unix:
В следующем примере изменяется существующий экземпляр Oracle DB для публикации файлов журналов в CloudWatch Logs. Значение --cloudwatch-logs-export-configuration является объектом JSON. Ключом для этого объекта является EnableLogTypes , а его значением является массив строк с любой комбинацией предупреждений , аудита , прослушивателя и трассировки .
Для Linux, macOS или Unix:
В следующем примере изменяется существующий экземпляр Oracle DB, чтобы отключить публикацию файлов журнала аудита и прослушивателя в журналах CloudWatch. Значение --cloudwatch-logs-export-configuration является объектом JSON. Ключ для этого объекта — DisableLogTypes, а его значение — массив строк с любой комбинацией предупреждений, аудита, прослушивателя и трассировки.
Для Linux, macOS или Unix:
Вы можете публиковать журналы Oracle DB с помощью RDS API. Вы можете вызвать действие ModifyDBInstance со следующими параметрами:
Изменение параметра CloudwatchLogsExportConfiguration всегда немедленно применяется к экземпляру БД. Поэтому параметр ApplyImmediately не действует.
Вы также можете опубликовать журналы Oracle, вызвав следующие операции RDS API:
Выполните одну из этих операций RDS API со следующими параметрами:
В зависимости от выполняемой операции RDS могут потребоваться другие параметры.
Предыдущие методы доступа к журналам оповещений и журналам прослушивателей
Просмотреть журнал оповещений можно с помощью консоли Amazon RDS. Вы также можете использовать следующую инструкцию SQL для доступа к журналу предупреждений.
Представление listenerlog содержит записи для Oracle Database версии 12.1.0.2 и более ранних версий. Чтобы получить доступ к журналу прослушивания для этих версий базы данных, используйте следующий запрос.
Для Oracle Database версии 12.2.0.1 и более поздних версий доступ к журналу прослушивателя можно получить с помощью Amazon CloudWatch Logs.
Oracle чередует журналы предупреждений и прослушивателей, когда они превышают 10 МБ, после чего они становятся недоступными в представлениях Amazon RDS.
Существует несколько способов найти журнал предупреждений Oracle, связанный с базой данных Oracle. С этой точки зрения виртуальные базы данных, подготовленные с помощью платформы динамических данных Delphix, ведут себя точно так же, как и любая другая база данных Oracle. Этими же методами можно найти журнал предупреждений.Обсуждаются различные методы, с помощью которых администраторы Delphix Dynamic Data Platform могут найти журнал предупреждений Oracle VDB, чтобы помочь в устранении неполадок, связанных с базой данных, возникающих в подготовленной Delphix VDB.
Использование ORACLE_BASE
Журнал предупреждений VDB не зависит от доступности базы данных и не хранится в Delphix. По умолчанию он должен располагаться в $ORACLE_BASE/diag или в диагностическом месте, предварительно определенном самим Oracle в Oracle 11.2 и более поздних версиях. Переменная среды ORACLE_BASE устанавливается всякий раз, когда пользовательская среда ОС устанавливается с помощью утилиты Oracle oraenv. Этот метод можно использовать даже в тех случаях, когда Delphix VDB не включена или не запущена.
Например:
Если вы установите среду пользователя Oracle с помощью oraenv на узле, на котором работает VDB, для вас будет установлена переменная среды ORACLE_BASE. Это зависит от записи, существующей для ORACLE_HOME, используемой VDB в /etc/oratab или /var/opt/oracle/oratab, в зависимости от используемой платформы ОС.
Используя запись db112, которая использует тот же ORACLE_HOME, что и моя VDB, vdb1, расположение журнала предупреждений будет
$ORACLE_BASE/diag/rdbms/ / /trace/alert_ .log
Динамическое представление производительности v$diag_info
В случаях, когда VDB запущена и работает, местоположение журнала предупреждений можно определить с помощью запроса к динамическому представлению производительности Oracle v$diag_info.
Например:
В этом примере журнал предупреждений будет расположен в /u01/app/oracle/diag/rdbms/vdb1/vdb1/trace и будет называться alert_vdb1.log.
Параметр базы данных Oracle background_dump_dest
В версиях, предшествующих Oracle 11g, расположение журнала предупреждений определяется параметром базы данных background_dump_dest. Этот параметр все еще существует в 11.2 и более поздних версиях. Однако настройка местоположения журнала предупреждений менее распространена, учитывая практику Oracle по централизации и управлению точками сбора диагностических данных. В работающих версиях VDB, более ранних, чем Oracle RDBMS 12.1, его все еще можно использовать для поиска журнала предупреждений, если VDB доступна и работает.
Например:
Использование ADRCI (командный интерфейс автоматического диагностического репозитория)
Прекрасный новый мир ADRCI можно использовать для поиска базы данных ORACLE_BASE, в которой находится централизованная коллекция диагностических данных.
Например:
adrci> показать базу
базой ADR является "/u01/app/oracle"
Чтобы найти расположение диагностики для определенной VDB
Чтобы просмотреть содержимое журнала предупреждений, используйте команду show alert adrci. По умолчанию будет выполнен переход к началу журнала предупреждений.
Расположение журнала предупреждений Oracle может различаться в зависимости от версии, и иногда его нелегко найти. Однако обычно он находится в 3 местах.
Для версии 11g и более поздних (12c, 18c, 19c)
Как мы можем заметить, программное обеспечение Oracle делит журналы предупреждений на отдельные выделенные каталоги в соответствии с уникальными именами их баз данных, которые основаны на структуре каталогов диагностического репозитория.
Для 9i и 10g
Для остальных случаев без зацепок
Это тот же способ определения DIAGNOSTIC_DEST .
Формат имени файла журнала предупреждений
Несмотря на то, что его расположение может варьироваться от версии к версии, имя файла журнала предупреждений всегда будет таким:
Иногда вы нигде не можете найти файл журнала предупреждений. Теперь давайте посмотрим, как мы можем его найти.
3 способа найти местоположение журнала предупреждений Oracle
Здесь я представляю три способа найти правильное расположение журнала предупреждений Oracle.
1. Назначение фонового дампа
Если вы являетесь администратором баз данных, вы можете запросить значение BACKGROUND_DUMP_DEST , параметра инициализации, где вы можете найти журнал предупреждений Oracle.
SQL> показать параметр background_dump_dest;
SQL> выберите значение из параметра v$, где имя = 'background_dump_dest';
Если вы не можете запросить базу данных, вы все равно можете найти расположение журнала предупреждений на уровне ОС.
2. Использование команды «Найти»
Почти во всех UNIX и Linux есть команда find, поэтому ее использование для поиска некоторых файлов является очень распространенным способом.
[oracle@test ~]$ find $ORACLE_BASE -type f -name alert_$ORACLE_SID.log
/u01/app/oracle/diag/rdbms/orcl/ORCL/trace/alert_ORCL.log
Мы находим файл с именем alert_$ORACLE_SID.log, начиная с $ORACLE_BASE . Как видим, файл найден.
3. Использование команды «Найти»
Иногда использование команды locate будет быстрее, чем find, чтобы найти путь к файлу журнала предупреждений.
[oracle@test ~]$ locate alert_$ORACLE_SID.log
/u01/app/oracle/diag/rdbms/orcl/ORCL/trace/alert_ORCL.log
В некоторых базах данных журналы предупреждений имеют большой размер, возможно, слишком большой, чтобы освободить место для других файлов. Мы должны знать, как уменьшить размер журналов предупреждений.
Для справки, способы найти местоположение журнала прослушивателя немного отличаются от способов, которыми мы находим журнал предупреждений Oracle. Вы можете посмотреть.
Файл журнала предупреждений (также называемый ALERT.LOG) представляет собой хронологический журнал сообщений и ошибок, записываемых базой данных Oracle. Типичными сообщениями в этом файле являются запуск базы данных, завершение работы, переключение журнала, ошибки пространства и т. д. Этот файл следует постоянно отслеживать для обнаружения непредвиденных сообщений и повреждений.
Oracle будет автоматически создавать новый файл журнала предупреждений при каждом удалении старого.
Расположение журнала предупреждений
Местоположение можно узнать с помощью параметра background_dump_dest
Начиная с версии 11g файл журнала предупреждений записывается в формате XML и в виде текстового файла (как и в предыдущих версиях). Расположение обоих этих файлов по умолчанию — новый дом ADR (автоматический диагностический репозиторий, еще одно новое место назначения дампа в 11g).
ADR задается с помощью параметра инициализации DIAGNOSTIC_DEST. Но вы все равно можете найти местоположение журнала предупреждений, используя параметр background_dump_dest.
background_dump_dest задается как
Новые функции 11g Alert log
Начиная с версии 11g базы данных Oracle, журнал предупреждений записывается как в виде файла в формате XML, так и в виде текстового файла, как и в более ранних версиях. Оба эти файла журнала хранятся в доме ADR. Корневой каталог ADR известен как ADR BASE. Автоматический диагностический репозиторий (ADR) — это структура каталогов, которая хранится вне базы данных. Этот параметр задается параметром инициализации DIAGNOSTIC_DEST.
Расположение дома ADR определяется следующим путем, который начинается с базового каталога ADR:
Например,
Так для СУБД oracle Home of Database имя XPROD
В домашнем каталоге ADR есть подкаталоги, в которых экземпляр базы данных хранит диагностические данные.
Файл журнала предупреждений, журнал предупреждений в формате XML, трассировка Файлы трассировки фонового и серверного процессов и файлы трассировки SQL, текстовый файл alert.log , cдамп основных файлов
Alert.log в формате XML
Журнал предупреждений называется log.xml и хранится в подкаталоге предупреждений домашней страницы ADR.
Чтобы получить путь к файлу log.xml
Утилита ADRCI для просмотра текстовой версии журнала предупреждений (с удаленными тегами XML)
Alert.log в текстовом формате
Файл alert.log называется alertSID.log и хранится в подкаталоге trace домашней страницы ADR.
Чтобы просмотреть текстовый файл alert.log
Откройте файл alert_SID.log в текстовом редакторе
В версии 11g Oracle также позволяет просматривать файл журнала предупреждений из базы данных. Существует фиксированная таблица X$DBGALERTEXT, когда вы запрашиваете ее, Oracle читает log.xml из каталога предупреждений (который содержит все данные, что делает alert.log), анализирует его и возвращает детали обратно в виде строк:
Есть также фиксированная таблица X$DBGDIREXT, которая возвращает все имена файлов и каталогов в каталоге [diagnostic_dest]/diag:
12c или выше Оповещение регистрирует новые функции
В версии 12c и более поздних версиях background_dump_dest устаревает. Мы можем найти местоположение журнала предупреждений, используя также ниже
как проверить ошибки журнала предупреждений в oracle с помощью команды Unix
Перейдите в каталог фонового дампа, чтобы запустить эти команды unix
Дата и ошибки в файле alert.log
Как найти дату запуска в файле alert.log
Как легко найти время запуска и завершения работы базы данных Oracle с помощью sqlplus
Вот шаги, необходимые для того, чтобы легко найти время запуска и завершения работы базы данных Oracle с помощью sqlplus
шаг 1) Создайте объект каталога базы данных
Читайте также:
