Has anyone seen the following error before in Websphere 6.1 Portal? What does it mean the database domain is currently unavailable? I tested DB connections via the Websphere console and they all worked. Not sure what database domain means. We saw this for multiple domains.
0000009f DataStoreCont E com.ibm.wps.datastore.impl.DataStoreContext handleException EJPDB0002E: Error occurred during database access.
com.ibm.wps.datastore.domains.DomainUnavailableException: EJPDB0101E: Database domain [Domain: cust] is currently unavailable.
at com.ibm.wps.datastore.impl.DataStoreContext.handleException(DataStoreContext.java:315)
The customization database holds information like users' private pages. In case they can access ie. shared settings their customized page becomes a new private version of the page. An other usage for the customization database are the portlet preferences. The database domain unavailable error message is a very generic way of telling that the database can not be accessed.
As you saw the error messages for several domains I would say your database server crashed. The connection testing feature of WAS only tests connection - not that any queries actually succeed. Such error messages can also be caused by misconfigured HA solutions.
Related
I have created a Google Cloud Project MySQL database to use in conjunction with the Jdbc service provided by Google Apps Script. Everything went as planned with the connection. I am basically connecting as it does in the docs.
var conn = Jdbc.getCloudSqlConnection(dbUrl, user, userPwd);
I shared the file with another account and all of a sudden I am seeing a red error saying:
'Failed to establish a database connection. Check connection string, username and password.'
Nothing changed in the code, but there is an error. When I go back to my original account and run the same bit of code, there is no error. What is happening here? Any ideas?
Jdbc.getConnection works from both: my account and another account:
var conn = Jdbc.getConnection('jdbc:mysql://' + IP + ':3306/' + database_name, user, password)
I'm really confused because the recommended method did not work.
There are two ways of establishing a connection with a Google Cloud
SQL database using Apps Script's JDBC service:
(Recommended) Connecting using Jdbc.getCloudSqlConnection(url)
Connecting using Jdbc.getConnection(url)
Notes:
IP is a Public IP address from the OVERVIEW tab in your database console:
I've allowed any host when created a user:
I am not sure whether this question has been resolved or not, but let me add this answer.
I also faced the same problem but I found the resolution. What I did is:
First, go to the console.
https://console.cloud.google.com
Then, open IAM.
and add the account as a member and add this permission: "Cloud SQL Client".
I think this is a permission issue in your second account. Necessary information are missing in your question. But, the secound account, if run as a another user, won't necessarily have your sqlservice authorization. The permission,
https://www.googleapis.com/auth/sqlservice
Manage the data in your Google SQL Service instances
is required to use Jdbc.getCloudSqlConnection(url), while Jdbc#getConnectionUrl() just requires external link connection permission
https://www.googleapis.com/auth/script.external_request
I believe that you can only connect to sql instances owned by you with getCloudSqlConnection() which doesn't even require external connection permission. This method probably calls your sql instance internally.
References:
Jdbc#getCloudConnection
Jdbc#getConnection
Conclusion
To connect to any external service, you need external_request permission. But, You don't need that permission to connect to your own documents say, Spreadsheets owned by you/have edit access permission - through SpreadsheetApp.openByUrl(). I believe it's the same thing with Jdbc.getCloudSqlConnection(). It calls your Google sql internally - So, even if you grant external request permission, It won't work. What will work for this method is
Installable triggers (which runs as you).
Add the second account also as owner in GCP-IAM (may not work though) See this answer
I'd double-check once again all IP ranges which should be whitelisted. According to your description it worked fine in first account, probably in second account Apps Script uses another IP for connection, which was not whitelisted or whitelisted with some typo. Could you share screenshot how did you exactly whitelist the ranges from this article?
I have a GAS Add-On that uses a Google cloud dB. I initially set this up by:
Whitelisting Google Cloud IP ranges in my SQL instance
Getting the script.external_request scope approved for OAuth Consent screen
This all works great from GAS for the add-on, but I suspect that if this whitelist is not comprehensive and volatile (which I expect it is), I will see intermittent connectivity issues.
I recently added a Firebase web app that needs access to the same dB. I had issues, because Firebase does not conform to those Google IP ranges and does not expose its IP for whitelisting. So I had to create a socket layer connection as if Firebase was an external service.
Which got me thinking, should I put a socket layer in my GAS Add-On? But nothing in the GAS JBDC Class documentation indicates a socket parameter.
Which leads me to a question that was not really answered in this thread:
Does anyone know why Jdbc.getCloudSqlConnection(url) is the "Recommended" approach? The documentation seems to imply that because the IP whitelisting is not required, Jdbc.getCloudSqlConnection(url) is using a socket (or some other secure method) to connect to the dB?
It also seems silly that if that is the case, that I would need two have two sensitive scopes to manage a dB connection. I would rather not go through another OAuth const audit and require my users to accept another scope unless there is a benefit to doing so.
We have an MVC3 site that uses the ASP.NET Membership Provider with Forms Authentication to let users onto the site. We have an Oracle database behind it.
It all works in house on development machines, test machines and deployment machines.
But at a client - they are getting the error "ORA-12154: TNS:could not resolve the connect identifier specified".
We thought this would be a simple case of a wrong config entry but all seems correct. They've also run a tnsping to the same TNS alias and it works. A connection via SQL*Plus also works. We've even got them to download a .NET connection string tester application and that connects ok using exactly the same connection string as the MVC3 site web.config has. It's only the website that comes back with this error. (note: all the tests were done from the same machine as the website is on)
Has anyone seen this before and provide some guidance on how to solve?
Thanks
The likely cause for this, from experience, is that the account under which the application is running is unable to read/access the TNSNAMES.ORA file, either due to file/folder permissions or network access permissions.
I have a web application that uses a local SQL Server Express database (a.k.a. ~/App_Data/ASPNETDB.MDF).
When I deploy to IIS 7.0 on Windows 2008 Standard (SP2), I get the error:
A network-related or instance-specific error occurred while
establishing a connection to SQL Server. The server was not found or
was not accessible. Verify that the instance name is correct and that
SQL Server is configured to allow remote connections. (provider: SQL
Network Interfaces, error: 26 - Error Locating Server/Instance
Specified)
The error message goes on to offer some advice
SQLExpress database file auto-creation error:
The connection string specifies a local Sql Server Express instance
using a database location within the application's App_Data directory.
The provider attempted to automatically create the application
services database because the provider determined that the database
does not exist. The following configuration requirements are necessary
to successfully check for existence of the application services
database and automatically create the application services database:
If the application is running on either Windows 7 or Windows Server
2008R2, special configuration steps are necessary to enable
automatic creation of the provider database. Additional information
is available at: http://go.microsoft.com/fwlink/?LinkId=160102. If
the application's App_Data directory does not already exist, the web
server account must have read and write access to the application's
directory. This is necessary because the web server account will
automatically create the App_Data directory if it does not already
exist.
If the application's App_Data directory already exists, the web
server account only requires read and write access to the
application's App_Data directory. This is necessary because the web
server account will attempt to verify that the Sql Server Express
database already exists within the application's App_Data directory.
Revoking read access on the App_Data directory from the web server
account will prevent the provider from correctly determining if the
Sql Server Express database already exists. This will cause an error
when the provider attempts to create a duplicate of an already
existing database. Write access is required because the web server
account's credentials are used when creating the new database.
Sql Server Express must be installed on the machine.
The process identity for the web server account must have a local user profile. See the readme document for details on how to create a
local user profile for both machine and domain accounts.
I don't understand how to troubleshoot 4. (where can I find the "readme document"?). However, the other items look correct to me.
Specifically...
The app pool in question is running as NETWORK SERVICE (not Application Pool Identity)
The user NETWORK SERVICE has Full Control of App_Data (do I understand correctly that it does NOT need Read/Write for App_Data's parent, since App_Data is already created?)
Interestingly, if I copy ASPNETDB.MDF and ASPNETDB.LDF from my development machine to the production App_Data, the error changes:
A network-related or instance-specific error occurred while
establishing a connection to SQL Server. The server was not found or
was not accessible. Verify that the instance name is correct and that
SQL Server is configured to allow remote connections. (provider: SQL
Network Interfaces, error: 26 - Error Locating Server/Instance
Specified) Description: An unhandled exception occurred during the
execution of the current web request. Please review the stack trace
for more information about the error and where it originated in the
code.
Exception Details: System.Data.SqlClient.SqlException: A
network-related or instance-specific error occurred while establishing
a connection to SQL Server. The server was not found or was not
accessible. Verify that the instance name is correct and that SQL
Server is configured to allow remote connections. (provider: SQL
Network Interfaces, error: 26 - Error Locating Server/Instance
Specified)
What am I missing?
I had the same error before and the problem was that my SQL Server service was stopped, this is pretty weird but sometimes they just crash,I had to reinstall SQL Server cause the service didn't even alloud me to start it,so you may want to check this.
I ended up moving the relevant tables to a new SQL Server database because I could not resolve the permissions issue.
That is the recommended approach anyhow for a production application, though it seems unfortunate that it was so hard (in terms of determining how to configure security) to deploy the ASPNETDB.MDF variant for a very low-volume website.
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........
i have developed an application and it is working fine but when ever i create a virtual directory for it in IIS and run the application i am getting connection failure exception and named pipes exception.
thanks!
It looks like you having some issue with the database connection from your application. Can you post your code and the exact nature of the error.
Without any code or details of the language it is hard to guess what the issue can be however a common one that occurs with asp.net could be your database connection string. Are you using a SQl Server / Sql Server Express database with your application? You need to check that the connection string.
The problem is the Integrated Security=True setting in your connection string. IIS uses the ASPNET windows login which will be different to the Windows login used when running from VS. You've got a few options:
Grant the ASPNET user the required access rights on your database
Use Sql Server authentication: Set up a user on the database as a sql login and pass this username / password in on the connection string and set Integrated Security=False
Change the identity IIS runs under to one that has access to the DB.
There may be other options also however I think these are most common. Which to choose depends on the architecture you are deploying to, personally I almost always go for Sql Server Authentication using a username and password. The web.config can be encrypted for further security if required.