Download Tivoli Workload Scheduler: Troubleshooting Guide

yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Cause and solution:
The problem is with the WebSphere Application Server which has a default
authentication timeout of 2 hours. The UpdateStats job runs without any interrupt
that would allow the WebSphere Application Server to reset its timeout.
To resolve the problem, reset the timeout as follows:
1. Edit the following file with a text editor:
where the default path for <WAS_profile_path> is TWA_home/WAS/TWSprofile.
2. Locate the key: authValidationConfig="system.LTPA" timeout="120"
3. Change the value of the timeout to an appropriately higher figure (the log of
UpdateStats shows you how much progress the job had made when it stopped;
it should be possible to extrapolate from that how much additional time is
4. Save the file.
5. Stop and restart the application server using the stopappserver and
startappserver commands.
6. Rerun UpdateStats.
DB2 might lock while making schedule changes
Multiple concurrent changes (modify, delete or create) to job streams or domains
might cause a logical deadlock between one or more database transactions. This is
a remote but possible problem you might encounter.
This deadlock might take place even if the objects being worked on are different
(for example, different job streams).
The problem affects database elements (rows or tables), not Tivoli Workload
Scheduler objects, so it is unrelated with the Locked By property of Tivoli Workload
Scheduler objects.
The same problem might arise when making concurrent changes for plan
When the deadlock occurs, DB2 rollbacks one of the deadlocking threads and the
following error is logged in the SystemOut.log of WebSphere Application Server:
AWSJDB803E An internal deadlock or timeout error has occurred
while processing a database transaction. The internal error
message is: "The current transaction has been rolled back
because of a deadlock or timeout. Reason code "2"."
In general, this type of error is timing-dependent, and the transactions involved
must overlap in very specific conditions to generate a deadlock. However it might
easily occur during plan generation (either forecast, trial, or current), when the
plan includes many objects and DB2 must automatically escalate locks from row to
table level, as the number of locked objects exceeds the current maximum limit.
You can mitigate the error by increasing the maximum number of locks that DB2
can hold. Refer to the DB2 Information Center to learn more about the DB2 lock
escalation mechanism and to find how to increase the maximum number of
concurrent locks.
Chapter 8. Troubleshooting engine problems
Document related concepts
no text concepts found