Virtual Classroom #16: Oracle Database Release and Patching Strategy for 19c and 23ai

Oracle Database Virtual Classroom Seminar #16 tells you everything about Oracle Database Release Planning and Patching Strategy for Oracle 19c, 21c and 23ai, the next Long Term Support release.
We start from opatch to datapatch, from Release Updates (RUs) to Monthly Recommended Patches (MRPs) to Quarterly Patch Bundles, Risk Matrix, CVE score, OJVM, the Mitigation Patch, tips and tricks, cleanup procedures and AutoUpgrade for patching.
Brought to you by the Oracle Database Upgrade, Migrations and Patching Product Management Team!
0:00:10 Welcome
0:02:10 Release Strategy
0:07:10 Install and Patching Strategy
0:11:40 Monthly Recommended Patches (MRPs)
0:19:10 Data Pump Bundle Patch
0:26:46 Upgrade and Patching incl AutoUpgrade
0:36:29 Patching Basics
0:41:11 Patching Methods (in-place, out-of-place, Standby-First, RAC Rolling)
0:51:42 RAC Rolling - Best Practices and Tips
0:58:34 Grid Infrastructure (GI) Patching
1:13:22 OJVM Patching - Oracle Java Virtual Machine
1:26:10 Patching Insights and Internals (binary patching)
1:30:40 Datapatch internals and removal/apply sequence
1:43:57 Distributed Patching with AutpUpgrade
1:48:25 Summary and Outro
Get the slides here:
dohdatabase.fi...
Find more Virtual Classrooms here:
mikedietrichde...

[@goldeneyenl1]

Hey Mike, With out-of-place patching, why do you switch over to the standby database and run datapatch from there instead of moving the primary database to the new Oracle Home and run datapatch from the original primary host? To me this seems an extra and unnecessary step. A primary database should be patched anyway, and whether datapatch is run from the original primary host or from the original standby host (now new primary) should make no difference. Or are you advising this method to make sure that the DG configuration is sane and has no gaps in log application? Kind regards, Michael Verheij

[@upgradenow]

Hi Michael, In this webinar, typically a switchover is much faster than a shutdown and restart of the primary database. Plus, if your application complies with the MAA guidelines then a switchover can be completely hidden from the application - just a short brownout while the sessions drain and re-connect. Or, with Application Continuity (or Transparent Application Continuity), you can hide the outage even further. But, if you prefer to keep on the same primary database, you can shut it down instead (do the standby first), and then run datapatch on the primary host. But you will have a longer outage than a switchover. Plus, we like the idea that patching also test your Data Guard config and that you can switchover without problems. Regards, Daniel

[@mayanksingh6663]

Very informative , question why its not recommended to create guaranteed restore point before running datapatch on primary , as its easier to rollback using GRP , kindly suggest

[@upgradenow]

Hi, That's a good point. If you keep users off the database until you finished datapatch, then a GRP could be a viable rollback plan. However, you can run datapatch while users are connected to the database. This is what we do with standby-first and RAC rolling patch apply. But even for single instance databases you can run datapatch with users connected. This minimizes the downtime needed. In such a case, a GRP is not a viable rollback plan because it would mean data loss. Every patch applied by Datapatch has a corresponding rollback action that can revert the apply. In case of a problem, Datapatch can always rollback to the starting point without issues. But feel free to use GRP as a rollback plan. It works - you just need to keep users off the database while you run Datapatch. Regards, Daniel

[@mayanksingh6663]

@@upgradenow Thanks Daniel for detail answer , but i would like to share real challenging patching experience using dbaascli, until now we were taking 7-8 hours of downtime for RU patching of ExaCS system and we end up with complex problem where datapatch failed and MOS also find hard to fix it during downtime , then it was blamed to us by MOS why there is no GRP to rollback datapatch , then later very senior MOS engineer joined and read the code and fixed internal to bring the PDB up , so i am still sure if datapatch can be run while users are connected , please share the MOS number to support this, so i can take this with team internally , Thanks lot

[@luap12000]

what is the impact of "forgetting" to run datapatch on a given database, after the RU apply on dbhome ?

[@upgradenow]

Hi, The impact is... unknown. We don't test that situation or take it into account. But I've seen other situations where it led to unexpected, intermittent errors. Could also be ORA-00600. Regards, Daniel

[@parameshhc]

Is there any way to find out/list out all the critical bugfix patches released against quarterly DB RU. also is there any API where we can find all the critical bugfix patches released against quarterly DB RU.

[@upgradenow]

Hi, We publish that information in MOS note 555.1. To my knowledge there are no API to get that information. Regards, Daniel

[@rajatsanwal9919]

Are two Oracle homes of same release possible in a server? @44:42

[@upgradenow]

Hi, Thanks for your question. Yes, you can have two Oracle homes of the same release on the same server. You can have as many as you like. You can even have two Oracle homes on the exact same patch level. Regards, Daniel

[@rajatsanwal9919]

Thanks Daniel.

[@2112pkm]

I heard oracle 19c datapump is screwed up. So its true !

[@upgradenow]

Hi, No, it's definitely not true. But like any other piece of software, we do find bugs in our software after release. If you apply the recent-most patches, I'm sure you'll find that Data Pump does an amazing job. If there's something specific you want us to improve, please do let us know. Thanks, Daniel