| Author |
Message
|
| jkocur |
 Posted: Mon Jul 14, 2003 12:27 pm Post subject: ORA-03113 / 1st message processed after DB backup |
 |
|
Newbie
Joined: 14 Jul 2003
Posts: 1
|
Hello,
We are currently experiencing an ORA-03113 - end-of-file on communication channel on the first message processed that accesses Oracle via ODBC after the nightly Oracle backup is completed. This appears to occur because the DB connection information is cached by WMQI. After Oracle is brought up, WMQI attempts to use the old connection information and receives the 3113 and throws an exception on the first message. WMQI then receives new a new connection and processing resumes normally. It appears that others have also had this problem, but I haven't noticed a resolution. We are running WMQI 2.1 CSD04 on AIX. Any assistance is appreciated.
Regards,
Jeff |
|
| Back to top |
|
 |
| kirani |
| Posted: Mon Jul 14, 2003 12:52 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Jeff,
You could set the BACKOUT THRESHOLD of your input queue to 1 or greater value, which will allow the broker to re-try the processing for this message. So, when the first message comes in, on first try, Broker will fail with invalid connection, but on the second try it will establish the new connection to the DB and use it.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| kwelch |
| Posted: Thu Jul 31, 2003 12:16 pm Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 255
|
Hi Jeff,
We had this same problem and wrote an error routine to check the exceptionlist for the 3113 error. Our applications are so time sensitive that we did not want to be retrying every error only the database connection errors. The only problem I had was with the backout threshold count. When we set it to 1 the message always went to the fail queue wired to the failure terminal of the input node. We had the error routine wired to the catch terminal. When we changed the backout threshold to 2 then the error was caught and retried again and processed normally. I would be curious to know if you get the backoutthreshold of 1 to work for you.
Karen |
|
| Back to top |
|
|
| Craig B |
| Posted: Fri Aug 01, 2003 4:56 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
I was under the impression that the BackoutCount had to be strictly less than the Threshold of the Input queue for it to be retried. Therefore, when your message is retried for the first time, your MQMD.BackoutCount = 1, and your Threshold is 1, and therefore your message is not retried.
_________________
Regards
Craig |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Aug 01, 2003 8:15 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Craig B wrote: |
| I was under the impression that the BackoutCount had to be strictly less than the Threshold of the Input queue for it to be retried. Therefore, when your message is retried for the first time, your MQMD.BackoutCount = 1, and your Threshold is 1, and therefore your message is not retried. |
Is this behavior documented somewhere? |
|
| Back to top |
|
|
| kirani |
| Posted: Fri Aug 01, 2003 8:36 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
| Craig B wrote: |
| I was under the impression that the BackoutCount had to be strictly less than the Threshold of the Input queue for it to be retried. Therefore, when your message is retried for the first time, your MQMD.BackoutCount = 1, and your Threshold is 1, and therefore your message is not retried. |
I believe it checks if the backout count is greater than backout threshold.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| kirani |
| Posted: Fri Aug 01, 2003 8:51 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
| JeffLowrey wrote: |
Is this behavior documented somewhere? |
Yes, it is documented in Introduction and Planning manual.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| Yanghui |
| Posted: Thu Aug 14, 2003 6:04 am Post subject: |
|
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
Hi, there,
Unfortunately I am hit by this problem currently.
Since I can't let the failed msg roll back to the MQInput queue, I have to go to the Karen's solution, which detects this specific error and resend the orginal message back to the MQInput Queue and let it re-processed.
The question I have is, how to locate the error in the easiest way? RecoverableException is recursive. I am working on XML domain. Should I search for "[Oracle 8] ORA-031132" one layer after another or is it better to change teh RecoverableException as a bitstream and search the string?
Any good suggestion is highly appreciated. Thanks in advance.
Regards
-Yanghui |
|
| Back to top |
|
|
| Craig B |
| Posted: Thu Aug 14, 2003 6:12 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
It will not be an easy task converting the ExceptionList to a bitstream because it has no owning parser whose task to would be to convert the fields in the tree to a bitstream.
If you take a look in : http://www.mqseries.net/phpBB2/viewtopic.php?t=10065
Then there is ESQL that can be used to search an ExceptionList of any format and depth and search for fields with specific values.
Hopefully this will give one option on how to do this.
_________________
Regards
Craig |
|
| Back to top |
|
|
|
|
