Friday, May 16, 2014

JDBC and CMAN and a new location for the database

I had an interesting issue this week.

The setup is as follows:

WLS with Webcenter. The Datasource point to a database for the metadata. This database sits in the database zone. As we are not allowed to connect directly to the database there is a CMAN in between.
After the setup of the CMAN and the database we had a connection using JDBC where the CMAN was our endpoint.

So far so good.

Now the IT department decided (a long time ago) to move a number of databases from one platform to another. As this meant a change in the IP and name of the database we expected that the only configuration that was needed to change was the CMAN.

Database moved, CMAN config adapted and voila: nothing works!

First test was to use the console and test the JDBC connection. Error was a

ORA-12514 TNS:listener does not currently know of service requested in connect descriptor.


This in itself was strange as from the WLS/Webcenter perspective nothing did change. Endpoint was still the CMAN, SID did not change after the move.

Second test was to see if the connection from the WLS machine to the CMAN was still OK. As there was no Oracle client on the system I just used a telnet connection to the assigned CMAN port. Perfect result: the connection was open, so something was listening on the machine on the given port. As I am positive that this machine only harbors a CMAN I was happy.

Third check - going to the CMAN folks and see if the connection from the CMAN to the DB was OK.
Worked like a charm. Config looked perfect to. 

Now this became a kind of a puzzle.

I went back to the WLS Admin console and restarted the JDBC connection. Still the same error.

I tried to change some settings in the JDBC settings but no avail.

Just for the fun of it I created a new JDBC connection pointing to the same CMAN endpoint with absolutely the same settings as before. Assigned the new JDBC datasource to a managed server (actually the cluster) and hit the test button. Now everything was the same as before but the name. It worked. Hooray!!!

As we had a number of datasources with some of them having names that are used inside the applications it seemed like a tedious idea to drop the datasources and recreate them. I did this for one cluster and it worked but I was a little bit too lazy to do this for all of them.

Then I tried something else. I went to a managed server of another domain and restarted it.
When it came back - which surprised me with a "broken" datasource - I went to the datasource and tested it again. Immediately the test can back without an error.

Trying another one - same result.
So obviously I restarted all MS (and the AS as they need db access as well). 

I wanted to let you know this as such a setting can impact your MAA environment when you change the endpoint of a database behind a CMAN.