RMAN06820: WARNING: FAILED TO ARCHIVE CURRENT LOG AT PRIMARY

RMAN archivelog backup at the standby site is throws the following errors

Logfile Details:
****************
RMAN06820: WARNING: failed to archive current log at primary database 
ORACLE error from target database:
ORA17629: Cannot connect to the remote database server 
ORA-17627: ORA-00942: table or view does not exist

But the rest of the backup actually complete successfully.

CAUSE:
******
11.2.0.4 onward as per 'unpublished' Bug 8740124, we now include the current standby redo log as part of an RMAN archivelog backup at the standby site. This is achieved by forcing a log switch at the primary site. However, the connection to the primary failed when attempting to do so.
This is due to this bug:
Bug 17580082 ACTIVE STANDBY RMAN06820: WARNING: FAILED TO ARCHIVE CURRENT LOG AT PRIMAR

Workaround:
***********
Do not use operating system authentication to login with RMAN. Use a username and password.
That is, do not use just the "/" (operating system authentication) connect to the standby database:
$ rman target /
Connecting as 'rman target /'
# it gets the sys user but not the password and so, it does NOT mean it is being explicitly specified to connect as sysdba.
Instead put in the username and password for the SYSDBA user:
$ rman target sys/password@stby
Connecting as 'rman target sysdba_user/password@stby'
Note: The password, within the password file, for the primary and standby should be identical.

For more details please look at the Doc ID: 1616074.1


Happy Learning :) 

EM12c Metric Evaluation Error – Supplied date is in the future

After the  Daylight Saving Time we are getting below metric collection errors from some host targets.

Metric Evaluation Error Details:
Host=oraprod
Target type=Database Instance
Target name=PROD
Categories=Error
Message= Row(1): Supplied date is in the future : now = Wed Nov 10 10:39:01 EST 2015 supplied value = Wed Nov 10 11:38:07 EST 2015
Severity=Critical
Event reported time=Nov 10, 2015 10:39:01 AM EST
Contact=Sivaram
Location=Banalore
Comment=DB archive
Department=CRM
Operating System=Linux
Platform=x86_64
Event Type=Metric Evaluation Error
Event name=wait_bottlenecks
Metric Group=Wait Bottlenecks
Collection Name=wait_bottlenecks_10i
Rule Name=CRM Metric Evaluation Error Any Target
Rule Owner=SYSMAN
Update Details:
Row(1): Supplied date is in the future : now = Wed Nov 10 10:39:01 EST 2015 supplied value = Wed Nov 10 11:38:07 EST 2015

Solution:
***********

Clearing and restarting agents on these hosts will fix the problem and it will disappear.
$ ps -ef|grep pmon
oracle   15676     1  0 Jul28 ?        00:15:26 ora_pmon_prod
oracle   20606 20239  0 04:07 pts/0    00:00:00 grep pmon
$ . oraenv
ORACLE_SID = [oracle] ? prod
The Oracle base has been set to /u01/app/oracle

$ ps -ef|grep emagent

oracle    3390 20239  0 04:31 pts/0    00:00:00 grep emagent
oracle    9521     1  0 Jul15 ?        00:02:12 /u01/app/oracle/product/12.1.0.2/core/12.1.0.4.0/perl/bin/perl

$ cd /u01/app/oracle/product/12.1.0.2/core/12.1.0.4.0/bin
$ ./emctl stop agent
$ ./emctl stop agent
$ ./emctl clearstate agent
$ ./emctl start agent
$ ./emctl upload agent

Happy Learning :)

How to modify db_file_name_convert parameter value on standby using DGMGRL

1) Check the value of the db_file_name_convert parameter

SQL> show parameter db_file_name_convert

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert                 string      +P1PROD_DATA/p1prod/datafile/,
    +F1PROD_DATA/f1prod/datafile

2. Change the db_file_name_convert  according to the your requirement in sql prompt
SQL> alter system set db_file_name_convert='+P1PROD_DATA/p1prod/datafile/','+F1PROD_DATA/f1prod/datafile/','+P1PROD_DATA2/p1prod/datafile/','+F1PROD_DATA2/f1prod/datafile/' scope=spfile;

Once you change the parameter value in sql prompt then you need to update the same in DGMGRL prompt other wise  you will get the error for the incosistent properties.

DGMGRL> show database f1prod inconsistentproperties
INCONSISTENT PROPERTIES
   INSTANCE_NAME        PROPERTY_NAME         MEMORY_VALUE         SPFILE_VALUE         BROKER_VALUE
         f1prod    DbFileNameConvert +P1PROD_DATA/p1prod/datafile/, +F1PROD_DATA/f1prod/datafile

DGMGRL> show configuration

Configuration - p1prod_dg

  Protection Mode: MaxPerformance
  Members:
  p1prod - Primary database
    f1prod - Physical standby database
      Warning: ORA-16792: configurable property value is inconsistent with database setting

Fast-Start Failover: DISABLED

Configuration Status:
WARNING   (status updated 37 seconds ago)

DGMGRL> show database f1prod

Database - f1prod

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 1 second ago)
  Apply Lag:          0 seconds (computed 1 second ago)
  Average Apply Rate: 886.00 KByte/s
  Real Time Query:    ON
  Instance(s):
    f1prod
      Warning: ORA-16675: database instance restart required for property value modification to take effect
      Warning: ORA-16714: the value of property DbFileNameConvert is inconsistent with the database setting

Database Status:
WARNING

3) Change the parameter value in DGMGRL prompt

DGMGRL> edit DATABASE "f1prod" SET PROPERTY DbFileNameConvert='+P1PROD_DATA/p1prod/datafile/,+F1PROD_DATA/f1prod/datafile/,+P1PROD_DATA2/p1prod/datafile/,+F1PROD_DATA2/f1prod/datafile/';
Warning: ORA-16675: database instance restart required for property value modification to take effect

Property "dbfilenameconvert" updated

Once you changed the parameter value then you need to restart the database in order to take the modified values to effect.

4) Stop and start the database using SRVCTL

$ srvctl stop database -d f1prod
[oracle@prodora02:/home/oracle f1prod]>
$ srvctl start database -d f1prod
You have new mail in /var/spool/mail/oracle
[oracle@prodora02:/home/oracle f1prod]>
$ srvctl status database -d f1prod
Database is running.

5) Now you can see that the inconsistent properties value is cleared as after database restart the parameter will effected with the new value.

DGMGRL> show configuration

Configuration - p1prod_dg

  Protection Mode: MaxPerformance
  Members:
  p1prod - Primary database
    f1prod - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS   (status updated 48 seconds ago)

DGMGRL> show database f1prod inconsistentproperties
INCONSISTENT PROPERTIES
   INSTANCE_NAME        PROPERTY_NAME         MEMORY_VALUE         SPFILE_VALUE         BROKER_VALUE

Happy Learning :)

Convert Physical Standby to Snapshot Standby and Vice Versa using DGMGRL

Check the below commands output before proceeding at standby server.
$ srvctl status database -d stand
$ srvctl status service -d stand
$ srvctl config database -d stand
$ ./crsctl status res -t

Connect to primary server and perform the below steps this will convert the physical standby to snapshot standby

DGMGRL> show configuration;

Configuration - DG-prod

  Protection Mode: MaxPerformance
  Members:
  prod   - Primary database
    stand - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS   (status updated 23 seconds ago)


DGMGRL> convert database stand to snapshot standby;
Converting database "stand" to a Snapshot Standby database, please wait...
Database "stand" converted successfully
DGMGRL> show configuration;

Configuration - DG-prod

  Protection Mode: MaxPerformance
  Members:
  prod   - Primary database
    stand - Snapshot standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS   (status updated 11 seconds ago)

DGMGRL> show database stand;

Database - stand

  Role:               SNAPSHOT STANDBY
  Transport Lag:      0 seconds (computed 0 seconds ago)
  Apply Lag:          1 minute 18 seconds (computed 0 seconds ago)
  Instance(s):
    stand

Database Status:
SUCCESS

Make sure that you have the enough space for the FRA.
The below query will give the FRA usagae details.
SQL> select name, (space_limit/1024/1024/1024) ||'GB' as Space_Limit, (space_used/1024/1024/1024)||'GB' as Space_Used from v$recovery_file_dest;
SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;

Do your tests on the snapshot standby at this time you can open in read-write mode. Once your work done then convert back to snapshot standby to physical standby.

DGMGRL> convert database stand to physical standby;
Converting database "stand" to a Physical Standby database, please wait...
Database "stand" converted successfully
DGMGRL> show configuration;

Configuration - DG-prod

  Protection Mode: MaxPerformance
  Members:
  prod   - Primary database
    stand - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS   (status updated 23 seconds ago)

Once done please crosscheck the sync status between primary and standby.

*********************Check Sync Status**************************

Primary:
*******
SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)
--------------
        127056

Standby:
*******
SQL> select max(sequence#) from V$archived_log where applied='YES';

MAX(SEQUENCE#)
--------------
        127056

Also check the all the oracle services are running as before the snapshot convert.

$ srvctl status database -d stand
$ srvctl status service -d stand
$ srvctl config database -d stand
$ ./crsctl status res -t

The outputs of the above commands should match with the previous one. If not we need to troubleshoot it.

Happy Learning :)