It’s been a while since I blogged about the DBMS_OPTIM_BUNDLE – and to me, the package is still sort of a mystery. Ideally you can least and enable or disable behavior changing optimizer fixes per RU. And in Oracle 19.10.0, you will find a new surprise. So You may need a one-off for DBMS_OPTIM_BUNDLE in 19.10.0.
Photo by Jonas Denil on Unsplash
Quick Recap
Just in case you haven’t dealt with DBMS_OPTIM_BUNDLE yet or for a while, a quick recap.
With this procedure, you can list the available patches to turn on or off at will:
SQL> set serveroutput on; SQL> execute dbms_optim_bundle.getBugsforBundle;
And if you’d like to check which fixes are installed BUT disabled, use this procedure:
SQL> execute dbms_optim_bundle.getBugsforBundle(201020D);
19.4.0.0.190719DBRU:
Bug: 29331066, fix_controls: 29331066
19.5.0.0.191015DBRU:
Bug: 28965084, fix_controls: 28965084
Bug: 28776811, fix_controls: 28776811
Bug: 28498976, fix_controls: 28498976
Bug: 28567417, fix_controls: 28567417
Bug: 28558645, fix_controls: 28558645
Bug: 29132869, fix_controls: 29132869
Bug: 29450812, fix_controls: 29450812
19.7.0.0.200414DBRU:
Bug: 29687220, fix_controls: 29687220
19.8.0.0.200714DBRU:
Bug: 29304314, fix_controls: 29304314
Bug: 29930457, fix_controls: 29930457
19.9.0.0.201020DBRU:
Bug: 27261477, fix_controls: 27261477, 31069997, 31077481
Bug: 28602253, fix_controls: 28602253
Bug: 31486557, fix_controls: 29653132
Bug: 29937655, fix_controls: 29937655
Bug: 30347410, fix_controls: 30347410
Bug: 30602828, fix_controls: 30602828
Bug: 30896685, fix_controls: 30896685
PL/SQL procedure successfully completed.
In addition, you can enable the fixes – but the general call does not allow you to enable it fix by fix. So you may need to tweak your preferred setting with an explicit _fix_control instead.
execute dbms_optim_bundle.enable_optim_fixes('ON','BOTH', 'YES')
January 2021 Release Update 19.10.0
Now when you plan to check the available patches in Oracle 19.10.0, you’ll see this:
SQL> set serveroutput on;
SQL> execute dbms_optim_bundle.getBugsforBundle;
19.9.0.0.201020DBRU:
Bug: 27261477, fix_controls: 27261477, 31069997, 31077481
Bug: 28602253, fix_controls: 28602253
Bug: 31486557, fix_controls: 29653132
Bug: 29937655, fix_controls: 29937655
Bug: 30347410, fix_controls: 30347410
Bug: 30602828, fix_controls: 30602828
Bug: 30896685, fix_controls: 30896685
PL/SQL procedure successfully completed.
There are no 19.10.0 fixes listed but instead the 19.9.0 ones.
Ups.
What happens now when you try to enable the 19.10.0 optimizer fixes:
SQL> execute dbms_optim_bundle.enable_optim_fixes('ON','BOTH', 'YES')
DBMS_OPTIM command: dbms_optim_bundle.enable_optim_fixes('ON', 'BOTH', 'YES')
Bundle's _fix_control setting as per action:ON
29331066:1 28965084:1 28776811:1 28498976:1 28567417:1 28558645:1
29132869:1 29450812:1 29687220:1 29304314:1 29930457:1 27261477:1
31069997:1 31077481:1 28602253:1 29653132:0 29937655:1 30347410:1
30602828:1 30896685:0
Taking current instance CDB2 as base, details on _fix_control setting for
CON_ID 1 :
1) Current _fix_control setting for spfile:
None
2) Final _fix_control setting for spfile considering current_setting_precedence
is YES
29331066:1 28965084:1 28776811:1 28498976:1 28567417:1 28558645:1
29132869:1 29450812:1 29687220:1 29304314:1 29930457:1 27261477:1
31069997:1 31077481:1 28602253:1 29653132:0 29937655:1 30347410:1
30602828:1 30896685:0
3) Current _fix_control setting in memory:
29331066:0 28965084:0 28776811:0 28498976:0 28567417:0 28558645:0
29132869:0 29450812:0 29687220:0 29304314:0 29930457:0 27261477:0
31069997:0 31077481:0 28602253:0 29653132:0 29937655:0 30347410:0
30602828:0 30896685:0
4) Final _fix_control setting for memory considering current_setting_precedence
is YES
29331066:0 28965084:0 28776811:0 28498976:0 28567417:0 28558645:0
29132869:0 29450812:0 29687220:0 29304314:0 29930457:0 27261477:0
31069997:0 31077481:0 28602253:0 29653132:0 29937655:0 30347410:0
30602828:0 30896685:0
WARNING: final _fix_control setting for memory is not same as final
_fix_control setting for spfile. Please look at point 2 and 4 above to see the
differences.
PL/SQL procedure successfully completed.
At first, this output is not easy to digest. And it is not well formatted either.
What happens?
But what did you get here? You enabled all fixes – until 19.9.0. But not the 19.10.0 ones. I did the formatting work. And the 20 fixes you’d enable are exactly the 20 fixes listed from 19.4.0 – 19.9.0. But you didn’t enable the 19.10.0 fixes.
The strange “order” you may recognize is simply coming from the fact that the first _fix_control listed is “29331066” – this is the change which came in in 19.4.0.
How to fix this?
Thanks to Kálmán Lehotai for bringing this to my attention. I was not aware that there is an issue. But when you check MOS Note: 2725758.1 – Oracle Database 19c Release Update & Release Update Revision January 2021 Critical Issues, you will find this section:
And it points you to Patch 31862593.
Downside of applying this patch: It is not RAC rolling installable as the readme states.
I downloaded, unzipped and applied the patch in my environment:
And I realized to my surprise that it takes quite a while to get the patch applied – in my tiny lab environment. The step “Patching component oracle.rdbms, 19.0.0.0.0…” took minutes for whatever reason.
I guess, these were the reasons why it took so long:
[Feb 1, 2021 10:33:04 AM] [INFO] [OPSR-TIME] Cooked inventory loaded successfully [Feb 1, 2021 10:33:04 AM] [INFO] CUP_LOG: Found poh CUP 30557433 is a subset of other poh CUP: 30869156 [Feb 1, 2021 10:33:04 AM] [INFO] CUP_LOG: Found poh CUP 30557433 is a subset of other poh CUP: 31281355 [Feb 1, 2021 10:34:33 AM] [INFO] Checking if Oracle Home has components required by patches... [Feb 1, 2021 10:34:33 AM] [INFO] CheckMissingComps: Cached file does not exist or is invalid, re-build prereq result.
and:
[Feb 1, 2021 10:41:57 AM] [INFO] CUP_LOG: Found poh PLO 31862593 implicitly overlays poh CUP: 31771877 [Feb 1, 2021 10:41:57 AM] [INFO] CUP_LOG: Found poh PLO 31862593 implicitly overlays poh CUP: 32218454 [Feb 1, 2021 10:43:22 AM] [INFO] [OPSR-TIME] Patch 31862593 saved to inventory [Feb 1, 2021 10:43:22 AM] [INFO] ApplySession: Skip patch verification. [Feb 1, 2021 10:43:22 AM] [INFO] [OPSR-TIME] Finished applying patch "31862593" to local system
I couldn’t find instructions to execute datapatch. So I will try it without.
Same calls, now with 31862593 in place
Let me repeat my checks from above:
SQL> execute dbms_optim_bundle.getBugsforBundle;
19.10.0.0.210119DBRU:
Bug: 29487407, fix_controls: 29487407
Bug: 30998035, fix_controls: 30998035
Bug: 30786641, fix_controls: 30786641
Bug: 31444353, fix_controls: 31444353
Bug: 30486896, fix_controls: 30486896
Bug: 28999046, fix_controls: 28999046
Bug: 30902655, fix_controls: 30902655
Bug: 30681521, fix_controls: 30681521
Bug: 29302565, fix_controls: 29302565
Bug: 30972817, fix_controls: 30972817
Bug: 30222669, fix_controls: 30222669
Bug: 31668694, fix_controls: 31668694
Bug: 31001490, fix_controls: 31001490
Bug: 30198239, fix_controls: 30198239
Bug: 30980115, fix_controls: 30980115
Bug: 30616738, fix_controls: 30616738
Bug: 31895670, fix_controls: 31895670
Bug: 19138896, fix_controls: 19138896
Bug: 31376708, fix_controls: 31670824
Bug: 30564898, fix_controls: 9876287, 30564898
Bug: 32234161, fix_controls: 32075777
Bug: 30842277, fix_controls: 30570982
Ah, now I can see the included fixes.
SQL> execute dbms_optim_bundle.getBugsforBundle(210119);
19.4.0.0.190719DBRU:
Bug: 29331066, fix_controls: 29331066
19.5.0.0.191015DBRU:
Bug: 28965084, fix_controls: 28965084
Bug: 28776811, fix_controls: 28776811
Bug: 28498976, fix_controls: 28498976
Bug: 28567417, fix_controls: 28567417
Bug: 28558645, fix_controls: 28558645
Bug: 29132869, fix_controls: 29132869
Bug: 29450812, fix_controls: 29450812
19.7.0.0.200414DBRU:
Bug: 29687220, fix_controls: 29687220
19.8.0.0.200714DBRU:
Bug: 29304314, fix_controls: 29304314
Bug: 29930457, fix_controls: 29930457
19.9.0.0.201020DBRU:
Bug: 27261477, fix_controls: 27261477, 31069997, 31077481
Bug: 28602253, fix_controls: 28602253
Bug: 31486557, fix_controls: 29653132
Bug: 29937655, fix_controls: 29937655
Bug: 30347410, fix_controls: 30347410
Bug: 30602828, fix_controls: 30602828
Bug: 30896685, fix_controls: 30896685
19.10.0.0.210119DBRU:
Bug: 29487407, fix_controls: 29487407
Bug: 30998035, fix_controls: 30998035
Bug: 30786641, fix_controls: 30786641
Bug: 31444353, fix_controls: 31444353
Bug: 30486896, fix_controls: 30486896
Bug: 28999046, fix_controls: 28999046
Bug: 30902655, fix_controls: 30902655
Bug: 30681521, fix_controls: 30681521
Bug: 29302565, fix_controls: 29302565
Bug: 30972817, fix_controls: 30972817
Bug: 30222669, fix_controls: 30222669
Bug: 31668694, fix_controls: 31668694
Bug: 31001490, fix_controls: 31001490
Bug: 30198239, fix_controls: 30198239
Bug: 30980115, fix_controls: 30980115
Bug: 30616738, fix_controls: 30616738
Bug: 31895670, fix_controls: 31895670
Bug: 19138896, fix_controls: 19138896
Bug: 31376708, fix_controls: 31670824
Bug: 30564898, fix_controls: 9876287, 30564898
Bug: 32234161, fix_controls: 32075777
Bug: 30842277, fix_controls: 30570982
Quite a long list in 19.10.0 containing 22 fixes. But we expected this. We managed to get a lot of important fixes into 19.10.0 to avoid the need for so many one-offs and merges.
Let me enable them to see what I will get in the SPFILE:
SQL> execute dbms_optim_bundle.enable_optim_fixes('ON','BOTH', 'YES')
DBMS_OPTIM command: dbms_optim_bundle.enable_optim_fixes('ON', 'BOTH', 'YES')
Bundle's _fix_control setting as per action:ON
29331066:1 28965084:1 28776811:1 28498976:1 28567417:1 28558645:1
29132869:1 29450812:1 29687220:1 29304314:1 29930457:1 27261477:1
31069997:1 31077481:1 28602253:1 29653132:0 29937655:1 30347410:1
30602828:1 30896685:0 29487407:1 30998035:1 30786641:1 31444353:0
30486896:1 28999046:1 30902655:1 30681521:1 29302565:1 30972817:1
30222669:1 31668694:1 31001490:1 30198239:7 30980115:1 30616738:0
31895670:0 19138896:1 31670824:0 9876287:1 30564898:1 32075777:0
30570982:1
Taking current instance CDB2 as base, details on _fix_control setting for
CON_ID 1 :
1) Current _fix_control setting for spfile:
None
2) Final _fix_control setting for spfile considering current_setting_precedence
is YES
29331066:1 28965084:1 28776811:1 28498976:1 28567417:1 28558645:1
29132869:1 29450812:1 29687220:1 29304314:1 29930457:1 27261477:1
31069997:1 31077481:1 28602253:1 29653132:0 29937655:1 30347410:1
30602828:1 30896685:0 29487407:1 30998035:1 30786641:1 31444353:0
30486896:1 28999046:1 30902655:1 30681521:1 29302565:1 30972817:1
30222669:1 31668694:1 31001490:1 30198239:7 30980115:1 30616738:0
31895670:0 19138896:1 31670824:0 9876287:1 30564898:1 32075777:0
30570982:1
3) Current _fix_control setting in memory:
29331066:1 28965084:1 28776811:1 28498976:1 28567417:1 28558645:1
29132869:1 29450812:1 29687220:1 29304314:1 29930457:1 27261477:1
31069997:1 31077481:1 28602253:1 29653132:0 29937655:1 30347410:1
30602828:1 30896685:0 29487407:0 30998035:0 30786641:0 31444353:0
30486896:0 28999046:0 30902655:0 30681521:0 29302565:0 30972817:0
30222669:0 31668694:0 31001490:0 30198239:0 30980115:0 30616738:0
31895670:0 19138896:0 31670824:0 9876287:0 30564898:0 32075777:0
30570982:0
4) Final _fix_control setting for memory considering current_setting_precedence
is YES
29331066:1 28965084:1 28776811:1 28498976:1 28567417:1 28558645:1
29132869:1 29450812:1 29687220:1 29304314:1 29930457:1 27261477:1
31069997:1 31077481:1 28602253:1 29653132:0 29937655:1 30347410:1
30602828:1 30896685:0 29487407:0 30998035:0 30786641:0 31444353:0
30486896:0 28999046:0 30902655:0 30681521:0 29302565:0 30972817:0
30222669:0 31668694:0 31001490:0 30198239:0 30980115:0 30616738:0
31895670:0 19138896:0 31670824:0 9876287:0 30564898:0 32075777:0
30570982:0
WARNING: final _fix_control setting for memory is not same as final
_fix_control setting for spfile. Please look at point 2 and 4 above to see the
differences.
PL/SQL procedure successfully completed.
This is the setting I have now in my SPFILE:
*._fix_control='29331066:1','28965084:1','28776811:1','28498976:1','28567417:1','28558645:1','29132869:1','29450812:1','29687220:1','29304314:1','29930457:1','27261477:1','31069997:1','31077481:1','28602253:1','29653132:0','29937655:1','30347410:1','30602828:1','30896685:0','29487407:1','30998035:1','30786641:1','31444353:0','30486896:1','28999046:1','30902655:1','30681521:1','29302565:1','30972817:1','30222669:1','31668694:1','31001490:1','30198239:7','30980115:1','30616738:0','31895670:0','19138896:1','31670824:0','9876287:1','30564898:1','32075777:0','30570982:1'#added through dbms_optim_bundle package
All together, 42/43 fixes get enabled/disabled with this call.
Do you really need the fix?
Now Kálmán’s question was: Do I need to apply the fix?
I was wondering as well – and this is the reason why I write this blog post. Technically, all should work fine even without the patch if you know the correct _fix_control setting to put into your SPFILE. So let me check this – now without applying patch 31862593:
SQL> alter system set "_fix_control"='29331066:1','28965084:1','28776811:1','28498976:1','28567417:1','28558645:1','29132869:1','29450812:1','29687220:1','29304314:1','29930457:1','27261477:1','31069997:1','31077481:1','28602253:1','29653132:0','29937655:1','30347410:1','30602828:1','30896685:0','29487407:1','30998035:1','30786641:1','31444353:0','30486896:1','28999046:1','30902655:1','30681521:1','29302565:1','30972817:1','30222669:1','31668694:1','31001490:1','30198239:7','30980115:1','30616738:0','31895670:0','19138896:1','31670824:0','9876287:1','30564898:1','32075777:0','30570982:1' sid='*' scope=both;
Works for me.
BUT … the problem is: DBMS_OPTIM_BUNDLE does not know about the fixes. When you check with:
SQL> exec dbms_optim_bundle.listBundlesWithFCFixes bundleId: 190719, bundleName: 19.4.0.0.190719DBRU bundleId: 191015, bundleName: 19.5.0.0.191015DBRU bundleId: 200414, bundleName: 19.7.0.0.200414DBRU bundleId: 200714, bundleName: 19.8.0.0.200714DBRU bundleId: 201020, bundleName: 19.9.0.0.201020DBRU
you’ll recognize that it is not aware of 19.10.0.
So if you’d ask me, I’d rather tend to apply this fix when you apply 19.10.0. As you may remember, you can do this in one action with -applyRU and -applyOneOffs. Just make sure to keep the unzipped fixes in strictly separated subdirectories.
Further Links and Information
- MOS Note: 2725758.1 – Oracle Database 19c Release Update & Release Update Revision January 2021 Critical Issues
- Patch 31862593
- In case you miss DBMS_OPTIM_BUNDLE … again? (Jun 6, 2019)
- In case you are missing DBMS_OPTIM_BUNDLE (Feb 11, 2019)
- DBMS_OPTIM_BUNDLE Package in Oracle 12.2 and 18c (Mar 8, 2019)
- DBMS_OPTIM_BUNDLE – only available in Oracle 12.1.0.2 … or not? (Jul 25, 2017)
- Package differences between Oracle 11.2.0.4 and Oracle 12.1.0.2 (Jun 23, 2015)
- Bug 27009164 – support for dbms_optim_bundle for CDBs
- Bug 29259128 – REGRESSION: PACKAGE SYS.DBMS_OPTIM_BUNDLE MISSING FROM RU OCT. 2018 (unpublished bug – hence no link added)
–Mike
Hi Mike,
it is possible to ask, why I need a complete outage of RAC while applying (and rollback! for preparing the next RU, every time as long it will superseeded) this OnOff. Regarding the readme.txt for dataguard it is Standby First applicable, hence maybe it‘s a error in readme? Hope so.
Hi Peter,
I was asking the same myself – why do I need an outage, especially since no API gets changes (or at least not via datapatch).
I can’t tell you unfortunately – but I know that developers don’t answer the questions during the fix creating whether it will be RAC Rolling or not “just by accident” usually.
Cheers,
Mike
Hi Peter and Mike,
patch inventory.xml shows.
true
I guess that the readme is not correct, but the inventory.xml is. The action file only seems to replace the XML file in rdbms/admin and I do not see why this can not be done rolling.
Hi Martin,
thanks for the input – let me check back with the owners.
Cheers,
Mike
Hi Mike,
Is there a blog post or MOS Doc ID that explains when you should enable these?
Presumably they are disabled by default and you wouldn’t simply enable them all in go right?
Cheers
Neil
Hi Neil,
this is a tricky question. I don’t operate a PROD environment. So I have no doubts that all of them need to be enabled. But when you fear behavior changes with the Optimizer, you may either decide to NOT enable them or enable them gradually (which does not work with DBMS_OPTIM_BUNDLE but requires altering the _fix_control setting manually afterwards.
It is a promise telling people:
When we change the optimizer’s behavior, we would like to give YOU the choice.
Cheers,
Mike
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 – Production
Version 19.10.0.0.0
SQL> set head off
SQL> set serveroutput on
SQL> exec dbms_optim_bundle.getBugsforBundle;
BEGIN dbms_optim_bundle.getBugsforBundle; END;
*
ERROR at line 1:
ORA-20002: ORA-20002: ORA-20002: Error stat’ing file bundlefcp_DBBP.xml,
getDocument Error, getBugsforBundle Error
ORA-06512: at “SYS.DBMS_OPTIM_BUNDLE”, line 1577
ORA-06512: at line 1
-rw-r–r–. 1 oracle oinstall 3.3K Jan 14 08:23 /netapp/oracle/product/1910i/rdbms/admin/bundlefcp_DBBP.xml
No patch applied yet.
Any thoughts as to why I would be getting this error? I started to create an SR with Oracle but I’m a bit stumped as to what group to route the issue to. Any ideas?
Hi Lance,
I seriously have no idea. Check with “opatch lsinventory” that the fix has been applied binary-wise.
I fear you will need to check with Support via an SR. Since you were asking about “which” group, I can’t tell you as I can’t open an SR, and hence can’t see the various options unfortunately.
Cheers,
Mike
OK, with the latest 19.11 and an attempt to once again use dbms_optim_bundle.getBugsforBundle, this time when I received the error, something clicked in my brain. Turns out the entry in DBA_DIRECTORIES was invalid for some of the entries including DBMS_OPTIM_ADMINDIR and DBMS_OPTIM_LOGDIR. I corrected those so they pointed to the correct location and the error is now gone.
Hi Lance,
I guess it is my fault, too, as I know about the issue but I haven’t added it to the blog yet.
Mike
No worries! You can’t add everything!
Really interesting – I’m not sure dbms_optim_bundle.getBugsforBundle works after an opatch rollback though:
SQL> set line 200
SQL> col DESCRIPTION format a40 wrap word
SQL>
SQL> select PATCH_ID,
2 DESCRIPTION,
3 ACTION,
4 — VERSION,
5 to_char(ACTION_TIME, ‘DD-MON-YY HH24:MI:SS’) ACTION_TIME
6 from dba_registry_sqlpatch
7 /
PATCH_ID DESCRIPTION ACTION ACTION_TIME
———- —————————————- ————— ——————
30901317 Windows Database Bundle Patch : APPLY 09-OCT-20 21:59:26
19.7.0.0.200414 (30901317)
31719903 Windows Database Bundle Patch : APPLY 23-JAN-21 22:01:06
19.9.0.0.201020 (31719903)
31719903 Windows Database Bundle Patch : ROLLBACK 25-JAN-21 15:51:50
19.9.0.0.201020 (31719903)
SQL> execute dbms_optim_bundle.getBugsforBundle;
19.9.0.0.201020DBRU:
☺ Bug: 27261477, fix_controls: 27261477, 31069997, 31077481
☺ Bug: 28602253, fix_controls: 28602253
☺ Bug: 31486557, fix_controls: 29653132
☺ Bug: 29937655, fix_controls: 29937655
☺ Bug: 30347410, fix_controls: 30347410
☺ Bug: 30602828, fix_controls: 30602828
☺ Bug: 30896685, fix_controls: 30896685
PL/SQL procedure successfully completed.
Surely that should show something like :
SQL> execute dbms_optim_bundle.getBugsforBundle;
19.7.0.0.200414DBRU:
☺ Bug: 29687220, fix_controls: 29687220
PL/SQL procedure successfully completed.
?
Thanks
Mark
Hi Mark,
do you have an SR for this issue?
I know that there is one big pitfall with DBMS_OPTIM_BUNDLE when you patch and use a new home – the directories won’t get adjusted.
But I haven’t seen this issue yet for the rollback.
Let me know if you have an SR (this makes it easier for me to follow up internally).
But if not, fine as well.
Cheers,
Mike
Here is some interesting note:
dbms_optim_bundle works with the DBMS_OPTIM_ADMINDIR directory, that is not being changed if you changed homes (for patching for instance; for unplug/plug PDBs to be checked), so the data still can be outdated.
Oracle does this magic for some directories like OPATCH_SCRIPT_DIR, but the rest is on DBAs.
Hi Ruslan,
this is correct – and thanks for the hint. One of my customer ran into this problem, too.
And I think there is even a bug number for this issue.
I hope it gets fixed soon.
Thanks
Mike
Hello Mike,
I wonder if this is related, or we have an error when creating goldimages. I don’t see 19.9, 19.10 or pre-19.8 Items in my list, we are running on 19.11:
SQL> set serveroutput on;
SQL> exec dbms_optim_bundle.getBugsforBundle;
19.8.0.0.200714DBRU:
Bug: 29304314, fix_controls: 29304314
Bug: 29930457, fix_controls: 29930457
PL/SQL procedure successfully completed.
SQL> exec dbms_optim_bundle.listBundlesWithFCFixes;
bundleId: 190719, bundleName: 19.4.0.0.190719DBRU
bundleId: 191015, bundleName: 19.5.0.0.191015DBRU
bundleId: 200414, bundleName: 19.7.0.0.200414DBRU
bundleId: 200714, bundleName: 19.8.0.0.200714DBRU
PL/SQL procedure successfully completed.
So, even if we have 19.11 already, where the fix for 31862593 is first included in (
19.11.0.0.DBRU:210420 (APR 2021)), we have no items besides 19.8.
See my other reply please – check DBMS_OPTIM_ADMINDIR and LOGDIR.
Thanks,
Mike
Hi Gerrit,
so you build a gold image with 19.11.0, and when you install it and create a database (or patch a database up to your gold image), and now you call DBMS_OPTIM_BUNDLE, then you are seeing just these entries?
Can you please check your DBMS_OPTIM_ADMINDIR and LOGDIR?
Maybe they are still pointing to 19.8.0?
Cheers,
Mike
Hi Mike,
From the looks of it all that DBMS_OPTIM_BUNDLE does it a spfile update. That fact that you say if you know the fix you can manually update the spfile confirms this.
But in the MOS doc ‘Managing “installed but disabled” bug fixes in Database Release Updates using DBMS_OPTIM_BUNDLE (Doc ID 2147007.1)’ says with regard to standbys
“This can be done only when the standby database is either activated or a graceful switchover is done . Once it is in read-write mode , use the same steps as metntioned earlier to enable or disable the fixes .”
Why is this? Anything getting written to the data files when you run DBMS_OPTIM_BUNDLE?
When we tested this out in standby didn’t get any errors. If you have a ADG reader farm it seems as per the doc it is not possible to set those fixes without a role change.
regards,
Asanga
Hi Asanga,
so you did use the same call within SQL Plus on the standby, and the update went into the SPFILE?
THanks,
Mike
Hi Mike,
Yes. If it’s an ADG (open read only) no issue in using the dbms_optim_bundle package and SPfile was updated.
But for normal standby (in mount mode) you can’t run dbms_optim_bundle. So to that extent document is right. But for ADG I didn’t see any issue. So just want to make sure, all this does it an SPFile entry not write anything to DB.
regards,
Asanga