Уменьшение времени простоя при повышении версии БД

Апгрейд базы данных - процесс нетривиальный и занимающий в общем случае немало времени. Обычно он делается либо экспортом-импортом (для небольших и некритичных к простою баз) или же путём установки новой версии софта и прогона скрипта для апгрейда словаря данных.
Если база у нас большая и важная, то время работы по обновлению весьма ограничено, поэтому надо постараться минимизировать время простоя, чтобы высвободить время для исправления ошибок, которые могут проявиться (и таки проявятся!) после апгрейда.
Основная суть такова: установку софта, последнего патчсета, начальное конфигурирование надо произвести на другом сервере, пока база будет полностью доступна, после чего подменить том, содержащий ORACLE HOME, на новый. Заодно отпадает необходимость в бэкапе старого home.
В этой статье я постараюсь кратко описать процесс апгрейда с 9.2.0.8 до 10.2.0.5. ОС - Solaris 10, в качестве менеджера томов используется VxVM.

Итак, приступим:

1. Делаем полный бэкап любым доступным способом (у меня стоит Symantec NetBackup), мне достаточно просто запустить политику.
2. На другом сервере создаём том в любой дисковой группе для установки софта:

   vxassist -U gen -g some_grp make proddb_home_new 9G+8k user=proddb group=dba
   newfs /dev/vx/rdsk/some_grp/proddb_home_new 
   mkdir /usr/oracle/proddb_new
   mount /dev/vx/dsk/some_grp/proddb_home_new /usr/oracle/proddb_new
   chown -R proddb:dba /usr/oracle/proddb_new

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

3. Ставим софт. Тут важно, чтобы UID пользователя на этом сервере совпадал с исходным. У нас используется NIS, поэтому UID для пользователя с одним и тем же именем на всех серверах будет совпадать.

   # Проверим значение переменной DISPLAY и если надо, установим его:
   echo $DISPLAY
   # Ставим. Надо выбрать пункт Install database software only:
   /install/10.2.0.1/database/runInstaller
   # Ставим последний патчсет:
   /install/Patchsets/10.2.0.5/Disk1/runInstaller
   # Размонтируем том - мы его сейчас потащим на основной сервер.
   umount /usr/oracle/proddb

4. Теперь на исходном сервере создадим том:

   vxassist -U gen -g proddb make proddb_home_new 9G+8k user=proddb group=dba

   И перетащим на него содержимое с временного тома:

   dd if=/dev/vx/rdsk/some_grp/proddb_home_new bs=1024k |\
   ssh root@prodsrv 'dd of=/dev/vx/rdsk/proddb/proddb_home_new bs=1024k'
   #Теперь можно удалить ставший ненужным временный том:
   vxassist -g some_grp remove volume proddb_home_new

5. Теперь смонтируем новый том рядом со старым и скопируем сетевые настройки:

   mkdir /usr/oracle/proddb_new
   mount /dev/vx/dsk/proddb/proddb_home_new
   cp -R network/admin/*.ora ../proddb_new/network/admin/

6. Запомним список инвалидных объектов, пригодтся для сравнения:

   CREATE TABLE bad_objs AS 
   	SELECT * FROM dba_objects 
   	WHERE status = 'INVALID';

7. Создадим SYSAUX tablespace, его не было в 9i, но появилось оно в 10g.

   # Создадим том для него
   vxassist -U gen -g proddb make sysaux_01.dbf 2G+8k user=proddb group=dba layout=concat

   -- Создадим tablespace
   CREATE TABLESPACE sysaux 
   	DATAFILE '/dev/vx/rdsk/proddb/sysaux_01.dbf'
   	EXTENT MANAGEMENT LOCAL
   	SEGMENT SPACE MANAGEMENT AUTO
   	ONLINE;

8. Создадим и настроим файл параметров:

   CREATE PFILE FROM SPFILE;

   cp dbs/initproddb.ora ../proddb_new/dbs/

   Там выставим параметры:
   aq_tm_processes и job_queue_processes=0 (на время обновления)
   compatible='10.2.0.5.0'

9. Теперь запишем время или SCN изменения, это будет точка, на которую можно будет восстановить базу в случае, если что-то пойдёт не так.
10. С этого момента база будет недоступна.
    Остановим все прикладные сервисы, отключим и остановим резервное копирование.
    Хорошей идеей будет перевести в оффлайн все табличные пространства кроме системных, временных и undo, т.к. процесс апгрейда их не затрагивает, а в случае проблем восстанавливать придётся меньше.

    ALTER TABLESPACE main_ts OFFLINE NORMAL;
    ...
    SHUTDOWN IMMEDIATE;

    Листенер тоже остановим:

    lsnrctl stop

11. Теперь меняем местами тома для домашнего каталога:

    # Копируем контролфайлы
    cp dbs/control* ../proddb_new/dbs
    # Размонтируем тома.
    umount /usr/oracle/proddb
    umount /usr/oracle/proddb_new
    # Переименовываем тома.
    vxedit -g proddb rename proddb_home proddb_home_old
    vxedit -g proddb rename proddb_home_new proddb_home
     
    # Монтируем новый том.
    mount /usr/oracle/proddb

12. Момент истины - апгрейд

    STARTUP UPGRADE
    @?/rdbms/admin/catupgrd
    -- Проверим состояние компонентов,
    -- они все должны быть VALID:
    SELECT comp_name, version, status 
    FROM dba_registry;
    -- Создадим файл параметров;
    CREATE SPFILE FROM PFILE;
    -- Отстановим базу
    SHUTDOWN IMMEDIATE
    -- Запустим снова
    STARTUP
    -- Сделаем табличные пространства доступными:
    ALTER TABLESPACE main_ts ONLINE;
    ...

    Если компоненты невалидны или не той версии, что нужно, то мои вам поздравления! Надо их переустановить поодиночке.
    Также не забываем вернуть прежние значения параметров aq_tm_processes и job_queue_processes.
    Не забываем запустить листенер:

    lsnrctl start

13. Все объекты у нас развалились, надо их перекомпилировать:

    @?/rdbms/admin/utlrp

    С этого момента база будет доступна, надо не забыть запустить снова бэкап логов.

14. Удалим старый том, он больше не нужен:

    vxassist -g proddb remove volume proddb_home_old

Обновление завершено, время ловить баги. Тут нам пригодится список объектов, полученный в шаге №6.
P.S. Если используется DataGuard, то резервный сервер апгрейдится таким же образом после основного.