Dennis G Allard <allard@oceanpark.com> wrote in
news:430240AE.9050505@oceanpark.com:

> Mark Bole wrote:
>> Dennis G Allard wrote:
>>
>>> Mark Bole wrote:
>>>
>>>> Dennis G Allard wrote:
>>>> [...]
>
>> I think I understand what you are trying to do -- recover the
>> physical standby with all available archived redo logs, then replace
>> the standby control file with the primary control file, copy the
>> primary online redo logs, and start up the database and let it
>> perform automatic instance recovery as if it were the primary. I
>> doubt it will work, but there's no harm in testing.
>
> Actually, not 'copy' the redo logs. Instead, mount the physical
> partition containing the redo logs (etc.) on the Standby so that
> it now sees those files as its own. That is the essence of an
> active/passive cluster. What used to be files local to the Primary
> server become local files on the Standby after the Primary goes
> off line and the Standby mounts the partitions.
>
>> Step back and consider your two main goals: you want guaranteed zero
>> loss of committed transactions, and you don't want any performance
>> penalty for copying those transactions to a second location in real
>> time. I don't think it is possible in this case to get "something
>> for nothing". Have you measured the actual impact of the performance
>> penalty? Have you measured the actual impact of losing, say, ten
>> minutes worth of transactions once every three years?
>
> In our case, I do agree that we can 'afford' to lose some transactions
> if it is very rare. But I also believe that the new clustering
> technologies (such as Red Hat Linux Cluster Suite) will make it
> possible to have ones cake and eat it too!
>
> I have scoured the web and USENET and Oracle docs. I am now convinced
> that this form of active/passive cluster database failover is not
> in common use. However, I see no reason that it cannot be
> implemented.
>
>>
>> If you trust your external storage array, why not put your whole
>> database on the external array, since you are already putting the
>> control files, online, and archived redo logs there? Do you know
>> that
>
> As a matter of fact, I have decided to do just that! Because then I
> could use the active/passive failover technique by simply installing
> Oracle on a backup server but keep it turned off. Fail over would
> cause the backup server to mount the external disks and bring Oracle
> up (and, for that matter, take over the IP of the failed primary
> server).
>
>> having a physical standby requires another full Oracle license (false
>> claims to the contrary not withstanding)? Do you know that Oracle
>
> I just attended Linux Expo in San Francisco last week. Oracle reps
> stated that they have a 'ten day rule' -- as long as you don't use
> the standby server database more than ten days in the year, there is
> no license fee.
>
>> recommends never backing up online redo log files, which is very
>> similar to what you are trying to do? Why not just set your archive
>> lag target
>
> Again, I'm not copying redo logs. I'm merely remounting them to a
> different CPU box. I agree there is no point in backing up redo
> logs (as opposed to archived redo logs, which, of course, one should
> backup back to at least the last hot or cold backup of the database).
>

The mount point for redo logfiles mentioned immediately above could
be a nasty single point of failure that could bring down both DBs.