Памятка внукам — вырезки из 30+ страничного README файла по инсталляции патча CPUApr2009 — только «соль»:
- Качаем с Металинка патч № 8290506 (инфа о всех доступных версиях патчах CPUApr2009 по платформам и версиям софта)
-
Создаем Restore Point (guaranteed / обычную), либо через Grid Control, либо вручную:
SQL> CREATE RESTORE POINT "Before upgrade to CPUApr2009"; SQL> CREATE RESTORE POINT "Before upgrade to CPUApr2009" GUARANTEE FLASHBACK DATABASE;
- Выключаем в базе AUDIT — меняем значение параметра audit_trail на null (он статический).
- Выключаем все — и базу, и ASM
- Бекапим TAR’ом оба хоума — ASM + DB — и не забываем oraInventory
-
Выставляем ORACLE_HOME на ASM и по инструкции:
unzip p8290506_10204_.zip cd 8290506 opatch napply -skip_subset -skip_duplicate
Если путь до opatch не прописан в PATH — пишем полный путь вызова:
/u01/app/oracle/product/10.2.0/db/OPatch/opatch napply -skip_subset -skip_duplicate
- Переключаем ORACLE_HOME на DB и повторяем предыдущий шаг.
-
Включаем ASM и по инструкции закачиваем необходимые скрипты в базу:
cd $ORACLE_HOME/rdbms/admin sqlplus /nolog SQL> CONNECT / AS SYSDBA SQL> STARTUP SQL> @catbundle.sql cpu apply SQL> QUIT
-
Проверяем, не было ли ошибок: каталог $ORACLE_HOME/cfgtoollogs/catbundle содержит два файла вида:
catbundle_CPU_[database SID]_APPLY_[TIMESTAMP].log catbundle_CPU_[database SID]_GENERATE_[TIMESTAMP].log
-
И последнее — перекомпилировать все, что развалидировалось.
- Проверка, выполнялась ли уже компиляция. Если запрос возвращает «no rows selected» — значит, ничего еще не делалось:
SQL> SELECT * FROM registry$history WHERE ID = '6452863'; no rows selected SQL>
- Предкомпиляционный скрипт — позволяет прикинуть, на сколько затянется компиляция и стоил ли ее делать сразу же, или maintenance window не на столько «широк» и компильнуть придется уже на рабочей системе:
cd $ORACLE_HOME/cpu/view_recompile sqlplus /nolog SQL> CONNECT / AS SYSDBA SQL> @recompile_precheck_jan2008cpu.sql SQL> QUIT
В моем случае результат был 18 119 объектов, требующих компиляции. Кстати, интересная деталь — я так и не понимаю, о каких объектах идет речь, т.к. запрос к DBA_OBJECTS на проверку всех объектов с полем STATUS != ‘VALID’ показывает 10-50 объектов, т.е. «это не они».
- Собственно, сама компиляция:
cd $ORACLE_HOME/cpu/view_recompile sqlplus /nolog SQL> CONNECT / AS SYSDBA SQL> SHUTDOWN IMMEDIATE SQL> STARTUP UPGRADE SQL> @view_recompile_jan2008cpu.sql SQL> SHUTDOWN; SQL> STARTUP; SQL> QUIT
У меня заняла около 30 минут и после работы осталось еще 12 000 нескомпилированных объектов. Они уже были видны через DBA_OBJECTS и для их компиляции используется стандартный скрипт utlrp.sql:
cd $ORACLE_HOME/rdbms/admin sqlplus /nolog SQL> CONNECT / AS SYSDBA SQL> @utlrp.sql
- Нужно ли патчить агента GC? Или поставить агента версии 10.2.0.5, судя по тому, что для большинства ОС он вышел совсем недавно, возможно он уже «пропатчен». Уточню.
- Если создавалась гарантированная точка восстановления (глава 5.2 Using Normal and Guaranteed Restore Points из книги Oracle® Database Backup and Recovery Basics 10g Release 2 (10.2)), необходимо внимательно следить за местом во FRA, используемом для обеспечения возможности восстановления:
SELECT NAME, TIME, ROUND (storage_size / 1024 / 1024 / 1024, 0) AS "Storage Size, Gb" FROM v$restore_point;
В моем случае, после установки патча в базу и компиляции объектов, запрос возвращал около 3 Гб; после запуска апликации и 30 минут работы (ночь, но работают ночные задания), размер вырос до 16 Гб. После чего я принял решение, раз все работает — точку восстановления стереть:
SQL> DROP RESTORE POINT "Before upgrade to CPUApr2009";
Вот собственно и все. Процесс установки CPUApr2009 очень прост и прозрачен, нужно лишь заказать maintenance window не менее 2-х часов и расписать заранее все действия, чтобы ничего не забыть.
Из оставшихся открытых вопросов: