Sending an update to this old thread:
I've worked around this ORA-12850 in 19c RAC now, it was about the GV$ PX
slaves not being able to reproduce the required plan in a remote instance
due to factored subquery materialization, so I just disabled that
feature and now ash_wait_chains is not hitting this Oracle bug anymore. I
just added INLINE hints to all WITH subqueries in the script, I didn't want
to set the *_with_subquery* parameter as this would be an "alter session"
and would affect any other queries you may run in your session too:
https://tanelpoder.com/posts/ora-12850-could-not-allocate-slaves-on-all-specified-instancs-error/
--
Tanel Poder
https://tanelpoder.com/seminar
On Thu, Jul 11, 2019 at 10:28 AM Chris Stephens <cstephens16@xxxxxxxxx>
wrote:
i went as low as 11.2.0.4 to no avail. just looked at 10053 trace and
about the only thing i noticed was "mesg=kxfxcp: slave join failed".
On Thu, Jul 11, 2019 at 8:51 AM Andy Klock <andyklock@xxxxxxxxx> wrote:
Chris Stephens <cstephens16@xxxxxxxxx> writes:
we recently installed 19c GI/RDBMS as a 3 node RAC cluster....
I did some googling and some searching on support.oracle.com to noavail.
I've got an SR open but was wondering if anyone else has hit this and/or
has a solution to prevent the ORA-12850.
Thanks in advance for any help!
I have not, but I'm also not on 19c. The assumption is that the CBO has
chosen a plan that requires more slaves than you have available. Perhaps
an adaptive plan or something? For a quick and dirty test, try
downgrading the optimizer for the
session and see what happens.
Something like,
alter session set optimizer_features_enable = '12.1.0.2'; -- or even
lower if you've left the adaptive features enabled
Andy K
