Re: Db2, Oracle, SQL Server

Mark A wrote:
> "Noons" <wizofoz2k_at_yahoo.com.au> wrote in message
> news:42073e33$0$27615$5a62ac22_at_per-qv1-
> > > decision support databases were the data was only loaded when the
table
> is
> > > not available to users, or when the table is available to users
and only
> > > selects are being executed.
> >
> > Just take a full table lock at the start and be done with it.
> > It's a very special case, the loading of DSS or DW data.
> > >
> For decision supports systems, it is not a unique occurrence. It is
not just
> the loads. It applies to the loads, utilities, and all queries. You
don't
> want a "select" only system to take row locks all the time, because
table
> locks are much faster. Storing locks in memory is also faster than
storing
> them on the blocks.

Bzzzzzt, wrong! You see Mark, this is where you can't keep changing ground rules. You cannot now extend things to every situation.

And your implied conclusion that other databases take row locks on reads or store locks on blocks is completely false and misinformed. I have already advised your sorry lot to get a copy of Steve Adams' book and LEARN how locks should be done properly in a database.

For once, instead of blurting off marketing RUBBISH, why don't you pull your head off the proverbial, do yourself a favour, get a copy of the book and READ it? It might make what you say about Oracle a little bit more credible. As is, you are exposed EVERY single time for the ignorance that you show.

And what you described above is common behaviour in any database that has a SQL SELECT statement. Big effing deal. The issue is with lock escalation upon changes. Non-existent locks on selects are a non-sequitur that are an issue only in your imagination.

>
> If running an OLTP application, it is quite easy to set the locklist
memory
> in DB2 to sufficient levels to prevent lock escalation. Even a child
could
> do it.

Apparently not. Judging by the amount of technical articles advising on how and why to do this. Received on Mon Feb 07 2005 - 19:28:35 CST