пятница, 30 декабря 2011 г.

Oracle и DNS

Даже не знаю, с чего начать статью. :)

Дело, собственно, в следующем. За последние полгода я несколько раз сталкивался с ситуацией, когда в определенных обстоятельствах оракловая база не стартует. При полной физической исправности. Либо к совершенно исправной работающией БД невозможно приконнектиться из сервера приложений.

Вскрытие показало, что больной умер в результате вскрытия ;)

Итак, в чем суть проблемы?

Суть проблемы - во взаимоотношениях Oracle RDBMS, Oracle Net и DNS.

Во-первых, о проблеме запуска.

В БД Oracle хардкодом вбито разрешение собственного имени сервера при старте базы, а точнее, при старте процесса SMON. На некоторых платформах (например, AIX5L), у которых при настройке разрешения имен первым не используются в обязательном порядке файлы hosts, а только затем DNS, в случае недоступности сервера (серверов) имен база отказывается стартовать.

Кстати, на Солярисе такие случаи мне лично незнакомы, поскольку в файле /etc/nsswitch.dns всегда первым идет разрешение посредством files:


# You must also set up the /etc/resolv.conf file for DNS name
# server lookup. See resolv.conf(4).
hosts: files dns


Соответственно, такой проблемы не возникает. Но так резолвер по умолчанию настроен не на всех платформах.

А вот данное поведение СУБД совсем не хорошо задокументировано. Во всяком случае, большими красными буквами это в руководствах не выделено и с разбегу не находится. Ровно до момента, когда вы с этим сталкиваетесь и лезете в службу технической поддержки с кодом ошибки. Причем в ноте саппорта сказано лишь "Проверьте /etc/resolv.conf".

На платформе AIX симптом недоступности DNS подтверждается затяжным коннектом к серверу по SSH, в котором по умолчанию также включено UseDNS yes.

Вторая проблема - с отсутствием подключения серверов приложений к работающей на момент недоступности DNS-серверов базе данных - менее очевидна. 

Для клиентов база данных выглядит полностью недоступной. И они начинают гневно доставать DBA. ;)

Диагностируется данная проблема посредством файла sqlnet.log, фиксирующим таймауты ns при установлении клиентских соединений.

Самый главный вопрос - что делать?

Первое и самое правильное решение: иметь в /etc/resolv.conf не менее двух внутренних (по отношению к локаальной сети) и полностью контролируемых DNS, один из которых должен быть всегда доступным - в частности, доступным по сети (обратите внимание, если сервер работает, но пакеты теряются - эффект будет примерно таким же: периодически пропадающие соединения с базой!).

Второе - сменить либо настройки резолвера сервера - на использование первым файла /etc/hosts и лишь после него - DNS, либо ОС сервера. ;)

Самое главное - кидаться проверять базу не нужно. Достаточно беглого взгляда на alert.log, чтобы убедиться, что с ней все нормально ну, или при проблемах старта - что происходит.

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