DB2 - What causes an Indoubt Thread?
What causes indoubt threads to occur in (IBM) DB2 on a IBM mainframe server?
I am asking this questions because it seems causing an indoubt thread is a very rare occurrence in (IBM) DB2 and once one is invoked it doesn't seem like its easy to stop.
More specific questions?
- Can a hung thread be stopped easily?
- What would cause a thread to hang in IBM DB2 on the mainframe?
Your question does not mention which App-server(s) you are using, and which Db2-operating-system-platform and version you are using, and which component(s) act as Transaction-Manager(s) and Resource-Manager(s) for distributed transactions. Those details can determine part of the answers. So without those details, the answer can be only generic.
Edit your question to provide the missing details.
In general, a distributed transaction is in doubt if at least one leg of the transaction fails to complete for some reason. That leg may or may not involve Db2. If at least one leg of a distributed transaction involves Db2, and at least one leg fails to complete then Db2 can show the transaction as in-doubt.
Depending on which leg of a distributed transaction has failed, the error details will be in different places. For example if the leg that failed involved an MQ message then you would search MQ diagnostics. If the leg that failed involved Db2, then you would search the diagnostics on the relevant Db2 platform that failed.
If Db2 is acting as a Resource-Manager, and a request to Db2 is failing to complete, then the reasons may be due to poor configuration, a bad access plan, an external (to Db2) function or procedure failing to return, locking issues, timeouts, rollbacks, and bugs, among other causes.
If Db2 Linux/Unix/Windows reports that there are indoubt transactions then Db2 also allows an operator to manually resolve such matters, according to instructions in the documentation. If the participating Db2 is running on z/OS or i-series then different documentation pages exist.作者: mao 发布者: 2017 年 12 月 27 日