I downloaded and installed on Windows the following:
IBM DB2 Runtime Client (64-Bit) 10.5
with the aim of connecting to a remote server database.
It installed here:
C:\Program Files\IBM\SQLLIB
But I don't see any DB2 folders in there.
I tried to catalog the remote db like this:
db2 catalog tcpip node testing remote the.server.com server 446
If I then try to connect to it, I get the following:
SQL1031N The database directory cannot be found on the indicated file system.
There is some wizard installed called the 'Default DB2 and IBM Database Client Interface Selection Wizard'. I ran this and it said it would create a default DB2 copy and would be used by default, called DB2COPY1 and it would be installed to C:\Program Files\IBM\SQLLIB.
But I'm nnot sure what this is doing really.
What do I need to do here to connect to the remote DB2??
EDIT:
I have managed to get a bit further based on this article here:
https://www-01.ibm.com/support/docview.wss?uid=swg21008914
my current commands look like:
db2 catalog tcpip node tstnode remote my.server.com server 446
db2 catalog db db1name as mytstdb at node tstnode authentication server
db2 catalog dcs db db1name as A123456DAT
db2 terminate
db2 connect to mytstdb user <username> using <password>
However the connect fails with:
SQL30061N The database alias or database name "A123456DAT " was not
found at the remote node. SQLSTATE=08004
Any ideas?
If you are connecting through port 446, I guess you are trying to connect to DB2 for IBM z or DB2 for IBM i. If yes, you will need at least Db2 Connect.
Regarding error "SQL30061N The database alias or database name "A123456DAT " was not found at the remote node. SQLSTATE=08004" it happens to me when the userid does not have some priviledges on the source system. If it is an IBM i, look at the corresponding spool file. DRDA Connections are attended by jobs called QRWTSRVR. With the IBM i command WRKSPLF SELECT(USERID) (changing USERID by the user trying the DRDA connection) you can see the spool files for jobs related to your connection. Usually spool file messages are very specific on the cause of the failure.
If you are trying to connect to DB2 on z, I don't have experience.
We've a DB2 10.5 instance running on Windows 2008 R2 server. This instance has 10 databases. We have been encountering the following error while performing an offline backup of one of the databases. The error occurs every 5 mins for more than an hour and at some point it is able to get an exclusive connection and backup this database
SQL1035N The operation failed because the specified database cannot
be connected to in the mode requested.
We tried the following:
db2 quiesce instance with restricted access and force connections
db2 deactivate database
db2 backup
db2 activate
db2 unquiesce instance
Before this, we also tried a force application all and db2terminate but was in vain. Has anyone encountered such and error before? Appreciate your thoughts and thanks for your time.
Regards,
I'm trying to setup the pgexercises data in my local machine. When I run: psql -U <username> -f clubdata.sql -d postgres -x I get the error: psql:clubdata.sql:6: ERROR: cannot execute CREATE SCHEMA in a read-only transaction.
Why did it create a read-only database on my local machine? Can I change this?
Normally the most plausible reasons for this kind of error are :
trying create statements on a read-only replica (the entire instance is read-only).
<username> has default_transaction_read_only set to ON
the database has default_transaction_read_only set to ON
The script mentioned has in its first lines:
CREATE DATABASE exercises;
\c exercises
CREATE SCHEMA cd;
and you report that the error happens with CREATE SCHEMA at line 6, not before.
That means that the CREATE DATABASE does work, when run by <username>.
And it wouldn't work if any of the reasons above was directly applicable.
One possibility that would technically explain this would be that default_transaction_read_only would be ON in the postgresql.conf file, and set to OFF for the database postgres, the one that the invocation of psql connects to, through an ALTER DATABASE statement that supersedes the configuration file.
That would be why CREATE DATABASE works, but then as soon as it connects to a different database with \c, the default_transaction_read_only setting of the session would flip to ON.
But of course that would be a pretty weird and unusual configuration.
Reached out to pgexercises.com and they were able to help me.
I ran these commands(separately):
psql -U <username> -d postgres
begin;
set transaction read write;
alter database exercises set default_transaction_read_only = off;
commit;
\q
Then I dropped the database from the terminal dropdb exercises and ran script again psql -U <username> -f clubdata.sql -d postgres -x -q
I was having getting cannot execute CREATE TABLE in a read-only transaction, cannot execute DELETE TABLE in a read-only transaction and others.
They all followed a cannot execute INSERT in a read-only transaction. It was like the connection had switched itself over to read-only in the middle of my batch processing.
Turns out, I was running out of storage!
Write access was disabled when the database could no longer write anything. I am using Postgres on Azure. I don't know if the same effect would happen if I was on a dedicated server.
I had same issue for Postgre Update statement
SQL Error: 0, SQLState: 25006 ERROR: cannot execute UPDATE in a read-only transaction
Verified Database access by running below query and it will return either true or false
SELECT pg_is_in_recovery()
true -> Database has only Read Access
false -> Database has full Access
if returns true then check with DBA team for the full access and also try for ping in command prompt and ensure the connectivity.
ping <database hostname or dns>
Also verify if you have primary and standby node for the database
In my case I had a master and replication nodes, and the master node became replication node, which I believe switched it into hot_standby mode. So I was trying to write data into a node that was meant only for reading, therefore the "read-only" problem.
You can query the node in question with SELECT pg_is_in_recovery(), and if it returns True then it is "read-only", and I suppose you should switch to using whatever master node you have now.
I got this information from: https://serverfault.com/questions/630753/how-to-change-postgresql-database-from-read-only-to-writable.
So full credit and my thanks goes to Craig Ringer!
Dbeaver: In my case
This was on.
This doesn't quite answer the original question, but I received the same error and found this page, which ultimately led to a fix.
My issue was trying to run a function with temp tables being created and dropped. The function was created with SECURITY DEFINER privileges, and the user had access locally.
In a different environment, I received the cannot execute DROP TABLE in a read-only transaction error message. This environment was AWS Aurora, and by default, non-admin developers were given read-only privileges. Their server connections were thus set up to use the read-only node of Aurora (-ro- is in the connection url), which must put the connection in the read-only state. Running the same function with the same user against the write node worked.
Seems like a good use case for table variables like SQL Server has! Or, at least, AWS should modify their flow to allow temp tables to be created and dropped on read nodes.
This occurred when I was restoring a production database locally, the database is still doing online recovery from the WAL records.
A little bit unexpected as I assumed pgbackgrest was creating instantly recoverable restores, perhaps not.
91902 postgres 20 0 1445256 14804 13180 D 4.3 0.3 0:28.06 postgres: startup recovering 000000010000001E000000A5
If like me you are trying to create DB on heroku and are stuck as this message shows up on the dataclip tab
I did this,
Choose Resources from(Overview Resources Deploy Metrics Activity Access Settings)
Choose Settings out of (Overview, Durability, Settings, Dataclip)
Then in Administration->Database Credentials choose View Credentials...
then open terminal and fill that info here and enter
psql --host=***************.amazonaws.com --port=5432 --username=*********pubxl --password --dbname=*******lol
then it'll ask for password, copy-paste from there and you can run Postgres cmds.
I suddenly started facing this error on postgres installed on my windows machine, when I was running alter query from dbeaver, all I did was deleted the connection of postgres from dbeaver and created a new connection
If you are using Azure Database for PostgreSQL your server gets into read-only mode when the storage used is near total capacity.
The error you get is exactly:
ERROR: cannot execute XXXXXXXXX in a read-only transaction
https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-compute-storage
I just had this error. My cause was not granting permission to the SEQUENCE
GRANT ALL ON SEQUENCE word_mash_word_cube_template_description_reference_seq TO ronshome_user;
If you are facing this issue with an RDS instance cluster, please check your endpoint and use the Writer instance endpoint. Then it should work now.
Issue can be dur to Intellij config:
Go to Database view> click on Data Source Properties (Shift + enter)> (Select your data source)>
Options tab> Under Connection : uncheck Read-only
For me it was Azure PostgreSQL failing over to standby during maintaince in Azure and never failing back to master when PostgreSQL was in HA mode. You can check this event in Service Health and also check which zone you current VM is running from. If it's 2 and not 1 them most likely that's the result of events described above.
I have two instances on two separate AIX servers. Both DB2 databases are up with their sample databases. I want to connect with one DB2 instance from the other instance.
I am new on DB2 and want to know how can I do that.
I have executed following commands:
This path is client instance:
#. /home/db2inst2/sqllib/db2profile
db2 catalog tcpip node db2serverinst remote lpar1 server 50005 remote_instance ctginst1
db2 => terminate
DB20000I The TERMINATE command completed successfully.
# db2 connect to db2serverinst user ctginst1
Enter current password for ctginst1: SQL1031N The database directory cannot be found on the indicated file system.
SQLSTATE=58031
The term "Connect to an instance" is not correct. The correct one is to attach:
Machine A
db2inst1
db-1
db-2
sample
Machine B
db2inst2
db-3
db-4
sample
db2inst3
sample
If you want to execute commands from Machine A into Machine B, you have to catalog db2inst2 AND/OR db2inst3 in db2inst1 (catalog tcpip node). Remember that you have to give different names to each cataloged object.
Once you have cataloged a remote instance, you could also issue database commands, but you have to catalog remote databases. You can have a remote sample, and a local sample, but alias should be different.
If you cataloged db2inst2 instance as db2inst2 node in local node from Machine A.
And you cataloged sample database as sample-2 alias in local node from Machine A.
You could execute in Machine A.
db2 attach to db2inst2
db2 connect to sample-2
Attach is for 'administrative' things, like list applciations, create db, etc.
Connect is to use the database.
You have only cataloged DB2 instance. You need to catalog the database at the remote server:
db2 catalog database XXXX at node db2serverinst
Obviously, you'll need to replace the XXXX with the actual name of the remote database. Once you've cataloged the database, you can then connect:
db2 connect to XXXX user ctginst1
Note, this only defines the connection. You won't be able to access objects within this remote database from other databases within the local instance without configuring federation.
I am using command
db2 restore db S18 from /users/intadm/s18backup/ taken at 20110913113341 on /users/db2inst1/ dbpath on /users/db2inst1/ redirect without rolling forward
to restore database from backup file located in /users/intadm/s18backup/ .
Command execution gives such output:
SQL1277W A redirected restore operation is being performed. Table space
configuration can now be viewed and table spaces that do not use automatic
storage can have their containers reconfigured.
DB20000I The RESTORE DATABASE command completed successfully.
When I'm trying to connect to restored DB (by executing 'db2 connect to S18'), I'm getting this message:
SQL0752N Connecting to a database is not permitted within a logical unit of
work when the CONNECT type 1 setting is in use. SQLSTATE=0A001
When I'm trying to connect to db with db viewer like SQuireL, the error is like:
DB2 SQL Error: SQLCODE=-1119, SQLSTATE=57019, SQLERRMC=S18, DRIVER=3.57.82
which means that 'error occurred during a restore function or a restore is still in progress' (from IBM DB2 manuals)
How can I resolve this and connect to restored database?
UPD: I've executed db2ckbkp on backup file and it did not identified any issues with backup file itself.
without rolling forward can only be used when restoring from an offline backup. Was your backup taken offline? If not, you'll need to use roll forward.
When you do a redirected restore, you are telling DB2 that you want to change the locations of the data files in the database you are restoring.
The first step you show above will execute very quickly.
Normally, after you execute this statement, you would have one or more SET TABLESPACE CONTAINERS to set the new locations of each data file. It's not mandatory to issue these statements, but there's no point in specifying the redirect option in your RESTORE DATABASE command if you're not changing anything.
Then, you would issue the RESTORE DATABASE S18 COMPLETE command, which would actually read the data from the backup image, writing it to the data files.
If you did not execute the RESTORE DATABASE S18 COMPLETE, then your restore process is incomplete and it makes sense that you can't connect to the database.
What I did and what has worked:
Executed:
db2 restore db S18 from /users/intadm/s18backup/ taken at 20110913113341 on /<path with sufficient disk space> dbpath on /<path with sufficient disk space>
I got some warnings before, that some table spaces are not moved. When I specified dbpath to partition with sufficient disk space - warning has disappeared.
After that, as I have an online backup, I issued:
db2 rollforward db S18 to end of logs and complete
That's it! Now I'm able to connect.