It’s patching day. And I’m already downloading the patch bundles for all my installations (11.2.0.4, 12.1.0.2, 12.2.0.1, 18c and 19c). The Oracle Security Alerts for July 2019 got published today.
Patch Advisory and Risk Matrix
You can find the July 2019 Patch Advisory here. I checked the risk matrix for the database. It contains 8 new fixes for the database server. Please pay attention that 3 of the vulnerabilities may be exploitable from a client without an Oracle Database server being installed. The highest score is 9.8.
Please check the risk matrix by yourself:
- https://www.oracle.com/technetwork/security-advisory/cpujul2019-5072835.html#AppendixDB
- Text form of the risk matrix for the Oracle Server
Oracle Critical Patch Update Advisory – July 2019
Database Server Patches
The patch availability MOS Note: 2534806.1 gives you access to the various database patches.
As usual, section 3.1.4 lists the database patch bundles.
And you will find the client patches at the end of each section.
There are the ones I will download for my installations (I don’t have OJVM installed anywhere):
- Database Update 19.4.0.0.190716 Patch 29834717 for UNIX
- Readme
- Opatch 12.2.0.1.17 minimum required
- Database Update 18.7.0.0.190716 Patch 29757256 for UNIX
- Readme
- Opatch 12.2.0.1.17 minimum required
- Database Jul 2019 Update 12.2.0.1.190716 Patch 29757449 for UNIX
- Readme
- Opatch 12.2.0.1.17 minimum required
- Database Proactive Bundle Patch 12.1.0.2.190716 Patch 29698629
- Only the higher powers know why this needs to be a system patch totaling to 3.5GB in size
- Readme
- Opatch 12.2.0.1.14 minimum required (I will take the 17 version)
- Database PSU 11.2.0.4.190716 Patch 29497421 for UNIX
- Readme
- Opatch 11.2.0.3.20 minimum required
I will keep you updated once I applied all of these patches to my environments.
–Mike
Hi Mike,
Do you know why AIX downloads were released for .190716 and then retracted <24h later?
19.3.0/19.3.1 deja vu all over again
Specifically:
29699079, 29699097, 29699168 for AIX
Hi Tim,
no I don’t know.
Thanks,
Mike
Hi Mike ,
For Database Proactive Bundle Patch 12.1.0.2.190716 Patch 29698629
These are the folder that must be present after unzipping (According to Oracle Readme ),
29496791
29938464
29938481
26983807
But after i unzipped p29698629_121020_Linux-x86-64.zip, the folders i got are as below,
29423125
29496791
29509318
26983807
Is the Oracle readme wrong ? Did you experience the same ?
Thanks ,
Midhun
Hi Midhun,
yes, the readme is incorrect – somebody put the patch numbers for October 2019 into it 🙂
I informed “the powers” last Thursday and I hope it gets solved quickly.
Cheers,
Mike
Mike,
I was patching 18.1 DB_HOME with the July 2019 patch and ran into a couple of issues.
a) The datapatch failed to load OJVM files into PDBs which were plugged into the CDBs from non-CDBs. MOS search revealed Doc ID 2488247.1. I applied the easy fix (without unplug/re-plug of PDB) and it worked. ,
b) For some reason, the patching script takes it upon itself to compile every invalid object in the database.
SQL> begin
2 for invalid_object in
3 (select object_id
4 from dba_objects
5 where status = ‘INVALID’
6 order by object_id)
7 loop
8 dbms_utility.validate(invalid_object.object_id);
9 end loop;
10 end;
11 /
Now, if my database has invalid application objects because of any reason whatsoever, the datapatch throws an error:
Validating logfiles…done
Patch 29757256 apply: WITH ERRORS
Although the patch is applied successfully, the DBA_REGISTRY_SQLPATCH keeps showing WITH ERRORS in status. I had to use:
datapatch -verbose -ignorable_errors=ORA-04045,ORA-04052,ORA-02019,ORA-00604,ORA-06512
The list of ignorable_errors has to include every ORA error thrown by every invalid object and only then I get a clean log and SUCCESS in DBA_REGISTRY_SQLPATCH.
Validating logfiles…done
Patch 29757256 apply: SUCCESS
Patching script never used to compile every invalid object, but I guess something has changed.
Thanks,
Arun
Hi Arun,
this is an error in the patch script, not in datapatch actually. It should be solved by now and for future versions. The person who wrote the patch itself added this section which caused the recompilation trouble 🙁
Sorry for the inconvenience and hitting this!
Mike
Hi Mike,
we did patch an Oracle 12.2 with July patch and got an error from one of the PDB’s.
Patch 29757449 apply (pdb XXXXXXDB): WITH ERRORS
logfile: /oracle/cfgtoollogs/sqlpatch/29757449/23009673/29757449_apply_XXXXCDB_XXXXXXPDB_2019Aug14_13_50_55.log (errors)
Error at line 3348: ORA-04045: errors during recompilation/revalidation of SYSMAN.MGMT_STARTUP
Error at line 3349: ORA-01031: insufficient privileges
The CDB has 8 PDB’s and only one gave the error. It’s an old db that was installed at first maybe on Oracle 9 and then has been upgraded several times after that.
Solution was simply to delete user sysman; DROP USER sysman CASCADE;
// Best Regards
Mika Wasserman
Mika,
did you open an SR for it and did Oracle Support recommend to you to drop SYSMAN??
I’m curious now 🙂
Mike
Hi Mike,
no, we didn’t open any SR. We did troubleshoot cdb and noticed that sysman schema was only in one out of eight pdb’s and it was was also locked. That database is very old, created maybe 15+ years ago and created propably with Oracle 9. The other pdb’s was about 5 years old and created with Oracle 11/12. Also in other cdb’s, where we have old pdb’s, there is a sysman schema. It’s always locked and not in use.
After we deleted sysman, the install of patch was successfull.
// Mika
Thanks for the update, Mika.
Cheers,
Mike
Hi, I opened a SR (3-20757928261) afterwards since we have to delete many sysman schemas.
Q
“- Is it OK to drop sysman schema from pdb’s? They are not in use (disabled) and we do not use DB Control.
A
Please drop them if you are not at all using. ”
// Mika
hey,
Did you faced any issue Invalid components, while patching on database 11.2.0.4 ??
Invalid components after applying Q3 patch on 11.2.0.4 .
2 components are invalid
1. JServer JAVA Virtual Machine
2. Oracle Database Java Package
Please open an SR and let support check – and file bugs if necessary.
Cheers,
Mike