Re: Redo Log Status

From: Sybrand Bakker <postbus_at_sybrandb.demon.nl>
Date: 1998/11/20
Message-ID: <36555ca4.20224143_at_news.demon.nl>#1/1


On Fri, 20 Nov 1998 12:16:22 +0100, Anne-Marie Ternes <anne-marie.ternes_at_cie.etat.lu> wrote:

>Hello Oracle fellows,
>
>A few days ago, I saw in my alert log a message like : "can not allocate
>redo thread xy, redo needs archiving".
>I added a new redo group with two redo members, so now I have three redo
>groups with each having two members. There have been no more alert
>messages of this kind.
>
>Today I checked the V$LOG table, and the status field told me that
>group1 and group2 are "inactive". What is the exact difference between
>"inactive", "active", and "unused"? What should be the ideal status of a
>redo group that is not the current redo group?
>I also checked the V$LOGFILE table, and there the status field tells me
>that both members of redo group 2 are "stale". According to the Oracle
>Server Reference book, this means that the "file's contents are
>incomplete". That's very nice, but it does not tell me what I should do
>next.
>
>Could somebody please explain to me in detail what is happening to my
>redo logs, and give me suggestions as to what I can do to get back to
>normal?
>
>Thank you very much for any help,
>
>Anne-Marie Ternes
>
Active: this is the current redo log
Inactive: a redo log that is currently not being written unused: a redo log that never has been written (ie immediately after you add a redo log it will be unused)
stale: I have never seen this, though I have an idea this will occur if you drop a redo log file or group.
What happened in your case, was that all logs needed archiving at the same time. This can be resolved by manually archiving in svrmgr. The command archive log next will manually archive all active redo log files that need archiving.
Note: if the device the archive files go to fills up and Oracle can not archive anymore, the complete database will hang.

Hth,

Sybrand Bakker, Oracle DBA Received on Fri Nov 20 1998 - 00:00:00 CET

Original text of this message