Апгрейд базы данных - процесс нетривиальный и занимающий в общем случае немало времени. Обычно он делается либо экспортом-импортом (для небольших и некритичных к простою баз) или же путём установки новой версии софта и прогона скрипта для апгрейда словаря данных.
Если база у нас большая и важная, то время работы по обновлению весьма ограничено, поэтому надо постараться минимизировать время простоя, чтобы высвободить время для исправления ошибок, которые могут проявиться (и таки проявятся!) после апгрейда.
Основная суть такова: установку софта, последнего патчсета, начальное конфигурирование надо произвести на другом сервере, пока база будет полностью доступна, после чего подменить том, содержащий ORACLE HOME, на новый. Заодно отпадает необходимость в бэкапе старого home.
В этой статье я постараюсь кратко описать процесс апгрейда с 9.2.0.8 до 10.2.0.5. ОС - Solaris 10, в качестве менеджера томов используется VxVM.
Итак, приступим:
- Делаем полный бэкап любым доступным способом (у меня стоит Symantec NetBackup), мне достаточно просто запустить политику.
-
На другом сервере создаём том в любой дисковой группе для установки софта:
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
. -
Ставим софт. Тут важно, чтобы 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
-
Теперь на исходном сервере создадим том:
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
-
Теперь смонтируем новый том рядом со старым и скопируем сетевые настройки:
mkdir /usr/oracle/proddb_new mount /dev/vx/dsk/proddb/proddb_home_new cp -R network/admin/*.ora ../proddb_new/network/admin/
-
Запомним список инвалидных объектов, пригодтся для сравнения:
CREATE TABLE bad_objs AS SELECT * FROM dba_objects WHERE status = 'INVALID';
-
Создадим 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;
-
Создадим и настроим файл параметров:
CREATE PFILE FROM SPFILE;
cp dbs/initproddb.ora ../proddb_new/dbs/
Там выставим параметры:
aq_tm_processes и job_queue_processes=0 (на время обновления)
compatible='10.2.0.5.0' - Теперь запишем время или SCN изменения, это будет точка, на которую можно будет восстановить базу в случае, если что-то пойдёт не так.
-
С этого момента база будет недоступна.
Остановим все прикладные сервисы, отключим и остановим резервное копирование.
Хорошей идеей будет перевести в оффлайн все табличные пространства кроме системных, временных и undo, т.к. процесс апгрейда их не затрагивает, а в случае проблем восстанавливать придётся меньше.ALTER TABLESPACE main_ts OFFLINE NORMAL; ... SHUTDOWN IMMEDIATE;
Листенер тоже остановим:
lsnrctl stop
-
Теперь меняем местами тома для домашнего каталога:
# Копируем контролфайлы 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
-
Момент истины - апгрейд
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
-
Все объекты у нас развалились, надо их перекомпилировать:
@?/rdbms/admin/utlrp
С этого момента база будет доступна, надо не забыть запустить снова бэкап логов.
-
Удалим старый том, он больше не нужен:
vxassist -g proddb remove volume proddb_home_old
Обновление завершено, время ловить баги. Тут нам пригодится список объектов, полученный в шаге №6.
P.S. Если используется DataGuard, то резервный сервер апгрейдится таким же образом после основного.