Automic Workload Automation

ORA-12514 error when starting JWP/JCP

  • 1.  ORA-12514 error when starting JWP/JCP

    Posted Aug 27, 2018 11:24 AM

    Recently I’ve seen intermittent errors when trying to start the Java-based AE server processes: the Java Work Processes (JWPs) and the Java Communication Processes (JCPs).

    20180827/093004.702 - 26     U00011849 UC4_sys_info: 'UC4 Version 12.2.0+build.7805'
    20180827/093004.703 - 26     U00011849 UC4_sys_info: 'BuildTimestamp 2018-06-26 15:45:58'
    20180827/093004.703 - 26     U00011849 UC4_sys_info: 'Buildnr: 0000007805  Changelist: 1530020723'
    20180827/093004.764 - 26     U00003545 UCUDB: Opening database ...
    20180827/093004.903 - 26     U00003611 DB OPEN executed. Return Code = '12514'
    20180827/093004.904 - 26     U00003590 UCUDB - DB error: '08006', 'Listener refused the connection with the following error:
    20180827/093004.904 - 26     ORA-12514, TNS:listener does not currently know of service requested in connect descriptor
    20180827/093004.904 - 26      ', '12514', 'java.sql.SQLRecoverableException'
    20180827/093004.906 - 26     U00032031 Error when connecting to Database

    The DB is running on a two-node cluster, and at any given time, the DB may be running on either node in the cluster.I spoke with our Oracle DBAs and discovered that the reasons for the errors was that maintenance was being performed on the DB servers. During the maintenance windows, the one undergoing maintenance node was marked STAND BY and READ ONLY.

     

    Normally, I would use an LDAP-based connection string to handle this sort of situation; but unfortunately, ucsrvjp does not support LDAP-based connection strings. (If you, like me, think it should, please vote for this idea: JWP should support LDAP-based Oracle JDBC strings in ucsrv.ini.)

     

    Because of this limitation, I have to hard-code one of the cluster node names into the JDBC connection string for the JWP & JCP. When I have seen the error above, I have so far been able to work around it by switching to the other node in the cluster. However, this requires manual intervention, and although I can request to be informed ahead of time of planned DB maintenance activities, there’s no way to be know about unplanned outages in advance.

     

    Absent a fix from CA, can anyone recommend another way to resolve this problem?