Facing a weird issue in DB2. Unable to connect to remote DB.
Catalogued Successfully. But when tried to connect to DB alias getting a error as
"SQL30061N The database alias or database name "NDTEST " was not
found at the remote node."
OS :- Linux
DB2Level :-
DB21085I This instance or install (instance name, where applicable:
"db2inst1") uses "64" bits and DB2 code release "SQL10055" with level
identifier "0606010E".
Informational tokens are "DB2 v10.5.0.5", "s141128", "IP23633", and Fix Pack
"5".
Product is installed at "/path/to/db2".
But we did not mention anything as "NDTEST ".
Database alias = QAZWSXED
Database name = NEWDB(changedName)
Node name = BASENNEW
Database release level = 10.00
Comment =
Directory entry type = Remote
Authentication = SERVER_ENCRYPT
Catalog database partition number = -1
Alternate server hostname =
Alternate server port number =
Node name = BASENNEW
Comment =
Directory entry type = LOCAL
Protocol = TCPIP
Hostname = hostname
Service name = portNumber
db2 connect to QAZWSXED
SQL30061N The database alias or database name "NDTEST " was not
found at the remote node. SQLSTATE=08004
Error means exactly what is say - there is no NEWDB databsae on BASENNEW node.
The fact that you were able to catalog the database doesn't mean it is actually there. There is no connection attempt during the CATALOG DATABASE command (one is not prompted for password).
E.g. if I would create local TCP/IP loopback for my instance:
$ db2 catalog tcpip node loop remote localhost server 61115
I can with no issues catalog both existing (SAMPLE) and non-existing database (BADDB):
$ db2 catalog database sample as loopsamp at node loop
DB20000I The CATALOG DATABASE command completed successfully.
DB21056W Directory changes may not be effective until the directory cache is
refreshed.
$ db2 catalog database baddb as loopbad at node loop
DB20000I The CATALOG DATABASE command completed successfully.
DB21056W Directory changes may not be effective until the directory cache is
refreshed.
I will be able to connect to the first one:
Enter current password for kkuduk:
Database Connection Info
Database server = DB2/LINUXX8664 11.5.0.0
SQL authorization ID = KKUDUK
Local database alias = LOOPSAMP
but connection attempt to non-existing one will fail with SQL30061N
db2 connect to loopbad user kkuduk
Enter current password for kkuduk:
SQL30061N The database alias or database name "BADDB " was not
found at the remote node. SQLSTATE=08004
Please verify the node directory on the remote server by runnnig
$ db2 list db directory
and see if you have an entry for your database which has type Indirect
Directory entry type = Indirect
Edit:
I didn't notice your edit that changed the database name. If error returns stalled database name then indeed db2 terminate is needed to create new CLP client application (db2bp).
E.g. if I would uncatalog incorrect entry and cataloged it again I will get similar error as client will use cached entry pointing to incorrect database name:
$ db2 uncatalog db LOOPBAD
DB20000I The UNCATALOG DATABASE command completed successfully.
DB21056W Directory changes may not be effective until the directory cache is
refreshed.
$ db2 catalog database sample as loopbad at node loop
DB20000I The CATALOG DATABASE command completed successfully.
DB21056W Directory changes may not be effective until the directory cache is
refreshed.
$ db2 connect to loopbad user kkuduk
Enter current password for kkuduk:
SQL30061N The database alias or database name "BADDB " was not
found at the remote node. SQLSTATE=08004
db2 terminate terminates the Db2 CLP client back end and reads correctly new entry from the catalog:
$ db2 terminate
DB20000I The TERMINATE command completed successfully.
$ db2 connect to loopbad user kkuduk
Enter current password for kkuduk:
Database Connection Information
Database server = DB2/LINUXX8664 11.5.0.0
SQL authorization ID = KKUDUK
Local database alias = LOOPBAD
Found the problem - There was one entry in DCS(Database Connection Services). To check DCS details
db2 list dcs directory
above command provided a DCS entry with Target Database Name as NDTest .
Working fine after removing/un cataloguing the DCS entry.
Related
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.
I'm trying to setup a local firebird instance to test against but am unable to connect to it with even ISQL. I have tried to following by following the quick start guide here:
CONNECT ..\examples\empbuild\employee.fdb user SYSDBA password masterkey;
Which resulted in:
Statement failed, SQLSTATE = 08001
unavailable database
After some searching I tried modifying that to:
CONNECT "localhost:C:\Program Files\Firebird\Firebird_2_5\examples\empbuild\employee.fdb" user SYSDBA password masterkey;
Which resulted in:
Statement failed, SQLSTATE = 28000
cannot attach to password database
After confirming I had the right directory path I decided to give on on connecting for now and try creating a new DB:
SQL>CREATE DATABASE 'C:\data\test.fdb' page_size 8192
CON>user 'SYSDBA' password 'masterkey';
Which also gave me the error:
Statement failed, SQLSTATE = 08001
unavailable database
Are there any common pitfalls I might be hitting? I've also tried the commands above both with and without the firebird service running. Also is there a detailed reference on the SQLSTATE codes?
As already mentioned in my comments the problem is caused by running the Firebird server as an application. Firebird has its password database (security2.fdb) in C:\Program Files\Firebird\Firebird_2_5. As this database is (almost, but not entirely) a normal Firebird database, the server requires write access to this database (for the transactions, etc).
By default (with UAC) users do not have write access to the password database, so this requires elevation to Administrator. So access to Firebird requires that you either run the application as a service with sufficient rights (eg as done by the default installer), or when running the server as application to run it 'As administrator'. Another option is to not install it in Program Files.
This BTW applies double when accessing the example employee database as this database file is also located in the Program Files folder.
This is for macOS/OSX (mine is 10.15) firebird ver 2.5 users.
The installation process here does not ask for a sysdba password. Which means: the security database 'security2.fdb' does not exist after a new installation.
This seems to be intentionally for security reasons since > ver 2.5.
To create one, we use the demo database as a helper:
open sql as su: >sudo isql (we don't have user rights on dir)
Connect to a existing db:
sql>connect
"/Library/Frameworks/Firebird.framework/Resources/examples/empbuild/employee.fdb
" user 'SYSDBA' password 'masterkey';
Now we created the missing file 'security2.fdb' in the folder:
"/Library/Frameworks/Firebird.framework/Resources/English.lproj/var/"
(jro)
I am trying to connect DB2 Server with ODBC, which is working fine if I specify Database in connection string.
driver = 'IBM DB2 ODBC DRIVER'
server = '10.30.30.114'
port = '50000'
protocol = 'TCPIP'
database = 'SAMPLE'
user = 'administrator'
pass = 'password'
DBI.connect("DBI:ODBC:Driver=#{driver};HostName=#{server};Port=#{port};Protocol=#{protocol};Database=#{database};Uid=#{user};Pwd=#{pass};")
The issue is I will not be knowing the database name in advance at the time of connecting to the server. I want the list of databases on the server and then tables in those databases, how should I approach?
You cannot "connect to a DB2 server" via ODBC; you can only connect to a database, for which you obviously need to specify the database name. You could use the DB2 C/C++ API calls db2DbDirOpenScan and db2DbDirGetNextEntry to list the database directory, but this code will need to be executed on the server itself, otherwise it will attempt to list the database catalog on the client machine.
IF you are connecting to DB2 for i server (formerly DB2 UDB on OS/400) --
Initially connect using hostname, allowing database to default. You can then get a list of databases in the DB2 for i SYSCATALOGS view. Your query might look like this:
SELECT catalog_name, -- database name
catalog_text -- DB description
FROM QSYS2.SYSCATALOGS
WHERE catalog_type='LOCAL' -- local to that host
AND catalog_status='AVAILABLE' -- REMOTE catalogs are 'UNKNOWN' status
You could then connect to that database if . Once connected to the appropriate database, you could query other DB2 for i catalog views such as SYSSCHEMAS and SYSTABLES. ODBC/JDBC Catalog views and ANS/ISO Catalog views would also be available.
Other API's are available outside of an ODBC connection via IBM i Access, if you prefer.
I have some databases on DB2 on an AIX server.
I login as the DB2 instance user id "chandroo" (having the db2profile set automatically when i login) and issue a command as below and get no result.
chandroo#xxxxxxxx::/db2/chandroo> db2 list db directory
chandroo#xxxxxxxx::/db2/chandroo>
However if I invoke the db2 directly from the installation directory I am able to see the entries , and I have no clue as to why it happens.
chandroo#xxxxxxxxx::/opt/IBM/db2/V9.5/bin> ./db2 list db directory
System Database Directory
Number of entries in the directory = 2
Database 1 entry:
Database alias = CHANDB
Database name = CHANDB
Local database directory = /db2/chandroo/db
Database release level = c.00
Comment =
Directory entry type = Indirect
Catalog database partition number = 0
Alternate server hostname =
Alternate server port number =
Database 2 entry:
Database alias = CHAN
Database name = CHAN
Local database directory = /db2/chandroo/db
Database release level = c.00
Comment =
Directory entry type = Indirect
Catalog database partition number = 0
Alternate server hostname =
Alternate server port number =
chandroo#xxxxxxxxx::/opt/IBM/db2/V9.5/bin>
It sounds like the db2profile script isn't being sourced properly. The environment variables defined in that script need to be set for your current AIX shell process, not a temporary subprocess started by sh, ksh, or bash. This is accomplished by specifying a single dot instead of a program name to run the db2profile script. The difference is subtle, but important.
If that is the problem, running this command will fix the problem by properly initializing your current shell process:
. ~chandroo/sqllib/db2profile
and commands like db2 list db directory will start working.
The next step is to determine what is keeping that from happening in your $HOME/.profile startup script. If you see the call to db2profile using the proper syntax as shown above, there might be a problem with the execution permissions on $HOME/.profile.
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.