MVSFORUMS.com Forum Index MVSFORUMS.com
A Community of and for MVS Professionals
 
 FAQFAQ   SearchSearch   Quick Manuals   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Database Deadlock causing program abend.....

 
Post new topic   Reply to topic   printer-friendly view    MVSFORUMS.com Forum Index -> Database
View previous topic :: View next topic  
Author Message
arshadh
Beginner


Joined: 10 Jan 2007
Posts: 33
Topics: 12

PostPosted: Mon Sep 24, 2007 9:05 am    Post subject: Database Deadlock causing program abend..... Reply with quote

Dear All,

In our database we have segmented tablespaces (i.e The table spaces are partitioned based on the Product type the partition can hold..)

Now the Problem is when we run a maintenance job for two different products (which means data is accessed from different partitions ) one of the job fails due to contention problem
Code:
 DSNT376I  -D3SP PLAN=PBPPRD00 WITH  129                             
         CORRELATION-ID=PRDNCDLY                                     
         CONNECTION-ID=BATCH                                         
         LUW-ID=USNBNET.A3SD3SP.C13756FD5E86=109392                 
         THREAD-INFO=PXAD:*:*:*                                     
         IS TIMED OUT. ONE HOLDER OF THE RESOURCE IS PLAN=PBPPRD00   
 WITH                                                               
         CORRELATION-ID=PRDNJDLY                                     
         CONNECTION-ID=BATCH                                         
         LUW-ID=USNBNET.A3SD3SP.C1375693AC23=108167                 
         THREAD-INFO=PPRD:*:*:*                                     
         ON MEMBER D3SP                                             
 .                                                                   
 DSNT501I  -D3SP DSNILMCL RESOURCE UNAVAILABLE  130                 
            CORRELATION-ID=PRDNCDLY                                 
            CONNECTION-ID=BATCH                                     
            LUW-ID=*                                                 
            REASON 00C9008E                                         
            TYPE 00000210                                           
            NAME PRD0001D.PRD0010S.00000001                         
 DSN3201I  -D3SP ABNORMAL EOT IN PROGRESS FOR  198                   


My question the two jobs are running for two differnet products which lie in different partitions .In that case why should the Deadlock situation occur..?

(one of my friend says that it is because of the SORT step while running the query inside the programs, Space problem arises and so abends)


P
Back to top
View user's profile Send private message
videlord
Beginner


Joined: 09 Dec 2004
Posts: 147
Topics: 19

PostPosted: Mon Sep 24, 2007 10:15 am    Post subject: Reply with quote

1. partitioned table space is not a segmented tablespace
2. REASON 00C9008E is timeout, not dead lock
3. TYPE 210 is resource partition
The batch job PRDNCDLY and PRDNJDLY must require lock on the same partition PRD0001D.PRD0010S.00000001

check the program and table parition difinition
Back to top
View user's profile Send private message
arshadh
Beginner


Joined: 10 Jan 2007
Posts: 33
Topics: 12

PostPosted: Mon Sep 24, 2007 10:53 pm    Post subject: Reply with quote

Thanks for ur comments..

Can you explain in detail the things I need to done..?I really can't understand your third and fourth point...

Our table space is divided based on the products. Both PRDNCDLY and PRDNJDLY are two differnet products which for sure wont fight for a same page in the TS...

Pls throw some light on this...
Back to top
View user's profile Send private message
videlord
Beginner


Joined: 09 Dec 2004
Posts: 147
Topics: 19

PostPosted: Tue Sep 25, 2007 8:30 am    Post subject: Reply with quote

based on the message, the 2 jobs access the same partition.
The lock level is partition, not page.

Please give detail information:
1, the partition index DDL (index key range)
2. The SQL in the 2 jobs
3. The input data to the job (if the SQL execution depend on the input)
Back to top
View user's profile Send private message
jsharon1248
Intermediate


Joined: 08 Aug 2007
Posts: 291
Topics: 2
Location: Chicago

PostPosted: Tue Sep 25, 2007 9:04 am    Post subject: Reply with quote

Resource Type 210 is an index space. You're most likely updating columns that are defined to indexes that are not the partitioning index. What is your commit frequency? You might be able to resolve this by issuing commits more frequently to release the index locks.

I seriously doubt that the SORT would in any way cause the DB2 timeout, unless you're running the SORT within a unit of work which would increase the duration of the unit of work. But that's really not the SORT causing the problem, it's a design issue.
Back to top
View user's profile Send private message
videlord
Beginner


Joined: 09 Dec 2004
Posts: 147
Topics: 19

PostPosted: Tue Sep 25, 2007 10:55 am    Post subject: Reply with quote

jsharon1248 wrote:
Resource Type 210 is an index space.

TYPE 201 is index, 210 is Partition
Back to top
View user's profile Send private message
jsharon1248
Intermediate


Joined: 08 Aug 2007
Posts: 291
Topics: 2
Location: Chicago

PostPosted: Tue Sep 25, 2007 11:31 am    Post subject: Reply with quote

Dyslexai strikes again.... Embarassed
Back to top
View user's profile Send private message
arshadh
Beginner


Joined: 10 Jan 2007
Posts: 33
Topics: 12

PostPosted: Thu Sep 27, 2007 11:58 pm    Post subject: Reply with quote

Thanks for your Suggestions....
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic   printer-friendly view    MVSFORUMS.com Forum Index -> Database All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


MVSFORUMS
Powered by phpBB © 2001, 2005 phpBB Group