Re: Combining Data Guard with clustered redo logs for high performancestandby
Dennis G Allard wrote:
> Mark Bole wrote:
>> Dennis G Allard wrote:
> I slightly misspoke -- the clustered disk will have the primary
> server redo logs, the primary server archived redo logs (that have
> not yet been shipped to the standby), and the primary server
> control file.
> The Standby will receive copies of the archived redo logs
> periodically and use them to maintain the Standby database.
> At time of failure of the Primary server the Standby will need
> to mount the clustered disk and obtain the Primary server
> redo logs and archived redo logs that had not been received
> prior to failure.
>>> I have not yet combed the Data Guard documentation
>>> to attempt to figure out if I can make use of its
>>> facilities for transferring archive redo logs and
>>> initiating fail over yet somehow inform the standby
>>> to mount the redo logs on the external storage
>>> prior to activation.
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.
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?
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
having a physical standby requires another full Oracle license (false
claims to the contrary not withstanding)? Do you know that Oracle
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
to 10 minutes and maintain the physical standby in a geographically
separate location, which will take care of many, many more scenarios
than the few you are trying to address, and is supported too? If you
look at it from a business point of view, rather than technical, you'll
be better off in my opinion.