Oracle DataGuard switchiver vs. failover

Switchover is a planned role reversal between primary and standby databases in DataGuard configuration. it guarantees no data loss and is typically done for maintenance. There is no need to re-enable either database when the transition occurs.

Failover is not planned and is typically performed in event of primary database failure event, when there is no possibility of recovering primary database in a timely fashion. When failure occurs, standby database is taking over the primary role. Failover may result in data loss, depending on the protection mode enabled at the time failover occurs.

If a DataGuard broker is enabled, we can automate the failover, however if DataGuard broker is not enabled, we will have to perform manual failover.

If a DataGuard broker cannot detect the heartbeat of the primary DB, it will automatically perform the failover.

ksh: /usr/bin/rm: 0403-027 The parameter list is too long.

Error: ksh: /usr/bin/rm: 0403-027 The parameter list is too long.

Details: This error occurs when attempting to remove old files using rm *.aud

Cause:There are too many files to remove

Solution:Use the following command instead to delete first all files that are older than 5 days:

find /oracle/admin/testP/adump/ -name '*.aud' -mtime +5 -exec rm {} \;

ORA-00119: invalid specification for system parameter LOCAL_LISTENER

Error: ORA-00119: invalid specification for system parameter LOCAL_LISTENER ORA-00132: syntax error or unresolved network name 'LISTENER_'

Details: This error occurs when attempting to start the database

Cause:The lack of a LOCAL_LISTENER, that must be defined in the TNSNAMES.ORA

Solution:In TNSNAMES.ORA (not in LISTENER.ORA) define the following entry for the local listener:

LISTENER_ =  (ADDRESS = (PROTOCOL = TCP)(HOST = servername)(PORT = 1521)) 

sp2-1503 unable to initialize oracle call interface

Error: sp2-1503 unable to initialize oracle call interface

Details: This error occurs when attempting to start sqlplus

Cause:PATH variable is not set correctly

Solution:Set and export PATH variable

export PATH=$ORACLE_HOME/bin:$PATH

TNS-03505: Failed to resolve name

Error: TNS-03505: Failed to resolve name

Details: This error occurs when doing tnsping DBName

Cause:ORACLE_HOME and/or PATH variables are not set correctly

Solution:Set and export both correct ORACLE_HOME and PATH

export ORACLE_HOME=/u01/app/oracle/product/11.2.0/client_1
export PATH=$PATH:$ORACLE_HOME/bin

ORA-12514: TNS:listener does not currently know of service

Error: ORA-12514: TNS:listener does not currently know of service

Possible Cause:The database might not have been registered with a listener

Diagnosing the error:The following things should eb done to diagnoze the error

1. Check what listener is running:

   > lsnrctl status
   

2. Check LOCAL_LISTENER parameter

   SQL> show parameter local_listener
   

   Usually it is blank by default and thus at startup the database is dynamically registered with the listener that is currently running. If LOCAL_LISTENER does have a value, then it means that database is trying to register with the configuration of the listener listed in LOCAL_LISTENER

Possible Solution:Clearing the value of LOCAL_LISTENER:

SQL> alter system set local_listener='';
SQL>lsnrctl reload

or

SQL> alter system set local_listener='' scope=both sid='*';
SQL>lsnrctl reload

RMAN-20001: target database not found in recovery catalog

Error: RMAN-20001: target database not found in recovery catalog

Details: This error occurs when attempting to backup the newly cloned database using RMAN

Cause:The database was not registered with recovery catalog.

Solution:Register the database with recovery catalog by performing the following steps:

1. Set the environment to your target database:

   > . oraenv
   > DBName
   

2. Connect to RMAN:

   > rman target /
   

3. Connect to catalog as rman user:

   RMAN> connect catalog rmanuser/pwd@RMANDB
   

4. Register target database:

   RMAN> register database;
   

The output will be:

database registered in recovery catalog
starting full resync of recovery catalog
full resync complete

Note: The database you are registering must not be a standby database, since standby database gets registered automatically whenever primary database is registered. Also the database must not be already registered in the recovery catalog. List of databases in recovery catalog can be retrieved byt loging in to RMAN repository and runnning:

select name, dbid from rc_database
where name=@DB_SID;