Re: Best database for web backend on Linux?
--------------6B323E597B88F10B1A436F17 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thor, Its interesting to note what is happening when Oracle is doing row level locking for you. On the server, in your working cache that oracle reserves for your queries (kind of like creating a shell for a user in UNIX), not only does Oracle have to track the pages you are working on, but it now has to keep track of all the rows you are thinking of updating. It also needs to "publish" any occurances of updates, locks and freed rows to other interested parties. This costs lots of clock cycles, not to mention memory. As an example, SAP on Oracle requires that you install at least 32Mb of ram PER USER on the server. Some of this is due to the way in which Oracle handles client access, but most of it is due to the overhead created by row level locking. Thor wrote: > Why are you assuming that row level locking requires you to lock the data on > read/browse??? LONG transactions are even better when you can get atomic, > row-level, locks rather than page locks. Unless you mean true long > transactions, then neither scheme is worthy of that. > > If you look at most Oracle aware tools, they only lock that single record, > iff that record has been modified. > > Thor HW -- ----==-- _ / / \\ ---==---(_)__ __ ____ __ / / /\\ \\ --==---/ / _ \\/ // /\\ \\/ / / /_/\\ \\ \\ -=====/_/_//_/\\_,_/ /_/\\_\\ /______\\ \\ \\ A proud member of TeamLinux \\_________\\/ email: carew@home.msen.com web: http://home.msen.com/~carew --------------6B323E597B88F10B1A436F17 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <HTML> Thor, <P>Its interesting to note what is happening when Oracle is doing row level locking for you. <BR>On the server, in your working cache that oracle reserves for your queries (kind of like <BR>creating a shell for a user in UNIX), not only does Oracle have to track the pages you are <BR>working on, but it now has to keep track of all the rows you are thinking of updating. It also <BR>needs to "publish" any occurances of updates, locks and freed rows to other interested parties. <BR>This costs lots of clock cycles, not to mention memory. <P>As an example, SAP on Oracle requires that you install at least 32Mb of ram PER USER <BR>on the server. Some of this is due to the way in which Oracle handles client access, but <BR>most of it is due to the overhead created by row level locking. <P>Thor wrote: <BLOCKQUOTE TYPE=CITE>Why are you assuming that row level locking requires you to lock the data on <BR>read/browse??? LONG transactions are even better when you can get atomic, <BR>row-level, locks rather than page locks. Unless you mean true long <BR>transactions, then neither scheme is worthy of that. <P>If you look at most Oracle aware tools, they only lock that single record, <BR>iff that record has been modified. <P>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>; </HTML> --------------6B323E597B88F10B1A436F17--