Tis true that once you introduce raid the 'Best Practice' becomes rather confusing. If you can get your log files on non raided disk on a separate disk array you will be achieving best practice I have some disks in a disk array non raided. Probably runs a bit faster as less disk writes required - also gives you more space but once you have multiplexed the disks for safety is it worth it? On 8 April 2010 10:02, Vladimir Barac <vbarac@xxxxxxxxxxxx> wrote: > Hello, listers > > > > What are general pros and cons on separating redo logs from database files? > Both database and redologs are already residing on RAID1 volumes. So this > separation would only mean – move redo logs to separate mount point (RAID1, > still). > > > > We have EMC consultant insisting that it is in line with best practices. > Why exactly is it a good thing, what "best practice" actually means – he > can't say. > > > > Our systems are moderately used OLTP databases. I we had lots of waits on > redo log writes (and we don’t), I would understand moving redo logs to flash > drives (for example). Or, as I have seen previously, database goes to RAID5 > and redo logs to RAID1 – depends a lot on database usage, etc. etc. > > > > Actual real life inputs are welcome. > > > > Regards, > > Vladimir Barac > > ______________________________________________________________________ > This e-mail message and any attachments to it are for the sole use of the > intended recipients and may contain confidential and privileged information. > This e-mail message and any attachments are the property of Yusuf A. > Alghanim & Sons w.l.l. or any of its subsidiaries or affiliates (“Alghanim > Industries”). Any unauthorized review, use, disclosure, or distribution of > this e-mail message or its attachments is prohibited. Any opinions expressed > in this message are those of the author and do not necessarily reflect the > opinion of Alghanim Industries. If you are not an intended recipient, please > notify the sender by reply e-mail and destroy all copies of the original > message and any attachments. > ______________________________________________________________________ > -- Howard A. Latham