CPUApr2009

Памятка внукам — вырезки из 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
  

Вот собственно и все. Процесс установки CPUApr2009 очень прост и прозрачен, нужно лишь заказать maintenance window не менее 2-х часов и расписать заранее все действия, чтобы ничего не забыть.

Из оставшихся открытых вопросов:

• Нужно ли патчить агента 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";