RE: Metalink and availability

• Jeremiah Wilton <jeremiah_at_ora-600.net> wrote:

> The thing that takes the most time with the CPU patches on Unix is that
> Opatch patches and relinks one binary at a time serially. Having the
> database down is completely unnecessary for many of these binaries, such as
> sqlplus etc. Furthermore, even running binaries like oracle and tnslsnr can
> be relinked with the databases open and running, and staged as alternately
> named files (oracle-new, tnslsnr-new). You can then move them all into
> place during a very brief outage for all instances.
>
> There are a number of tricks that you can use to greatly reduce the apply
> time for the CPU patches. Start with the one-off patch apply guidelines in
> my paper:
>
> http://www.ora-600.net/articles/stayinalive.pdf
>

Jeremiah,

Thanks for a good write up! I also enjoined reading your "The DBA Disaster Diary: Double Failure" story -- I can relate ...

I had a concern about patching ORACLE_HOME while the instance is running (as described in your article by modifying patch scripts and oracle make-files). I think that replacing shared libraries that oracle binaries depend on might cause some side-effects on the running instance(s). It's also not supported as the patch clearly states that all processes must be down.

Instead, I would suggest to pre-stage a copy of patched ORACLE_HOME that was built on a different server, shutdown all running instances and quickly switch ORACLE_HOMEs then apply DB portion of the upgrade (if any). So far ORACLE has been good at separating DATABASE portion of the upgrade from the SOFTWARE.

I am an APPS DBA (97%) and have used similar technique for staging APPS APPL_TOPs and APPS tech-stack (tools ORACLE_HOMEs) during major upgrades. We'd stage the software ahead of time then ONLY run the database portion (d drivers) of the upgrade thus reducing the total upgrade time. Still, in the APPS "world" major upgrades take 40-60 *continuous* hours. That's why I wouldn't recommend running APPS in "front" of a true 24/7/365 shop (back-end is OK maybe ...). You just can't turn replication ON on something like this:

14:59:41 SYSTEM_at_XUPG:amanda> select count(*), object_type
14:59:46   2  from dba_objects
14:59:50   3  group by object_type
14:59:53   4  order by 1 desc;

  COUNT(*) OBJECT_TYPE

---------- ------------------
     45979 SYNONYM
     37683 INDEX
     37046 PACKAGE
     35940 PACKAGE BODY
     26436 VIEW
     21359 TABLE
     10095 JAVA CLASS
      8759 SEQUENCE
      2588 TRIGGER
      1457 TYPE
       933 INDEX PARTITION
       575 LOB
       438 TABLE PARTITION
       412 MATERIALIZED VIEW
       290 JAVA DATA
       209 PROCEDURE
       197 JAVA RESOURCE
       164 FUNCTION
       143 QUEUE
        85 LIBRARY
        71 TYPE BODY
        61 DATABASE LINK
        46 RULE SET
        27 OPERATOR
        25 EVALUATION CONTEXT
        20 CONTEXT
        20 RULE
        10 CLUSTER
         8 JAVA SOURCE
         7 INDEXTYPE
         4 CONSUMER GROUP
         3 DIRECTORY
         3 RESOURCE PLAN

15:09:01 SYSTEM_at_XUPG:amanda> select trunc(sum(bytes)/1024/1024) mbytes,segment_type
15:09:32 2 from dba_segments
15:09:35 3 group by segment_type;

    MBYTES SEGMENT_TYPE

---------- ------------------
         0 CACHE
       158 CLUSTER
     55514 INDEX
       133 INDEX PARTITION
        22 LOBINDEX
       773 LOBSEGMENT
         0 ROLLBACK
         8 SPACE HEADER
     63907 TABLE
       313 TABLE PARTITION
        83 TYPE2 UNDO

## with so many (2706) transactions per hour (slow day) ##
amanda.XUPG-> grep "26-MAY-2006 14" xupg.log | wc -l

    2706

Regards,
- Vitaliy

--
http://www.freelists.org/webpage/oracle-l