Re: Best database for web backend on Linux?

Posted in 1998

Evan Carew — Tue, 20 Oct 1998 19:47:10 +0000 — source: Informix-list mailing list archive (1991-1998)

--------------4415FB970461B0EE646B0FE7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Good question Thor. It is important to read those benchmarks very carefully. When Sybase and Oracle came to my job site to do a bake off, we noticed they were utilizing a special setting for their server designed for the benchmarks. This setting of course disables row level locking. When we forced both vendors to do "out of box" installs the picture changed substantially. When we also did feature by feature comparison, it was interesting to note just how badly you could make Oracle perform. As a programmer somewhat familliar with the history of the two products this didn't suprise me overly much. Sybase's history includes being the first fully client server database whereas Oracle's includes being a reasonable mainframe based database that converted to the client server model (some would say not very well). Should you ever have the chance, you want to force a vendor to do thourough stored proceeduretesting while someone runs a large query where the result set is guaranteed to be larger than the memory pool alloted to the data server. You also want to be shure you review all the database performance settings so they don't manage to pull the wool over your eyes (you would hope this would go without saying). The last time I did this, it managed to crash the INFORMIX box (a bug in their implementation of stored procedures) and really sloooow down the oracle box. The sybase server by comparison didn't sag too much. You also want to get a feeling for what feature aren't shared by all the servers, for instance, Sybase has the ability to partition its memory pool so the neat trick mentioned above will have no effect on performance. Another issue is that there are certain SQL dvanced optimizations that are impossible with ORACLE . For refrences to this, see Optimizing Transact-SQL Programming Techniques by Dr. David Rozeshtein & Anatoly Abramovich . Thor wrote: > I like row-level locking. Everyone is trying to get it into their > dbms. It sure saves a tonne of coding (grab the sybase docs and read > the timestamp work they suggest for high availability and avoid > blocking, yuck).If row-level locking is implemented well, it doesn't > need to grind the database to a standstill, maybe if it's an > afterthought/option to add, you might see that.If that were the case, > then why is Oracle able to post such fast benchmarks? Thor HW -- ----==-- _ / / \\ ---==---(_)__ __ ____ __ / / /\\ \\ --==---/ / _ \\/ // /\\ \\/ / / /_/\\ \\ \\ -=====/_/_//_/\\_,_/ /_/\\_\\ /______\\ \\ \\ A proud member of TeamLinux \\_________\\/ email: carew@home.msen.com web: http://home.msen.com/~carew --------------4415FB970461B0EE646B0FE7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <HTML> <BODY BGCOLOR="#FFFFFF"> Good question Thor. It is important to read those benchmarks very carefully. When Sybase and Oracle came to my job site to do a bake off, we noticed they were utilizing a special setting for their server designed for the benchmarks. This setting of course disables row level locking. When we forced both vendors to do "out of box" installs the picture changed substantially. When we also did feature by feature comparison, it was interesting to note just how badly you could make Oracle perform. As a programmer somewhat familliar with the history of the two products this didn't suprise me overly much. Sybase's history includes being the first fully client server database whereas Oracle's includes being a reasonable mainframe based database that converted to the client server model (some would say not very well). Should you ever have the chance, you want to force a vendor to do thourough stored proceeduretesting while someone runs a large query where the result set is guaranteed to be larger than the memory pool alloted to the data server. You also want to be shure you review all the database performance settings so they don't manage to pull the wool over your eyes (you would hope this would go without saying). The last time I did this, it managed to crash the INFORMIX box (a bug in their implementation of stored procedures) and really sloooow down the oracle box. The sybase server by comparison didn't sag too much. You also want to get a feeling for what feature aren't shared by all the servers, for instance, Sybase has the ability to partition its memory pool so the neat trick mentioned above will have no effect on performance. Another issue is that there are certain SQL dvanced optimizations that are impossible with ORACLE . For refrences to this, see Optimizing Transact-SQL Programming Techniques by Dr. David Rozeshtein & Anatoly Abramovich . Thor wrote: <BLOCKQUOTE TYPE=CITE> I like row-level locking.  Everyone is trying to get it into their dbms.  It sure saves a tonne of coding (grab the sybase docs and read the timestamp work they suggest for high availability and avoid blocking, yuck).If row-level locking is implemented well, it doesn't need to grind the database to a standstill, maybe if it's an afterthought/option to add, you might see that.If that were the case, then why is Oracle able to post such fast benchmarks? Thor HW</BLOCKQUOTE>   <PRE>--  ----==-- _                     / /  \\ ---==---(_)__  __ ____  __    / / /\\ \\ --==---/ / _ \\/ // /\\ \\/ /   / /_/\\ \\ \\ -=====/_/_//_/\\_,_/ /_/\\_\\  /______\\ \\ \\ A proud member of TeamLinux \\_________\\/ email: carew@home.msen.com web: <A HREF="http://home.msen.com/~carew">http://home.msen.com/~carew</A></PRE>;   </BODY> </HTML> --------------4415FB970461B0EE646B0FE7--