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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
