Re: Separating online redo logs from database files

On Thu, Apr 08, 2010 at 12:02:19PM +0300, Vladimir Barac 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


The main problem with "Best practice" is to understand what it means and what 
is behind it ;-)
Seriously, when I talk to some people and asking them why they think it should 
be done that way
I can (many times ...) hear: "because it is best practise". But when I drill 
down they cannot
explain why this is best practise. My feeling is that _sometimes_ they don't 
understand
the topic/subject/issue very well and the "best practise" is a sort of 
discussion avoidance ...
Of course I am curious why they want to avoid discussion ... ;-)

Also Best Practise is sometimes born within special environment what means that 
if you have
slightly different environment you should carefully check if the best practise 
is really
the "best" for you.

In our case we had all databses (and their redo logs) spread over all available 
disks.
It worked very well and our DBA never reported any issue related to e.g. log 
file sync
Of course you can hace much bigger load so this config might not work for you.

Now we are changing our approach to place redo (from different databases) on 
separated
disks (+dedicated array cache).


Regards
Przemyslaw Bak (przemol)
--
http://przemol.blogspot.com/




























--
http://www.freelists.org/webpage/oracle-l

Other related posts: