Re: Which HA Solution allows to have least downtime while havingoracleupgrades/patches

CP wrote:

> Hi Hans,
>
> Thanks a lot for the information. I have been going through the MAA
> document apart from others, it's a 198 page interesting document and I

I *did* say this was a high level document, didn't I - it's only 198 pages <g>. I also like the

> am still on it. I am really serious about getting some information
> which would help me to have a clear and concrete understanding of
> various HA/DR options/solutions and the best solution which can be used
> to provide minimum downtime for online applications (or any web related
> apps which can't afford extended downtime) using Oracle.

In all discussion I have ith those who want to go down the HA path, I suggest answering the following questions before starting on the solutions:

1. What are the applications that need to be protected?
2. What does the (per-minute x time-of-day) cost of downtime graph look like for each application?
3. What is the cyclic load nature of the app across the year?
4. Are the apps truly so interconnected that you can not stage transactions for 1/2 to 1 hour minimum load period?

> I also need some sanity check on this idea - whether or not it is
> practically possible or if I am missing/overlooking something?

The biggest mistake I see made (do it all the time myself) consistently is assuming that all the data needs to be online at one time, and all the applications need to be upgraded at one time.

If the application is pipelined you may be able to upgrade pieces independantly. This is especially true if the segments can communicate via (using Oracle's terminology) workflow, advanced queues and business events. The 'divide and conquor' rule really helps here.

The second biggest mistake I see made is the assumption that one solution fits all. Note that RAC, Dataguard, RAC-Guard and Replication are not mutually exclusive.

> Assuming that I have a two-node Multi-Master Replication setup which is
> presently on Oracle9i 9.2.0.1, can I do the following to patch from the
> present version to the latest. Or for that matter, say from Oracle8i to
> Oralce9i or from Oracle9i to OracleXXi.

> 1. Push all the transactions from the Node 2 to 1.
> 2. Disable the push job on Node 1.
> 3. Shutdown Node 2.
> 4. Patch Oracle on Node 2 and open it for use. Connections would be
> routed to Node 2 instead of 1 or from 1.
> 5. Push all the transactions from Node 1 to 2.
> 6. Disable the push job on Node 2.
> 7. Patch Oracle on Node 1 and so on......

Theoretically sound (except I would not want to start at 8i or lower).

Significant amount of this is inherent in Dataguard (physical) - the biggest gotcha I forsee being the log file compatibility across versions so this will not be viable in all situations.

> As regards Upgrading from lower to higher version I am sure there would
> be restrictions stating that all the participating nodes should be on
> the same version of Oracle if not at least on the same patchset.

Lets not forget that the OS version and it's associated patches may have an impact as well.

The bottom line - testing in the separate test environment is mandatory. Practice, evaluate, identify the glitches and determine the true time and true potential outage before attempting on the live system. (For those organizations that believe they can not afford a test environment I have no answer ...) Received on Sat Jun 21 2003 - 12:21:41 CDT