The Data Pump Bundle Patches get released on top of every RU since over a year now. But a real issue with missing files got detected recently. So in case you had applied Data Pump Bundle Patches: You may need to download and apply again.
What is in the Data Pump Bundle Patch?
The Data Pump Bundle Patch is a convenient and very useful vehicle to apply Data Pump patches which are usually not included in a Release Update (RU). While RUs are per definitionem RAC-rolling and Standby-First, the Data Pump Bundle Patch can be applied online but the datapatch part is not RAC-rolling. It will change the DBMS_DATAPUMP and DBMS_METADATA packages. If you’d kick off datapatch on node 1 while somebody else would start Data Pump from node 2, it may result in an issue when you execute datapatch.
We are working on a convenient way to make those patch bundles rolling as well. But it isn’t as simple as it sounds.
In the last Data Pump Bundle Patch more than 70 fixes were bundled together. And it is recommended to apply them, especially when you use Data Pump at least from time to time. And this includes Transportable Tablespaces and the packages mentioned above as well.
How do you find the Data Pump Bundle Patches?
Finding the DPBPs is very simple. Just add MOS Note: 2819284.1 – Data Pump Recommended Proactive Patches For 19.10 and Above to your favorite notes.
It contains a table listing the Data Pump Bundle Patch on top of each release update since 19.10.0. And it gives you access to the list of included fixes.
Why you may need to re-download and apply again?
A few weeks ago a customer logged and SR. And issue which was supposed to be fixed in the (I think to remember) 19.16.0 DPBP did still happen. Oracle Support started an investigation. And the customer was right.
After digging deeper a almost worst-case scenario became true. Most of the bundle patches since 19.14.0 missed several PLB files. So you basically need to re-download and apply the bundle again. The patch number did not change.
Since it has the same patch number, you really should remove the existing one if you downloaded a version before November 21, 2022. Check the file’s date in the patches’ /rdbms/admin directory. If it says Nov 21, all is good. If it is older, then please re-download, deinstall the existing one and apply it again.
You can find the information in this alert MOS Note: 2912069.1 – ALERT: Data Pump Bundle Patches (DPBPs) From 19.14.0 and on Are Missing Files. You may be tempted to just add the missing files and run datapatch again. But datapatch won’t do anything since it does not recognize a need to do anything.
This is the list of Data Pump Bundle Patches being affected by this issue and requiring re-download and re-apply unfortunately:
What happens if you don’t do follow the advice?
At first, you may miss a fix being active which is supposed to be fixed. You’d not have all the patches in place which are supposed to be there. We can’t guarantee that everything works fine.
And we all know that this is a terrible situation. You’d expect patches to do what we released them for. We can just apologize for this inconvenience.
Support described the risk quite well in MOS Note: 2912069.1:
… since Data Pump will instead use the old versions of the files already in place, it may become unstable or have unpredictable behavior due to it using files that were never meant to work together.
Further Links and Information
- MOS Note: 2819284.1 – Data Pump Recommended Proactive Patches For 19.10 and Above
- MOS Note: 2912069.1 – ALERT: Data Pump Bundle Patches (DPBPs) From 19.14.0 and on Are Missing Files
This is a desaster.
In Doc ID 2912069.1 it is mentioned that three files are missing: so why not compare the previous version of …. says … patch 34547013 with the re-released version in order to determine the missing files and extract-and-copy into the proper locations inside the binary.
I thought the same. But the problem is the recut of the software under the same patch number. Datapatch would not detect when you add the missing scripts. You potentially could apply them manually. But I would need to dig into the fix to check exactly what needs to be done. If we would have released an additional fix on top of the BP, this would have created even more nonsense.
But generally, I am with you.
sorry for the maybe stupid question. But do I have to run “dpload.sql” after applying the bundle patch? And if yes, in every CDB/PDB or only in CDB?
at first: This is not a stupid question.
And second, no, you don’t have to run it. Datapatch will utilize it during the patch run to load DP package changes into the database. And the highly improved dpload.sql will make this way more efficient. And datapatch takes care on everything (as long as your PDBs are up).
great, thanks for the answer.
But i understand it correctly when I download the latest DB Bundle Patch for Windows (like 19.17) today I don´t need to install the DP Bundle Patch, right?
no, you don’t have to install the DP Bundle Patch. Even there is one for Windows as well.
But you can “live” without it for sure. It fixes mostly DBMS_DATAPUMP, DBMS_METADATA, XMLTYPE conversion issues, TTS stuff – and the patching topic which can be dramatically slow without the fixes in dpload.sql.
The language of patch readme is very ambiguous. The third line says that “This patch is non-RAC Rolling Installable.” But, the patch apply instructions, step 9 implies that the patch can be applied to one node at a time which makes it a rolling patch. So, is it a rolling installable patch or do I need a full downtime? If I can guarantee that no one will run Datapump from other RAC nodes, can I apply it in a rolling fashion?
working on a blog post for tomorrow to clarify this.
In brief, you can’t apply the entire patch rolling since “datapatch” is the problem.
But you can apply the binaries – not even just rolling but ONLINE while everything is up and running.
Please be patient, I am crafting this together in the afternoon for tomorrow.
It doesn’t sound like these patch sets are “first-class citizens”. Is it at least supposed to be forward compatible with future RUs / Windows Bundle Patches, or might we need to uninstall it before future updates?
they are most helpful and can decrease patching time massively due to several optimizations.
Please read my blog post tomorrow about why they aren’t included in RUs (yet) and what happens next.
Since they are merge patches, they can’t stay in your existing home if you patch in-place. If you patch out of place, no prob at all. But if you patch into the existing home, then you must roll them back before you move to 19.18.0 for instance.
Yes, I’ll be applying the patch in-place, and it’s very likely that the next patch that gets installed is 19.18.0. In other words, after going through a 20 minute datapatch to install the DPBP, the only performance improvement I’m likely to see is …. uninstalling the DPBP faster?
if you apply patches in-place, then I see that this is a painful experience.
But at first, you will have 75 issues fixed. This is why you have the DPBP. And one significant change, which hits the most when you have PDBs, are the improvements of dpload.sql. Now the bad thing when I think about it is that in-place-patching will likely remove dpload.sql again.
I have a question for you Mike. We do use datapump on occasion. However, we have never applied the Datapump Bundle Patch to this point. We have just applied the Oct 2022 Quarterly DB/OJVM Combo patch. Do you recommend applying the Datapump Bundle patch of top of that? Thanks in advance.
it really depends. There are a lot of issues fixed, not only with Data Pump but also with DBMS_METADATA, XML conversions etc.
As usual, the rule should be: If you don’t see any issue yet, then you may live without it. But if you are annoyed by long patching times or if you find issues here and there, it is recommended to take the bundle. I will clarify this more in my tomorrow’s blog post.
ok i see that there may be a reason why it’s not (yet) included in RU. but what’s hard to understand – and this is so typically oracle – why isn’t this better communicated? actually i don’t know if other components also have to be patched besides the RU.
Isn’t there a document in the MOS where you can see every available (and latest) patch for all components of a 19 or 21 home? Actually – there are already pages like this but you only find RU and OJVM there…
well, this would be a good discussion topic for one or more after-work beer 😉
I just learned the other day about important MOS notes I had no clue about their existence. And I work for this company and have a fairly large network across all LOBs … 🙂
do you know when the latest DPBP (19.18) will be available ?
Or can I apply the 19.17 DPBP into 19.18 as well ?
it is already ready. Actually, it was ready before 19.18.0 got released. I just assume that the MOS note hasn’t been updated yet as they lag behind usually.
Please download it from MOS with: Patch/bug 34972375 on top of 19.18.0 – and sorry for the inconvenience 🙁 We don’t own the MOS note by ourselves, and hence rely on “somebody else” updating it in a timely fashion.
thanks for your quick reply.
I also opened an SR at the same time.
You won, I haven’t received an answer from the SR so far.
Haha … thanks Hans-Martin.
And meanwhile Roy talked to our support contact who is the owner of the MOS note. Simple reason why it hasn’t been updated yet is that the list of the new additional fixes in this BP does get delivered without the proper links. He needs to create all the links manually now for each of the 24 or so additional bugs. Note should be updated soon I hope.
For years I have been patching the quarterly patches on databases. Recently, I get more the feeling that I miss a lot. We have seen the Datapump Bundle patches, the preupgrade.jar patches, and recently the new monthly patches.
Are there more obvious patches I miss? And why wouldnt Oracle include Datapump and preupgrade.jar in the quarterly patches? Risk is, that we have multiple 19.18 releases running, but all are different in some way!
this is the MOS Note:
which lists the fixes which aren’t (or can’t be) in RUs.