С наступающим днём знаний! Скидки на авторские курсы и системы-песочницы

Вот и прошла первая половина августа, а это значит, что лето заканчивается и впереди у нас новый учебный и рабочий сезон.

В связи с этим поздравляю всех с наступающим днём знаний!

Знания - это инвестиции, которые помогают нам выстоять, не смотря на тяжёлые времена, периоды перемен и неопределённости. Всё что вас окружает в жизни может как появиться, так и исчезнуть. Как часто говорят: "Бог дал, Бог взял". Может поменяться окружение, место вашей локации, но вы со своими знаниями, навыками, умениями, будете везде и всегда. Именно с вами вам и жить. Помните, что в любом месте человек опытный и умелый сможет выжить и жить достойно. С учётом окружающих условий конечно же. 

Желаю вам не терять интереса к жизни, постоянно учиться и узнавать что-то новое. Ну и стараться вкладывать в своё будущее по мере возможности. Помоги себе завтрашнему уже сегодня. :)

По традиции, в связи с праздником, скидка на пакеты моего обучающего курса SAPADM 2.1. Напоминаю, что курс был полностью переписан и теперь основан на версии SAP NetWeaver 7.52 и платформе Linux/Oracle. 

Тому, кто напишет мне на почтовый ящик shibolov@gmail.com до 23:59 8 сентября, я отдам любой пакет этого курса за 16 000* рублей. 

А все три пакета нового курса в эти дни можно получить всего за 40 000* рублей (вместо 72 000 рублей).

Дополнительно делаю скидку на первую версию курса SAPADM 1.0. В наших российских реалиях и он кому-то может пригодиться. 

Весь курс можно получить всего за 20 000* рублей (вместо 30 000 рублей).

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

Ну и не обойду стороной системы песочницы. Напомню, что есть 2 версии системы:

• SAP ERP 6.0 EHP7 AS ABAP (пустая система),
• SAP ERP 6.0 EHP7 AS ABAP (IDES версия).

Любую из этих систем с бесконечной лицензией и вашим пользователем с полным набором полномочий и ключом разработчика в период текущей акции можно получить всего за 7 000* рублей. Подробности о системах тут.

Условия акции:

* - для получения забронированных пакетов или системы-песочницы со скидкой необходимо  будет оплатить их до конца сентября.

Автор: Шиболов Вячеслав Анатольевич

Обучение SAP Basis. Обновление Пакета 3 в рамках курса SAPADM 2.1

Наконец-то у меня дошли руки до третьего пакета курса SAPADM 2.1. 

В своё время я выпустил третий пакет заданий в рамках курса SAPADM 2.0, но после, как только появилась такая возможность, освежил систему/инструменты/задания и выпустил курс SAPADM 2.1. Были обновлены первые два пакета, а обновление третьего застряло в планах.  

И вот, наконец, он тоже обновлён. Полностью переписан под новую версию SAP системы и базу данных Oracle. Обновлены все скриншоты, добавлены комментарии, исправлены неточности и ошибки. Курс немного вырос в объёме (рис. 1). 

Рис. 1. Описание заданий третьего обучающего пакета курса SAPADM 2.1.

Купив этот пакет обучения, вы изучите всё, что необходимо начинающему администратору базы данных Oracle в рамках SAP системы. А самое главное, что обучение будет происходить на реальной боевой системе. Все инструменты администрирования, транзакции, работа с табличными пространствами, запуск и останов базы данных в различных условиях, создадите свой цикл резервного копирования, попробуете создавать разные виды бэкапов и восстановление из них, сможете понять как менять параметры базы данных и анализировать производительность. Минимум 22 часа практического погружения в администрирование базы данных, не включая часов потраченных на изучение теоретических основ Oracle. 

Как всегда полная поддержка с моей стороны в плане ответов на дополнительные вопросы и ссылок на материалы. 

Кто прошёл первые два и не смотрел в сторону третьего, сейчас может быть самое время его пройти.

Цена за SAPADM 2.1. Пакет 3 - 24 000 рублей.

Тем, кто купил предыдущие 2 пакета этого курса, сделаю скидку на третий пакет. 

Пишите мне на почту shibolov@gmail.com с указанием в заголовке письма названия обучающего курса - SAPADM 2.1.

Страница курса SAPADM 2.1.

Автор: Шиболов Вячеслав Анатольевич

С очередным днём знаний!

Поздравляю всех с днём знаний!

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

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

Кто же хочет нарастить свои skills в области SAP Basis добро пожаловать в мои обучающие курсы.

В этот раз привычной скидки от текущей цены не будет, так как грядёт повышение цен с 1 октября 2023 года. Поэтому пока курсы по старой цене. 

Так что кто хочет начать "свой учебный год" с моих курсов, пишите на почту - shibolov@gmail.com с указанием в заголовке письма названия обучающего курса - SAPADM 1.0 или SAPADM 2.1.

Автор: Шиболов Вячеслав Анатольевич

С наступающим днём знаний! Скидки на авторские курсы обучения SAP Basis

 Поздравляю всех с наступающим днём знаний!

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

Ну и по традиции, в связи с праздником, скидка на пакеты моего обучающего курса SAPADM 2.0. Напоминаю, что курс был полностью переписан и теперь основан на версии SAP NetWeaver 7.50 и платформе Linux/Oracle. 

Тому, кто напишет мне на почтовый ящик shibolov@gmail.com до 23:59 6 сентября 2021 года, я отдам любой пакет курса за 12 000* рублей. 

А все три пакета нового курса в эти дни можно получить всего за 35 000* рублей (вместо 48 000 рублей).

Условия акции:

* - для получения забронированных пакетов со скидкой, их надо будет оплатить до конца сентября 2021 года.

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

Автор: Шиболов Вячеслав Анатольевич

Автоматический запуск/останов SAP инстанции на Linux: примеры использования

В прошлый раз я рассказал, как с помощью shell-скриптов интегрировать процесс запуска/останова SAP системы в процесс инициализации операционной системы Linux. Всего один скрипт, написанный по определённым правилам, и 2 ссылки на него для старта и останова (рис. 1). А в результате ваша SAP система будет останавливаться, когда операционная система отправляется в shutdown или reboot и аналогично запускаться при её старте. Это позволит получить работающую систему при внезапном незапланированном рестарте сервера. Особенно это актуально для дополнительных серверов приложений или кластерной конфигурации. Когда при сбое на основном узле кластера система должна стартовать на резервном узле без вмешательства администратора. Большинство систем построения отказоустойчивых кластеров имеет свои инструменты для старта-останова приложений, но иногда возможно и использование собственных разработок. Тем более если они тщательно протестированы и работают без сбоев.

Рис. 1. Пример расположения инициализационного скрипта и ссылок на него.

Вторая польза от этих скриптов в том, что вы можете использовать их для ручного останова, запуска или проверки состояния SAP системы. Скрипт для центральной инстанции запускает и останавливает не только SAP инстанцию, но и базу данных с сопутствующими процессами (например, процесс LISTENER). Опции, которые можно использовать для этого, я перечислял в прошлом посте (рис. 2). В случае решения каких-то проблем с системой (troubleshooting) лучше выполнять запуск/останов не скриптами, а командами, отслеживая внимательно выполнение каждого шага. А вот если система работает стабильно, то почему бы не облегчить себе немного жизнь: выполнить одну команду, вместо 2-4? :)

Рис. 2. Пример ручного использования инициализационного скрипта.

Третий момент, где мы можем использовать этот скрипт - это запланированный рестарт SAP системы целиком или только её части. Например, изменили вы параметры SAP инстанции и теперь вам необходимо выполнить рестарт инстанции, чтобы параметры подхватились системой. Если у вас есть такой shell-скрипт, то можно запланировать его запуск с нужными параметрами через планировщик операционной системы cron. И при планировании выбрать интервал времени, когда вы можете устроить downtime системе (рис. 3). Чаще всего это возможно сделать или в ночное время, или выходной день, в зависимости от требований к системе. 

Рис. 3. Пример планирования рестарта SAP инстанции через cron.

Главное после такого рестарта, не забудьте закомментировать или удалить запись в планировщике. А то в будущем возможен "сюрприз". 

Ну и последний пример применения скриптов инициализации - это резервное копирование. На текущем проекте резервное копирование выполняется средствами программного обеспечения HPE Data Protector (иногда называют Micro Focus Data Protector). А для серверов, как я уже рассказывал, используется система виртуализации VMware vSphere. Data Protector прекрасно умеет интегрироваться с VMware и при резервном копировании виртуальных машин использует снимки виртуальных машин (snapshots). Таким образом, происходит резервное копирование "замороженного" снимка виртуальной машины (то есть консистентного состояния всех виртуальных дисков) без прерывания работы основной системы. Для получения более консистентного снимка можно перед его созданием выполнить останов SAP системы вместе с базой данных. А после создания снимка SAP систему сразу же запустить, обеспечив её доступность для пользователей. Реализовать это можно через средства Data Protector. Перед выполнением запроса на создание снимка виртуальной машины программное обеспечение резервного копирования может из целевой операционной системы выполнить shell-скрипт  /usr/sbin/pre-freeze-script, а сразу же после создания - другой shell-скрипт /usr/sbin/post-thaw-script. Ну а в этих скриптах можно прекрасно использовать уже написанный инициализационный скрипт для SAP системы (рис. 4).

Рис. 4. Пример shell-скриптов для Data Protector.

Рис. 5. Журнал создания снимков VM для резервного копирования.

Как видите (рис. 5) в данном случае рестарт системы занимает буквально пару минут. В течении этого времени создаётся снимок виртуальной машины, после чего SAP система становится вновь доступной для пользователей. А система резервного копирования (СРК) может спокойно копировать виртуальные диски снимка на целевое хранилище, не влияя на работу SAP системы. И самое главное, мы получаем абсолютно консистентную копию виртуальной машины.

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

Автор: Шиболов Вячеслав Анатольевич

Автоматический запуск/останов SAP инстанции на Linux

В далёком 2010 году я выкладывал посты (часть 1, часть 2) про процесс запуска операционной системы HP-UX. Помимо этого там было описано как настроить автоматический запуск и останов SAP системы вместе с операционной системой. 

Потом, как вы помните, был пост, в котором я описывал процесс миграции системы на платформу x86_64 и операционную систему Linux. Пост назывался "История одной миграции SAP системы или Век живи, век учись! - III". Таким образом, система стала работать на операционной системе SUSE Linux Enterprise Server версии 11 SP4 и встал вопрос как автоматизировать запуск и останов SAP системы уже в данной операционной системе. 

Всё это я веду к тому, что в этот раз хочу рассказать как решил этот вопрос, может быть кому-то пригодится.

Операционная система SUSE Linux Enterprise Server 11, как и HP-UX, в качестве системы инициализации использует SysV. В этом случае процесс инициализации совместим со стандартом операционной системы System V. Тогда как почти все современные, на данный момент, дистрибутивы Linux (и SLES, начиная с версии 12) перешли на новую систему инициализации - systemd. Если кратко, то SysV основан на наборе shell-скриптов, а systemd это огромный программный универсальный комбайн с большим количеством функций (если интересны детали, то начать изучение можно с этого). А описание версий дистрибутивов (и систему инициализации, в частности) можно найти, например, на сайте DistroWatch.com. 

За основу shell-скриптов для решения поставленной задачи я взял скрипт, которым кто-то из читателей поделился в комментарии к старому посту про HP-UX. Но "из коробки" у меня скрипт не заработал. Точнее при ручном выполнении скрипта всё работало "на ура": система запускалась и останавливалась. А вот при запуске скрипта во время старта операционной системы возникали какие-то проблемы и он не срабатывал. Анализ показал, что в скрипте не работает изящное решение по выделению системного идентификатора SAP системы (и базы данных) SAPSID и DBSID из имени скрипта. То есть по какой-то причине при запуске скрипта процессом init не работал вот этот кусок кода:

FILENAME=`basename $0`

SAPSID=${FILENAME:6:3} 

В итоге, я заменил эти строки на прямое указание идентификатора системы в коде:

SAPSID=DLC 

Здесь DLC - это пример системного идентификатора системы.

Потом было ещё несколько усовершенствований, переделок. В итоге, работающие именно у меня скрипты можно скачать по этой ссылке.

Напоминаю ещё раз, что скрипты служат для автоматизации процесса запуска/останова старой SAP системы (используются скрипты startsap и stopsap) с базой данных Oracle на Linux, использующем систему инициализации SysV.

Инструкция по установке скриптов не сложная:

1. Для настройки запуска/останова SAP инстанции с базой данных Oracle cкопировать скрипт sapctlSID_CI в директорию /etc/init.d, переименовав имя файла и добавив в имя скрипта текущий SAPSID, командой вида:

cp sapctlSID_CI /etc/init.d/sapctl<SID>

2. Отредактировать файл /etc/init.d/sapctl<SID>, изменив в начале скрипта строки:

# Provides:          sapctlSID
и
SAPSID=SID 

Заменив значение SID на свой <SID>.

Например, 

# Provides:          sapctlDLC
...
SAPSID=DLC 

3. Права/полномочия на файл должны быть "755", а владельцы файла/группы: "root:root".

4. Следующая команда автоматически создаст ссылки в необходимых директориях /etc/init.d/rc*.d/ для запуска и останова SAP на нужном уровне ОС:

chkconfig --add sapctl<SID>

5. После выполнения вышеописанных шагов скрипт будет автоматически запускать и останавливать SAP систему вместе с базой данных ORACLE и процессами sapOScol и LISTENER на 3 и 5 уровнях операционной системы соответственно.

6. Вручную скрипт можно запускать командами со следующими опциями:

• /etc/init.d/sapctl<SID> status - показывает статус всех процессов SAP + DB;
• /etc/init.d/sapctl<SID> stop - останавливает все процессы SAP + DB;
• /etc/init.d/sapctl<SID> start - запускает все процессы SAP + DB;
• /etc/init.d/sapctl<SID> restart - сначала останавливают систему целиком, а потом запускает SAP + DB;
• /etc/init.d/sapctl<SID> r3stop - останавливает все процессы только SAP инстанции;
• /etc/init.d/sapctl<SID> r3start - запускает все процессы только SAP инстанции;
• /etc/init.d/sapctl<SID> r3restart - сначала останавливает, а потом запускает все процессы только SAP инстанции.

7. Для временного или постоянного отключения автоматического старта и останова SAP системы достаточно удалить ссылки из директорий /etc/init.d/rc*.d/ командой:

chkconfig --del sapctl<SID>

8. Скрипт с именем sapctlSID_DI предназначен для запуска/останова отдельной диалоговой инстанции SAP системы. Всё что относится к запуску базы данных из него удалено. Процесс установки и настройки идентичен вышеописанному. При работе в ручном режиме работают опции "status, stop, start и restart".

Данная инструкция есть в текстовом файле внутри архива со скриптами. Так что достаточно скачать архив.

Ещё раз спасибо тому, кто поделился своим скриптом. Без этого процесс решения моей задачи однозначно занял бы больше времени. А этот пост, надеюсь, кому-то поможет быстрее решить его задачу.

Автор: Шиболов Вячеслав Анатольевич

Ошибка ORA-28000: the account is locked

Вы не сталкивались с такой ошибкой? А я вот на днях столкнулся и хочу поделиться своей историей. Может быть эта информация поможет кому-то из вас быстрее разобраться в похожей ситуации.

Однажды, после окончания планового оффлайн бэкапа, система оказалась недоступна для работы. 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. Так как в современных версиях систем пароль хранится уже не в базе, а в файловой системе (подробнее) и попыток попасть в базу данных со стандартным (неверным) паролем не производится. Но в нашей жизни всё бывает и надо быть готовым ко всему.

Автор: Шиболов Вячеслав Анатольевич

Как рабочие процессы SAP соединяются с базой данных Oracle - II

В первой части статьи я описал как в SAP системе рабочий процесс, используя двух этапный механизм, определяет пароль владельца ABAP схемы (SAP<SCHEMA-ID>) и подключается с помощью этого пользователя к базе данных Oracle.

Такой механизм использовался до версии Oracle 11g. Но с выходом базы данных Oracle 11g оказалось, что это последняя версия СУБД от Oracle, которая поддерживает OPS$-механизм для удалённого соединения с ней. В связи с этим компания SAP также внесла поправки в работу своих приложений. И начиная с SAP kernel Release 7.20 (примерно с 100 пакета поддержки) представила новый метод для хранения пароля владельца базы данных и соединения с ней. В SAP kernel Release 7.20 зашифрованный пароль для пользователя базы данных может хранится не в базе данных, а на уровне файловой системы. Такой способ называется Secure Storage in File System (SSFS). 

И в этом случае рабочий процесс открывает соединение с базой данных в один шаг, читая контактную информацию и пароль пользователя из защищённого хранилища (рис. 1).

Рис. 1. Пример сообщений из журнала рабочего процесса при коннекте с базой данных новым способом.

Для того, чтобы рабочие процессы и внешние утилиты SAP (R3load, R3trans) использовали новый метод, необходимо в DEFAULT профиль SAP инстанции добавить ряд параметров (рис. 2). Про профили и параметры SAP системы я уже рассказывал в своё время в статьях (1, 2).

Одновременно должны быть установлены переменные окружения пользователя операционной системы <sid>adm (рис. 3).

Рис. 2. Параметры SAP инстанции, связанные с SSFS способом коннекта. 

Рис. 3. Переменные окружения пользователя ОС для SAP системы, связанные с SSFS способом коннекта. 

На уровне операционной системы в директории /usr/sap/<SID>/SYS/global/security созданы специальные директории и файлы со строгими правами на доступ (рис. 4). В файле SSFS_<SID>.DAT хранится как раз информация необходимая для соединения с базой данных, включая зашифрованный пароль владельца схемы.

Рис. 4. Список директорий и файлов, хранящих информацию для соединения с базой данных.

Для просмотра содержимого хранилища в SAP Kernel есть утилита rsecssfx. Набрав одноимённую команду, можно получить список всех записей (опция list) или содержимое отдельной записи (опция get). Содержимое записи с паролем зашифровано и не будет показано в целях безопасности (рис. 5).

Рис. 5. Пример использования команды rsecssfx.

Вот так работает новый механизм хранения владельца схемы, включая его пароль.

Для обратной совместимости, вплоть до версий SAP Kernel 7.38 и базы данных Oracle 11.2, поддерживается одновременно и старый, двух этапный, метод. Хотя SAP уже в этих версиях рекомендует переходить на новый метод хранения пароля на уровне файловой системы. Ведь сделать это можно даже в системах на базе SAP NetWeaver 7.0, так как эти программные продукты поддерживают SAP Kernel 7.20. Переход на это ядро я описывал в одноимённом посте.  

И стоит иметь в виду, что если в Oracle 11g установить параметры профиля REMOTE_OS_AUTHENT=TRUE, то при старте инстанции в терминале или в системном журнале можно увидеть сообщения об ошибке вида:

• ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance,
• ORA-32006: REMOTE_OS_AUTHENT initialization parameter has been deprecated.

Эти сообщения можно проигнорировать, так как не смотря на них старый механизм всё ещё будет работать. Необходим он, если в UNIX системах утилиты SAP BR*Tools и рабочие процессы SAP всё ещё используют OPS$-механизм, который и требует установки параметра REMOTE_OS_AUTHENT=TRUE. 

Ну а начиная с SAP Kernel 7.40 поддерживается только SSFS механизм хранения пароля пользователя SAP<SCHEMA-ID>.

Для смены пароля владельца схемы необходимо пользоваться SAP утилитами BR*Tools (версия не ниже 7.20 пакет поддержки 28). Команда вида:

> brconnect -u / -f chpass 

изменит пароль и в системных таблицах Oracle, и в защищенном SSFS хранилище.

Есть правда небольшой нюанс на переходных системах, там где возможна работа обоих методов. Такая команда при выполнении проверит есть ли таблица OPS$<USER>.SAPUSER. И если она ещё существует в базе данных, то пароль пользователя изменится в ней, а новое хранилище SSFS будет проигнорировано. Поэтому при переходе на новый метод необходимо эту таблицу удалить.

Либо в команде BRCONNECT можно использовать дополнительную опцию "-s|-secstore", где можно указать поменять пароль для коннекта рабочими процессами ABAP инстанции. Например, командой вида:

> brconnect -u / -c -f chpass -o SAPSR3 -p <new_password> -s abap 

При использовании этой опции пароль будет изменён именно в SSFS хранилище, а наличие таблицы OPS$<USER>.SAPUSER будет проигнорировано.


OPS$-механизм, который я описывал в прошлой части может быть использован не только для удалённого соединения, но и для локального. И даже в версиях Oracle 12c и выше локальное соединение с использованием OPS$-механизма всё еще поддерживается. Его могут использовать, например, утилиты BR*Tools или администратор при выполнении операций с базой данных (в утилите SQLPlus). 

Но если вы хотите от него отказаться окончательно, то можно его заменить на специального пользователя BRT$ADM, с помощью которого утилиты из набора BR*Tools и будут открывать соединение и  выполнять задачи по администрированию базы данных. После создания такого пользователя OPS$-пользователей из базы данных можно окончательно удалить. Подробности про этот переход и про работу BR*Tools, включая вопросы смены пароля владельца схемы в SSFS, можно найти в SAP note # 1764043 - Support for secure storage in BR*Tools.

Также на данную тему советую изучить SAP notes:

• 1611877 - Support for ABAP SSFS during database connect,
• 1622837 - Secure connection of AS ABAP to Oracle via SSFS,
• 1639578 - SSFS as password store for primary database connect.

В них детально описано как перевести систему на новый метод хранения пароля и соединения с базой данных. 

Стоит ещё отметить, что SSFS механизм хранения пароля владельца схемы используется не только при разворачивании системы на Oracle, но и при работе с Sybase ASE, SAP HANA и SAP MaxDB (см. SAP note 1639578).

А если хотите погрузиться в администрирование базы данных Oracle на практике, то добро пожаловать в мой авторский курс по SAP Basis. 

Автор: Шиболов Вячеслав Анатольевич

Как рабочие процессы SAP соединяются с базой данных Oracle - I

Как вы знаете, основными "рабочими лошадками" SAP инстанции являются рабочие процессы (SAP Work Processes или WP), которыми управляет диспетчер. В случае с AS ABAP это ABAP диспетчер. При использовании с SAP системой СУБД Oracle рабочие процессы SAP инстанции для корректной работы должны соединиться с базой данных. После открытия соединения каждому рабочему процессу SAP будет соответствовать один процесс на уровне СУБД, так называемый shadow-процесс.
При этом на сервере приложений SAP на уровне операционной системы рабочие процессы запускаются и работают под пользователем <sid>adm (в UNIX) или SAPService<SID> (в случае Windows). В свою очередь все таблицы и индексы в базе данных, которые используются текущей SAP системой, принадлежат одному пользователю базы данных. Этот пользователь называется владельцем схемы (которая объединяет все таблицы и индексы) и имеет имя SAP<SCHEMA-ID>. Стандартно в SAP инсталляциях имя владельца схемы - SAPSR3,  но иногда может быть SAP<SID>, а в старых системах пользователь носил имя - SAPR3 (до версии SAP Basis 4.6D). Владельца схемы в текущей инсталляции можно определить, если на начальном экране в системе выбрать пункт меню «Система -> Статус…» (рис. 1 и 2).

Рис. 1. Просмотр владельца схемы в базе данных.

Рис. 2. Пример владельца схемы в базе данных.

Для получения полного доступа к таблицам базы данных рабочие процессы SAP инстанции должны соединяться именно под этим пользователем. Данный пользователь на уровне Oracle (как и любой другой) защищён паролем. Но рабочие процессы SAP не знают этот пароль, так как это пользователь другого уровня, не уровня сервера приложений. Поэтому в своих решениях для рабочих процессов SAP использует механизм, который позволяет узнать пароль владельца схемы в процессе создания соединения. Об этом механизме я и хотел сегодня рассказать.

Данный механизм основан на сохранении пароля пользователя SAP<SCHEMA-ID> не только в системной таблице Oracle (в которой хранятся пароли всех пользователей на уровне базы данных), а еще и в специальной таблице. Специальная таблица имеет имя SAPUSER, и принадлежит схеме другого пользователя базы данных - OPS$<SID>ADM (в UNIX) или OPS$<DOMAIN>\<SID>ADM (в Windows). В Windows, к этой таблице также имеет доступ пользователь OPS$<DOMAIN>\SAPService<SID>, от которого и работают рабочие процессы SAP, как я написал выше.

Небольшое отступление про OPS$-пользователей (OPS$<USERS>) или OPS$-механизм базы данных Oracle. При разворачивании SAP системы, на этапе установки базы данных Oracle, программа установки спрашивает пароли для создаваемых пользователей: SYS, SYSTEM и SAP<SCHEMA-ID>. Это отдельные пользователи базы данных, которые создаются на уровне Oracle. Но помимо этих пользователей, программа установки создаёт отдельную группу пользователей, которые используют механизм Oracle, называемый "OS authentication". Эти пользователи имеют префикс "OPS$" и содержат имя пользователя операционной системы. Для UNIX систем это OPS$<SID>ADM, OPS$ORA<SID> и, в последних релизах Oracle, OPS$ORACLE. А для Windows соответственно OPS$<DOMAIN>\SAPService<SID> и OPS$<DOMAIN>\<SID>ADM. Заметьте, что в случае с Windows обязательное условие это добавление домена в имя OPS$-пользователя. Если сервер не в домене, то используется hostname сервера (рис. 3). 

Рис. 3. Пример списка пользователей базы данных Oracle, развернутой в ОС Linux.

OPS$-механизм разрешает пользователям операционной системы (для которых создан соответствующий OPS$<USER>) соединяться с базой данных без ввода пароля. То есть аутентификация пользователя переносится на уровень операционной системы, где и проводится проверка пароля.

Для активации OPS$-механизма необходима установка двух параметров инстанции Oracle:

• REMOTE_OS_AUTHENT=TRUE – разрешает удалённое соединение (OS authentication) для тех пользователей операционной системы UNIX, у которых в базе данных есть соответствующий OPS$-пользователь. То есть соединение возможно с любого компьютера в сети, с которого возможно открыть соединение с базой данных,
• OS_AUTHENT_PREFIX=OPS$ - начальный префикс для таких пользователей в базе данных. Для SAP систем значение по умолчанию "OPS$".

Теперь вернёмся к вопросам соединения рабочих процессов SAP инстанции к базе данных Oracle.

SAP инстанция может работать как на том же сервере, где работает сервер базы данных, так и на отдельном сервере. Поэтому при старте рабочего процесса он не знает: база данных доступна локально или удаленно. Следовательно в Oracle должен быть разрешён удаленный логин (параметр REMOTE_OS_AUTHENT). Стоит сразу обозначить, что в целях обеспечения безопасности права OPS$-пользователя ограничены. Он может лишь присоединиться к базе данных и прочитать запись только в таблице SAPUSER, так как эта таблица принадлежит ему. Читать, добавлять или изменять данные в других SAP таблицах (в основной схеме базы данных) ему запрещено.

Рис. 4. Схема соединения рабочих процессов SAP к базе данных Oracle.

Когда рабочий процесс SAP запускается и пытается соединиться с базой данных Oracle, он выполняет следующие шаги (рис. 4):

1. Рабочий процесс открывает коннект к базе данных как соответствующий OPS$-пользователь с аутентификацией на уровне операционной системы.
2. С помощью SQL-запроса SELECT к таблице SAPUSER рабочий процесс читает пароль пользователя SAP<SCHEMA-ID>.
3. Текущее соединение с базой данных Oracle закрывается.
4. Рабочий процесс открывает новое соединение с использованием уже пользователя SAP<SCHEMA-ID> и пароля, который он получил на предыдущем этапе из таблицы SAPUSER.

Если один из вышеуказанных шагов по какой-то причине не выполнен, то соединение не устанавливается и рабочий процесс на уровне операционной системы сервера останавливается с ошибкой.

А вот как этот процесс коннекта к базе данных выглядит на уровне сообщений журнала рабочего процесса SAP (рис. 5).

Рис. 5. Пример журнала рабочего процесса SAP.

Также стоить добавить, что такой двух этапный механизм коннекта к базе данных используют не только рабочие процессы, но и некоторые SAP утилиты. Например, R3trans или R3load. 

Для смены пароля владельца схемы (пользователь SAP<SCHEMA-ID>) нельзя использовать методы базы данных Oracle (например, команду password) (рис. 6). Так как в этом случае пароль изменится только в системных таблицах Oracle, а в таблице OPS$<USER>.SAPUSER останется старым и рабочие процессы не смогут соединиться с базой данных (рис. 7).

Рис. 6. Пример смены пароля владельца схемы методами Oracle.

Рис. 7. Пример ошибки при попытке рабочего процесса открыть соединение с базой данных.

Чтобы смена пароля не привела к ошибкам в работе системы, для этой операции необходимо использовать утилиты BR*Tools (в старых системах - SAPDBA). Про эти утилиты я писал в этой статье. Утилита от SAP изменит пароль владельца схемы не только в системных таблицах Oracle, но и таблице OPS$<USER>.SAPUSER. А это обеспечит корректную работу описанного выше механизма соединения рабочих процессов (рис. 8 и 9).

Рис. 8. Корректный способ смены пароля владельца схемы - 1.

Рис. 9. Корректный способ смены пароля владельца схемы - 2.

А если обратить внимание, что на нижнем уровне в brtools запускается утилита BRCONNECT, то пароль можно сменить, запустив эту программу напрямую одной командой вида:

> brconnect -u / -f chpass 

Хотя пароль владельца схемы в таблице SAPUSER и хранится в зашифрованном виде, рекомендую дополнительно ознакомиться с рекомендациями по организации более безопасной инфраструктуры, прочитав SAP note #157499 - OPS$ connect and security aspects. Там описано, например, как ограничить список IP-адресов машин, с которых возможен удалённый коннект к серверу базы данных, используя OPS$-механизм. 

А начиная с Oracle 11g была прекращена поддержка со стороны Oracle OPS$-механизма для удалённого подключения и, SAP (начиная с SAP Kernel 7.20) стал использовать новый механизм для организации соединения рабочих процессов SAP и базы данных. Но об этом я расскажу уже во второй части статьи. 

Автор: Шиболов Вячеслав Анатольевич

Базовые механизмы СУБД Oracle: Redo Logs и Undo Segments

В начале хочу сразу обозначить, что я не являюсь супер бизоном, который знает Oracle вдоль и поперёк. С базами данных Oracle мне приходится иметь дело только с позиции SAP Basis консультанта, для которого база данных это лишь одна из компонент большой инфраструктуры. Да и мои взгляды на вопросы установки, мониторинга и администрирования сформированы через призму документации компании SAP. 

Поэтому этот пост прошу воспринимать не как попытку показать какой я умный, а как попытку упорядочить картину прежде всего у себя в голове. Знаете же выражение: пока объяснял, сам понял. :)

Теперь можно начинать. :)

Представим базовую часть СУБД Oracle в виде схемы, изображённой на рисунке 1. Предупреждаю сразу: тут далеко не все части и процессы Oracle. Я отобразил только те процессы и компоненты, которые важны в рамках механизмов, которые я буду описывать далее.

Рис. 1. Базовая структура базы данных Oracle.

СУБД Oracle можно разделить на две части:

• инстанция базы данных, состоящая из процессов и общих областей памяти (System Global Area или SGA), 
• файлы базы данных на уровне файловой системы.

Как вы скорее всего уже знаете, при использовании базы данных Oracle в SAP системах в качестве клиентов базы данных выступают рабочие процессы SAP инстанций (SAP WPs). Каждому такому процессу соответствует один рабочий процесс со стороны инстанции Oracle (shadow process).

Data block

Самая маленькая логическая единица, которую Oracle использует при операциях с данными - это data block. При создании базы данных его размер можно выбрать, но в SAP инсталляциях размер data block всегда 8 Кб (8 192 байт).

Database buffer cache

Все данные базы данных Oracle содержатся в дата-файлах (data files), которые хранятся на дисковом хранилище. Однако обработка данных никогда не производится напрямую в файлах. При операциях чтения соответствующий процесс базы данных (shadow process) сначала копирует данные из дата-файлов в Database buffer cache (конечно, если этих данных еще нет в кэше). И только после этого передаёт данные пользователю, то есть рабочему процессу SAP. Так как все подключенные к инстанции Oracle пользователи могут совместно использовать одни и те же, скопированные из дата-файлов в Database buffer cache, данные, то данный механизм существенно ускоряет последующие операции чтения.

Размер Database buffer cache инстанции Oracle имеет ограниченный размер, так как оперативная память сервера не безгранична. Поэтому в кэше хранятся только последние прочитанные блоки данных. А перезапись блоков кэша происходит по алгоритму LRU («наиболее давно используемый»).

Любые изменения данных в базе данных (операции INSERT, UPDATE или DELETE) также всегда производятся в Database buffer cache. При этом изменённые блоки кэша помечаются как «dirty blocks». При копировании данных в кэш такие блоки (dirty buffers) не могут быть перезаписаны shadow процессами, до тех пор пока эти изменённые блоки не будут скопированы в дата-файлы. Записью «dirty blocks» занимается не shadow процесс, а специальный фоновый процесс инстанции Oracle - DBW0 (database writer).

Процесс DBW0 активируется в следующих случаях:

• перед тем, как скопировать данные в кэш, shadow процесс сканирует области Database buffer cache на наличие не изменённых блоков, которые можно перезаписать. И если количество сканированных блоков достигает определённого порогового значения, то shadow процесс сигнализирует DBW0, чтобы он записал часть «dirty blocks» на диск. DBW0 копирует часть «dirty blocks» в дата-файлы, используя алгоритм LSU (Least Number of Stream Used). После этого эти блоки в кэше становятся доступными для shadow процессов.
• в момент Checkpoint, когда DBW0 записывает все «dirty blocks» из Database buffer cache в файлы на дисках. Событие Checkpoint инициируется фоновым процессом CKPT. Детали будут чуть ниже.

Использование механизма отложенной записи повышает быстродействие. Во-первых, во многих случаях, прежде чем DBW0 скопирует блок на диск, данные в блоке могут несколько раз измениться. Во-вторых, повышается эффективность операций ввода-вывода, так как DBW0 часто выполняет запись сразу нескольких блоков параллельно.

Почти всегда можно руководствоваться правилом: чем больше данный кэш, тем быстрее работает база данных. Вспомните мой старый пост про это.

Консистентность данных

Но основанный на отложенной записи механизм должен избегать потери данных и обеспечивать консистентность базы данных, даже в случае сбоя любого компонента системы. А сбой может быть как аппаратным (например, сбой дискового хранилища), так и программным - сбой инстанции Oracle.

Как я уже рассказывал здесь, транзакция базы данных - это LUW (logical unit of work) сервера базы данных. Так как LUW всегда атомарная, то изменения из LUW должны быть или выполнены полностью, или полностью отменены. Для достижения консистентности данных (и консистентности чтения данных) в рамках концепции LUW СУБД Oracle использует Redo-записи для отката или восстановления (например, после сбоя) и Undo-записи для отката неподтверждённых (uncommitted) транзакций.

Redo-записи

Redo-записи содержат информацию необходимую и достаточную для того, чтобы реконструировать, восстановить или откатить, внесенные в базу данных с помощью SQL-запросов данные прежде всего в подтверждённых (commit) транзакциях.

Параллельно с изменением блоков данных в Database buffer cache, shadow процесс записывает Redo-записи в Redo log buffer. Это круговой буфер, находящийся в SGA, в который временно записываются все завершённые и незавершённые изменения данных. Фоновый процесс LGWR (log writer) периодически записывает порции записей из Redo log buffer последовательно на диск - в Online redo log file. 

Oracle redo log file имеет заранее заданный фиксированный размер и не растёт динамически, как обычный файл. Поэтому, когда текущий Online redo log file заполняется, процесс LGWR закрывает файл и начинает запись в следующий. В SAP инсталляциях по умолчанию используется 4 группы Online redo log files по 2 копии файлов в каждой. Online redo log file, в который LGWR пишет в данный момент, называется CURRENT. А процедура переключения файлов называется log switch.

Так как количество Online redo log files также заранее ограничено, Oracle перезаписывает старые Redo-записи новыми, используя эти файлы по кругу. 

Каждый log switch СУБД увеличивает LSN (log sequence number). С помощью LSN Oracle автоматически создаёт последовательные номера для Redo log files. 

LGWR начинает запись в следующие моменты:

• при подтверждении (commit) любой транзакции,
• каждые 3 секунды,
• когда Redo log buffer полон на одну треть,
• когда DBW0 собирается записать изменённые блоки из Database buffer cache на диск, а некоторые соответствующие Redo-записи еще не были записаны в Online redo log files. Таким образом предотвращается попытка записи с опережением журналирования (write-ahead logging).

Этого достаточно для того, чтобы всегда иметь место для новых Redo-записей в Redo log buffer. При этом по умолчанию размер этого буфера при установке в SAP системах небольшой (1 - 8 Мб).

Дополнительно когда пользователь (рабочий процесс SAP) подтверждает завершение (commit) транзакции, транзакции присваивается SCN (system change number) базы данных. Oracle записывает SCN, вместе с Redo-записями транзакции в Redo log buffer. При этом DBW0 нет необходимости записывать блоки данных в момент подтверждения (commit) транзакции. Потому что в СУБД Oracle используется журналирование с опережением записи.

Новые значения модифицированных данных, которые хранятся в Redo-записях, называются «after images».

Undo-записи

Undo-записи содержат информацию необходимую для отмены или отката любых изменений в блоках данных, которые были выполнены в результате неподтверждённых (uncommitted) транзакций.

Undo-записи содержат старые значения изменённых данных, называемые «before images».

Oracle хранит Undo-записи в специальных Undo сегментах, которые хранятся в специальном пространстве - Undo space. При этом Undo space может быть реализовано двумя способами:

• Automatic Undo Management (AUM),
• Manual Undo Management.  

При AUM администратор должен лишь создать специальное табличное пространство - Undo tablespace (PSAPUNDO) достаточного размера и настроить пару параметров Oracle. Управление Undo сегментами СУБД осуществляет сама.

При ручном управлении необходимо создать и настроить некоторое количество Rollback segments, у которых необходимо тщательно рассчитать размер и параметры. Данные сегменты также располагаются в отдельном табличном пространстве (PSAPROLL). Про проблемы с данными сегментами у меня был отдельный пост. 

Начиная с Oracle 9i по умолчанию используется AUM.

Таким образом Undo-записи хранят информацию для транзакций, сохраняя её в Undo space, как минимум, до завершения транзакции. Так как данные записи используются для отката транзакций, то Undo-записи могут быть перезаписаны только после того, как транзакция будет подтверждена (commit) или сброшена (rollback). 

Стоит отметить, что Oracle может использовать Undo-записи и для других целей. Например, для консистентного чтения из snapshots. В этом случае данные читаются из «before images». В то время, как происходит изменение этих же данных в ещё неподтверждённых (uncommitted) транзакциях.

Control file

Каждая база данных Oracle имеет свой контрольный файл (control file). Это маленький бинарный файл, необходимый как в момент старта базы данных, так и в процессе работы. Следовательно данный файл должен быть всегда доступен на запись.

Control file содержит записи, которые определяют физическую структуру и состояние базы данных. Например, в нём хранится информация о табличных пространствах, именах и положении дата-файлов и Online redo log files, а также текущий LSN.

Править файл напрямую нельзя. Только процессы СУБД могут вносить изменения в control files. Если физическая структура базы данных изменяется (например, добавляется новый дата-файл), СУБД автоматически обновляет control file.

Oracle control file очень важен для работы базы данных. Поэтому несколько копий могут быть сохранены в разных местах, а СУБД обновляет их одновременно. В SAP системах по умолчанию сконфигурировано 3 копии control files.

Checkpoint

Checkpoint это момент времени, в котором файлы базы данных находятся в консистентном состоянии. Достигается это состояние тем, что в этот момент DBW0 сбрасывает все текущие изменённые блоки из Database buffer cache в дата-файлы. За инициацию события Checkpoint отвечает специальный фоновый процесс CKPT, который и даёт команду процессу DBW0 начать запись блоков. Одновременно Checkpoint обозначает специальную позицию в Redo log. 

Что происходит в момент Checkpoint:

1. DBW0 активируется, получая сигнал в определённые моменты времени от фонового процесса CKTP.
2. DBW0 копирует все текущие «dirty blocks» на диск. Причём, пока DBW0 закончит выполнять запись, другие блоки в кэше могут быть изменены, но они уже не записываются.
3. Когда событие Checkpoint закончится (то есть будут записаны все выбранные блоки), самый старый буфер из «dirty blocks» в Database buffer cache будет обозначать точку в Redo log, после которой может быть начато восстановление в случае сбоя. Это позиция журнала и называется Checkpoint position.

Кроме этого процесс CKTP также выполняет следующие шаги:

• записывает информацию о Checkpoint в заголовок каждого дата-файла,
• записывает информацию о Checkpoint position в Online redo log file в контрольный файл Oracle (control file).

Информация о позиции Checkpoint в Online redo log file в контрольном файле необходима в процессе восстановления инстанции. Позиция Checkpoint сообщает инстанции Oracle, что все Redo-записи, которые были записаны до этого момента, не нуждаются в восстановлении. Так как эти данные уже записаны в дата-файлы.

Частота Checkpoints один из важных факторов, который напрямую влияет на время необходимое для восстановления инстанции в случае сбоя. Чем реже будут в системе происходить Checkpoints, тем большее времени будет необходимо инстанции для восстановления в случае сбоя.

Хотя частоту Checkpoint можно настроить через параметры Oracle, при разворачивании SAP систем эти параметры не используются. А Checkpoint всегда возникает только в моменты переключения Online redo log files (log switch).

Восстановление базы данных

Теперь основываясь на всех механизмах, которые были описаны выше, разберём как происходит восстановление базы данных.

Речь пойдёт не о восстановлении из резервной копии базы данных, которую должен выполнять администратор. А речь пойдёт об автоматическом восстановлении базы данных, которое СУБД производит в момент старта. Так называемое instance recovery. Оно необходимо, если предыдущий останов базы данных был выполнен не чисто, например, с опцией IMMEDIATE или ABORT. Или произошёл сбой работы сервера базы данных по аппаратной или программной причине.

Автоматическое восстановление при старте содержит следующие важные шаги:

1. В control file находится последний Checkpoint. После этого, начиная с позиции Checkpoint, читаются Redo-записи из Online redo log files и заново проводятся все транзакции, указанные в журнале. Происходит процесс roll forward. Заметьте, что этот шаг всегда включает и проведение изменений для Undo space, то есть восстанавливаются «before images».
2. Для всех заново применённых транзакций, которые не были подтверждены (commit) до сбоя или были отменены прямо перед сбоем (поэтому для них нет подтверждения в Redo log), выполняется откат. Для отката используется образ «before images» из Undo space. СУБД уверена, что это всегда возможно, потому что Undo-записи незавершённых транзакций из Undo space никогда не удаляются и не перезаписываются.

В результате после открытия консистентная база данных содержит только те изменения, которые были подтверждены (commit) перед сбоем.

Из процесса восстановления базы данных видно, что Online redo log files это одна из критически важных частей сервера Oracle. А если вспомнить, что в SAP установках Checkpoint наступает только в момент log switch, то при автоматическом восстановлении СУБД всегда нужен последний Online redo log file целиком. И если он будет потерян во время сбоя, то полное восстановление (complete recovery of database) будет невозможно. В результате чего данные будут потеряны, а база данных может оказаться в неконсистентном состоянии.

Поэтому-то Online redo log files должны храниться минимум в двух копиях, каждая из которых расположена на отдельном диске. Так же в продуктивной системе база данных должна работать в ARCHIVELOG режиме. В этом режиме фоновый процесс ARC0 (archiver) копирует каждый только что записанный Online redo log file в Offline redo log file. Offline redo log file в своём имени содержит LSN. Понятно, что копирование возможно начать только после переключения (log switch) и необходимо закончить до повторного возвращения процесса LGWR к этому файлу. Так как в таком режиме перезапись старых Redo-записей в Online redo log files не разрешается до тех пор, пока эти записи не скопированы в Offline redo log files.

Ну и должно соблюдаться ещё одно ограничение: могут быть перезаписаны только те Redo-записи, которые расположены до позиции Checkpoint в Redo log. То есть соответствующие им изменения уже записаны в дата-файлы. Это гарант возможности автоматического восстановления инстанции в случае сбоя.

Об Online redo log file и ARCHIVELOG режиме я подробно рассказывал в постах:

• Журнальные файлы Oracle и archivelog mode. Часть I,
• Журнальные файлы Oracle и archivelog mode. Часть II,
• Файл-пустышка.

Если хотите разобраться в вопросах администрирования базы данных Oracle на практике, то можете приобрести мой обучающий курс SAPADM 2.0. Этой теме в курсе полностью посвящён третий пакет заданий. 

Автор: Шиболов Вячеслав Анатольевич