I just dropped 350 tables, only 2 left to be dropped.
When I try to drop these 2 tables, I get the following error:
SQL0911N The current transaction
has been rolled back because of a deadlock or timeout. Reason
code "68". SQLSTATE=40001
Explanation:
The current unit of work was involved in an unresolved contention
for use of an object and had to be rolled back.
The reason codes are as follows:
2 transaction rolled back due to deadlock.
68 transaction rolled back due to lock timeout.
72 transaction rolled back due to an error concerning a DB2 Data
Links Manager involved in the transaction.
Note: The changes associated with the unit of work must be
entered again.
The application is rolled back to the previous COMMIT.
User Response:
To help avoid deadlock or lock timeout, issue frequent COMMIT
operations, if possible, for a long-running application, or for
an application likely to encounter a deadlock.
Federated system users: the deadlock can occur at the federated
server or at the data source. There is no mechanism to detect
deadlocks that span data sources and potentially the federated
system. It is possible to identify the data source failing the
request (refer to the problem determination guide to determine
which data source is failing to process the SQL statement).
Deadlocks are often normal or expected while processing certain
combinations of SQL statements. It is recommended that you
design applications to avoid deadlocks to the extent possible.
sqlcode : -911
sqlstate : 40001
Any solutions?
shsandeep - 16 Mar 2006 06:02 GMT
Solution found:
2 Applications were holding locks on those tables.
bikkaran@in.ibm.com - 20 Mar 2006 12:41 GMT
> Solution found:
> 2 Applications were holding locks on those tables.
Run teh command "
db2 force application all
It will remove all the locks
Knut Stolze - 20 Mar 2006 12:54 GMT
>> Solution found:
>> 2 Applications were holding locks on those tables.
[quoted text clipped - 3 lines]
>
> It will remove all the locks
This will actually force off all applications. Being a little bit more
careful to identify the applications and forcing off only the offending
ones would be better. And even better would be to get the application to
commit and close all holdable cursors involving the tables in question.

Signature
Knut Stolze
DB2 Information Integration Development
IBM Germany