View previous topic :: View next topic |
Author |
Message |
arshadh Beginner
Joined: 10 Jan 2007 Posts: 33 Topics: 12
|
Posted: Mon Sep 24, 2007 9:05 am Post subject: Database Deadlock causing program abend..... |
|
|
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 |
|
|
videlord Beginner
Joined: 09 Dec 2004 Posts: 147 Topics: 19
|
Posted: Mon Sep 24, 2007 10:15 am Post subject: |
|
|
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 |
|
|
arshadh Beginner
Joined: 10 Jan 2007 Posts: 33 Topics: 12
|
Posted: Mon Sep 24, 2007 10:53 pm Post subject: |
|
|
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 |
|
|
videlord Beginner
Joined: 09 Dec 2004 Posts: 147 Topics: 19
|
Posted: Tue Sep 25, 2007 8:30 am Post subject: |
|
|
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 |
|
|
jsharon1248 Intermediate
Joined: 08 Aug 2007 Posts: 291 Topics: 2 Location: Chicago
|
Posted: Tue Sep 25, 2007 9:04 am Post subject: |
|
|
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 |
|
|
videlord Beginner
Joined: 09 Dec 2004 Posts: 147 Topics: 19
|
Posted: Tue Sep 25, 2007 10:55 am Post subject: |
|
|
jsharon1248 wrote: | Resource Type 210 is an index space. |
TYPE 201 is index, 210 is Partition |
|
Back to top |
|
|
jsharon1248 Intermediate
Joined: 08 Aug 2007 Posts: 291 Topics: 2 Location: Chicago
|
Posted: Tue Sep 25, 2007 11:31 am Post subject: |
|
|
Dyslexai strikes again.... |
|
Back to top |
|
|
arshadh Beginner
Joined: 10 Jan 2007 Posts: 33 Topics: 12
|
Posted: Thu Sep 27, 2007 11:58 pm Post subject: |
|
|
Thanks for your Suggestions.... |
|
Back to top |
|
|
|
|