Тетрадочка DBA

CPUApr2009

Posted by shane54lv на 27 Май, 2009

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

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

 
%d такие блоггеры, как: