Yesterday I blogged about the Oct 2019 Patch Bundles being available for download. And while I wrote this blog post, I downloaded all of them for my environments. Here I’d like to share with you the most simple path to apply them. As I have no cluster or ASM, I don’t have to patch Grid Infrastructure. And I don’t even have OJVM in any of my databases right now. Due to space constraints in my lab environment I will apply the patches in-place. You shouldn’t do this but instead use always a new home you patch. This allows you …Continue reading...
Well, it is Friday night – and I’d rather should sleep or do something cool people tend to do on Friday night’s. But I try to verify a strange issue with DBMS_OPTIM_BUNDLE and the October 2018 Update for Oracle 188.8.131.52. I’m patching. Can you think of anything better on a Friday night than patching?
Of course I know that I’m not alone. I know at least two customers I work with right now who do some maintenance jobs tonight as well. And I’m struggling with OPatch … oh OPatch … why is datapatch so stubborn?
My test setup
I have …Continue reading...
Thanks to Connor McDonald (Mr. AskTom) I learned today that one topic is not clear from our patches
readmes: Do you have to execute “
datapatch” when you create a new database? And it’s true. It does not get explained in the readme anywhere.
Do you have to execute “datapatch” when you create a new database?
If you never applied an Oracle patch bundles you may ask now: What is “
datapatch” doing. And the answer is very simple. When you apply a patch bundle usually the patch does not include only binary files but also …
Does the Database Configuration Assistant (DBCA) execute “datapatch -verbose” in Oracle 12.2 when you create a new database?
Does DBCA in Oracle 12.2 execute
datapatch when you create new database? I was curious if this misbehavior from the previous release has been fixed. Good news: It got fixed with Oracle Database 184.108.40.206. The DBCA does execute “
datapatch -verbose” automatically now when you create a new database. In the previous release this did not happen – you had to execute it manually after creating a new database.
Quick Test Scenario
I …Continue reading...
At the DOAG Conference in November in Nürnberg in November 2016 a customer asked me right after my talk about “Upgrade to Oracle Database 12.2. – Live and Uncensored” why the DBA_REGISTRY_HISTORY does not get updated when he applies a Bundle Patch and follows all instructions including the “./datapatch -verbose” call.
I was wondering as well and asked him to open an SR. Which he did. And he received the message from Support that it is not supposed to appear in Oracle 12c anymore this way but only in DBA_REGISTRY_SQLPATCH. Now I dug a bit deeper …Continue reading...
Usually I don’t post twice a day but as my post scriptum for the previous blog post got longer and longer I decided to write an entry about it – maybe simply because I feel soooo happy that my patch application succeeded flawless.
For many of you the following steps may look very boring as you have done this many times. But I use the blog also to brain-dump information for myself 😉 And for those who’d like to play with it, I summarized the steps fitting exactly into our Hands-On-Lab environment.
I downloaded the following patches:
- Database Proactive
Actually, command line upgrades are affected as well, if you do not use OS authentication. Apparently, datapatch is not able to execute in non-OS authentication mode. See MOS note 1635007.1.
You are doing a command line upgrade to Oracle Database 12c with catctl.pl – and you don’t use OS authentication allowing connections with “/ as sysdba” then datapatch.pl won’t be able to execute the SPU/PSU/BP related SQL commands as it will fail to connect to your database with an ORA-1017 (invalid username/password) error.
Bug 18361221 …Continue reading...
During my last Hands-On-Labs in Uruguay and Argentina I’ve had several people wondering about these messages below when running the command line upgrade with catctl.pl:
This (and another) message breaks the nicely structured format of the catctl.pl output. And as it ends with an “err” extension it looks to many people as if the upgrade had gotten an error,
But please don’t feel disturbed. It’s just messages from sqlpatch invocation – and the “err” extension is just pointing to an error file in case something has gone wrong.
In a future release such messages …Continue reading...
A few weeks ago I did blog about the DBUA (Database Upgrade Assistant) not executing ‘datapatch’ (i.e. not applying the SQL changes involved with a SPU/PSU/BP) automatically:
For DBUA, please note that this behavior DOES NOT APPLY to command line upgrades done with catctl.pl – as you can see from this somewhat disturbing messages during the upgrade in phase 65 and phase 69 (which are not errors but just informational messages for datapatch’s execution):
But afterwards I have learned that things are worse.
The same behavior is true when you create
I have blogged about the Grid Infrastructure Management Repository (GIMR) a while back:
And Markus Michalewicz, our Director of Product Management, Oracle Real Application Clusters (RAC), has published a very interesting and helpful insight article about GIMR on July 30, 2015. Read it here:
Since Oracle Database 220.127.116.11 the GIMR database will be created by default – and it is a single tenant database having a CDB$ROOT and one active PDB.
Recently the question came up if – in the likely event of applying a PSU …Continue reading...
You may have read a posting dis-recommending PSU1 and PSU2 for Oracle Multitenant 18.104.22.168 especially in RAC/GI environments earlier this week. Actually following a lot of internal discussions I will post some advice and clarification later this week.
Now I have an useful update:
Datapatch Issues are covered within a separate MOS Note making it easier to keep track and find workarounds for known issues.
Please see MOS Note:1609718.1 Datapatch Known Issues