ORA-65040: operation not allowed from within a pluggable database

 Starting 12c, after introduction of pluggable databases, there are certain operations that can be performed only at the root container level. If you try to execute that operation/SQL within the PDB, you will receive ORA-65040. In this case you must ensure that the command you are executing is being executed at the root container level. Following is only one example of such operations that can only be performed from the root container.

Listener log file is empty and logging not happening

If listener log file is empty and no logging records are being logged in the log file, this probably means that someone truncate listener log file on the fly without following proper process. In Windows OS, you can not modify or truncate a file (listener log file in this case) that is in use by another proceess, however, Linux based OS would let you do this. After that, logging would no longer continue. Here I have explained the proper way of rotating listener log file. These instructions can be used for listener log file rotation as well as solving the issue of empty listener log file discussed here.

TNS-12508: TNS:listener could not resolve the COMMAND given

If you are in process of rotating listener log file  and you receive TNS-12508 while disabling log_status, this means you have imposed admin restrictions in listener log file for this listener. Same error would be returned for any other settings you would want to change using “set” command from lsnrctl utility. In the following I have reproduced this error and explained how to set and unset admin restrictions in listner log file.

Rotating Listener Log File

Rotating database log files is a common and day-to-day practice for DBAs. Rotation of logs is a process whereby we rename (and archive/compress) current log files so that new log files get created. Listener’s log file is also part of this practice because size of listener log file increases very fast, and it may increase beyond several GBs within a couple of months. If listener log file is not rotated, this may sometimes cause initial connection to database become slow. Therefore, this is very important to rotate listener log file. In the following I will explain how we rotate listener log file.

ORA-46697: Keystore password required

SQL> show pdbs       CON_ID CON_NAME                       OPEN MODE  RESTRICTED ---------- ------------------------------ ---------- ----------          2 PDB$SEED                       READ ONLY  NO          3 MYPDB1                           READ WRITE NO   SQL> create pluggable database testpdb from MYPDB1; create pluggable database testpdb from MYPDB1 * ERROR at line 1: ORA-46697: Keystore password required.

Investigating "read by other session" Wait Event

This article explains about the wait event “read by other session”. In this article I will explain how to further investigate about SQLs and segments involved in this wait event. This should be noted that unless this wait event is the result of slow IO performance, this wait event has to be tuned at the application side or by tuning the segment. To find out which SQLs and which table/index are causing this wait, we can query v$active_session_history (or DBA_HIST_ACTIVE_SESS_HISTORY); SAMPLE_TIME column can be used in WHERE clause to restrict rows for the event details during a specific period. Alternatively, we can also query v$session_wait to find out sessions currently waiting on this wait event.

ORA-19910: can not change recovery target incarnation in control file

If you are trying to resolve ORA-19909 on your physical standby database which is out of sync with primary because of ORA-19909, and you face ORA-19910, the probably cause is that redo apply process is still active. This was exactly the case with me when I tried to reset the incarnation number of my physical primary database. In the following you can see the exact command and error message returned.

Error ORA-235 occurred during an un-locked control file transaction

Error ORA-235 occurred during an un-locked control file transaction.  This error can be ignored.  The control file transaction will be retried. RFS[2]: Opened log for thread 2 sequence 40781 dbid 2440526278 branch 1089779374 RFS[3]: Opened log for thread 1 sequence 40695 dbid 2440526278 branch 1089779374 RFS[4]: Opened log for thread 1 sequence 40693 dbid 2440526278 branch 1089779374 RFS[1]: Opened log for thread 2 sequence 40779 dbid 2440526278 branch 1089779374 Tue Mar 21 04:11:38 2023 Archived Log entry 66837 added for thread 2 sequence 40781 rlc 1089779374 ID 0x0 dest 2: Tue Mar 21 04:11:40 2023 Archived Log entry 66838 added for thread 1 sequence 40693 rlc 1089779374 ID 0x0 dest 2: Tue Mar 21 04:11:40 2023 Archived Log entry 66840 added for thread 1 sequence 40695 rlc 1089779374 ID 0x0 dest 2: Tue Mar 21 04:11:43 2023

Read by Other Session - Oracle Wait Event

Prior to 10.1 version, this wait event was part of Buffer Busy Wait, however, after 10.1 this wait event was separated from buffer busy wait and is now visible in AWR reports. This wait event is reported if multiple sessions are waiting for the same data block to be read from the disk into the buffer cache. This could be alarming if this wait event is reported as one of the top wait events in the AWR reports. There could be different causes of this wait event to be at the top. In this article I will discuss how we can troubleshoot this wait event.

Recovering a Dropped Table using RMAN Backup

There are different ways to recover back a dropped table i.e. recovering from recycle bin if it is set to on, using flashback, importing from an export backup of the table, or using RMAN backup. In this article I will explain how to recover a table using RMAN backup. Database must be running in archivelog mode with RMAN backup available. Backup should have been from the time when table existed. Using this method, we can also recover tables to a previous state (keeping existing version of table) by providing SCN or timestamp.