Re: RAID-5 vs. Disk Mirroring

I can't comment on performances changes when moving from RAID-5 to mirroring, since we never ran RAID-5. My understanding of RAID-5 and mirroring would make me think that mirroring would be much faster on writes, and similar performance on reads. The amount of write performance improvement would depend on how many disks were in the RAID-5 array. Mirroring would be slow if you were mirroring to the same spindle or maybe to the same controller ( in a multiple controller disk system).

In your case, adding redo logs should not have impacted performance unless the redo log files were added to a disk/spindle that has very high disk I/O. This would cause a lot of disk I/O contention, and WILL slow down your system. Did your redo log files move when you went from RAID-5 to mirroring? If all mirrors of your redo log files are on the same disk, you might notice some performance hits since LGWR would have to write to one log file, then the other log file, instead of being able to write to both log files at the same time.

Archiving the log files shouldn't degrade your system, since the only impact on the system is when the logs are actually being archived.

I would also check the layout of tablespaces on the disks when you changed to mirroring. You may be seeing the results of a poorly laid-out database, and you may have a lot of disk I/O contention.

Hope this helps,

Mike Strong
Texas Instruments, Inc., Houston
Oracle DBA
(713) 274-3317
My opinions only.

In article jer_at_smallmouth.execpc.com, Jer_at_execpc.com () writes:

What about just mirroring vs RAID-5? We are noticing a HUGE performance problem going from Raid-5 to Mirroring and am wondering if it's the mirror or the addition of logs/archive mode (wasn't on before)?

In article <1996Jan29.181912.5617_at_newshost.micro.ti.com>, <mstrong_at_wotangate.sc.ti.com> writes:
> Newsgroups: comp.databases.oracle
> Path:

daily-planet.execpc.com!homer.alpha.net!solaris.cc.vt.edu!newsfeed.internetmci. com!swrinde!cs.utexas.edu!news.ti.com!newshost!raiders!mstrong
> From: mstrong_at_wotangate.sc.ti.com (Mike Strong,713 274 3317,0883922)
> Subject: Re: RAID-5 vs. Disk Mirroring
> Message-ID: <1996Jan29.181912.5617_at_newshost.micro.ti.com>
> Sender: news_at_newshost.micro.ti.com
> Reply-To: mstrong_at_wotangate.sc.ti.com
> Organization: Texas Instruments Inc.
> References: <4ebtuu$9ln_at_maverick.tad.eds.com>
> Date: Mon, 29 Jan 1996 18:19:12 GMT
> Lines: 44
>
> We just made the decision to go with striping/mirroring instead of RAID-5.
 The RAID-5
> performance issues were one major reason. The other reason is that in order
 to add
> drives to a RAID-5 array, the database needs to be exported, the new drives
 added,
> the disks reformatted, and the database imported (this is according to a SUN
 rdbms
> guru and our system admin; don't yell at me if this isn't correct). We did
 not want
> to take the downtime hit for the

 export/install/format/praying/import/praying.
>
> My boss was not happy with the disk cost (1G = 500M mirrored), but he really
 did not
> like the downtime costs.
>
> Hope this helps,
>
> Mike Strong
> Oracle DBA
> Texas Instruments, Inc., Houston
> (713) 274-3317
>
> My opinions only.
>
> In article 9ln_at_maverick.tad.eds.com, bob_at_latcost1.alaao.ats.eds.com (Bob
 Stewart) writes:
> > BBAP (bbap_at_aol.com) wrote:
> > : Does anyone have experience to share on either RAID-5 or Disk Mirroring.
 

> > : We are trying to make a decision on a direction. The concern is which
> > : method will ensure that data will be there (no loss is permited), while
> > : not comprimising performance. Cost is not a consideration.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > When do I start?
> >
> > Seriously. If cost is not really a consideration, then don't bother
> > looking at RAID5. RAID5 solutions are considerably slower on average
> > than mirroring solutions. Both are reliable.
> >
> > Later.
> > --
> > Bob Stewart ASE
> > (310) 335-7152 Air Transportation Division
> > bob_at_latcost1.alaao.ats.eds.com
> >
> > I am definitely NOT speaking for EDS.
>
>
>
>
>
Received on Fri Feb 02 1996 - 00:00:00 CET