Security processing failed with reason "19" ("USERID DISABLED or RESTRICTED"). SQLSTATE=08001 - db2

I am running into this error when trying to access db2 through my code, as well as the cloud console. I am using db2 hosted on ibm cloud.
Security processing failed with reason "19" ("USERID DISABLED or RESTRICTED"). SQLSTATE=08001
I am unable to perform sql queries, or access any of my table data through the console, or perform any admin access. I cannot figure out what the issue is let alone how to solve it. What could be my issue?

While I agree with #mao, here is my finding (worked for me with a free account) for anyone who ends up here for the same problem. As suggested in discussion forums at IBM course, Applied-data-science-capstone, you need to create new service credentials for your Db2 database. If you do not have any important table in your current database, it is even safer to delete it and recreate a new Db2 either in London or Dallas region followed by new service credentials. As of today, if you use sqlalchemy package in Python, versions higher than 1.4 are incompadible so:
!pip uninstall sqlalchemy==1.4 -y && pip install sqlalchemy==1.3.24
To find the location of your credentials on IBM cloud check: Connection credentials or this picture.

This is not a question for stackoverflow because it is not about programming Db2. It is an operational matter for IBM.
Some people reported this symptom with accounts that were created long ago, or which failed to migrate to new versions of Db2-on-cloud , or which became expired before migrations through lack of use or lack of renewals.
If you pay for an IBM managed service, then contact IBM cloud support to resolve such problems.
If you have a free (lite) account, currently you get no formal support. You can drop the service, and create a new service , possibly at a different data centre, using a different email address if necessary.

Related

CloudRun Suddenly got `Improper path /cloudsql/{SQL_CONNECTION_NAME} to connect to Postgres Cloud SQL instance "{SQL_CONNECTION_NAME}"`

We have been running a service using NestJS and TypeORM on fully managed CloudRun without issues for several months. Yesterday PM we started getting Improper path /cloudsql/{SQL_CONNECTION_NAME} to connect to Postgres Cloud SQL instance "{SQL_CONNECTION_NAME}" errors in our logs.
We didn't make any server/SQL changes around this timestamp. Currently there is no impact to the service so we are not sure if this is a serious issue.
This error is not from our code, and our third party modules shouldn't know if we use Cloud SQL, so I have no idea where this errors come from.
My assumption is Cloud SQL Proxy or any SQL client used in Cloud Run is making this error. We use --add-cloudsql-instances flag when deploying with "gcloud run deploy" CLI command.
Link to the issue here
This log was recently added in the Cloud Run data path to provide more context for debugging CloudSQL connectivity issues. However, the original logic was overly aggressive, emitting this message even for properly working CloudSQL connections. Your application is working correctly and should not receive this warning.
Thank you for reporting this issue. The fix is ready and should roll out soon. You should not see this message anymore after the fix is out.

Unable to connect from BigQuery job to Cloud SQL Postgres

I am not able to use the federated query capability from Google BigQuery to Google Cloud SQL Postgres. Google announced this federated query capability for BigQuery recently in beta state.
I use EXTERNAL_QUERY statement like described in documentation but am not able to connect to my Cloud SQL instance. For example with query
SELECT * FROM EXTERNAL_QUERY('my-project.europe-north1.my-connection', 'SELECT * FROM mytable;');
or
SELECT * FROM EXTERNAL_QUERY("my-project.europe-north1.pg1", "SELECT * FROM INFORMATION_SCHEMA.TABLES;");
I receive this error :
Invalid table-valued function EXTERNAL_QUERY Connection to PostgreSQL server failed: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request.
Sometimes the error is this:
Error encountered during execution. Retrying may solve the problem.
I have followed the instructions on page https://cloud.google.com/bigquery/docs/cloud-sql-federated-queries and enabled BigQuery Connection API. Some documents use different quotations for EXTERNAL_QUERY (“ or ‘ or ‘’’) but all the variants end with same result.
I cannot see any errors in stackdriver postgres logs. How could I correct this connectivity error? Any suggestions how to debug it further?
Just adding another possibility for people using Private IP only Cloud SQL instances. I've just encountered that and was wondering why it was still not working after making sure everything else looked right. According to the docs (as of 2021-11-13): "BigQuery Cloud SQL federation only supports Cloud SQL instances with public IP connectivity. Please configure public IP connectivity for your Cloud SQL instance."
I just tried and it works, as far as the bigquery query runs in EU (as of today 6 October it works).
My example:
SELECT * FROM EXTERNAL_QUERY("projects/xxxxx-xxxxxx/locations/europe-west1/connections/xxxxxx", "SELECT * FROM data.datos_ingresos_netos")
Just substitute the first xxxxs with your projectid and the last ones with the name you gave to the connection in The bigquery interface (not cloudsql info, that goes into the query)
Unfortunately BigQuery federated queries to Cloud SQL work currently only in US regions (2019 September). The documents (https://cloud.google.com/bigquery/docs/cloud-sql-federated-queries) say it should work also in other regions but this is not the case.
I tested the setup from original question multiple times in EU and europe-north1 but was not able to get it working. When I changed the setup to US or us-central1 it works!
Federated queries to Cloud SQL are in preview so the feature is evolving. Let's hope Google gets this working in other regions soon.
The BigQuery dataset and the Cloud SQL instance must be in the same region, or same location if the dataset is in a multi-region location such as US and EU.
Double check this according to Known issues listed.
server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request.
This message usually means that you will find more information in the logs of the remote database server. No useful information could be sent to the "client" server because the connection disappeared so there was no way to send it. So you have look in the remote server.

Keep getting error ""Create Service - Failed to fetch" on IBM Cloud's Db2 page

I've tried, failed, deleted the database and tried again 7 times now and I get this error each time. I'm on the lite plan and taking the IBM Data Science Certification course and I can't get past this part. Any assistance would be greatly appreciated.
Deleting database (can only have one in lite plan I believe) retried several times
I just verified that I am able to create a fully working Lite instance on my end. Is it possible that it's a networking issue on your end? Was that the full error message? It seems to be cut off. In what region and datacenter are you trying to create the service instance?

Cannot create Services in IBM Bluemix

Every time, when I try to create a service in IBM Bluemix (web and CLI), the following error message appears:
Creating service instance my-compose-for-mysql-service in org XXX / space XXX as XXX...
FAILED
Server error, status code: 502, error code: 10001, message: Service broker error: {"description"=>"Deployment creation failed - {\"errors\":\"insufficient_storage\",\"status\":507}"}
How can free storage or fix the error?
I already did the following steps:
Delete all other spaces and apps
Delete all services
Reinstall CLI
-
This error message is stating that the compose backend has reached full capacity and does not have enough resources to create your service.
The compose engineers will be aware of this issue and will be working towards adding more capacity to the backend.
Please wait and try again later, or if urgent raise a support ticket.
Are you using the experimental version of the MYSQL service, which has been retired? The experimental instances were disabled recently on August 7, 2017. There is a newer production version of the Compose for MySQL service, which is available here: https://console.ng.bluemix.net/catalog/services/compose-for-mysql/
For more information about the experimental service retirement and its replacement, see: https://www.ibm.com/blogs/bluemix/2017/06/bluemix-experimental-services-sunset/
Okay, after reaching out to various support agents:
The problem is not a general bug. I was using a company related account which accumulate all databases of the company domain in one Sandbox which is just running out of storage. Compose seems to already working on it.
My solution until the official fix: Use a different non-business account to host the database.

How can we access Bluemix hosted "Compose for MongoDB" service from "outside"?

Situation:
Have created today a new Compose for MongoDB Service instance in Bluemix
Need:
I have to access this MongoDB DIRECTLY with tools (eg. Mongo Managemant Studio Pro, mongo.exe, etc.) for bulkloading, testing, ad-hoc data fix, etc.
Problem:
I have not found any docs, samples nor a CLEAR statement that
a) gives me some confirmation that THIS is possible
b) gives me COMPLETE information (not just some technical fragments that might have worked year ago) how to do it.
Maybe I am looking to the wrong places or do not know the right people. However I am stuck on this, and before quitting Bluemix MongoDB maybe somebody has a copy/past solution or handson step by step manual.
Any help welcome. Thanks!
Connecting to MongoDB service in Bluemix from an application is possible. For this answer I have used the application "Robo3T" and here are the steps:
Access your MongoDB Service on you Bluemix account. Usually under
"Cloud Foundry Services"
Open section "Manage", from "Connection Settings" copy from "HTTPS" the connection address and port. In this example "sl-eu-lon-2-portal.5.dblayer.com" and "20651"
In Robo3T create a new connection with the connection address from previous step
In tab Authentication configure database name, username and password
. The credentials are found as in step 1
From "Connection Settings" copy the SSL Certificate into a text file and save locally.
In Robo3T Add the certificate to the connection in the "SSL" tab
Test the connection and save the settings
Answer
YES, Bluemix hosted Compose for MongoDB instances can be connected from the mongo Shell and some updated DB Managment tools.
However, you have to make sure, that in case you are running the newest DB versions, that your tools (shell and DB management GUIs) comply with the newest DB features such as encryption etc.
Origin of the Problem
My problem was due to older and therefore incompatible versions of the mongo shell and DB-managment tools running against the newest MongoDB versions with their specialities on encription and multiple servers to be handled in the URI.
At least two DB managment tools are not compatible with the newest DB version and will take their time to get fixed. The problem is, that both will not tell you about this. They just do not not connect. No logs on either side. Period.
So my advise here: look for tool providers who express dedicated compliance with the specific version of your DB.
Advise to the Bluemix Team
It might not take much time to provide some sample connection strings for the most common tools like the mongo shell, MongoBooster, etc. to take the hassle and guesswork out of interpreting the Environment variables and figuring out what is needed for specific connection strings and what is not.
For instance MongoDB Atlas hosting provides for every cluster readymade connection strings for many tools you can just copy/past and done!
Connecting to Atlas took me 5 Minutes. For Bluemix I have lost hours! Not because it is complex, but because the documentation and the generated Info is somehow incomplete and messy - at least for the ones who do not connection strings for their living!