ORA-65179: cannot keep datafiles for a pluggable database that is not unplugged

 

SQL> alter pluggable database pdb2 close; Pluggable database altered. SQL> drop pluggable database pdb2; drop pluggable database pdb2 * ERROR at line 1: ORA-65179: cannot keep datafiles for a pluggable database that is not unplugged

 

ORA-19809: limit exceeded for recover files

 I faced ORA-19809 when backup of one of my databases failed during archived log backup phase. In our backup script we had a statement “ALTER SYSTEM ARCHIVE LOG CURRENT” just before the backup command for archived redo logs. When ALTER SYSTEM ARCHIVE LOG CURRENT statement was executed, following error stack was returned.

ORA-10485: Real-Time Query cannot be enabled while applying migration redo

This error message may appear in the alert log file of standby database after an upgrade/PSU etc. is applied on the primary database and if real time apply is enabled on the standby database.

The procedure to apply a PSU or other (rolling) patches is that it is first applied on the standby database server and after that on the primary database, and any post patch (or upgrade) scripts are executed on the primary database. Once this completes, all database changes happened during patch/upgrade scripts execution are shipped through redo logs to the standby database and standby database eventually becomes in sync with the primary.

CORRUPTION DETECTED: In redo blocks starting at block in dataguard

If this error comes in dataguard (physical standby) database, oracle will automatically delete the corrupted archived log file and then we would require to copy the affected archived log from the primary site and so that managed recovery could proceed. I was thinking that oracle should automatically fetch the affected/corrupted archived log itself from the primary site, but then I realized the reason of not happening this automatically and I will explain the reason later.

Once this type of corruption is detected, following type of message is shown in the alert log file.

ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected

For me, the reason of this error was that I tried to open a standby database and then tried to start the managed recovery in order to utilize active dataguard feature. First, I cancelled the managed recovery, then opened the standby database, and as soon as I execute the command to start managed recovery process, ORA-01093 popped up; as you can see below.

ddl_lock_timeout to avoid ORA-00054

I have a previous article available here that explains about ORA-00054 and the reason of this error, and alto the enhancement starting 12c to avoid this error. In this article I would further explain ORA-00054 and how to use an initialization parameter DDL_LOCK_TIMEOUT to avoid this error. Instead of returning this error because of a lock on the object, your DDL would keep waiting for the locks to be released and get executed automatically when object is available for the DDL operation.

ASM Disks not Reachable After Reboot - Manually Loading ASM Driver

After a system reboot if you see ASM disks are not available, and scanning ASM disk returns “Unable to instantiate disk”, as follows, it could be because oracleasm driver was not loaded and hence ASM did not work as expected. As a result, ASM disks will not be visible to ASM instance and ASM diskgroups would not mounted. Following is the example output of if you execute “oracleasm scandisks” command.

Not All Endpoints Registered

If issuing “crsctl status resource” command show the status of listener as “Not All Endpoints Registered”, it is usually because of contradictions in the Listener settings. It means that probably you have a manually setup listener (by editing listener.ora file) with different settings than registered with the CRS/HAS. Or, there could be multiple listeners configured from multiple oracle homes – one from Grid Infrastructure home, and other listener with same configuration running from other home and started manually (using lsnrctl command).

DBMS_AW_EXP: BIN$ZRGxDTT9TumIWFOmM0qIHQ==$0 not AW$

If you see any similar messages during expdp, you may ignore these messages. Alternatively, you may purge the recyclebin and initiate the expdp again. Issue “purge dba_recyclebin” from SQLPUS. The messages displayed in expdp log are as follows.

Initialization parameter setting back to original value

I faced a very strange situation whereby I was setting my log_archive_dest_1 parameter using ALTER SYSTEM command with SCOPE=BOTH, which meant that this parameter value change should have been consistent across the instances reboot as this change was also being made in the spfile (SPFILE was in use for that database/instance) as well as in memory. However, it was not happening actually. After every instance restart, the value of this parameter would again set to the old value and this was causing problems for us.