Где находится log listener oracle
Обновлено: 07.07.2024
Листенер по команде STATUS сообщает о себе массу информации, включая:
Простейший метод удаленной отправки команд листенера, это использование lsnrctl в командной строке с параметрами:
lsnrctl < команда > IP адрес
lsnrctl status 192.168.1.100
lsnrctl stop 192.168.1.100
Для защиты листенера существуют несколько параметров, которые повышают его безопасность.
Установка пароля листенера
Эта мера является обязательной и позволит остановить большинство попыток атак. Обычно это простой процесс, вам требуется установить пароль в lsnrctl, который будет хранится в файле listener.ora в зашифрованном виде, или установить параметр PASSWORDS_, тогда пароль будет хранится в открытом виде.
LS NRCTL> set current_listener <имя_листенера>
LSNRCTL> change_password
Old password: <нажать ввод если старого пароля не было>
New password: <указать новый пароль>
Reenter new password: <повторить ввод нового пароля>
LSNRCTL> set password
Password: <указать пароль>
LSNRCTL> save_config
Проверяете файл listener.ora на наличие параметра PASSWORDS_. Важно помнить, что в версиях Oracle до 10g можно использовать как обычный пароль так и зашифрованную строку пароля.
Локальная авторизация на уровне ОС
TNS-01190: The user is not authorized to execute the requested commend
TNS-01189: The listener could not authenticate the user
Локальная аутентификация может быть отключена установкой параметра LOCAL_OS_AUTHENTICATION_ в файле listener.ora:
Включение журналирования
Мера так же является обязательной, это позволит определить атаки, выполнение команд и попытки подбора пароля перебором.
Установка ADMIN_RESTRICTIONS в LISTENER.ORA
Действие является обязательным, и позволяет запретить любые изменения листенера во время работы. Достигается установкой параметра ADMIN_RESTRICTIONS_ в значение ON в файле listener.ora. Этот параметр позволит запретить исполнение команд set и все изменения в работу листенера можно будет внести только вручную в файл listener.ora.
П осле перезапускаете листенер выполнив команду reload в lsnrctl, для того что бы изменения вступили в силу. Все последующие изменения можно будет делать только вручную в файле listener.ora, не используя команду set в lsnrctl. После внесения изменений в файл listener.ora используйте команду reload или stop и start в lsnrctl.
Защита директории $ORACLE_HOME /network/admin
Эта мера призвана ограничить разрешения на исполняемые файлы tnslsnr и lsnrctl. Они расположены в директории $ORACLE_HOME/bin, и разрешения на них, в *NIX системах, по рекомендации Oracle должны быть выставлены в 0751. Возможно изменить разрешения на 0700, что более обезопасит файлы, но это можно делать только после тщательной проверки на тестовых средах.
ORACLE очищает и обрезает файл журнала монитора (listener.log)
В базе данных ORACLE, если файл журнала прослушивателя (listener.log) не усечен, файл журнала прослушивателя (listener.log) будет становиться все больше и больше, предположительно Многие люди слышали о том, что «размер журнала LISTENER.LOG не может превышать 2 ГБ, что приведет к тому, что прослушиватель LISTENER не сможет обрабатывать новые соединения». Конечно, это неправда и не будет абсолютно появился, но это произошло только в старой 32-битной системе Linux или Unix. Настоящая причина в том, что встроенная файловая система некоторых 32-битных ОС не поддерживает файлы размером более 2 ГБ, что приводит к мониторингу Сервисный процесс (tnslsnr) добавить ошибку записи журнала.
Так разве нет необходимости вырезать и поддерживать файлы журнала мониторинга? ответ отрицательный. Конечно, файл журнала прослушивателя (listener.log) необходимо регулярно чистить. Если вы не очищаете его регулярно, вы столкнетесь со следующими проблемами:
1: файл журнала прослушивателя (listener.log) становится все больше и больше, занимая дополнительное место для хранения. (Конечно, цена на капусту сейчас хранится, что неплохо для этих нескольких гигабайт места. Но мы все равно должны продолжать совершенствоваться в духе мастерства)
2: файл журнала прослушивания (listener.log) становится слишком большим, что вызовет некоторые проблемы: размер журнала LISTENER.LOG не может превышать 2 ГБ, и если он превышает, прослушиватель LISTENER не может обрабатывать новые соединения.
3: файл журнала прослушивателя (listener.log) становится слишком большим, что вызывает некоторые проблемы с производительностью и затрудняет запись и просмотр.
Также сказано, что процесс службы мониторинга обычно использует стандартную функцию C Write для записи в Listener.log, а файл listener.log использует O_WRONLY | O_CREAT | O_APPEND, O_APPEND добавляется в конец файла. Вообще говоря, метод записи с добавлением не будет медленнее из-за большего размера файла. Если оставить в стороне этот , поиск определенного дня или определенной ошибки в большом файле журнала прослушивания (listener.log), это действительно вызывает некоторые проблемы с производительностью. Найти его тоже довольно хлопотно.
Следовательно, файл журнала слушателя (listener.log) следует регулярно очищать.Еще один способ сказать это - усечение файла журнала. Что касается усечения журнала монитора, следует отметить некоторые проблемы. Когда я изучал ORACLE, я обнаружил ошибку при усечении журнала монитора. Давайте продемонстрируем
Как показано выше, после усечения журнала мониторинга (listener.log) процесс службы мониторинга (tnslsnr) не записывает новую информацию мониторинга в listener.log, но продолжает запись listener.log.20150114
Правильный процесс должен выполняться следующим образом:
Шаг 1. Сначала остановите процесс службы мониторинга (tnslsnr) для записи журналов.
Шаг 2. Скопируйте файл журнала прослушивателя (listener.log) и назовите его в формате listener.log.yyyymmdd.
Шаг 3: Очистите файл журнала приемника (listener.log). Есть много способов очистить файлы
3.1 echo “” > filename
3.2 cp / dev / null или echo / dev / null> имя файла
Шаг 4. Запустите процесс службы мониторинга (tnslsnr) для записи журналов
Конечно, вы также можете удалить файл журнала прослушивателя (listener.log), и экземпляр базы данных автоматически создаст файл listener.log.
Конечно, эти операции должны выполняться с помощью сценариев оболочки, а затем объединяться с заданиями crontab для периодической очистки и усечения файлов журнала мониторинга. Например, сценарий оболочки в Интернете, который очищает и обрезает файлы журнала мониторинга.
Этот сценарий не решил одну проблему, а именно, как долго хранится усеченный файл журнала мониторинга. Например, я хочу хранить эти усеченные журналы мониторинга только в течение одного месяца и хочу, чтобы задание выполнялось автоматически. Мне не нужно вручную выполнять операцию. Есть такой сценарий cls_oracle.sh, который может сделать это полностью. Конечно, он архивирует и очищает другие файлы журналов, такие как файлы предупреждений (alert_sid.log) и т. Д. . Функция очень мощная.
Настройте задание в crontab, запускайте этот сценарий каждую ночь в полночь и храните файлы журнала в течение 31 дня.
На этом занятии вы узнаете, что такое прослушиватель, для чего он нужен. Как настроить прослушиватель для созданной ранее нами базы данных. Как управлять прослушивателем. Как запустить и остановить экземпляр базы данных.
Прослушиватель
Прослушиватель (Listener) - главный сетевой компонент на стороне сервера Oracle, позволяющий устанавливать соединение между клиентским компьютером и базой данных Oracle. Один прослушиватель может обслуживать неограниченное количество баз данных.
Прослушиватель управляется файлом listener.ora. Может быть сконфигурирован только один файл listener.ora, на сервере может быть настроено несколько прослушивателей, и этот единственный файл может обслуживать их все. Как правило, если на одном сервере настроено несколько прослушивателей, то это сделано либо с целью обеспечения отказоустойчивости, либо для балансировки обращений к базе данных. Несколько прослушивателей, так же настраиваются при использовании Real Application Cluster.
Каждый прослушиватель представляет собой именованный процесс, запускаемый на каждом сервере баз данных. По умолчанию, прослушиватель имеет имя LISTENER и создается при установке Oracle. Если же вы настраиваете несколько прослушивателей, то каждый должен иметь уникальное имя. Ниже представлен пример файла listener.ora:
Теперь вы имеете общее представление о прослушивателе. И можем настроить прсолушиватель для нашей базы данных.
Для создания будем использовать утилиту netca, она как и многие утилиты находится в каталоге $ORACLE_HOME/bin. Для запуска, перейдем в нужную директорию и выполним:
oracle@test: cd /u01/app/oracle/product/11.1.0/db_1/bin
oracle@test:/u01/app/oracle/product/11.1.0/db_1/bin> ./netca
Откроется окно графического приложения:
Предлагаются варианты, чего собственно будем настраивать. Нас интересует прослушиватель, поэтому выбираем "Listener configuration" и переходим далее.
Предлагается выбрать действие, добавить, перенастроить, удалить или переименовать. Поскольку на нашей машине еще не настроено ни одного прослушивателя, то единственное доступное действие - Добавить. Что и выбираем, и переходим далее.
На этом шаге указываем имя прослушивателя, по умолчанию предлагается имя LISTENER, как и говорилось в начале урока. На данный момент не планируется настраивать дополнительные прослушиватели и базы данных на тестовой машине, поэтому соглашаюсь с предложенным именем и перехожу к следующему шагу.
Здесь предстоит указать протоколы, которые будут использованы. Как правило, используется обычный TCP, его и выбираем. Жмем далее.
Указываем порт, который будет использоваться прослушивателем. По умолчанию, это 1521. Оставляем как есть и переходим далее.
Сейчас система интересуется, будет ли настраиваться еще один прослушиватель, отвечаем нет, переходим далее, и завершаем настройку. Если все хорошо, то на следующем экране система сообщит об успешном завершении настройки.
Теперь, когда прослушиватель настроен, можно познакомится с основными командами управления. Для управления прослушивателем используется утилита lsnrctl, расположена там же, где и утилита для настройки прослушивателя. Для ее запуска выполним:
oracle@test: cd /u01/app/oracle/product/11.1.0/db_1/bin
oracle@test:/u01/app/oracle/product/11.1.0/db_1/bin> ./lsnrctl
Результатом исполнения, будет приглашение работать с консолью прослушивателя:
Для прослушивателя доступны три основные команды: start, stop и status. Команда start служит для запуска процесса прослушивания, stop - остановка, status - показывает текущий статус прослушивателя.
Для удобства, вы можете указывать команду сразу же после вызова утилиты, например, запустим созданный только что прослушиватель:
Аналогичным образом можно выполнить остановку или просмотреть статус.
Это все хорошо, скажете вы, но как быть если прослушивателя два, или три, как объяснить Oracle с каким прослушивателем хочет работать пользователь?
В случае, если у вас более одного прослушивателя, вы должны указать имя прослушивателя в команде. Например, выполним запуск прослушивателя, обратившись по имени:
oracle@test:/u01/app/oracle/product/11.1.0/db_1/bin> ./lsnrctl start LISTENER
Когда прослушиватель один, то указывать имя не обязательно, но если их более одного, то указание имени является обязательным.
И вот теперь, когда у нас настроен прослушиватель, можно наконец то достучаться до нашей базы данных, и убедится, что она есть, работает и вполне реальна.
Для этого, убедимся что наш прослушиватель запущен, выставим переменные окружения:
oracle@test:export ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1
oracle@test:export ORACLE_SID=test
Этими командами выставлена директория ORACLE_HOME и текущий SID. Переходим в каталог $ORACLE_HOME/bin.
oracle@test:/u01/app/oracle/product/11.1.0/db_1/bin> ./sqlplus / as sysdba
SQL*Plus: Release 11.1.0.7.0 - Production on Sun Feb 8 18:51:55 2009
Copyright (c) 1982, 2008, Oracle. All rights reserved.
Connected to an idle instance.
SQL>
Если база данных потушена, то об этом будет сообщено: Connected to an idle instance. Т.е. мы подключились к простаивающему экземпляру. Если же база данных поднята, то сообщится версия базы данных и редакция. Сейчас база данных погашена, для работы с ней, требуется ее запустить. Для этого выполним:
[oracle@test bin]$ ./sqlplus / as sysdba
SQL*Plus: Release 11.1.0.7.0 - Production on Thu Mar 19 19:49:47 2009
Copyright (c) 1982, 2008, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 845348864 bytes
Fixed Size 1316656 bytes
Variable Size 503318736 bytes
Database Buffers 335544320 bytes
Redo Buffers 5169152 bytes
Database mounted.
Database opened.
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@test bin]$
Сейчас база данных готова к работе. Для того что бы прверить работоспособность можно снова зайти в sqlplus и выполнить любой sql запрос. Например:
Вам будет выведена информация о базе данных.
Остался вопрос, как остановить базу данных. Остановка базы данных осуществляется так же через sqlplus. Для этого заходим в него, как было описано выше, при описании запуска базы данных Oracle. Ниже показана процедура остановки экземпляра базы данных и прослушивателя:
Сейчас база данных и прослушиватель остановлены. На этом завершим урок. В дальнейших уроках, будет более подробно остановимся на запуске и остановке экземпляра базы данных. Расскажу о параметрах остановки и запуска экземпляра и как они могут повлиять на работоспособность базы данных или помочь в случае сбоев.
Добрый день! Работая разработчиком Oracle PL/SQL, часто ли вам приходилось видеть в коде dbms_output.put_line в качестве средства debug-а? Стоит признать, что к сожалению, большинство (по моему личному мнению и опыту) разработчиков Oracle PL/SQL не уделяет должного внимания логированию как к «спасательному кругу» в случае возникновения ошибок. Более того, большая часть разработчиков не совсем понимает зачем нужно логировать информацию об ошибках и самое главное, не совсем понимают что делать и как использовать эту информацию в будущем.
Предисловие
Данным постом хотел бы начать цикл статей посвященных «Логированию ошибок» в Oracle PL/SQL. В первую очередь донести мысль до многих разработчиков, о том как можно построить функционал фиксации, хранения логов в БД. На своем опыте продемонстрировать поэтапный процесс создания полноценного логирования в БД. Рассказать как нам удалось создать логирование ошибок, разработать единую нумерацию событий для их дальнейшей идентификации, как поверх логирования «натянуть» мониторинг событий, создать функционал позволяющий увидеть все текущие ошибки в БД в виде таблиц (с указанием частоты возникновения ошибок и кол-ва и т.д.), графиков (отразить динамику роста кол-ва ошибок) и правильно распределить ресурсы для устранения тех или иных ошибок.
Оговорюсь сразу, что на рынке возможно уже есть успешные существующие коммерческие продукты осуществляющие логирование гораздо лучше и качественнее хотя бы, потому что у них есть многолетний опыт внедрения и сопровождения своего продукта в различных компаниях. Я же хочу показать один из множества примеров реализации функционала логирования, которые вполне можно осуществить силами своих разработчиков.
Введение
Модель логирования позволяет реализовать:
Единый подход в обработке и хранении событий
Собственную нумерацию и идентификацию событий происходящих в БД (статья)
Единый мониторинг событий (статья в разработке)
Анализ событий происходящих в БД (статья в разработке)
Описанные выше характеристики указаны в порядке нумерации и каждый следующий пункт (шаг) есть улучшение и усложнение существующей модели. Описание этой модели будет сложно выполнить в рамках одной статьи, поэтому опишем их последовательно. Начнём с первого пункта.
Единый подход в обработке и хранении событий
Основной идеей "Единого подхода в обработке и хранении событий" заключается в создании одного одновременно простого и в тоже время очень сложного правила: "Все объекты базы данных (функции, процедуры) в обязательном порядке должны завершаться блоком обработки исключений с последующим логированием события". Простота заключается в том, что легко, в команде разработчиков, на словах договориться об исполнении данного правила. Сложность же заключается в том, что данное правило должно быть установлено на ранних этапах создания вашей БД и выполняться обязательно на протяжении всего жизненного цикла. Внедрить функционал логирования в уже существующие и действующие БД очень сложно (практически не возможно).
Все объекты базы данных (функции, процедуры) в обязательном порядке должны завершаться блоком обработки исключений с последующим логированием события. Для этого можно использовать шаблон процедуры (функции) описанный во второй статье.
Наверное сейчас кто-то из читателей может возразить: "Зачем в обязательном порядке?". А всё очень просто, если вы разработчик PL/SQL и вы не согласны с этим правилом, то вот вам пример. Посмотрите на свой текущий проект более внимательно. Скорее всего вы найдете какое-нибудь логирование событий реализованное кем-то, когда-то. Вспомните сколько раз вы обращались к этому логированию при решении багов. Именно в таких ситуациях, когда есть срочность по времени в исправлении бага, вы или ваши коллеги начинают использовать dbms_output.put_line в качестве экспресс-дебага (быстрый способ получения значений переменных используемых в коде). Согласитесь, что для исправления бага мало знать в какой процедуре, в каком запросе и на какой строке возникла ошибка, необходимо знать параметры запроса на которых возникает ошибка. И вот тут нам на помощь приходит "Логирование событий", потому что помимо места возникновения ошибки мы узнаем параметры вызова процедуры, в которой возникает ошибка и это очень упрощает исправление бага.
Первая статья посвящена базовому функционалу «Логирования событий». В простейшей реализации это одна общая таблица и пакет процедур для работы с ней. Для создания и демонстрации логирования, нам необходимо реализовать следующие объекты БД (весь список объектов с их исходными кодами представлен в Git):
Таблица messagelog - единая таблица логов. Именно в данной таблице будет храниться информация о дате и времени события, об объекте где происходит событие, типе события с указанием кода, текста и параметров. В нашем примере, столбец backtrace вынесен в отдельную таблицу messagelog_backtrace для удобства.
Примечание. Представленное ниже описание таблицы является демонстрационным с минимальным набором столбцов для создания простейшего функционала логирования. Наличие дополнительных столбцов и их тип данных может меняться в зависимости от целей и задач логирования.
Также, учитывайте пожалуйста, что создание партиции требует как минимум Oracle EE. Создание партиции вне указанной версии Oracle приведет к нарушению лицензионного соглашения.
Читайте также: