Re: Standby strategy

Some remarks:

• I assume that you are using Open VMS 6.2 ?
• It seems to me a waste of capacity to not making use of Digitals cluster-technology
• If you're using SQL*net you might have a problem with TNSNAMES. The HOST parameter is essential to locate the right LISTENER after fail-over. You should use two copies of it with different HOST-names
• The idea is possible when the database (and Oracle Server) are brought down normally. When this is not the case you will keep the problem with the control files and status of the database.
• Beside starting up the instance on the fail-over node, you should start Oracle as well.

conclusion:
The risks are bigger then the profit. Use the products which are designed for it at try to convince your client of that.

regards,
Guus van de Sande
Independent Oracle Consultant

Nigel Rudgyard <nigel_at_rudgyard.demon.co.uk.nospam> schreef in artikel <890075227.29319.0.nnrp-07.c1ed0cd9_at_news.demon.co.uk>...
> We are currently trying to devise a suitable strategy for maintaining a
 hot
> standby system using two clustered DEC Alphas. Two disks within each box
 are
> volume shadowed thus giving each machine visibility to all the Oracle
 files
> within the installation. We are using Oracle v7.1.5.
>
> Up until recently we had been intending to make use of the Oracle
 Parallel
> Server option, however due to the associated costs, this solution is no
> longer acceptable to our client unless it represents the viable option
> within the project timescales.
>
> Since we are not really using OPS as it was originally intended - for the
> most part the standby machine is idle - it crossed my mind that a much
> cheaper solution is potentially possible. Assuming the two machines are
> known as A and B, the strategy goes something like this; a single
 database
> instance starts up (in exclusive mode) on machine A. At failover the
 Oracle
> instance upon A is shutdown (assuming that it is still up) and a new
> database instance, accessing the same database, in started up upon B.
> Simple.
>
> Now so long as we can guarantee that the two instances (or more precisely
> the two occurences of the same database instance) are never connected to
 the
> database simultaneously then we are OK. If this cannot be guaranteed then
> the database is in danger of being corrupted. Note that unlike two
 instances
> running upon the same machine I don't believe that Oracle will trap this
 on
> our behalf. The 2nd instance to connect will, after interrogating the
> control files, presumably see that there is an inconsistency and attempt
 to
> perform crash recovery.
>
> Has anybody had any experience of implementing such a strategy ? Is it
> viable ?
>
>
>
Received on Mon Mar 16 1998 - 00:00:00 CST