IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

table scan can cause deadlock over RID?


IBM Mainframe Forums -> DB2
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
dejunzhu

Active User


Joined: 08 May 2008
Posts: 390
Location: China

PostPosted: Fri Jul 04, 2014 8:36 am
Reply with quote

I have a cursor declared as blow
Code:
declare c1 cursor for
select a,b,c,d,e,f,g
from taba
where a=:a
    and b=:b
for update


if a duplicable index defined on column(a,b), there is no problem for high volumn transaction ;

but if no index defined on column a,b, when fetch operation is performed against the above declared cursor, program error with sqlcode -911, which indicates deadlock occurred on RID of tablespace.

the default isolation level of the program is CS, when no index defined on the columns in the where clause, we can expect tablescan is chosen by DB2.
I'm confused why tablescan can cause deadlock for high-volumn transaction? I can understand that might happend for isolation level RR or RS, but why CS?
Back to top
View user's profile Send private message
guptae

Moderator


Joined: 14 Oct 2005
Posts: 1208
Location: Bangalore,India

PostPosted: Fri Jul 04, 2014 11:52 am
Reply with quote

Hi There,

What is the lock size defined for this tablespace?
Back to top
View user's profile Send private message
GuyC

Senior Member


Joined: 11 Aug 2009
Posts: 1281
Location: Belgium

PostPosted: Fri Jul 04, 2014 1:14 pm
Reply with quote

-911 indicates deadlock OR timeout, and both need at least 2 transactions.
a timeout is more likely in this case.


* The "for update " causes a U-lock to each page you're trying to read.
* A tablescan reads a lot more pages than a Direct indexscan.
thus the chance that a page you're trying to read is already U- or X-locked is a lot higher.

replace "page" by "row" if you have row-locking.
Back to top
View user's profile Send private message
dejunzhu

Active User


Joined: 08 May 2008
Posts: 390
Location: China

PostPosted: Fri Jul 04, 2014 9:48 pm
Reply with quote

guptae wrote:
Hi There,

What is the lock size defined for this tablespace?

locksize is ROW lock
Back to top
View user's profile Send private message
dejunzhu

Active User


Joined: 08 May 2008
Posts: 390
Location: China

PostPosted: Fri Jul 04, 2014 9:50 pm
Reply with quote

GuyC wrote:
-911 indicates deadlock OR timeout, and both need at least 2 transactions.
a timeout is more likely in this case.


* The "for update " causes a U-lock to each page you're trying to read.
* A tablescan reads a lot more pages than a Direct indexscan.
thus the chance that a page you're trying to read is already U- or X-locked is a lot higher.

replace "page" by "row" if you have row-locking.

thanks for your kind reply.
I examed the reason code for -911, and it indicates deadlock.

The locksize of the tablespace is already set to ROW lOCK
Back to top
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 3048
Location: NYC,USA

PostPosted: Sun Jul 06, 2014 9:34 am
Reply with quote

Did you check for any other thread holding this table at the same time or did you make another run afterwords?
Back to top
View user's profile Send private message
dejunzhu

Active User


Joined: 08 May 2008
Posts: 390
Location: China

PostPosted: Sun Jul 06, 2014 5:17 pm
Reply with quote

Rohit Umarjikar wrote:
Did you check for any other thread holding this table at the same time or did you make another run afterwords?

I can be sure that records that satisfies the selection criteria of the cursor only belongs to only one task, and will not become selection candidates for other tasks.
Back to top
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 3048
Location: NYC,USA

PostPosted: Sun Jul 06, 2014 11:58 pm
Reply with quote

Did you make another run? Did you try the same query in SPUFI or any tool? And can you try doing this by removing FOR UPDATE from the cursor and see what SQLCODE you get?
Back to top
View user's profile Send private message
GuyC

Senior Member


Joined: 11 Aug 2009
Posts: 1281
Location: Belgium

PostPosted: Mon Jul 07, 2014 3:01 pm
Reply with quote

* it is irrelevant wether the row satisfies the selectgion criteria. The U-lock will be taken before evaluation of the criteria.
* just to be sure : yoiu don't have lock escalation ?
Back to top
View user's profile Send private message
dejunzhu

Active User


Joined: 08 May 2008
Posts: 390
Location: China

PostPosted: Tue Jul 08, 2014 7:51 pm
Reply with quote

GuyC wrote:
* it is irrelevant wether the row satisfies the selectgion criteria. The U-lock will be taken before evaluation of the criteria.
* just to be sure : yoiu don't have lock escalation ?

how to check if there is lock escalation?
Back to top
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 3048
Location: NYC,USA

PostPosted: Tue Jul 08, 2014 8:19 pm
Reply with quote

Quote:
how to check if there is lock escalation?


Did you attempt to speak to your DBA about this? He can provide you all the details but also can be referenced to this link.

www-01.ibm.com/support/knowledgecenter/?lang=en#!/SSEPEK_10.0.0/com.ibm.db2z10.doc.perf/src/tpc/db2z_lockescalation.dita
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> DB2

 


Similar Topics
Topic Forum Replies
No new posts Load new table with Old unload - DB2 DB2 6
No new posts Pulling a fixed number of records fro... DB2 2
No new posts Multiple table unload using INZUTILB DB2 2
No new posts Check data with Exception Table DB2 0
No new posts Dynamically pass table name to a sele... DB2 2
Search our Forums:

Back to Top