Path: newssvr20.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!in.100proofnews.com!in.100proofnews.com!news.maxwell.syr.edu!postnews1.google.com!not-for-mail From: vslabs@onwe.co.za (Billy Verreynne) Newsgroups: comp.databases.oracle.misc Subject: Re: tuning an simple insert-statement Date: 10 Oct 2003 05:37:35 -0700 Organization: http://groups.google.com Lines: 69 Message-ID: <1a75df45.0310100437.3e511f00@posting.google.com> References: <3f5991a9$1@news.swissonline.ch> <3F59C6BD.7090009@comcast.net> <3f59f32e$1@news.swissonline.ch> <1a75df45.0309061217.1374f0b@posting.google.com> <3f83e403$1@news.swissonline.ch> NNTP-Posting-Host: 198.54.206.91 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1065789455 13367 127.0.0.1 (10 Oct 2003 12:37:35 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 10 Oct 2003 12:37:35 +0000 (UTC) Xref: newssvr20.news.prodigy.com comp.databases.oracle.misc:132186 Pascal wrote i > now I have a rather technical question to ask you: > you told me that you could write a little fast database by taking more > shortcuts. what do you understand with shortcuts? Eliminating overheads. Ignoring scalebility. Ignoring crash recovery. Simply put - streaming persistant objects to disk and memory using very fast and very basic file and memory streams. A million objects can be loaded (and constructed) like that (yep, prototype code was written and benchmarked) within seconds. > I have do answer the question why oracle is slower than other databases > (focus: my simple application). It is not really slower IMO. Not if you are doing it correctly and not if you are making the same comparisons. > what are the technical differences in the implementation > of these db's? I'm not looking for details, but rather for concepts. May I suggest the Oracle Concepts manual at http://tahiti.oracle.com ? - it will provide a much better (and more accurate) explaination. > perhaps you can give me some points where to start with my analysis. IMO that's pretty difficult. Cache is an object database. Oracle is object relational data processing platform. It is far beyond a database. It incorporates operating system features and application server features. The speed of a single transaction is irrelevant. What is relevant is the speed of 10 million transactions. How well the data processing platform (aka database) can scale. There's a Linux cluster used within EA Arts (or one of its subsidiaries). It uses Oracle RAC. It runs far over 20,000+ SQL *statements* a second. Not transactions - *statements*. On an older K-class HP-UX platform, I've seen 1.2+ billion rows processed (reading over 1 Terrabyte of data) within 13 hours. You work out the maths for that per second. :-) Can something like Cache scale as well? Can it *really* handle such huge loads without showing strains and cracks? OTOH though, if you are running a small database setup, do you need that? Horses for courses. Which is why you cannot simply compare product A with product B and say product B is better. Never mind taking a *single* specific feature from product A and compare that with product B. The comparison must be qualified. Must have the same baseline criteria. And that is IMO not possible. And even if you have an ideal closed system to do that comparison, the results will have no real world meaning or application. What you can do is look at the technical aspects of said feature. Then comment on that from a pure technical perspective (not comment, not compare ;-). > perhaps you know a good book or a good homepage!? Start with tahiti.oracle.com and look at the Oracle Concepts manual. -- Billy