Category Archives: Oracle Database

Oracle Broke DICTIONARY in 12.2+ PDBs

2023-01-06 Update: There is now also a fix for 19.17. Patch 34754803: REGRESSION TRACKING BUG FILED FROM MERGEREQ

2023-01-05 Update: There is a fix for 19.16! Patch 28998679: COMMENTS MISSING FROM DICTIONARY IN PDB

But that fix ONLY appears to work in 19.16.  When I tried to apply the patch to my 19.17 database, it told me that I was missing the 19.16 patch. So I’m off to log a bug against the patch and to see if we can get the patch into the actual database patches…

2019-08-09 Update: Still broken in 18.6 on Oracle Cloud.

When Oracle introduced pluggable databases in Oracle 12.1, they were supposed to be indistinguishable from non-pluggable databases as far as clients were concerned. Basically, this was true. But one thing that has since broken, at least in 12.2 and higher (confirmed in 18.3), is the comments on the DICTIONARY view.

I (and my students at ACC) use the DICTIONARY view or DICT for short quite a bit as it’s a quick way to find the data dictionary view that you are looking for.

DICTIONARY (or the DICT synonym) is great. It’s got two columns, TABLE_NAME and COMMENTS. Comments are very useful to search through (make sure to use UPPER as they are mixed case) because sometimes the table name can be a bit opaque.

The entry for DICTIONARY is pretty clear:

select * 
  from dict 
 where table_name = 'DICTIONARY';
TABLE_NAME COMMENTS 
DICTIONARY Description of data dictionary tables and views

The above is exactly what you get when you are connected to the root container (CDB$ROOT) of any version of a multitenant database.

However, if you connect to any pluggable database other than version 12.1 (12.1 worked as expected), you’ll get the following for the same query:

TABLE_NAME   COMMENTS   
DICTIONARY   (null)

It turns out that in 12.2 databases and higher, there is only a single comment in the DICTIONARY view when you are connected to a pluggable database:

select * 
  from dict 
 where comments is not null;
TABLE_NAME         COMMENTS 
DBA_CONTAINER_DATA Describes default and object-specific CONTAINER_DATA attributes

And, interestingly enough, in a PDB, DBA_CONTAINER_DATA has no rows! So the only comment in the DICTIONARY view in a PDB is for a view that has no data in PDBs. Obviously, someone dropped the ball here.

In a 12.1 pluggable database, you’d get a LOT of comments in the DICTIONARY view:

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 64bit Production

SYS@devpdb > select count(*) from dict where comments is not null;

COUNT(*)
----------
2882

I pointed this out to Oracle Support back in August of 2018. After first not believing me and asking me what I might have done to my data dictionary, and claiming that they couldn’t reproduce it, and then admitting that they could reproduce it, a bug was logged.

Currently, they are here:

“The bug is at Sev2 and will be worked upon by Dev as per the priority.”

The bug number is 28998679.

You can make the DICTIONARY view work in PDBs by creating a database link to the root container and getting the comments from there. Obviously (I hope), updating the actual view name (DICTIONARY) and/or public synonym (DICT) wouldn’t be supported, so you should create your own public synonym and/or view. Of course, I’m not sure how you’d get developers to use it since they are expecting DICTIONARY/DICT to just work…

As an aside, I came across this when building an APEX application for my students that would let them use an interactive report against DICTIONARY to search for interesting data dictionary views.

2023-01-05 Update

I was able to verify that if you have a 19.16 database, the patch does fix the issue.

[oracle@databaseserver DB:dbacon ~]
$ opatch lspatches
28998679;COMMENTS MISSING FROM DICTIONARY IN PDB
34160635;OCW RELEASE UPDATE 19.16.0.0.0 (34160635)
34086870;OJVM RELEASE UPDATE: 19.16.0.0.220719 (34086870)
34133642;Database Release Update : 19.16.0.0.220719 (34133642)

OPatch succeeded.

[oracle@databaseserver DB:dbacon ~]
$ sql sys@orcl as sysdba


SQLcl: Release 22.4 Production on Thu Jan 05 21:44:41 2023

Copyright (c) 1982, 2023, Oracle.  All rights reserved.

Password? (**********?) *********
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.16.0.0.0

SYS@orcl AS SYSDBA > select count(*) as "Total Comments" 
                       from dict 
                      where comments is not null;


Total Comments
______________
          4453

However, this patch will then block you from upgrading to 19.17.

2023-01-06 Update

There is now also a fix for 19.17. If you apply patch 34754803 then life is good:

[oracle@databaseserver DB:dbacon ~]
$ opatch lspatches
34754803;REGRESSION TRACKING BUG FILED FROM MERGEREQ
34444834;OCW RELEASE UPDATE 19.17.0.0.0 (34444834)
34411846;OJVM RELEASE UPDATE: 19.17.0.0.221018 (34411846)
34419443;Database Release Update : 19.17.0.0.221018 (34419443)

OPatch succeeded.

[oracle@databaseserver DB:dbacon ~]
$ sql / as sysdba


SQLcl: Release 22.4 Production on Fri Jan 06 15:37:33 2023

Copyright (c) 1982, 2023, Oracle.  All rights reserved.

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.17.0.0.0

SYS@CDB$ROOT AS SYSDBA > select count(*) from dict where comments is not null;

   COUNT(*)
___________
       4458

SYS@CDB$ROOT AS SYSDBA > alter session set container=orcl;

Session altered.

SYS@CDB$ROOT AS SYSDBA > select count(*) from dict where comments is not null;

   COUNT(*)
___________
       4459
Advertisement

SQL Developer SSH Connections In Depth

Capture

Available now: A 29-page white paper on SQL Developer SSH Connections that explains in detail how SSH connections should be configured between your desktop/laptop and your organization’s database!

The vast majority of explanations out on the internet of how to configure SSH connections between Oracle SQL Developer and an Oracle Database use incredibly simplistic explanations, often using the oracle os account as the ssh user (absolutely a worst practice!), and not including important things like how firewalls will impact connections, how your ssh server should be configured, etc.

I wrote a 29-page white paper which has been published on the Insum.ca website. It covers the above and more in exacting detail. If you click the link above you’ll be taken to a description of the white paper and then to a page where you’ll be able to download it after supplying a name and email (a fair trade for the amount of time and effort I put into the white paper…).

Note: The image above is from the white paper and is used for explanation purposes only… None of those things actually exist except for the WordPress external firewall that protects just this blog, or, actually, all the blogs at WordPress.com.


Beware: Oracle RMAN Password Only Encrypted Compressed Backups to Tape Might Not Decrypt

So, a few weekends ago I had a BIG scare. I was moving an Oracle Database Appliance from one data center to another. Oracle said the only supported method to do so was to wipe the machine back to bare metal and rebuild it in the new data center with all the new IP addresses and network settings. To prepare for this I did a cold backup of a database to tape (really Oracle Cloud Backup) and used the following RMAN commands:

RMAN> set encryption on identified by ******************* only;
RMAN> backup device type sbt incremental level 0
      tag '2018_06_29_SERVER_MOVE' force as compressed backupset database;

Unfortunately, when it came time to read that backup from Oracle Cloud Backup (our configured sbt device), I got the following error:

ORA-19913: unable to decrypt backup

As I worked through the issue with Oracle Support for a very long time I eventually started working with some support folks who said the following:

“I’ve seen issues in the past when you do a password only encrypted compressed backup to tape where it can’t be decrypted. You shouldn’t do that.”

I think this is potentially one of the biggest bugs in the history of Oracle (if you can’t trust a backup then something is very very wrong!) if the issue is really there… I’ve yet to be able to do any additional testing of this, but figured I’d give folks a warning.

As an aside, I did take a disk backup before the tape backup and then copied the disk backup to a mounted NFS drive. I was able to move that disk backup over to the server and restore from it, so no customer data was harmed during the server move.


I’ll be speaking at AOUG on Friday December 15th

IMP_web001

I’ll be speaking, but if you come, you’ll be building!

You’ve heard about the Internet of Things (IoT). C2 Consulting has put together a hands on lab where you’ll get to build an IoT thermostat from electronic components and hook it up to to REST components in an Oracle Database and then control everything from an APEX application.

You can register for the event at this link or at this url if that link doesn’t work for some reason:
https://docs.google.com/forms/d/e/1FAIpQLSdKP0TZ8KraEuAoSM1Ad0FSqkzBIP5QMCuc4uItKneeG7nBNA/viewform?c=0&w=1

This is the lab we’ll be working through and it’s pretty awesome (and award winning!): https://concept2completion.com/iotemp

Here’s some details about the when and where:

Event Timing: Friday, December 15th from 11 am to 1:30 PM
Event Address: National Instruments at 11500 North Mopac Expressway, Building C, Rooms 1S13-1S15.
Parking available in the garage for building C.

If you are in the Austin area on Friday December 15th hopefully I’ll see you there.