Hi
Few random thoughts on the topic:
1) SSD/flash world is growing and changing rapidly. Soon enough
most storage is going to be in some form of flash
2) SSD/flash is perfect for random reads and not so good for
continuous writes by design (search write cliff SSD). With your values for
redo it most likely shouldn't be an issue
3) anything under few hundred MB of redo/sec can be served with reasonable
latency by rotational disks provided you have a good write cache
4) log file sync waits are not only about writing redo, it's much more
complex than that, especially with modern oracle releases. If you need
better advice then you need to start with 1h statspack/awr report of your
system
5) usually these days people use ASM and its striping for the best results
from all available disks, and rarely spend time deciding how to assign
parts of database to different drives.
On Wednesday, 16 December 2015, Storey, Robert (DCSO) <
RStorey@xxxxxxxxxxxxxxxxxx> wrote:
Morning,
I’ve been reading multiple docs on SSD/HDD and the benefits within an
oracle database.
If I am reading this write, for an OLTP system, the SSD/FLASH will provide
excellent random read/write abilities.
But folks seem contradicted on using the SSD for the Redo logs. Some say
its best practice, others say it does not buy you anything.
I have a 24/7 OLTP application that generates a modest amount of redo. My
overall DB is about 95 gigs, I generate about 600megs of redo in a day
(10meg files, switching every 30 or so). My system is getting to end of
life, and I see more log_file_sync waits, and buffer busy waits. I suspect
my I/O subsystems are getting worked hard. My top waits appear to be
sequent file reads and scattered reads, log file sync, and buffer busy.
What’s the general verdict on using SSD for the data files? Best idea
for redos? My thoughts there are separating them to different drives, ie,
two separate single disks, with a group member on each disk.
Thoughts?
Thanks
