Oracle 12C Problem with datapatch. Part 2, the “fix”
27/08/2015 2 Comments
so after much too-ing and fro-ing with Oracle Support, we finally have a solution to my datapatch problem. Prevent the timeout from happening when running datapatch! We know which part of the code was timing out, and we can do this by setting an undocumented event: 18219841.
Here’s a show test to show you how that was done:
SQL: select dbms_sqlpatch.verify_queryable_inventory from dual; VERIFY_QUERYABLE_INVENTORY -------------------------- ORA-20008: timed out. Job Load_opatch_inventory_1execution time is more than 120Secs
(wait a while for the background job to clean up)
SQL: alter session set events '18219841 trace name context forever'; Session Altered SQL: select dbms_sqlpatch.verify_queryable_inventory from dual; VERIFY_QUERYABLE_INVENTORY -------------------------- OK patch 19769480 installed in all nodes patch 20299023 installed in all nodes patch 28031110 installed in all nodes
and switch it back off
alter session set events '18219841 trace name context off';
You may note above that I was changing the context for the session only, as a test. To get it to work with datapatch, you will need to use “alter system” commands before and after running datapatch.
I would recommend that you do not set this event without first contacting Oracle Support. You may wish to quote “Bug 21121707” I would recommend you un-set it afterwards too – you don’t know what it’s doing and you don’t understand if there are any negative side-effects.
To check if the event is set in your session/system:
in sqlplus... sql: var level number sql: exec dbms_system.read_ev(1821984, :level); sql: print :level LEVEL ------------------- 1
Addendum: After a twitter conversation, it was noted by Martin Berger (@martinberx) that the nature of the query had changed with the event set, and that it was no longer calling the scheduler jobs. I did note, however, that it’s still calling the same pre-processor, but without the timeout (so it will run until it’s finished, however long that may be): $ORACLE_HOME/QOPatch/qopiprep.bat – It’s getting information from GV$QPX_INVENTORY, whatever that view does. Answers on a post card (or comment) please.
Pingback: Log Buffer #438: A Carnival of the Vanities for DBAs | InsideMySQL
Pingback: Log Buffer #438: A Carnival of the Vanities for DBAs | MySQL