Jan
24
I was chatting with Doug recently about disk layouts, and the conversation rolled onto disk and volume topologies and layouts.
Where I'm working at the moment, there has been a myth propogated that striping is good for data filesystems, and concats are better for redo logs.
Quite where this has come from, I'm not entirely sure. However.. whilst thinking about this I came to the conclusion that for redo logs, the layout is largely irrelevant.
Assuming that is, if you are striping, you are using a reasonably large column width, and you're not trying to RAID5 the redo log, which would likely result in poor performance unless accelerated by some write caching controller. The thinking went something along these lines:
The theory is that the size of the redo log write will be very small (a matter of bytes or, at the most a couple of kilobytes, I'd imagine (it's been a while since I've actually traced any of this through to physical I/O - so this is a largely theoretical argument) so let's assume for the time being that an "average" redo write is 1KB, and we have a striped layout with a column width of 256KB (this was based on a specific example), the chance of a redo log write spanning two columns (and therefore requiring two separate physical write ops instead of one) is going to be:
KB in a column= 256
Bytes in a column= 256*1024= 262144
For a two block write (2* 512bytes) to span two columns, it would require to start at least (512*2-1) bytes from the end of the column (=1023 bytes)
The probability therefore of a redo log write requiring two separate write operations = 1024/262144= 0.0039% (and even then, the two writes are on distict spindles, possibly even different controllers, and will probably happen in parallel).
Based on the aforementioned assumptions - that sort of probabilities I can live with, and so can the DBA team. So, whilst we are striping the data volumes, it makes good sense to also stripe the redo logs. Keep it the SAME.
0 Trackbacks