By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,589 Members | 2,276 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,589 IT Pros & Developers. It's quick & easy.

DB2 performance variables

P: n/a
Does anyone know of any problems on setting the following db2
environment variables?

DB2_EVALUNCOMMITTED=ON
DB2_SKIPINSERTED=ON
DB2_SKIPDELETED=ON

Also is it correct to assume the effect of those settings would be the
same as running a query "WITH UR" ?

Thank you

Leo

Apr 21 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
<le**********@gmail.com> wrote in message
news:11**********************@z34g2000cwc.googlegr oups.com...
Does anyone know of any problems on setting the following db2
environment variables?

DB2_EVALUNCOMMITTED=ON
DB2_SKIPINSERTED=ON
DB2_SKIPDELETED=ON

Also is it correct to assume the effect of those settings would be the
same as running a query "WITH UR" ?

Thank you

Leo


There are some circumstances when an application is coded in a certain way,
where you might not want to use the settings. For more information on when
this might be, see this link:
http://www-128.ibm.com/developerwork...m-0509schuetz/

These are not really performance settings, but they can minimize lock
contention, so if you have a lot of lock wait time in your application you
may be able to increase performance. Also, these settings can "sometimes" be
useful in preventing deadlocks when application programs are not coded in
the proper way that would avoid them.

Using these settings is not the same as running a query "WITH UR" although
in some very specific circumstances with specific queries, the result may be
the similar in that lock wait time is eliminated..

Note that the above settings are ignored on queries which use the RR
isolation level.
Apr 21 '06 #2

P: n/a
le**********@gmail.com wrote:
Does anyone know of any problems on setting the following db2
environment variables?

DB2_EVALUNCOMMITTED=ON
DB2_SKIPINSERTED=ON
DB2_SKIPDELETED=ON

Also is it correct to assume the effect of those settings would be the
same as running a query "WITH UR" ?

That is incorrect. WITH UR will see uncommitted rows. The variables
above skip uncommitted rows.

DB2_SKIPINSERTED is safe (there is nothing wrong about not seeing a new
row that isn't committed yet).

The other two may or may not be safe depending on your app.

Cheers
Serge

--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab
Apr 22 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.