| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Combining Data Guard with clustered redo logs for high performance standby
Mark Bole wrote:
> Dennis G Allard wrote: >
> > You mean Data Guard Broker, not Data Guard. >
> > > You are confusing online redo logs, standby redo logs, and archived redo > logs.
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 implemented this once but used an NFS mount for the 'clustered' disk. It is highly inadvisable to use an NFS mount for redo logs so I plan to use a true external active/passive cluster instead this time around.
Here is some more definition of what I plan to do...
There will be a 'Primary database server' and a 'Standby database server'. If the Primary server fails, the Standby server will be 'activated' to replace the Primary server and begin acting as the Primary server (with due notification and/or IP modifications so that clients see it as the Primary server).
I will use a physically shared disk array in an active/passive configuration to store files that are used by the Primary server before it fails and are mounted and accessed by the Standby after the Primary server fails. I.e., the shared disk is only used by the Primary server while the Primary server is operating. But after the Primary server fails, the Standby will mount the shared disk to obtain the latest redo logs.
There are three kinds of files on external disk array:
primary server redo logs
primary server archived redo logs
primary server control files (not sure I need these on the cluster)
A process will send archived redo logs to the standby at regular intervals. The standby will have its own local control file. The state diagram for the standby during the time it is acting as a Standby (pre-activation) is as follows (the commands shown are current as of Oracle 8.1.7 and may need to be updated for Oracle 10g):
> Standby Database State Diagram (Standby mode) > > +-------+--------> Shutdown > | ^ | > | | | > | | | startup nomount > | | | pfile=/u01/app/oracle/admin/<SID>/pfile/initSTANDBY.ora > | | | > | | Started > | | | > | | | > | | shutdown | alter database mount standby database; > | | immediate | > | +<-------- > | Mounted (not open) ----------------------------+ > | +--------> | > | | | | > | | | <receive primary site archived logs> | > | | | | > | | cancel | recover automatic standby database | > | | | | > | | | | alter > | +--------- Recovered (through most recent archived log) | database > | | | open > | | | read only; > | | alter database open read only; | > | | | > | | | > +------------------ Open (read only) <----------------------------+ > shutdown abort
The Standby control files and initSTANDBY.ora are created by the following procedure:
> 1. Back up the primary database data files via either cold or hot backup. > > 2. Create a standby control file > (ALTER DATABASE CREATE STANDBY CONFOLFILE AS 'filename') > > 3. Archive the current online redo logs of the primary database > (ALTER SYSTEM ARCHIVE LOG CURRENT) > > 4. Transfer the standby control file, archived log files and backed-up > data files to the standby database.
In the above diagram, nodes represent states that the Standby database can be in and arrows are labeled by the database operation used to cause a transition to the state the arrow points to.
The process <receive primary site archived logs> can be implemented via scp or other remote copy program over a TCP connection. (I'm hoping Data Guard [Broker] can help with that.)
Normally, in the above diagram, the Standby oscillates between the states 'Mounted' and 'Recovered'. After new archived redo logs arrive from the Primary database, the Standby is transitioned to the 'Recovered' state (my terminology) by the 'recover automatic standby database' command, which consumes all available archive redo logs that have an SCN less than the current Standby control state.
Now, what happens when the Primary server fails?
The fail over process causes the Standby Server to perform the following
> . > . -- Primary site failure detected > . > started (mounted) > | > | obtain primary site online redo logs, control files and > | any remaining archived logs (not sure I need the control files) > | > | recover automatic standby database; > | > Recovered (through most recent archived log) > | > | cancel > | > Mounted (not open, recovered through all primary site archived logs) > | > | shutdown immediate > | > Shutdown > | > | <copy production control files, production online redo logs > | to /u01/oradata/<SID>/ -- OK to do copy prior to above shutdown> > | > | <Assure production parameter file in admin/pfile/init<SID>.ora> > | > Shutdown (still) > | > | startup mount pfile=/u01/app/oracle/admin/<SID>/pfile/init<SID>.ora > | > | > Mounted > | > | recover database > | > | > Recovered > | > | alter database open > | > | > Open (normal read/write operation) > | > | alter system archive log all [ Doc says do this 'after opening' > | but Appendix C - Post Open Script does it before opening :-( ] > | > Continue using system as a primary site database
>> I realize that one can use RAC to achieve HA
>> via a clustered disk array. However, me thinks
>> that a less expensive solution for HA could be
>> obtained by combining Data Guard with the above
>> idea of using external storage just to store the
>> redo logs (and control files?). In this way, one
>> should be able to operate Data Guard with a
>> LogXptMode set to ARCH. At time of fail over,
>> one would need to point the Standby database
>> server to the redo logs that had been previously
>> mounted by the primary server.
> > > Are you willing for your online redo logs to be a single point of > failure, or not? Once you answer that question, you can proceed.
I will either use Oracle mirroring or Hardware mirroring of the online redo logs. In that sense, they will not be a single point of failure.
The external disk array we have has dual storage processors, dual fiber channel ports, and hardware RAID.
It is true that if we mirror enough information to internal disks on the Standby, we can achieve a further level of reliability. But my goal is to have *zero* impact on transaction performance of the Primary server. My reading of the Data Guard documentation is that it is not able to provide recoverability to the last committed transaction without some loss of performance (LogXptMode = SYNC).
Cheers,
Dennis
>> 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.
>>
>> Has someone out there attempted this feat?
>>
>> Thanks,
>> Dennis
> > > -Mark BoleReceived on Tue Aug 16 2005 - 01:47:02 CDT
 |
 |