After a password change for database access test connections were failing in the Websphere 6.1 WAS DMGR.
We then changed the password in the jdbc lookup properties and test connection succeded but in the systemout logs we still are getting invalid logon exception. Is it possible that we have to restart the server everytime we do some changes in the data source properties?
Related
I have been trying to establish a connection to use ORDS and was successful once, but now I am receiving a 404 error when I try to connect to my database on ORDS.
When I first log onto http://127.0.0.1:1521/ords/sql-developer, I receive the following messages:
The service is disabled in this environment
Stack Trace
DisabledException [statusCode=404, reasons=[The service is disabled in this environment]]
This is what I've tried:
java -Doracle.net.tns_admin=C:\Users\ip4169\Desktop\ORDS\ords -jar ords.war validate
-> Completed validating Oracle REST Data Services version 19.4.0.r3521226. Elapsed time: 00:00:15.700[CHECK]
java -Doracle.net.tns_admin=C:\Users\ip4169\Desktop\ORDS\ords -jar ords.war standalone
enter image description here->
oejs.Server:main: Started #8299ms [CHECK]
I've checked my TNSORA.net files and see my database information is included inside.
Here is the ORDS error page:
If someone could please assist me through this I would be very grateful!
The 404 was happening at login time while trying to access SQL Developer Web for a user.
Two things to check:
the database connection pool is correctly configured
the schema is rest enabled
In this case the pool wasn't being established at startup because the ORDS_PUBLIC_USER password wasn't correct - ORDS couldn't create database connections.
Once the database user password was reset to what was defined in the pool config XML file, an ords restart showed the pool being established. Check the stdout when starting ords for errors!
If on the other hand you're getting errors trying to access the App in general at the /ords/sql-developer url, then -
You need to ensure SQL Developer Web is enabled.
Add these lines to your defaults.xml file and restart ords
<entry key="feature.sdw">true</entry>
<entry key="restEnabledSql.active">true</entry>
I am trying to install Informatica Server.
During domain configuration repository database information I get database connectivity error.
Error: Test Connection Failed. Correct the database connection information and test the connection again.
But when I connect using same details through Oracle SQL Developer to this database, it works fine.
I am using service name and port number field from the TNS File, still getting this error.
I think you can check tomcat log, catalina.out logs. This will help on finding out real issue.
Go to command prompt and type ping localhost and see if its responding anything. May be you can use IP and check host file.
I have a strange use case running spring boot microservices, the services lives inside an openshift cluster and the problem I face is due to a database password renewal policy.
The app uses JDBC connection to access an oracle database and the DB password is retrieved during container startup from a homegrown vault. The issue is the password keeps change once every 90 days.
The application uses JDBC connection pool to talk to the database and the service is expected to receive a high volume of traffic, therefore an increased number of sessions. In the middle of a session if the password gets renewed how do we ensure we use the working password to run queries always in the jdbc connection pool.
We tried a couple of things running a separate service that would retrieve the password momentarily and the consumer service which requires the password would simply use the last successful password from the database service, its kind of an ugly implementation.
Tried multi-container pods with an Auxillary pod listening for database changes and that was a lame idea as well.
The core problem is loading up JDBC connection pool which already has the auth to establish to connection and communicate with the database. So in the middle of a session how do we update the password?
Any ideas ?
I suppose you are using a secret store (e.g.: Vault, AWS Secrets Manager, etc.) to get the password. If so, I think you are halfway done.
Check out #RefreshScope, you can refresh the spring context which will fetch the new configuration (the password) and recreate some beans (the datasource).
I am trying to change the datasource in WebSphere pointing to some other environment. I am able to connect it using toad or sqldeveloper. However when I am trying to test the connection from websphere, it is giving the following error.
"java.sql.SQLException: ORA-28040: No matching authentication protocol DSRA0010E: SQL State = 99999, Error Code = 28,040. View JVM logs for further details."
I tried restarting the server but didn't helped. Not sure what is going wrong in this.
You didn't post any configuration information or server logs, so, assuming the old Oracle connection URL was working prior to you changing it, one common cause of this problem is changing the connection URL to move from an Oracle 11 instance (or earlier) to an Oracle 12 instance without properly updating the classpath of the WebSphere JDBC Provider to use at least the ojdbc6.jar.
In WebSphere 6.1 I have created a datasource to an Oracle 11g instance using the thin JDBC client.
In Oracle I have two users, one existing and another newly created.
My websphere datasource is OK if I use the component-managed authentication alias of the existing user, but fails with "invalid user/password" message if I use the alias of the new user. The error message is:
The test connection operation failed for data source MyDB (Non-XA) on
server nodeagent at node MY_node with the following exception:
java.sql.SQLException: ORA-01017: invalid username/password;
logon denied DSRA0010E: SQL State = 72000, Error Code = 1,017.
View JVM logs for further details.
There is nothing in the JVM logs. I have grepped all websphere logs and they do not mention my connection at all.
I can confirm that the username and password are correct by logging in via SQLPlus or (to prove the JDBC connection is OK) via SQuirreL.
I have checked in Oracle that the new user has all the system privs that the existing user has.
Any thoughts on what is going on or how I can debug this further?
Just FYI. I am guessing you are running WebSphere in Network Deployment mode.
This behavior you're experiencing is actually by design.
The reason for it is that the "Test Connection" button you see on the admin console, invokes the JDBC connection test from within the process of the Node Agent. There is no way for the J2C Alias information to propagate to the Node Agent without restarting it; some configuration objects take effect in WebSphere as soon as you save the configuration to the master repository, and some only take effect on a restart. J2C aliases take effect on restarts.
In a Network Deployment topology, you may have any number of server instances controlled by the same Node Agent. You may restart your server instances as you'd like, but unless you restart the Node Agent itself, the "test connection" button will never work.
It's a known WebSphere limitation... Which also exists on version 7.0, so don't be surprised when you test it during your next migration. :-)
If this happens to anyone else, I restarted WebSphere and all my problems went away. It's a true hallmark of quality software.
Oftentimes when people tell me they can't log into Oracle 11g with the correct password, I know they've been caught out by passwords becoming case-sensitive between 10g and 11g.
Try this :
data source definition
security
use the j2c alias both autentication managed by component and autentication managed by container
IBM WAS 8.5.5 Knowledge Center - Managing Java 2 Connector Architecture authentication data entries for JAAS
If you create or update a data source that points to a newly created J2C authentication data alias, the test connection fails to connect until you restart the deployment manager.
After you restart the deployment manager, the J2C authentication data is reflected in the runtime configuration. Any changes to the J2C authentication data fields require a deployment manager restart for the changes to take effect.
The node agent must also be restarted.
I have point my data source to componenet-manage authentication as well as container-managed authentication.Its working fine now........