EM12c agent deployment fails with agent port passed by user is busy...

EM12c agent deployment fails with "ERROR: Agent Configuration Failed SEVERE: Agent port passed by user is busy and cannot proceed with the configuration. Pass a free port and retry the configuration.”
netstat -an doesnt show the port being in use and rerun of the deployment fails consistently with the same error.

In the end, it's the hostname mismatch issue where the hostname in '/etc/hosts' file is different to what's configured in '/etc/sysconfig/network'.

Once that's fixed by updating the entry in the network file, agent deployment succeeded.

This is another error that's not straight forward to resolve as nowhere as it gives an indication that there's a hostname conflict.

rconfig fails with ORA-25152: TEMPFILE cannot be dropped at this time

Was doing a single instance db to RAC conversion on a 11.2.0.3 cluster using rconfig and the process fails with ORA-25152 during "Setting TEMP tablespace" step.
Verified if the temp segments are in use but no processes are accessing.
The fix that finally worked is 

• drop the tempfile using 'alter database tempfile 'xxx/temp01.dbf' drop including datafiles;
• run rconfig and it worked fine this time
• add tempfile back using 'alter tablespace temp add tempfile size 4000M;

Did notice a few bug reports on Metalink however there's no workaround available so the above should do the trick if you happen run into this issue.

Connecting to RAC 11gR2 SCAN using SQLDeveloper

Here are a few options to connect to a 11gR2 RAC Database (using SCAN address) using SQLDeveloper, couldn't find this info handy anywhere so thought of posting it which could be of some help to developers/DBA's out there.

11gR2 RAC Connection to SCAN Hostname using JDBC Option

11gR2 RAC Connection to SCAN Hostname using SERVICE Name Option

11gR2 RAC Connection to SCAN Hostname using TNSNAMES Option

11gR2 Uninstall aka Deinstall procedure

Uninstall procedure has changed in 11gR2 and it's not the traditional OUI based uninstall anymore.

Oracle binaries include 'deinstall' utility which is by default available under $ORACLE_HOME/deinstall directory.
However it's recommended to download the latest one from OTN website which comes as a separate utility.

That's available under the 'see all' page of  http://bit.ly/bxzTd3 for your platform.


Once downloaded, it can be unzipped at a temporary location and can be used as below.

There's a checkonly option which checks the status of the Oracle software home configuration and recommended to run prior to actually removing the software.
Of course, it's always recommended to backup the binaries and inventory anyway.

./deinstall   -home   /u00/app/oracle/product/11.2.0/dbhome_1    -checkonly


Once the above runs successfully, run the command without the -checkonly option

./deinstall   -home   /u00/app/oracle/product/11.2.0/dbhome_1

and it cleanly removes the software and inventory entries which allows you perform another clean installation again!

However one issue here....the deinstall utility prompts for the listener (you cant avoid that) and it can stop the listener process and delete the listener.ora even if the listener is running from a different ORACLE_HOME and this can be an issue in a multi home environment.

The workaround for this at the moment is to "unset TNS_ADMIN" as per Metalink Note.1067622.1.

dblink and case sensitive logon

Was trying to setup a simple db link between a 10gR2(10.2.0.3) db and a 11gR2 db and the select query fails with 

SQL> select sysdate from dual@linka;

select sysdate from dual@linka

                         *

ERROR at line 1:

ORA-01017: invalid username/password; logon denied

ORA-02063: preceding line from LINKA

The credentials work fine on the target 11g db from sqlplus, so no typo issue.

A quick fix that worked is to enclose the db link password in "double quotes".

So the solution is to 

• drop the db link
• recreate using 'create database link LINKA connect to username identified by "xxxx" using 'connect string';

and the select query worked just fine.

A quick search on metalink revealed (note:473716.1) this behaviour is due to the case sensitive logon feature enabled on the 11g side using SEC_CASE_SENSITIVE_LOGON parameter set to TRUE.