The problem with SANs in many organisations is that you just get allocated space in the larger scheme of things. Depending on the architecture, it can be hard to specify exactly where your data goes, so you don't have the chance to optimise its layout. You want to spread your data across as many disks as possible in order to parallelise the I/O, so I'd go for local drives because you have comlete control over them
The sad thing is that disks are getting bigger, but it's better to have lots of smaller ones rather than a few (or even one) big one(s). You'd either stripe at the hardware level or lay your data out manually. Genterally you'll need to know your data hotspots - which you or your DBA can find out through the v$ tables, or via Enterprise Manager.
The other thing to consider is that Oracle has partitioned tables, so you can spread you can spread the hotspots around the disks, cos in most cases, there are a couple of tables that bear most of the I/O brunt
Finally, most I/O bottlenecks can be improved by closely examing your database schema, tuning your SQL and finally look at your hardware. Hardware considerations come last. Unlike coding, premature optimsation through db design is absolutely essential, as it's almost impossible to refactor the design once it's gone live. Also use the v$ tables to identify your worst performing SQL I/O-wise - they can often be tuned through judicious choice of indexes, optimizer hints etc.
Finally, you don't need a super-grunty server, just as many disks as you can afford!
In reply to Re: OT: What Hardware is important for large I/O bound processes
by astroboy
in thread OT: What Hardware is important for large I/O bound processes
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |