Top 60 Oracle Blogs

Recent comments

Database management

12cR2 needs to connect with password for Cross-PDB DML

In a previous post, I explained that Cross-PDB DML, executing an update/delete/insert with the CONTAINERS() clause, seems to be implemented with implicit database links. Connecting through a database link requires a password and this blog post is about an error you may encounter: ORA-01017: invalid username/password; logon denied

random “ORA-01017: invalid username/password” in 12cR2

Since 12cR2 is out, we give our 12c new feature workshop with hands-on exercises on 12.1 and 12.2 releases. When I gave it last month, I had a small problem when doing demos: sometimes the connections as sysdba failed with “ORA-01017: invalid username/password”. It was at random, about one every 5 login attempts and I was sure that the password did not change. As I give another of this training next week, I tried to reproduce and fix this issue and finally found out that the problem was really random: dependent on the entropy when reading /dev/random

12cR2 Cross-container DML – insert into container()

Multitenant has been introduced in with the goal to share resources but isolate data. However, having all PDBs in the same root may be convenient to manipulate data in multiple PDBs. In the first patchset,, a way to query cross-container has been introduced for the CDB administrator to see data in other containers. In the second release,, this goes further with the introduction of Application Containers and cross-PDB DML. Currently, not all possibilities are documented and not all documented features are actually working. This will probably improve in next patchset. I’ll start here with something simple: insert from root into a table which is in a PDB.

Can you open PDB$SEED read write?

If you are in multitenant, you probably already felt the desire to open the PDB$SEED in READ WRITE mode.

  • Can you open PDB$SEED read write yourseld? Yes and No.
  • Should you open PDB$SEED read write yourself? Yes and No.
  • How to run upgrade scripts that need to write to PDB$SEED?

In 12.1 you have no reason to open the seed read write yourself. In 12.2 there is one reason when you are in LOCAL UNDO mode, because you may want to customize the UNDO tablespace.

12c nologging and Data Guard

The title sounds weird because Data Guard synchronisation is based on the redo stream, so it makes no sense to do nologging operations on the primary. And this is the reason why we set FORCE LOGGING on a Data Guard configuration. However, to lower the downtime of a migration done with Data Pump, you may want to import with minimal logging and then re-synchronize the standby. This post is about the re-synchronisation in 12.1

Nologging Data Pump

When you want to lower the downtime for a migration, you can disable force logging (alter database no force logging), and run impdp with the following: transform=disable_archive_logging:y
Don’t forget to re-enable force_logging at the end and to re-synchronize the standby.

12cR2 partial PDB backup

I had a recent question about the following mention from the 12cR2 Multitenant book, about Partial PDB backups:
Here is an example in 12.2 with local undo to illustrate the answer, which may help to understand what is a partial PDB backup.

Listener and Virtual IP

When you configure a standby database, you want the application to transparently connect to the primary database, wherever it is. That’s the role of Transparent Application Failover, but this requires configuration on the client side. If you can’t configure TAF, you can use a virtual IP address. But then the question is how to configure the listener.ora to handle connections to this VIP.

Don’t worry, if you configured everything as recommended, with the hostname declared in /etc/hosts, and listener.ora referencing this host name, then you can simply ignore the VIP for your configuration. The reason is that when the host specified in the listener.ora resolves to the same IP address as the hostname of the server, then Oracle listener binds the port on all interfaces, and this includes the VIP.


Do you know the RMAN Recovery advisor? It detects the problems, and then you:

RMAN> list failure;
RMAN> advise failure;
RMAN> repair failure;

You need to have a failure detected. You can run Health Check if it was not detected automatically (see In 12.2 you can run the repair directly, by specifying what you want to repair.


Data Pump is a powerful way to save data or metadata, move it, migrate, etc. Here is an example showing few new features in 12cR1 and 12cR2.

New parameters

Here is the result of a diff between 12.1 and 12.2 ‘imp help=y’

But for this post, I’ll show the parameters that existed in 12.1 but have been enhanced in 12.2


This is a 12.1 feature. The parameter LOGTIME=ALL displays the system timestamp in front of the messages in at the screen and in the logfile. The default is NONE and you can also set it to STATUS for screen only and LOGFILE for logfile only.

SecureFiles on multi-datafiles tablespaces

When we have a tablespace with multiple datafiles, we are used to seeing the datafiles filled evenly, the extents being allocated in a round-robin fashion. In the old time, we used that to maximize performance, distributing the tables to all disks. Today, we use LVM striping, maximum Inter-Policy, ASM even distribution. And we may even use bigfile tablespaces, so that we don’t care about having multiple datafiles.

But recently, during test phase of migration, I came upon something like this: