Re: RDBMS Comparison 1.2
chuckg@Starbase.NeoSoft.COM (Chuck G.) wrote: > >Comparing Database Engines >========================== > >This document is intended to stimulate input regarding the strengths, >weaknesses, and gotchas for advanced relational database engines. >Feedback will be used to develop a profile of each product and >product comparisons. > ........ >Oracle Server 7 >--------------- >The Oracle Server 7 enjoys the largest market share of Unix relational >database engines (as opposed to file access tools). It employs a multitude >of processes to enhance throughput. Logging is particularly robust, allowing >transactions to be larger than the transaction log. Many sites use Oracle to >replace mainframe databases. > >Server management is too complex. The multiprocess architecture of >Oracle Server 7 can lead to server lockups. The optimizer requires hints >to avoid poor performance. > Could you elaborate. What is complex about the server management? Many Oracle instances run out of the box with only two parameters changed-- The amount of blocks to buffer and the size of the shared pool. There are lots of tunable parameters but you don't have to touch them if you don't want to or have the knowledge to. Most of the things you have to consider for other servers like "How big to make my logs so my server doesn't die, How many locks do you think I might generate, How do I get row level locking from this page level locking system, How can I get correct (consistent) answers from my Server, How can I avoid blocking due to locks,...." and so on just aren't an issue with Oracle. The multi-process architecture leads to lockups? When? How? I've been using Oracle for a long time and haven't seen the dreaded server lockup. If anything the multi-process architecture AVOIDS server lockups. It would be a multi-threaded, single process engine that would lock up. If one thread in the single process takes over, the whole server goes with it. Please explain what you mean by server lockups. The optimizer does not require hints to avoid poor performance. Rather the optimizer accepts DOCUMENTED hints when the programmer/DBA knows better. Compare this to the UNDOCUMENTED hints used by others and available only when you scream for them. >Disclaimer >---------- >I do not speak for my employers. I am responsible for all unattributed >factual errors. This document is not intended to endorse any product. >Trademarks belong to their respective owners. > >Contact Information >------------------- >Please send feedback, input, and corrections to chuckg@neosoft.com. > >$Id: dbcompare.txt,v 1.2 1995/06/20 13:26:41 chuckg Exp $ >-- >chuckg@NeoSoft.com "Daddy!" -- D. Rooter Thomas Kyte tkyte@us.oracle.com