Conversion

Special characters show junk in CLOB columns after upgrade to Oracle 19.7.0 with JDBC

When you’d copy & paste the above title into a search engine, you may come across a very similar sounding blog post I wrote two years ago. Today, my dear colleague Dirk asked me on behalf of a customer if it’s possible that this bug is back in 19.7.0. Of course, I said “No”, for sure not. Bug 26380097 was fixed in Oracle 18c already. Gladly, Dirk insisted. So I checked the SR his customer opened.

And now I can write an unplanned blog post about Special characters show junk in CLOB columns

Continue reading...

OJVM datapatch fails with ORA-29532 – but the root cause is noncdb_to_pdb.sql

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 noncdb_to_pdb.sql.

OJVM datapatch fails with ORA-29532 - but the root cause is noncdb_to_pdb.sql

Photo by Alexandra Gorn on Unsplash

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 …

Continue reading...

noncdb_to_pdb.sql – why does it take so long?

What is noncdb_to_pdb.sql?

noncdb_to_pdb.sql - Why does it take so long?The script noncdb_to_pdb.sql gets run only once in the life span of your database. It gets executed when a regular Oracle database (non-CDB) gets move to become part of a Single-/Multitenant deployment as a pluggable database (PDB). But why does it take so long?

You will never run this script again for this database. The script is a sanity script to clean up and change things in a non-CDB, and unite it finally and irreversible with the CDB.

How long does it take to complete?

Runtime varies a lot. It depends mainly on the number of objects …

Continue reading...

Move to Locally Managed Tablespaces

As I’ve got asked during the workshop in Warsaw how to migrate Dictionary Managed to Locally Managed tablespaces here’s some additional information and an example.

To find out if a tablespace is dictionary or locally managed you’d use this query:

SQL> select
TABLESPACE_NAME, EXTENT_MANAGEMENT from DBA_TABLESPACES;

The procedure to migrate to locally managed tablespace is:

SQL> EXECUTE
DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL(‘tbs’);

And the whole migration procedure would look like this:

STARTUP RESTRICT
EXCLUSIVE;
EXEC
DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL(‘TBS’);
— do this for all tablespaces except SYSTEM, TEMP and SYSAUX
DROP TABLESPACE
TEMP;
— necessary if there’s no “real” temp tablespace definded yet – see Note:160426.1
CREATE

Continue reading...