Fwd: Mirroring redo log groups or not ?
Date: Tue, 7 Apr 2009 22:27:43 -0700
This should have been a "reply-all"
- Forwarded message ---------- From: Rich <richa03_at_gmail.com> Date: Tue, Apr 7, 2009 at 10:25 PM Subject: Re: Mirroring redo log groups or not ? To: "Crisler, Jon" <Jon.Crisler_at_usi.com>
How much control do you have over the application and what it does? Can you "fix" the app to commit less or batch commits?
Failing that, I think RAID10 for the redo logs might be a decent fix at the database/storage level, however, be cognizant of recovery in the event of potential issues with non-grouped redo...
I would recommend separate redo LUNS - something like redoa1 & redoc2 on LUN1, redoa2 and redob1 on LUN2, redob2 and redoc1 on LUN3 with the letter being the group and and the number being the member. While I understand you may not have the LUNs to do that, seems it might be prudent.
On Tue, Apr 7, 2009 at 9:35 PM, Crisler, Jon <Jon.Crisler_at_usi.com> wrote:
> Its one of the top issues measured in AWR / ADDM. The problem
> corresponds to poor response time for disk as measured at the host, and at
> the SAN level.
> *From:* Rich [mailto:richa03_at_gmail.com]
> *Sent:* Wednesday, April 08, 2009 12:33 AM
> *To:* cicciuxdba_at_gmail.com
> *Cc:* mwf_at_rsiz.com; kennaim_at_gmail.com; david.barbour1_at_gmail.com; Crisler,
> Jon; Rajeev Prabhakar; Oracle-L Freelists
> *Subject:* Re: Mirroring redo log groups or not ?
> Back to the OP's question.
> I think you mean "log file sync", right?
> This means a session waits for LGWR to write redo to disk after commit or
> It is usually due to too many commits or short transactions; you should
> commit in batch or use faster redo log disk IO.
> However, we need more information. This wait has numerous steps with even
> more implications.
> First off, what makes you think this is THE issue?
> What are the following:
> "redo write time" statistic
> "log file parallel write" waits
> Is the system otherwise busy during high numbers of this event?
> It may not be as simple as just moving the redo logs to faster disks...