Sunday, December 27, 2015

Running a Command or Script in the Background on Linux

Many times we (DBAs) are in a situation when we need to run some command or script from the command prompt on the Linux, and during command/script execution; we face disconnection of session and our process stops in the middle leaving a lot of mess for us to clear. To avoid this kind of situation, it is advised to execute long running scripts or commands in the background using Linux “nohup” command. In the following example, I have a script “recovery.sh” that contains RMAN commands to restore and recover a huge database on a server, so I would execute this script in background as follows
$ nohup ./recovery.sh &

Immediately after executing this command, my session would return to the command prompt, and my script would keep executing in the background. A file “nohup.out” would get created in the current directory that will contain all the output returned by the script. We can monitor the progress by using “tail” command on this output file
$ tail –f nohup.out

Likewise, if I am applying a patch using opatch, I can run command in the background as follows
[root@myserver]# nohup opatch apply &

Note that if we are running a command/script that needs an input during its execution, above example would not work for that because using nohup in above fashion does not return any prompt to get any input from the user.

Friday, December 25, 2015

Using scp command on Linux to copy Files and Directories

DBAs need to move files from one host to the other in Linux environment. In this article, I would explain how to use scp (secure copy) command to copy files or directories from one host to the other.
Currently I am on 192.168.20.20 (MYDBSERVER is the hostname in this case) and I have a file /u01/oracle.tar on second host 192.168.20.30 that I want to transfer to /u01 on my current host, 192.168.20.20. On current host I am connected as user “salman” and “oracle” is the user on remote host 192.168.20.30 that I will use to connect to remote host for this copy operation.
[salman@MYDBSERVER /] cd /u01
[salman@MYDBSERVER u01]$  scp oracle@192.168.20.30:/u01/oracle.tar /u01/
The authenticity of host '192.168.20.30 (192.168.20.30)' can't be established.
RSA key fingerprint is ce:dd:13:2d:ac:96:a1:cd:52:9e:f3:b4:03:ea:2d:25.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.20.30 ‘(RSA) to the list of k//nown hosts.
oracle@192.168.20.30's password:
oracle.tar                                                                                                                            100% 3268MB  26.4MB/s   02:04

To copy whole directory, use –r option. In the following example, I will copy wole directory /u01/backup from 192.168.20.30 to the current directory (/u01) on current host 192.168.20.20. to specify current directory on current server, use “.”.
[salman@MYDBSERVER u01]$  scp -r oracle@192.168.20.30:/u01/backup  .


Sunday, December 13, 2015

ORA-19909: datafile 1 belongs to an orphan incarnation

Your MRP (Managed Recovery Process) may stop on your standby database with ORA-19909 error as can be seen in bellow excerpt from alert log file

Warning: Recovery target destination is in a sibling branch
of the controlfile checkpoint. Recovery will only recover
changes to datafiles.
Datafile 1 (ckpscn 8706894683401) is orphaned on incarnation#=1
MRP0: Background Media Recovery terminated with error 19909
Thu Apr 23 05:19:18 2015
Errors in file d:\oracle\1020\admin\prodb\bdump\proddb_mrp0_134344.trc:
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: '+DATA/oradata/proddb/system01.dbf'

Thu Apr 23 05:19:18 2015
Managed Standby Recovery not using Real Time Apply
Thu Apr 23 05:19:19 2015
Errors in file d:\oracle\1020\admin\proddb\bdump\proddb_mrp0_134344.trc:
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: '+DATA/oradata/proddb/system01.dbf'

Thu Apr 23 05:23:01 2015
SUCCESS: diskgroup ARCHDG was mounted
Thu Apr 23 05:23:01 2015
Primary database is in MAXIMUM PERFORMANCE mode

This error can have different reasons. In my case, I performed a test failover physical standby database and then revert it back to physical standby, but I missed a step during converting the database back to physical standby – the step was to execute command “ALTER DATABASE CONVERT TO PHYSICAL STANDBY”

Solution is to reset the incarnation of standby database to same as primary. You can use “list incarnation of database” command on primary to find out current incarnation of primary database and then follow the following steps to reset standby database’s incarnation to same as primary.
C:\Users\Administrator>rman

Recovery Manager: Release 10.2.0.4.0 - Production on Thu Apr 23 09:19:13 2015

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

RMAN> connect target /

connected to target database: PRODDB (DBID=2441588677, not open)

RMAN> list incarnation of database;

using target database control file instead of recovery catalog

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       PRODDB    2441588677       PARENT  1          14-MAY-11
4       4       PRODDB    2441588677       ORPHAN  8702580384129 06-MAR-15
5       5       PRODDB    2441588677       ORPHAN  8702775998686 09-MAR-15
3       3       PRODDB    2441588677       ORPHAN  8702881829269 10-MAR-15
2       2       PRODDB    2441588677       CURRENT 8706832322629 22-APR-15

RMAN> reset database to incarnation 1;

database reset to incarnation 1

RMAN> list incarnation of database;


List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       PRODDB    2441588677       CURRENT 1          14-MAY-11
4       4       PRODDB    2441588677       ORPHAN  8702580384129 06-MAR-15
5       5       PRODDB    2441588677       ORPHAN  8702775998686 09-MAR-15
3       3       PRODDB    2441588677       ORPHAN  8702881829269 10-MAR-15
2       2       PRODDB    2441588677       ORPHAN  8706832322629 22-APR-15


 Once done, MRP process started working fine again and started applying redo logs to the standby database.

Tuesday, December 8, 2015

ORA-17627 and ORA-12154 Returned by RMAN Duplicate Command

During RMAN DUPLICATE command, you might face this error message returned by RMAN.
C:\Users\administrator>rman target sys/pass11g@pri auxiliary sys/pass11g@aux

Recovery Manager: Release 11.2.0.3.0 - Production on Wed Sep 9 12:35:18 2015

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: PROD (DBID=3343192461)
connected to auxiliary database: STBY (not mounted)

RMAN>  duplicate target database for standby from active database;

Starting Duplicate Db at 09-SEP-15
using channel ORA_AUX_DISK_1

contents of Memory Script:
{
   backup as copy reuse
   targetfile  'd:\oracle\11203\DB\DATABASE\PWDprod1.ORA' auxiliary format
 'd:\oracle\11203\DB\DATABASE\PWDprod2.ORA'   ;
}
executing Memory Script

Starting backup at 09-SEP-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=695 instance=opera1 device type=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 09/09/2015 12:41:29
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 09/09/2015 12:41:28
ORA-17629: Cannot connect to the remote database server
ORA-17627: ORA-12154: TNS:could not resolve the connect identifier specified
ORA-17629: Cannot connect to the remote database server


It actually means that TNS service at the primary database host is not properly configured to connect with the AUXTILIARY database specified in the connect string in above command block (C:\Users\administrator>rman target sys/pass11g@pri auxiliary sys/pass11g@aux). You should make sure that “aux” TNS service is properly configured at the primary site and you can connect with the auxiliary instance using this TNS service. For further details on. error ORA-12154, see this document

ORA-12154 and TNS-03505

You may receive error “ORA-12154: TNS:could not resolve the connect identifier specified” while trying to connect with the database, and also “TNS-03505: Failed to resolve name” while using TNSPING to test the connection. Reasons for both of these error is that you have not created TNS service correctly
  • Make sure that TNS_ADMIN is pointing to the correct network directories.
  • Make sure that TNSNAMES is selected in NAMES.DIRECTORY_PATH parameter in SQLNET.ORA file
  • Make sure that service name you are using to connect to the database is being spelt correct in the connect string
  • If you have specified NAMES.DEFAULT_DOMAIN parameter with the domain name, make sure that TNS service is using this domain name as part of its name. For example if NAMES.DEFAULT_DOMAIN is set to WORLD, your TNS service should look like MYDBTNS.WORLD, and to connect to the database using this TNS, you can use wither @MYDBTNS or @MYDBTNS.WORLD.
  • If you have not specified NAMES.DEFAULT_DOMAIN; yet you created your TNS service with domain name i.e. MYDBTNS.WORLD, then you must use full TNS service name in your connect string i.e. @MYDBTNS.WORLD.

Wednesday, December 2, 2015

Creating ASM Diskgroups

In this article I would explain how to create new ASM diskgroups. I used Grid Infrastructure 12.1.0.1 on Oracle Linux 6 for this article, but process is same for other Unix based platforms or Windows systems, and also for other Oracle versions (10g, 11g).
Before we move forward, you may have a look at my articles related to
stamping ASM disks on windows and creating ASM disks using ASMLib on Linux to know how we create disks which are used for ASM diskgroups.
Log into the system as Grid Infrastructure software owner (ORA_DBA OS group member on Windows), and connect to the ASM instance as SYSASM user
[grid@salman1 ~]$ sqlplus /nolog

SQL*Plus: Release 12.1.0.1.0 Production on Wed Dec 2 14:21:25 2015

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

SQL> conn sys as sysasm
Enter password:
Connected.
SQL>

Query v$asm_disk to list all available disks that can be used to create a diskgroup.
SQL> select path,header_status,state,os_mb from v$asm_disk;

PATH                 HEADER_STATU      STATE              OS_MB
-------------------- ------------ -------- ----------     ---------------------------
ORCL:DISK5           FORMER              NORMAL         4094
ORCL:DISK1           FORMER              NORMAL         4094
ORCL:DISK2           FORMER              NORMAL         4094
ORCL:DISK10         PROVISIONED  NORMAL         4094
ORCL:DISK4           FORMER              NORMAL         4094
ORCL:DISK8           FORMER              NORMAL         4094
ORCL:DISK6           FORMER              NORMAL         4094
ORCL:DISK3           FORMER              NORMAL         4094
ORCL:DISK7           FORMER              NORMAL         4094
ORCL:DISK9           FORMER              NORMAL         4094

We see here total 10 disks having 4G size each (these are virtual disks on my virtual machine). Header status is FORMER if this disk was already part of a diskgroup, and PROVISIONED if this is a new disk.
External Redundancy Diskgroup
Now we create an ASM disk group with external redundancy which means that mirroring will not be done at ASM level. We create diskgroups with external redundancy if we are handling mirroring at RAID level for fault tolerance.

CREATE DISKGROUP DATA EXTERNAL REDUNDANCY DISK 'ORCL:DISK1', 'ORCL:DISK2'
ATTRIBUTE 'compatible.asm' = '12.1.0.1', 'compatible.rdbms' = '11.2.0.3';

SQL> select group_number,name,type,total_mb from v$asm_diskgroup;

GROUP_NUMBER NAME                           TYPE             TOTAL_MB
------------ ------------------------------ ------ ----------------------------------------
           2 DATA                                               EXTERN       8188
compatible.asm attributes specifies the diskgroup compatibility with the ASM version. compatible.asm=12.1.0.1 would mean that we can utilize all the ASM options introduced in 12.1.0.2. compatible.rdbms is used to specify the version of database that can be stored in this diskgroup.
lsdg command of ASMCMD can also be used to see the information of the diskgroup.
[grid@salman1 ~]$ asmcmd
ASMCMD> lsdg data
State               Type         Rebal   Sector  Block    AU             Total_MB    Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name
MOUNTED   EXTERN  N         512      4096      1048576     8188             8132          0                             8132                      0                      N                   DATA/

Failure Groups in Normal or High Redundancy Diskgroups
We specify failure groups while creating a diskgroup. If we don’t specify failure groups then each disk would be in its own failure group. For example if we create a normal redundancy diskgroup with 10 disks and don’t specify any failure groups; each disk would be in its own failure group, and 2 copies of each ASM extent (not database extent) would be maintained on any 2 different disks. In case of High Redundancy Diskgroup, 3 copies would be maintained on 3 different disks.
If we specify failure groups; suppose 5 disks in failuregroup1 and 5 disks in failuregroup2, one copy of ASM extent would be on any of the 5 disks in failuregroup1 and second copy would be on any disk in failuregroup2.
Usually we group disks together in a failure group that have tendency of failing together. For example if we have 2 disk controllers having 5 disks each, we would like to group disks in controller 1 together in failure group 1 and disks in controller 2 together in failure group 2. This way there will be 2 mirrored copies of each ASM extent are maintained on different disk controller’s disks. If controller 1 fails and all disks are not accessible, second copy of ASM extent would remain accessible from other failure group that is on controller 2 

Normal Redundancy Diskgroup
In a diskgroup with normal redundancy; 2 copies of each ASM extent (not database extent) are maintained on 2 different disks in 2 different failure groups. Normal redundancy diskgroup requires at least 2 failure groups.
CREATE DISKGROUP DATA NORMAL REDUNDANCY DISK 'ORCL:DISK1', 'ORCL:DISK2'
ATTRIBUTE 'compatible.asm' = '12.1.0.1', 'compatible.rdbms' = '11.2.0.3';

High Redundancy Diskgroup
In a diskgroup with high redundancy; 3 copies of each ASM extent (not database extent) are maintained on 3 different disks in 3 different failure groups. High redundancy diskgroup requires at least 3 failure groups.

create diskgroup data high redundancy failgroup failuregroup1 disk 'ORCL:DISK1','ORCL:DISK2','ORCL:DISK3'
failgroup failuregroup2 disk 'ORCL:DISK4','ORCL:DISK5','ORCL:DISK6'
failgroup failuregroup3 disk 'ORCL:DISK7','ORCL:DISK8','ORCL:DISK9' ;

Thursday, November 26, 2015

ORA-00354: corrupt redo log block header

If you see ORA-00354 in your alert log file, as can be seen bellow
Tue Nov 24 14:36:25 2015
Thread 1 cannot allocate new log, sequence 16492
Private strand flush not complete
  Current log# 9 seq# 16491 mem# 0: D:\ORACLE\ORADATA\MYDB\REDO9_01.RDO
Thread 1 advanced to log sequence 16492
  Current log# 6 seq# 16492 mem# 0: D:\ORACLE\ORADATA\MYDB\REDO6_01.RDO
Tue Nov 24 14:36:27 2015
ARCH: Archival stopped, error occurred. Will continue retrying
Tue Nov 24 14:36:27 2015
Errors in file d:\oracle\admin\MYDB\bdump\MYDB_arc0_3148.trc:
ORA-16014: log 3 sequence# 16454 not archived, no available destinations
ORA-00312: online log 3 thread 1: 'D:\ORACLE\ORADATA\MYDB\REDO3_01.RDO'

Tue Nov 24 14:37:30 2015
Thread 1 cannot allocate new log, sequence 16493
Private strand flush not complete
  Current log# 6 seq# 16492 mem# 0: D:\ORACLE\ORADATA\MYDB\REDO6_01.RDO
Thread 1 advanced to log sequence 16493
  Current log# 4 seq# 16493 mem# 0: D:\ORACLE\ORADATA\MYDB\REDO4_01.RDO
Tue Nov 24 14:37:55 2015
ARC1: Log corruption near block 132988 change 521383134 time ?
Tue Nov 24 14:37:55 2015
Errors in file d:\oracle\admin\MYDB\bdump\MYDB_arc1_6612.trc:
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 132988 change 521383134 time 11/17/2015 04:06:08
ORA-00312: online log 3 thread 1: 'D:\ORACLE\ORADATA\MYDB\REDO3_01.RDO'

ARC1: All Archive destinations made inactive due to error 354
ARCH: Archival stopped, error occurred. Will continue retrying
Tue Nov 24 14:37:55 2015
Errors in file d:\oracle\admin\MYDB\bdump\MYDB_arc1_6612.trc:
ORA-16038: log 3 sequence# 16454 cannot be archived
ORA-00354: corrupt redo log block header
ORA-00312: online log 3 thread 1: 'D:\ORACLE\ORADATA\MYDB\REDO3_01.RDO'

Trace file as highlighted above might look similar to the following.
kcrrfail: dest:1 err:354 force:0 blast:1
*** 2015-11-24 14:33:55.237 20216 kcrr.c
ORA-16038: log 3 sequence# 16454 cannot be archived
ORA-00354: corrupt redo log block header
ORA-00312: online log 3 thread 1: 'D:\ORACLE\ORADATA\MYDB\REDO3_01.RDO'
*** 2015-11-24 14:35:55.237
*** 2015-11-24 14:35:55.237 60653 kcrr.c
ARC1: Log corruption near block 132988 change 521383134 time ?
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 132988 change 521383134 time 11/17/2015 04:06:08
ORA-00312: online log 3 thread 1: 'D:\ORACLE\ORADATA\MYDB\REDO3_01.RDO'
*** 2015-11-24 14:35:55.237 60653 kcrr.c
ARC1: All Archive destinations made inactive due to error 354
*** 2015-11-24 14:35:55.237 58915 kcrr.c
kcrrfail: dest:1 err:354 force:0 blast:1
*** 2015-11-24 14:35:55.253 20216 kcrr.c
ORA-16038: log 3 sequence# 16454 cannot be archived
ORA-00354: corrupt redo log block header
ORA-00312: online log 3 thread 1: 'D:\ORACLE\ORADATA\MYDB\REDO3_01.RDO'
*** 2015-11-24 14:36:55.128
*** 2015-11-24 14:36:55.128 20216 kcrr.c
*** 2015-11-24 14:37:55.253
*** 2015-11-24 14:37:55.253 60653 kcrr.c
ARC1: Log corruption near block 132988 change 521383134 time ?
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 132988 change 521383134 time 11/17/2015 04:06:08
ORA-00312: online log 3 thread 1: 'D:\ORACLE\ORADATA\MYDB\REDO3_01.RDO'
*** 2015-11-24 14:37:55.253 60653 kcrr.c
ARC1: All Archive destinations made inactive due to error 354
*** 2015-11-24 14:37:55.253 58915 kcrr.c
kcrrfail: dest:1 err:354 force:0 blast:1
*** 2015-11-24 14:37:55.268 20216 kcrr.c
ORA-16038: log 3 sequence# 16454 cannot be archived
ORA-00354: corrupt redo log block header
ORA-00312: online log 3 thread 1: 'D:\ORACLE\ORADATA\MYDB\REDO3_01.RDO'
*** 2015-11-24 14:39:55.268
*** 2015-11-24 14:39:55.268 60653 kcrr.c
ARC1: Log corruption near block 132988 change 521383134 time ?
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 132988 change 521383134 time 11/17/2015 04:06:08
ORA-00312: online log 3 thread 1: 'D:\ORACLE\ORADATA\MYDB\REDO3_01.RDO'
*** 2015-11-24 14:39:55.268 60653 kcrr.c
ARC1: All Archive destinations made inactive due to error 354
*** 2015-11-24 14:39:55.268 58915 kcrr.c
kcrrfail: dest:1 err:354 force:0 blast:1
*** 2015-11-24 14:39:55.284 20216 kcrr.c
ORA-16038: log 3 sequence# 16454 cannot be archived
ORA-00354: corrupt redo log block header
ORA-00312: online log 3 thread 1: 'D:\ORACLE\ORADATA\MYDB\REDO3_01.RDO'

It clearly means that there is corruption in the redo log file belonging to group 3. Although current log sequence number is 16492, but sequence number 16454 has not been archived because only member of log group 3 is corrupt and hence cannot be archived. Following query also confirms that sequence 16454 has not been archived.
SQL> SELECT sequence#, name FROM V$ARCHIVED_LOG ORDER BY 1;
SEQUENCE# NAME
---------- ------------------------------------------------------------------------------
     16452 D:\ORACLE\ADMIN\MYDB\ARCHIVE\MYDBT001S164520609542238.ARC
     16453 D:\ORACLE\ADMIN\MYDB\ARCHIVE\MYDBT001S164530609542238.ARC
--MISSING SEQUENCE 16445
     16455 D:\ORACLE\ADMIN\MYDB\ARCHIVE\MYDBT001S164550609542238.ARC
     16456 D:\ORACLE\ADMIN\MYDB\ARCHIVE\MYDBT001S164560609542238.ARC
     16482 D:\ORACLE\ADMIN\MYDB\ARCHIVE\MYDBT001S164820609542238.ARC
     16483 D:\ORACLE\ADMIN\MYDB\ARCHIVE\MYDBT001S164830609542238.ARC
     16484 D:\ORACLE\ADMIN\MYDB\ARCHIVE\MYDBT001S164840609542238.ARC
     16485 D:\ORACLE\ADMIN\MYDB\ARCHIVE\MYDBT001S164850609542238.ARC
     16486 D:\ORACLE\ADMIN\MYDB\ARCHIVE\MYDBT001S164860609542238.ARC
     16487 D:\ORACLE\ADMIN\MYDB\ARCHIVE\MYDBT001S164870609542238.ARC


Cause
This issue could be caused by storage or hardware issue causing redo logs to be corrupted. have a thorough check of the hardware and storage. OS logs may or may not show issues with the hardware or storage for this scenario.

Solution
You should always have multiple redo log member in each redo log group so that if one logfile member is corrupt, other member could be used to archive the log data. For this scenario since there is only one member, the solution is to clear this redo log file group so that it can be re-used again.
SQL> alter database clear unarchived logfile group 2;

Database altered.

Important Note: Take full database backup immediately after clearing the redo log group because archived log for sequence 16454 is not available because of redo log corruption and recovery would not be possible if a medial failure occurs at this point.

Sunday, November 22, 2015

RMAN-00600: internal error, arguments [9222] [] [] [] []

I faced following error message while creating a standby database from live database using RMAN DUPLICATE command.

C:\Users\administrator>rman target sys/pass11g@pri auxiliary sys/pass11g@aux

Recovery Manager: Release 11.2.0.3.0 - Production on Wed Sep 9 12:35:18 2015

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: PROD (DBID=3343192461)
connected to auxiliary database: STBY (not mounted)

RMAN> run{
2>  allocate channel c1 type disk;
3>  allocate auxiliary channel standby-db type disk;
4>  duplicate target database for standby from active database;
5>  }

using target database control file instead of recovery catalog
allocated channel: c1
channel c1: SID=695 instance=prod1 device type=DISK

allocated channel: standby-db
channel standby-db: SID=465 instance=prod2 device type=DISK

Starting Duplicate Db at 09-SEP-15

contents of Memory Script:
{
   backup as copy reuse
   ;
released channel: c1
released channel: stby
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 09/09/2015 12:35:46
RMAN-05501: aborting duplication of target database
RMAN-00600: internal error, arguments [9222] [] [] [] []
RMAN-01009: syntax error: found ";": expecting one of: "archivelog, as, auxiliary, backupset, backup, channel, check, controlfilecopy, copies, copy, cumulative, current, database, datafilecopy, datafile, db_file_name_convert, db_recovery_file_dest, device, diskratio, duration, filesperset, force, f
RMAN-01007: at line 3 column 4 file: Memory Script

Solution
For standby database to work properly and connect with the primary (and primary to connect with the standby), password file of primary needs to be copied to the standby database host. In my case, I forgot to do this before executing DUPLICATE command “FROM ACTIVE DATABASE”. After copying password file, my duplicate command executed successfully.



Sunday, November 15, 2015

RMAN-05001 auxiliary filename string conflicts with a file used by the target database

If this error message is being returned during RMANDUPLICATE DATABASE command, it is because RMAN would try to created destination files at the same location where source database files exist; and since it cannot overwrite existing files, so it and returns error message. To avoid this error, NOFILENAME check option should be used with DUPLICATE command. Otherwise use one of the following to specify different file names
  • Use DB_FILE_NAME_CONVERT init parameter
  • Use DB_FILE_NAME_CONVERT option in DUPLICATE command
  • SET NEWNAME  for each datafile in the RMAN run block with DUPLICATE command



Wednesday, November 11, 2015

Heartbeat failed to connect to standby

If Primary database alert log is showing error message similar to the following,
PING[ARC1]: Heartbeat failed to connect to standby 'standby-db'. Error is 16058.
it means that primary database is not able to ship redo log data to standby database because standby database instance is not mounted; which is required for shipping the redo log data to standby site.
To avoid this error and keep standby in-sync with primary, make sure that standby database instance is in mount state and is accessible from the primary database.