|
Home > Archive > Oracle certifications > April 2002 > Multiplexing of redo log files..
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Multiplexing of redo log files..
|
|
| rohit1346 2002-04-09, 7:25 am |
| My question is regarding the multiplexing of redo log files.Suppose we create 2 groups and have 2 members in each group, so in all we have 4 files..
group 1 ) file 1 , file 2
group 2 ) file 1 , file 2
Now, if LGWR fails to write to both files of group 2, then database will crash, my question is ... why can't the other group can take over and act independently and prevent database from crashing? | |
| Ian_J 2002-04-09, 11:00 pm |
| If the members of each group are identical (ie multiplexed), then LGWR needs the second group to work so that it can write in a circular fashion. If that makes any sense?. To be honest though I can't remember if each member of a group is an exact copy of the other members.
Make any sense?
Thought not | |
| aneesh_bhatia 2002-04-10, 11:10 am |
| As far as I know...the LGWR will write the same data to each member in a group, where each member will exist on a different drive, so incase of disk failure the other group should simply take over...with no problems. I think Oracle always needs two groups for backup. But if you had two groups and if one of them failed then the other one would take over not giving you an error. That is the reason why you need a minimum of two groups. But I think the problem would arise when the only redo group left is full and a log switch is attempted...there will be no other redo group and then an error should occur.
This is what i think...DBA's out there please confim this!
Cheers! | |
| stecal 2002-04-10, 6:50 pm |
| Scenario 1 - you have a good group remaining
You must have at least 2 log groups for the database to open. You should startup mount the database, create a new log group with the appropriate members, delete the missing log group, then attempt to open the database.
Scenario 2 - an inactive group goes bad
(This is from MetaLink)
You have an "INACTIVE" ONLINE REDO LOG GROUP that has become corrupt or has
been deleted.
Solution Description:
=====================
If corrupt, drop and rebuild the lost redo log group.
1.) SHUTDOWN (clean, not immediate, not abort)
2.) STARTUP MOUNT
3.) Query V$LOG to see if the log was archived
4.) ALTER DATABASE CLEAR LOGFILE for the lost redo logs
NOTE: If there is an offline datafile (check V$DATAFILE)
that requires the cleared UNARCHIVED log to bring it online,
the UNRECOVERABLE DATAFILE parameter is required. The
datafile and its entire tablespace must be dropped from the
database because the redo necessary to bring it online is
being cleared, and there is no copy of it.
ALTERNATIVE: If the database is in archivelog mode, a backup
of the database can be restored and the archivelog and redo logs
up to, but not including, the corrupt redo log, can be applied.
The database can then be opened with resetlogs.
5.) At the operating system (OS) level delete the damaged
redo log files.
NOTE: This step can be skipped if the log file is missing.
6.) ALTER DATABASE DROP LOGFILE GROUP #
7.) ALTER DATABASE ADD LOGFILE GROUP # '<DATAFILE>' size <size>; |
|
|
|
|