Scenario : Setting up a physical standby from Exadata to a non-Exadata single instance. tnsping from standby to primary works fine but tnsping from primary to standby fails with:
TNS-12543: TNS:destination host unreachable
I am able to ssh standby from primary, can ping as well but tnsping doesn’t work. From the error description we can figure out that something is blocking the access. In this case it was iptables that was enabled on the standby server.
Stopping the service resolved the issue.
service iptables stop
chkconfig iptables off
The error is an obvious one but sometimes it just doesn’t strike you that it could be something simple like that.
Hit this silly issue in one of the data guard environments today. Primary is a 2 node RAC running 184.108.40.206 and standby is also a 2 node RAC. Archive logs from node2 aren’t shipping and the error being reported is
ORA-12154: TNS:could not resolve the connect identifier specified
We tried usual things like going to $TNS_ADMIN, checking the entry in tnsnames.ora and then also trying to connect using sqlplus sys@target as sysdba. Everything seemed to be good but logs were not shipping and the same problem was being reported repeatedly. As everything on node1 was working fine so it looked even more weird.
From the error it is clear that the issue is with tnsnames entry. Finally found the issue after some 30 mins. It was an Oracle EBS environment so the TNS_ADMIN was set to the standard $ORACLE_HOME/network/admin/*hostname* path (on both the nodes). On node1 there was no tnsnames.ora file in $ORACLE_HOME/network/admin so it was connecting to the standby using the Apps tnsnames.ora which was having the correct entry for standby. On node2 there was a file called tnsnames.ora in $ORACLE_HOME/network/admin but it was not having any entry for standby. It was trying to connect using that file (the default tns path) and failing with ORA-12154. Once we removed that file, it started using the Apps tnsnames.ora and logs started shipping.
A rather not so great post about an ORA-00600 error i faced on a standby database. Environement was 220.127.116.11 on Sun Super Cluster machine. MRP process was hitting ORA-00600 while trying to apply a specific archive log.
The error message was something like this
MRP0: Background Media Recovery terminated with error 600
Errors in file /u01/app/oracle/product/18.104.22.168/diag/diag/rdbms/xxxprd/xxxprd1/trace/xxxprd1_pr00_6342.trc:
ORA-00600: internal error code, arguments: , , , , , , , , , , , 
Some googling and MOS searches revealed that the error was due to corrupted archive log file. Recopying the archive file from primary and restarting the recovery resolved the issue. The fist argument of the ORA-600 is actually the sequence no of the archive it is trying to apply.
So there is a new toy in the market for database geeks : Oracle has released database 12c. Every social platform is abuzz with the 12c activity. So thought that I should also complete the ritual
In this post Aman has already summed up many important links.
Maria Colgan has posted some useful links here.
And here is a link to a slidedeck about Upgrading and Migrating to 12c.
Happy 12c’ing !