Joined: 26 Nov 2002 Posts: 12372 Topics: 75 Location: San Jose
Posted: Tue Jul 25, 2006 12:11 pm Post subject:
chagantivamsee,
Your job failed because the Start command was not able to acquire the lock. Why do you need a START database before the RUNSTATS step? Was there a load step prior to the start? Any way here is the detailed explanation of the reason 00C900A8
Code:
00C900A8
Explanation: The table space, index, or partition could not be started
because of a failure to acquire the lock. Activity on the table space,
index, or partition must quiesce before the START DB ACCESS(FORCE) command
can acquire the necessary lock.
The abend reason code is issued by the following CSECT: DSNISTFO
System Action: The START operation is not performed.
User Response: Wait for all activity on the table space, index, or
partition to complete before reissuing the START command.
Problem Determination: The requested operation is not performed. Message
DSNI002I is issued. For more information, refer to the description of this
message in "DSNI... messages" in item DSNI.... If the problem persists after
all activity on the table space, index, or partition completes, gather
diagnostic information to pursue the problem.
SYS1.LOGREC contains information in the variable recording area (VRA) of
the system diagnostic work area (SDWA). Significant fields for this code
are: VRARRK13, VRARRK14, and VRARRK15. If you suspect an error in DB2,
refer to Part 2 of DB2 Diagnosis Guide and Reference for information on
identifying and reporting the problem.
Collect the following diagnostic items listed in Appendix C, "Problem
determination" in item -PROBLEM_DETERMI : 1, 3, 5, 32, 33
If you have authority then the run the following command from the option 7 of DB2 primary menu
Your job failed because the Start command was not able to acquire the lock. Why do you need a START database before the RUNSTATS step? Was there a load step prior to the start? Any way here is the detailed explanation of the reason 00C900A8
Code:
00C900A8
Explanation: The table space, index, or partition could not be started
because of a failure to acquire the lock. Activity on the table space,
index, or partition must quiesce before the START DB ACCESS(FORCE) command
can acquire the necessary lock.
The abend reason code is issued by the following CSECT: DSNISTFO
System Action: The START operation is not performed.
User Response: Wait for all activity on the table space, index, or
partition to complete before reissuing the START command.
Problem Determination: The requested operation is not performed. Message
DSNI002I is issued. For more information, refer to the description of this
message in "DSNI... messages" in item DSNI.... If the problem persists after
all activity on the table space, index, or partition completes, gather
diagnostic information to pursue the problem.
SYS1.LOGREC contains information in the variable recording area (VRA) of
the system diagnostic work area (SDWA). Significant fields for this code
are: VRARRK13, VRARRK14, and VRARRK15. If you suspect an error in DB2,
refer to Part 2 of DB2 Diagnosis Guide and Reference for information on
identifying and reporting the problem.
Collect the following diagnostic items listed in Appendix C, "Problem
determination" in item -PROBLEM_DETERMI : 1, 3, 5, 32, 33
If you have authority then the run the following command from the option 7 of DB2 primary menu
This will give you a list of all who is having a lock on the table space.
Hope this helps...
Cheers
Kolusu
Hi Kolusu,
Thanks a lot for your reply.
Yes, there is a load step prior to the start. Thats the reason why we have a START before RUNSTATS. Is there a way where we can forcefully acquire a lock on the table space? I thought ACCESS(FORCE) does it. But, its proven that it doesn't.
And any idea why the Step02 was successful even though Step01 wasn't? Can I call this a Job successful or do I need to restart it?
1. Try access(UT) if you want to run RUNSTATS utility. Usually we didn't run ACCESS(FORCE) in production environment, it may cause data inconsitant.
2. The START... ACCESS(UT) command can be run before load, and START ...ACCESS(RW) after all utility finished.
3. START command may mail if other user/thread lock the tablespace. One way we have done before:
code a REXX program to check any lock on the table, (may kick out the user/cancel the thread or you can wait, depend on your application)
then run the command when no other locks
Joined: 03 Jan 2003 Posts: 283 Topics: 27 Location: US
Posted: Mon Jul 31, 2006 8:37 am Post subject:
If there's a LOAD step, the LOAD normally put the tablespace in cpy pending or check pending or index pending status - What's the need to START the database here?
________
Oshawa Car Assembly
Last edited by coolman on Sat Feb 05, 2011 1:45 am; edited 1 time in total
Joined: 26 Nov 2002 Posts: 12372 Topics: 75 Location: San Jose
Posted: Mon Jul 31, 2006 8:45 am Post subject:
Quote:
If there's a LOAD step, the LOAD normally put the tablespace in cpy pending or check pending or index pending status - What's the need to START the database here?
coolman,
After a load is performed on a db2 table , as you said the table is placed under copy/check pending. To remove this you need to run the CHECK Data utility. You can avoid that by using the START Command provided you know that the data you loaded satisfies all the table constraints(primary key/foregin key ...)
Access(Force) Resets any indications that a table space, index, or partition is unavailable because of pages in the logical page list, pending deferred restarts, write error ranges, read-only accesses, or utility controls. FORCE also resets the CHECK pending, COPY pending, and RECOVER pending states. Full access to the data is forced.
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
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
