enq: TX - row lock contention - Row Lock Wait

This wait event appears if continuous row locking and session blocking is happening in the in the database. If your end user complains about the application hang or slowness, excessive row locking could be one of the reason of it. Sometime an ad-hoc process executes for purging of data or bulk update of data that would cause huge locking whereby application users may face application slowness or hang. To identify the problem, you can generate AWR report to find out what is going on and find out what is causing locking. Following is an image of AWR report that shows row locking (eventually causing the sessions blocking) is responsible for more than 90% of database time.

ORA-16053: DB_UNIQUE_NAME my_dr, is not in the Data Guard

SQL> alter system set log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST DB_UNIQUE_NAME=my_d, valid_for=(ALL_LOGFILES, ALL_ROLES)' sid='*'; alter system set log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST DB_UNIQUE_NAME=my_dr valid_for=(ALL_LOGFILES, ALL_ROLES)' sid='*' * ERROR at line 1: ORA-02097: parameter cannot be modified because specified value is invalid ORA-16053: DB_UNIQUE_NAME my_dr, is not in the Data Guard Configuration

ORA-16024: parameter LOG_ARCHIVE_DEST_1 cannot be parsed

SQL> alter system set log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST DB_UNIQUE_NAME=my_dg,valid_for=(ALL_LOGFILES,ALL_ROLES)' sid='*'; alter system set log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST DB_UNIQUE_NAME=my_dg,valid_for=(ALL_LOGFILES,ALL_ROLES)' sid='*' * ERROR at line 1: ORA-02097: parameter cannot be modified because specified value is invalid ORA-16024: parameter LOG_ARCHIVE_DEST_1 cannot be parsed

Pluggable Database Cloning on Local Host (Local CDB)

 Cloning a pluggable database locally or remotely has become a routine task for DBAs. Different DBAs use different methods to clone a pluggable database. The cloning may be needed on the local host where source pluggable database exists, or requirement could be to clone it on a different host. In this article, I will explain how to clone a pluggable database on the local host (local container database). Click here to learn about how to clone a pluggable database from a remote host using database link.

Pluggable Database Remote Cloning Using Database Link

Cloning a pluggable database locally or remotely has become a routine task for DBAs. Different DBAs use different methods to clone a pluggable database. The cloning may be needed on the local host, where source pluggable database exists, or requirement could be to clone to a different host. In this article, I will explain how to clone a pluggable database remotely using a database link. Click here to learn about how to clone a pluggable database on the local host (local container database).

Monitoring RMAN Restore and Recovery Progress

 While we start a restore and recovery process for database or datafiles, next step is to monitor the progress of restore and recovery process. This is particularly important when end user or customer is keen to learn the approximate completion time of recovery when a critical system is down because of database/datafile corruption. In this article, I would explain how we monitor the recovery of database, and approximate time of completion for the recovery process.

Renaming Datafile(s) in Standby Database

 Renaming a datafile on standby database is a quite simple process. If you are using ASM diskgroups as storage, the primary and standby databases already have different locations and names, and you can use RMAN command “switch datafile/database to copy” to move a datafile to a new location. This method is explained here as part of standby database incremental restore. If you are using file system for datafiles storage, you might sometimes need to relocate one or more datafiles to a different location; for example if file system is full. Following are the steps that you can follow to relocate a datafile in this case.

CRS-4535: While Starting CRS

Follow this document to understand the process of stopping and starting the CRS or Cluster. But, there is a possibility that CRS got stopped automatically because of some reason (for example: if file system where CRS/Grid Infrastructure is installed gets full that mames CRS to crash). In this case, if you try to start, stop or check the status of CRS, you may be returned CRS-4535. There could be other reasons for this error message as well.

ORA-16541: database is not enabled

 Accidentally or purposely, we sometimes need to disable a database from DG broker configuration. This is done by using command on DGMGRL.

[oracle:DB_DG ~]$ dgmgrl / DGMGRL for Linux: Version 11.2.0.4.0 - 64bit Production Copyright (c) 2000, 2009, Oracle. All rights reserved. Welcome to DGMGRL, type "help" for information. Connected.

Error: ORA-16765: Redo Apply is running

DGMGRL for Linux: Version 11.2.0.4.0 - 64bit Production Copyright (c) 2000, 2009, Oracle. All rights reserved. Welcome to DGMGRL, type "help" for information. Connected. DGMGRL> show configuration   Configuration - TEST DG configuration

Error: ORA-16724: cannot resolve gap for one or more standby databases

 If there is an archive gap and dataguard database is not fully in synch with the primary database, initiating DGMGRL and connecting to the database would immediately show ORA-16724 with the configuration. This can be seen bellow.

Standby Database Archived Redo Logs Gap and Incremental Restore

Archive log gap is a very common issue that DBAs face every now and then. Normally standby instance would automatically fetch the required archived logs in case of any gap, but there could be scenarios when missing archived logs cannot be found, restored or fetched. In some scenarios, standby database me be several weeks behind the primary and restoring and applying huge number of archived logs could take very long time. In such case, we can take incremental backup of primary database and restore it on the standby to make in in sync with primary. I will explain this procedure in this article.

ORA-17627: ORA-01017: invalid username/password; logon denied

 If you are doing a duplicate database from active database and commands fails with a combination of ORA-17627: ORA-01017, as follows

RMAN> duplicate target database to dupdb from active database;  Starting Duplicate Db at 23-FEB-18 using target database control file instead of recovery catalog allocated channel: ORA_AUX_DISK_1 channel ORA_AUX_DISK_1: SID=4201 device type=DISK allocated channel: ORA_AUX_DISK_2 channel ORA_AUX_DISK_2: SID=4306 device type=DISK allocated channel: ORA_AUX_DISK_3 channel ORA_AUX_DISK_3: SID=4411 device type=DISK allocated channel: ORA_AUX_DISK_4 channel ORA_AUX_DISK_4: SID=4516 device type=DISK current log archived at primary database