If you are performing a datapump export and you are returned following error for one or more tables, this means that probably a simultaneous partition maintenance operation is in progress during this time this table was accessed for export. ORA-31693, ORA-02354, ORA-02149
ORA-31693: Table data object "<TABLE_OWNER>."<TABLE_NAME>":"<PARTITION_NAME>" failed to load/unload and is being skipped due to error: ORA-02354: error in exporting/importing data ORA-02149: Specified partition does not exist |
If you are performing a SCN or time based recovery and RMAN-20208 is returned, It means that there was a SCN or time-based recovery previously done after which database was opened with reset logs, and now database has a new incarnation number. If you once again want to perform a recovery for any reason, or previously done incomplete recovery was not until the point where we wanted database to be, you need to reset the incarnation of the database and repeat the incomplete recovery process.
Starting 12c with the introduction of pluggable databases, we can perform point-in-time recovery either at CDB (container database) level or at individual pluggable databases level, in a multi-container CDB. CDB level recovery is same as conventional database point-in-time recovery that existed prior to 12c. In this document I will explain how to perform point-in-time recovery of a CDB (that could be a non-container database, or a multi-container database with one or more PDBs); and also, recovery of an individual PDB in a multi-container CDB database.
This document explains how to enable database flashback, creating restore points and performing recovery using guaranteed restore point. In the following I will explain how we can perform a time based, or SCN based flashback restore. Before proceeding further, make sure that flashback is enabled, and flashback logs are also getting created in the fast recovery area. Flashback logs are managed automatically, and oldest flashback logs are purged by oracle if there is a space crunch sensed in the fast recovery area. Oracle will try to keep flashback logs until the time (in the past) specified in the parameter db_flashback_retention_target. However, this value is only a soft limit and specified in minutes.
Creating standby redo log files is a recommended way of configuring dataguard in Oracle database environment. If there is any discrepancy found in standby redo log configuration, you might face ORA-16789 warning. While checking status of dataguard configuration through DGMGRL command, following is that you might see as an example, in a dataguard broker configuration.
|
[oracle]$
sqlplus |
I faced this error message when I tried to drop a table from my PDB which was opened in read-write mode without any restriction.
|
SQL> drop table test; |
You should use “including
datafiles” clause while dropping a pluggable database otherwise ORA-65179 would
be returned
|
SQL> drop pluggable database testpdb; |
Starting 12.2, if you are planning to clone a PDB locally or remotely, you can do that while source PDB is open in read-write mode (hot cloning). In 12.1, if you start your CREATE PLUGGABLE DATABASE command while a transaction is already active in the source PB, you will be returned ORA-65342. Therefore, the better option is to close the source PDB, and then start it as read-only so that no transactions could hinder the cloning process
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.
