Вы не сталкивались с такой ошибкой? А я вот на днях столкнулся и хочу поделиться своей историей. Может быть эта информация поможет кому-то из вас быстрее разобраться в похожей ситуации.
Однажды, после окончания планового оффлайн бэкапа, система оказалась недоступна для работы. SAP GUI выдавал сообщение о том, что база данных системы недоступна.
Первая мысль была: "Ну, наверное, по какой-то причине затянулся бэкап". Но переход на уровень операционной системы сервера показал, что база данных запущена, а процессов резервного копирования в операционной системе нет. Правда, со стороны Oracle работают только фоновые служебные процессы и нет ни одного shadow-процесса.
Вы наверное знаете, что при оффлайн резервной копии базы данных (или как её ещё называют "холодный" бэкап) процессы ABAP инстанции не останавливаются, а остаются работать, потеряв коннект к базе данных. При этом рабочие процессы с настойчивостью и периодичностью пытаются открыть соединение к базе данных. Поэтому, как только база данных становится доступной для соединения, рабочие процессы открывают соединения, а Oracle запускает для каждого рабочего процесса SAP инстанции отдельный shadow-процесс. Подробнее о том, как рабочие процессы SAP системы подключаются к базе данных я описывал в статьях: "Как рабочие процессы SAP соединяются с базой данных Oracle - I" и "Как рабочие процессы SAP соединяются с базой данных Oracle - II".
Так вот, shadow-процессов Oracle не наблюдалось. Я подключился к базе данных через SQLPlus, используя пользователя SYSTEM. Соединение установилось успешно. На всякий случай перестартовал базу данных. Проверил: shadow-процессов как не было, так и нет. При этом рабочие процессы SAP инстанции в списке процессов операционной системы висели.
Хорошо. Последний рестарт SAP системы был давно, вдруг что-то подглючило на уровне сервера приложений, подумал я. И решил перезапустить сервер приложений. Но скрипты запуска системы выдают: "База данных не запущена, будем запускать. Попытка запуска базы данных заканчивается ошибкой - "база данных недоступна". Стоит отметить, что скрипты запуска SAP системы для проверки доступности базы данных используют утилиту R3trans, входящую в состав SAP Kernel, запуская её с опцией "-d" (рис. 1 и 2).
 |
| Рис. 1. Пример успешной проверки соединения с базой данных. |
 |
| Рис. 2. Пример безуспешной проверки соединения с базой данных. |
Проверка переменных окружения пользователей, настроек Oracle client, процесса Listener ничего не дала.
И только в третий раз просматривая журналы рабочих процессов SAP инстанции (файлы dev_w*), обратил внимание, что код ошибки при попытках коннекта к Oracle отличается от типичного. Когда база данных остановлена, выдаётся код ошибки 1034.
 |
| Рис. 3. Пример кода ошибки соединения с остановленной базой данных. |
А тут выдавался код 28000 (рис. 4).
 |
| Рис. 4. Код ошибки при соединении с базой данных в текущем случае. |
По коду ошибки удалось выяснить, что ошибка заключается не в недоступности Oracle, а в блокировке пользователя. Как вы уже знаете, из вышеупомянутых статей, что рабочие процессы SAP системы при подключении к Oracle используют пользователя владельца схемы в базе данных. В данном случае это пользователь SAPSR3. Так вот этот пользователь и оказался заблокированным.
К блокировке пользователя привёл параметр базы данных Oracle - FAILED_LOGIN_ATTEMPTS. Начиная, с версий Oracle 10g значение данного параметра, по умолчанию, равно 10. В предыдущих версиях СУБД по умолчанию стоит значение UNLIMITED. Посмотреть значение в текущей базе данных можно запросом вида:
SQL> select LIMIT from DBA_PROFILES where PROFILE='DEFAULT' AND RESOURCE_NAME='FAILED_LOGIN_ATTEMPTS';
или
SQL> show parameter FAILED_LOGIN_ATTEMPTS;
Как вы помните из моего поста, при соединении с базой данных, до версии Oracle 11g в SAP системе использовался механизм хранения пароля пользователя владельца схемы в отдельной табличке OPS$<USER>.SAPUSER. Так как в момент оффлайн бэкапа база данных недоступна, то рабочий процесс не может получить к ней доступ и прочитать продуктивный пароль пользователя. И как видно из скриншота (рис. 3), каждый раз делается ещё и дополнительная попытка открыть соединение с дефолтным паролем, который зашит в коде ядра. Допускаю, что случилась такая ситуация, что в момент старта базы данных было сделано больше 10 попыток логина к базе данных со стороны SAP системы с этим стандартным паролем (который отличается от продуктивного пароля). В результате этого Oracle автоматически заблокировал пользователя (владельца схемы) и последующие попытки SAP системы присоединиться к базе данных проваливались уже по этой причине, вплоть до моего вмешательства.
Разрешение ситуации: разблокировка пользователя. Разблокировать пользователя можно в SQLPlus командой вида:
SQL> alter user SAPSR3 account unlock;
После этого рабочие процессы корректно подключаются к базе данных. Для предотвращения возникновения ситуации в будущем - установка параметра в большее значение, вплоть до UNLIMITED. Сделать это можно SQL-командой вида:
SQL> alter profile default limit FAILED_LOGIN_ATTEMPTS 50;
Со стороны компании SAP ситуация описана в SAP note 951167 - ORA-28000: the account is locked.
P.S. Думаю, что описанная ситуация довольно таки редкая и возможна только в узком круге версий систем SAP и базы данных Oracle. Так как в современных версиях систем пароль хранится уже не в базе, а в файловой системе (подробнее) и попыток попасть в базу данных со стандартным (неверным) паролем не производится. Но в нашей жизни всё бывает и надо быть готовым ко всему.
Автор: Шиболов Вячеслав Анатольевич