Minimal Downtime Patching

Сегодня речь пойдёт о патчинге БД, а точнее о том, как минимизировать downtime системы во время установки патчей.

Методика заключается в создании дополнительного Oracle Home клонированием исходного и установке на него патчей без остановки БД. После этого необходимо остановить БД, поменять местами старый и новый Oracle Home, стартовать БД и выполнить postinstallation шаги. Тем самым downtime сокращается до времени рестарта БД и выполнения postinstallation steps на новом OH.

Весь процесс установки патчей можно разделить на две части: ONLINE и OFFLINE. ONLINE часть – это подготовительная часть, которая делается без остановки БД и состоит из клонирования Oracle Home и установки на него патчей. OFFLINE часть состоит из рестарта БД с изменением Oracle Home и выполнения постинсталляционных шагов.

  ·   ONLINE part

1. Клонирование Oracle Home

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

Есть два варианта. Первый вариант - изменение переменной окружения ORACLE_HOME на путь к новому OH. Второй вариант - замена директории, в которой находится OH на символьную ссылку и пересоздание этой ссылки во время остановки БД.

С первым вариантом всё ясно - остановили БД, изменили переменные окружения и стартовали БД на новом OH, но есть вероятность того, что старое значение переменной ORACLE_HOME может встречаться например в скриптах или окружении других пользователей, что приведёт к ошибкам. Нужно найти все упоминания о нём и изменить на новый, а это может быть довольно проблематично

Второй способ лишён этого недостатка. Вместо директории, в которой располагается Oracle Home создаётся символьная ссылка, и после остановки БД необходимо её пересоздать ссылаясь на нужный OH. Переменные окружения менять не нужно.



$ echo $ORACLE_HOME
/oracle/PROD/11203
$ ls -l /oracle/PROD/
/oracle/PROD/11203  

# Oracle Home "/oracle/PROD/11203" - директория

$ mkdir /oracle/PROD/11203_2
$ cd /oracle/PROD/11203
$ find . -depth | cpio -pvd ../11203_2 #Клонирование OH

$ ls -l /oracle/PROD/
/oracle/PROD/11203
/oracle/PROD/11203_2


Таким образом в директории "/oracle/PROD/11203_2" находится копия OH. Для переключения OH нужно будет остановить БД и выполнить следующие команды:


$ mv /oracle/PROD/11203 /oracle/PROD/11203_1
$ ln -s /oracle/PROD/11203_2 /oracle/PROD/11203


Итого имеем два независимых OH, находящихся в директориях "/oracle/PROD/11203_1" и "/oracle/PROD/11203_2" и символьную ссылку "/oracle/PROD/11203", указывающую на нужный OH.

$ ls -l /oracle/PROD/
/oracle/PROD/11203 -> /oracle/PROD/11203_2
/oracle/PROD/11203_1
/oracle/PROD/11203_2


Клонирование можно делать разными способами, в примере описанном выше использовалась команда cpio. Важно, чтобы символьные ссылки после копирования сохранили свой первоначальный вид. (При копировании командой cp символьные ссылки заменяются на файлы, на которые они ссылаются).
Проверяем что все файлы скопировались (количество файлов должно совпадать):

$ find /oracle/PROD/11203 | wc -l  # Old OH
$ find /oracle/PROD/11203_2 | wc -l  # New OH


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

$ cd /oracle/PROD/11203_2
$ find ./ -type l -exec ls -l {} \;
./bin/lbuilder -> /oracle/PROD/11203/nls/lbuilder/lbuilder # Нужно пересоздавать
./jdk/bin/java -> ../jre/bin/java
./jdk/bin/javaw -> ../jre/bin/javaw
./jdk/bin/keytool -> ../jre/bin/keytool
./jdk/bin/policytool -> ../jre/bin/policytool
./jdk/bin/rmid -> ../jre/bin/rmid
./jdk/bin/rmiregistry -> ../jre/bin/rmiregistry
./jdk/bin/tnameserv -> ../jre/bin/tnameserv
./jdk/jre/bin/classic/libjvm.a -> libjvm.so
./jdk/jre/bin/j9vm/libjvm.a -> libjvm.so
./jdk/jre/bin/libjsig.a -> libjsig.so
./lib/libclntsh.so.10.1 -> libclntsh.so
./lib/libnnz10.a -> /sapBTR/oracle/BTR/11203_2/lib/libnnz11.a
./lib/libnnz10.so -> libnnz11.so
./lib/libobk.a -> /usr/lib/libobk64.a
./lib/libodm11.so -> libodmd11.so
./precomp/public/ORACA.COB -> oraca.cob
./precomp/public/ORACA.H -> oraca.h
./precomp/public/SQLCA.COB -> sqlca.cob
./precomp/public/SQLCA.H -> sqlca.h
./precomp/public/SQLDA.H -> sqlda.h

$ ln -sf /oracle/PROD/11203_2/nls/lbuilder/lbuilder ./bin/lbuilder


Для того, чтобы патчи успешно применились на новый OH нужно зарегистрировать его в Central Inventory. Для этого находим расположение Central Inventory, далее заходим в директорию ContentsXML и редактируем файл inventory.xml
Нужно добавить туда строку описывающую новый OH по аналогии с уже существующими.

На этом этап клонирования OH можно считать завершённым.


2. Установка Патчей
Установку патчей нужно делать согласно инструкции в patch readme, главное на этом этапе изменить значение переменных окружения так, чтобы они указывали на неактивный в данный момент OH.

  ·   OFFLINE part

1. Рестарт БД с изменением Oracle Home

Останавливаем БД и все сервисы, использующие старый OH. Если для замены OH был выбран первый способ, то изменяем переменные окружения. При втором способе выполняем действия описанные выше (пересоздаём символьную ссылку). Запускаем БД на новом OH.


2. Выполнение postinstall шагов
Postinstallation шаги выполняются согласно patch readme.

Заключение

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