Steve Shapero writes:
>i need to be able to do the selects so my website doesn't go down when i
am doing updates...
The other suggestions I have seen on this topic look helpful. However, I'd
personally avoid the UR isolation level. Once you start getting data that
way, you have to begin to accept a certain amount of inconsistent data,
which is a pretty serious consequence. This is more of an issue in OLTP
than DSS, since OLTP transactions can make lots of changes before finally
committing their work.
Make absolutely sure that the units of work performing the inserts or
updates are as small as possible. If you change or insert too many rows in
a single UOW, DB2 will escalate all those row-level locks into one big
table lock that blocks absolutely everyone.
You must also determine how the other programs are looking for data in the
table that is being updated. If the queries are searching on non-indexed
columns, they may be forcing full-table scans, which will clumsily trip
over the row-level locks that belong to the uncommitted work. When a table
is changing a lot, the safest way to get data out of the table is to make
sure that the queries always hit an index (like querying by a specific
primary key value).
Good Luck,
Fred
-
::: When replying to the list, please use 'Reply-All' and make sure
::: a copy goes to the list ([EMAIL PROTECTED]).
*** To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED]
*** For more information, check http://www.db2eug.uni.cc
