The other day I received a question from a colleague about the risk of having GI and database both not being on the same RU. And a long while ago I blogged about it. We recommend that you keep it in synch. But you don’t have to. At the same time I received a wish from Ernst Leber to post something on the blog he and his colleague had trouble with when upgrading to 19c in a RAC environment. AutoUpgrade hung. But he titled his email with “not an AutoUpgrade problem!”. Still I agree, it is worth to write …Continue reading...
Ernst Leber sent me an email today. He hit an error at a customer upgrading to Oracle 19.9.0 on Exadata with AutoUpgrade. ORA-1422 and ORA-6512 from SYS.DBMS_STATS in Post Upgrade were signaled – and he better flashed back to the Guaranteed Restore Point. He found even a MOS note but still had questions. So time to blog about it in case you hit this error sequence as well.
What happens, and when does it happen?
At first, this is not an AutoUpgrade issue. You may see the same error stack in the post upgrade …Continue reading...
Oh … it’s Windows week here. And all this even though since I didn’t install Oracle on Windows for quite a while. But of course I’m fully aware that many of you out there operate Oracle on Windows. In this particular case thanks to Joël for the pointer to this issue. Oracle 19c on Windows may flood your trace file directory.
In every release of Oracle 19c, at least until 19.10.0 BP, you may find out that every few minutes a trace file gets written into the %ORACLE_BASE%\diag\..\..\trace directory. And all …Continue reading...
As I learned from a customer this week, this patch is a must have when you use Partitioning and you attempt to upgrade to Oracle 19.9.0 or earlier. So please apply patch 31088341 before Upgrade to prevent ORA-1403 happening.
What is the issue?
This applies to all 19c upgrades at least until 19.9.0.
The fix is included from 19.10.0 Release Update onward. So if you are upgrading to 19.10.0 or higher, you can stop reading here (thanks Pablo for the hint!).
You may see this error pattern in catupgrd0.log:
==Error from catupgrd0.log=== =================================================================… Continue reading...
This is the right blog post for a Friday 13th. And please forgive me – I wanted to put this on the blog earlier as two of my customers hit this weeks ago already. But it must have fallen through the cracks. Still, now it is hopefully not too late to tell you what you should do if you hit ORA-29702 – and your instance does not startup in the cluster anymore. Especially when you tested a database upgrade – and after a restore, the database doesn’t want to start, no matter what you try.… Continue reading...
Where do I start? One of the customer accounts I worked the longest time with recently upgraded to Oracle 19c on Exadata. They are an Exadata customer since 2009. After going live on 19c, a few days later they hit an MGA Issue – and it is fixed with Oracle 19.8.0 and newer. But question no.1 was: Why hasn’t Oracle warned us – and how could we have learned about it?
What is the MGA?
OK, I have heard of SGA and PGA. But MGA? The first two hits when I search with …Continue reading...
Kudos to Robert Ortel who brought this nice misbehavior to my attention. And even though it looks like this would be an OJVM issue, it is caused by
noncdb_to_pdb,sql, the script which is used to convert a non-CDB to a PDB. When you apply an OJVM patch, OJVM datapatch fails with ORA-29532 – but the root cause is
It’s a bit tricky
First things first. This is not a blog post to blame OJVM. The problem just happens because
datapatch for an OJVM patch touches data in the dictionary which hasn’t …
Sometimes it is necessary to warn you about known pitfalls to avoid frustration. In this particular case I decided not to blog about it simply because I thought this won’t happen to too many other people. Well, yesterday my good friend Philippe Fierens dropped me a message about an issue he ran into with a Transportable Tablespace PDB Migration and Local Undo. And I immediately knew what caused him trouble – and I regret that I didn’t blog about it (sorry Philippe!). We’ve seen the same problem with a large ExaCC migration project …Continue reading...
Strange things happen sometimes. I got alerted by a customer before Christmas about package
DBMS_OPTIM_BUNDLE missing after applying a Release Update. I’ve had a conversation with Nigel Bayliss, the Optimizer PM – but Nigel hasn’t heard of such things either. We both investigated but couldn’t reproduce the issue. But after the end-of-the-year holidays I received similar messages from other customers. In case you miss
DBMS_OPTIM_BUNDLE in 12.2, then this blog post should help you.
What is DBMS_OPTIM_BUNDLE?
I blogged about this package in the past already several times:Continue reading...
I really don’t want to turn this blog into an accumulation of issues and flaws. But as I explained many times before, the blog for me is also a way to dump information I likely will need the sooner or later again.
Recently I blogged about another RMAN issue in Oracle 22.214.171.124 with traces. This was fixed with the July 2018 RU for Oracle 126.96.36.199. But the issue below about which Piero Ferraz from Brazil alerted me (thanks!!!), happens in exactly this RU.
RMAN Backup Gives RMAN-06091: No Channel Allocated for Maintenance
This issue gets introduced with the July …Continue reading...
Again I’ll have to thank my colleague Roland Gräff from the German ACS Support team in Stuttgart for bringing this into our radar. Roland alerted me a week ago about an issue with exports in Oracle 188.8.131.52 only when you are on a certain patch level. I summarize the issue here under Data Pump 184.108.40.206 – Wrong Dump File Version – ORA-39142.
In the below blog post you will learn about the actual issue, where it happens and when, and of course how to workaround it.
When does it happen?
The issue I will describe below happens only with …Continue reading...
Thanks to my support colleague Roland Graeff who told me about this issue at a customer today. And I consider this a pretty serious issue. It can happen that Special characters show junk in CLOB columns after upgrade to Oracle 220.127.116.11. with JDBC.
This is as bad as it sounds. Roland told me about a case where the application showed weird characters instead of German umlauts (ä, ö, ü, Ä, Ö, Ü) after an upgrade from Oracle Database 18.104.22.168 to 22.214.171.124.
Special characters show junk in CLOB columns after upgrade to Oracle 126.96.36.199 with JDBC
Roland explained to me that …Continue reading...
I love visiting customers onsite. Last week I visited die Mobiliar in Bern, Switzerland. I received a list of open issues to discuss – which is very good to prepare a visit. And when we all were sitting together there was this “Ah, one final thing”. They have an issue with traces the databases writes every few seconds. As a remedy the DBAs increased the backup interval to remove the traces as otherwise the system would potentially run out of inodes or space. All the traces had the same pattern. And I learned quickly: these are MMON unconditional traces in …Continue reading...
I blogged about the Adaptive Features fixes in the past several times. But following some of the comments readers had I believe there’s some additional info for Adaptive Feature Fixes in Oracle 188.8.131.52 necessary.
What happened so far?
We delivered the most important fixes not only for adaptive features but only for dynamic sampling and some other things with the Database Bundle Patch in October 2017 for Oracle Database 184.108.40.206. The fixes got delivered on MS Windows a bit earlier.
- Enabling Oracle 12.2 ADAPTIVE Features in Oracle 220.127.116.11 – BEFORE the patches got included in BPs
- Oracle 12.2 Adaptive Features
There is a fancy new command to unplug a PDB in Oracle Database 18.104.22.168:
ALTER PLUGGABLE DATABASE pdb1 UNPLUG INTO 'pdb1.pdb';
The nice thing with this command differing in the file ending of ‘
pdb‘ instead of ‘
xml‘ as you used it in Oracle 12.1 (and the ‘
xml‘ option is still available of course): Instead of just creating an
xml description file it
zips everything together into a PDB archive.
SQL> show pdbs CON_ID CON_NAME OPEN MODE RESTRICTED ---------- ------------------------------ ---------- ---------- 2 PDB$SEED READ ONLY NO SQL> create pluggable… Continue reading...
Related blog posts:
- RMAN Catalog Upgrade fails – ORA-02296 – error creating modify_ts_pdbinc_key_not_null
(April 19, 2016)
- RMAN Catalog requires Enterprise Edition (EE) since Oracle Database 22.214.171.124
(April 22, 2016)
- RMAN Catalog Upgrade to Oracle 126.96.36.199
(August 1, 2014)
Thanks to Ah Huat Tan from Amway IT Services for keeping me updated!
Actually as I see that more people who got hit by this issue so I’d consider it to be worth to write about it.
Problem and Analysis
You’d apply the July 2016 PSU or BP. According to the readme you are required to upgrade your RMAN catalog afterwards. The …Continue reading...
Credits to Chris Smids from Proximus in Belgium 🙂 Thanks, Chris!!!
Upgrade to Oracle 188.8.131.52 is slow in phase: #65 ?
You are wondering why phase: #65 of the database upgrade to Oracle Database 184.108.40.206 takes quite a while. You dig down into the catupgrd0.log and recognized this statement taking a while:
dbms_output.put_line('catuposb, update 4 - rows updated ' || rows_updated); END; -- end of update for system internally generated objs /
The cause for this issue is buried in the script catuposb.sql hitting stale histograms which did not get refreshed even if you gathered dictionary stats before the upgrade …Continue reading...
This issue got raised to my via a customer I know for quite a while – all credits go to Andy Kielhorn for digging down into that issue and solving it.
Failed RMAN Catalog Upgrade from 220.127.116.11 to 18.104.22.168
The RMAN catalog upgrade:
SQL> @?/rdbms/admin/dbmsrmansys.sql $ rman CATALOG rman/xxx@rman01 RMAN> UPGRADE CATALOG; RMAN> UPGRADE CATALOG;
failed with the following sequence of error messages:
error creating modify_ts_pdbinc_key_not_null RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-06004: ORACLE error from recovery catalog database: ORA-02296: cannot enable (RMAN.) - null values found error creating modify_tsatt_pdbinc_key_not_null RMAN-00571: =========================================================== RMAN-00569: =============== ERROR… Continue reading...
A customer (Thanks Stefano!) alerted me on this issue during a workshop and I did some further investigation. Basic headline is:
Query on ALL_SYNONYMS is very slow in Oracle Database 22.214.171.124 compared to 11g.
The workaround for this 21324443: SLOW QUERY IN 12C ON ALL_SYNONYMS. is:
dbms_stats.gather_table_stats('SYS','OBJ$',estimate_percent =>100, method_opt => 'for columns flags size 1, spare3 size 254, type# size 254');
and I see that at least 8 other customers opened SRs hitting the same issue.
Does the workaround suit you in any way?
The bug had no progress since it was opened. If you are seeking progress …Continue reading...
This Infoworld article from Jan 17, 2012 Fundamental Oracle flaw revealed did alert Oracle database customers.Infoworld has raised this issue to Oracle before going public with it. Patches are included in the Jan 2012 CPU and PSU. So again, it’s strongly recommended to apply the Jan 2012 PSU (or CPU if you are just asking for security fixes) to your environments.
- Please read on OTN the Critical Patch Update Advisory from January 2012
- You’ll find an explanation from Oracle Support in
MOS Note:1376995.1: Information on the System Change Number (SCN) and how it is used in the Oracle Database