Oracle ERP DBA

In the last post, I had talked about the pitfalls in configuring PCP in non-RAC instances. I have figured out (is it really the solution? - only time will tell!) workarounds for the 2 pitfalls that I had listed. 1. How would the VNC server failover when using PCP with non-RAC? Ans: The best bet would be to start the vnc server using the virtual hostname instead of the physical hostname (thanks to my colleague Mansoor who suggested it). Once the VNC is started using the virtual hostname, set the display variable to this value and run autoconfig so that the changes are reflected in the concurrent manager and the report server startup scripts. So, when the VIP (and hence, the virtual host) fails over, the VNC would still be running. This solution needs to be tested thoroughly though. Below is the command that I can use: $ vncserver -name <VIRTUAL_HOSTNAME>:<PORT_NUMBER> 2. The web tier 806_ORACLE_HOME tnsnames.ora can be modified to include the FNDFS_<PHYSICAL_HOSTNAME>

It was a wonderful surprise when I stumbled upon Metalink Note ID: 743716.1 , which details steps for configuring PCP in non-RAC instances. This is very useful while using hardware or software clustering and not Oracle clustering (RAC). We are using Veritas clustering (software clustering) for server failover. We were recently testing server failover and there are two things that I am unable to figure out as of now and which necessitates manual intervention rendering the whole failover mechanism manual: 1. How would the VNC server failover when using PCP with non-RAC? Since, the hostname changes when the failover happens, the display variable would still be pointing to the failed server and not the failover server. The work around to the above problem is obviously to reset the display variable and run autoconfig, which would mean that the failover mechanism is no longer automatic. 2. As soon as the failover happens, we need to make a manual entry in the Web Tier $TNS_ADMIN/tnsnames.ora