When trying to run setup I am getting errors on connecting to the database - how do I troubleshoot this?
I am getting the following error when trying to connect to the database:
"The server was unable to connect to the database because the database connection settings are invalid or because the database is unreachable.(SQLSTATE 08006, SQLCODE 17002). Verify the connection settings in the teamserver.properties file.....ID CRJAZ2654E
This is a Windows 2012 r2 Server running WAS 8.5.5.11 connecting to Oracle 11.2.0.4 on Redhat 6.8
Ping works, Firewall is off,
I am getting an SSL handshake error in the JTS log. I tried changing the protocol on WAS from SSL_TLS to SSL_TLSv2 with no luck.
Thank you for your help
Michael
3 answers
Hi Michael There's few reasons that might cause this error.
One of them is the configuration to reach the database isn't correct configured. It can be reviewed in the teamserver.properties. Another commom reason in Oracle databases, is the listener not able to be reached.
You might also verify the listener and try to tnsping the database alias. Check this : https://jazz.net/forum/questions/219268/crjaz2654e-error-when-configuring-database-connection-properties-in-jts-setup-wizard
It might have some helpful information
You may have two issues there, depending on the SSL error is related to Oracle or not.
Check jts.log and ccm.log files, locate the message containing "SQLSTATE 08006, SQLCODE 17002", then go to the bottom of the stack trace and the last "Caused by" should give you some hints about what went wrong.
Only if the Oracle server is SSL enabled (usually it's not unless you have a strong reason to do so), the SSL handshake error should be taken into account for database connection issue.
The SSL setting in WAS affects the (incoming) connection from its clients (browsers and spawned threads). The DB connection is outgoing from WAS' point of view so it is not affected.
You need to look into the details of the SSL handshake error to figure out which application JTS was trying to connect when it failed.
The solution turns out to be a bit easier than expected.
After we shut down iptables (Redhat firewall) for both ipv4 and ipv6 everything started working just fine.
Note to all....The error logs showing the SSL protocol errors led us down the wrong path for a long time. Had lots of people scratching their head over that one.
The key was one individual that just happened to do a telnet to the ip and port. This failed. We had performed multiple pings and got back good connection signal, but it was the telnet that told us that the port was closed.
Thanks to all that offered their solutions!
Michael