Morten Torstensen wrote: > John R Pierce wrote: >> certainly are. The database adminstrators will spend hours pouring >> over IO logs and database statistics in order to better optimize the >> distribution of tables and indicies across the available tablespaces. > > Didn't realise Oracle was that primitive. One should just balance all > the tablespaces out over multiple volumes and or controllers and add > table partitioning as needed. Transaction filesystem is a striped > filesystem over the same raid/volumes. > > Then if you need more I/O bandwidth you just add more controllers and > disks. thats the shotgun approach, yes. in our case, our production systems are a very large very complex realtime oracle database running on large scale Sun enterprise hardware on bigiron EMC storage, using dozens and dozens of raid10 logical volumes as you do NOT want to have a single 10TB volume, sorry. by hand optimizing the tablespace layouts of the applications tables and indicies, which have very specific access patterns, we can get double the throughput of the blind 'just stripe the universe' approach. Since we're dealing with $millions worth of servers here at each production factory, tossing more iron at the problem isn't always the best solution. btw, we've found Oracle 10's new 'self optimizer' to do a far worse job of query optimization than what we have been able to hand tune out of Oracle 9, so we're not upgrading until this changes. we're embarking on a pilot project to evaluate a smaller scale version of this manufacturing execution system on linux + postgres as there are smaller installations which can't justify the costs of Oracle.