After RAC migrations, such as "migrating your single instance EBS database to a 2 node RAC enviroment" , you may start encountering errors in PO related workflows..
The error you may get is the following:
Wf_engine_Util.Function_Call(PO_REQAPPROVAL_ACTION.OPEN_DOC_STATE,POAPPRV..
The solution is already documented in 11.5.10: Intermittent Document Manager Error #3 in VERIFY_APPROVER_AUTHORITY in RAC Instance (Doc ID 376556.1)
The document says it is Error3 , so it is different than the error presented in the screenshot above .( it is error 1 there), but it does not matter, the fix is the document is the solution.
The solution is basically setting "Concurrent:TM Transport Type" profile to "QUEUE" in site level.
But why?
Why we are setting Concurrent:TM Transport Type to "QUEUE"?
The answer is that, normally Transaction Manager uses DBMS PIPEs (When, Concurrent TM Transport Type is set to "PIPE") to communicate with with the Service Manager, and any user process initiated by Forms, or Standard Manager requests. DBMS_PIPE is by design requires the sessions which there is a need for establising a communication between eachother , to be in the same instance.
As, DBMS_PIPE is a package that lets the sessions in the same instance to communicate using Oracle Pipes, using them in a RAC environment is not acceptable. That's why we set Concurrent:TM Transport Type to "QUEUE" in RAC environments unless we have multiple application nodes which have concurrent manager services dedicated to their own database instances.
The error you may get is the following:
Wf_engine_Util.Function_Call(PO_REQAPPROVAL_ACTION.OPEN_DOC_STATE,POAPPRV..
The solution is already documented in 11.5.10: Intermittent Document Manager Error #3 in VERIFY_APPROVER_AUTHORITY in RAC Instance (Doc ID 376556.1)
The document says it is Error3 , so it is different than the error presented in the screenshot above .( it is error 1 there), but it does not matter, the fix is the document is the solution.
The solution is basically setting "Concurrent:TM Transport Type" profile to "QUEUE" in site level.
But why?
Why we are setting Concurrent:TM Transport Type to "QUEUE"?
The answer is that, normally Transaction Manager uses DBMS PIPEs (When, Concurrent TM Transport Type is set to "PIPE") to communicate with with the Service Manager, and any user process initiated by Forms, or Standard Manager requests. DBMS_PIPE is by design requires the sessions which there is a need for establising a communication between eachother , to be in the same instance.
As, DBMS_PIPE is a package that lets the sessions in the same instance to communicate using Oracle Pipes, using them in a RAC environment is not acceptable. That's why we set Concurrent:TM Transport Type to "QUEUE" in RAC environments unless we have multiple application nodes which have concurrent manager services dedicated to their own database instances.
No comments :
Post a Comment
If you will ask a question, please don't comment here..
For your questions, please create an issue into my forum.
Forum Link: http://ermanarslan.blogspot.com.tr/p/forum.html
Register and create an issue in the related category.
I will support you from there.