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