(Picture by Hermes Rivera, via Unsplash)
EDIT : This bug has finally been fixed by patch 28809007 and should be included with release 20.1 🙂 !
This blog post describes a very specific problem I encountered while using datapatch.
I recently patched 400+ 220.127.116.11 databases on RHEL 7.5 with Database Proactive Bundle Patch + OJVM PSU 18.104.22.168.180717 as described in this previous blog post.
Everything went very well on all databases, except one, maybe one of the most critical databases because it is a repository centralizing information about all databases in our ecosystem.
Datapatch would not work properly and would output the following error :
SQL Patching tool version 22.214.171.124.0 Production on Mon Oct 8 15:25:07 2018
Copyright (c) 2012, 2017, Oracle. All rights reserved.
Connecting to database...OK
Bootstrapping registry and package to current versions...done
Error in bootstrap log /ccv/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_27945_2018_10_08_15_25_07/bootstrap1_SOMEDB.log:
Error at line 31: ORA-01427: single-row subquery returns more than one row
Prereq check failed, exiting without installing any patches.
Please refer to MOS Note 1609718.1 and/or the invocation log
for information on how to resolve the above errors.
SQL Patching tool complete on Mon Oct 8 15:25:09 2018
Continue reading “Problem with datapatch, sqlpatch_bootstrap.sql and obj$”
(Picture by Jannes Glas, via Unsplash)
I have to admit that I always volunteer at work when a patching has to be done. I like patching. Not the patching process itself, but the learning process. Sometimes it even helps me get better at troubleshooting.
Today I just want to gather in one post a few things that came up after applying
Database Proactive Bundle Patch + OJVM PSU 126.96.36.199.180717, hoping this can help someone somewhere 🙂 I will update this post later if I encouter new issues.
Continue reading “Issues encountered after applying Database Proactive Bundle Patch + OJVM PSU 188.8.131.52.180717”
After having several issues with adaptive features on 12.1 databases, in some cases, the quickest way to solve problems was to simply set ‘optimizer_adaptive_features’ parameter to FALSE.
In 12.2, this parameter became obsolete and was replaced with two different parameters : ‘optimizer_adaptive_plans’ and ‘optimizer_adaptive_statistics’. Therefore, it is recommended to apply Patch 22652097 (PROVIDE SEPARATE CONTROLS FOR ADAPTIVE PLANS AND ADAPTIVE STATISTICS FEATURES) in order to have the same behaviour in 12.1.
I read thoroughly the README file of Patch 22652097 and applied it on my 12.1 homes. But when I tried to start the databases afterwards, some of them returned the following errors :
Continue reading “Patch 22652097 in 12.1 makes optimizer_adaptive_features parameter obsolete”