- DB2 Client Overview
- Roadmap to Distributed Communications
- Configuring DB2 Clients
- Manually cataloging the DB2 Directories
- Binding Utilities
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Manually cataloging the DB2 Directories
Access to both local and remote databases uses entries in the DB2 directories. The directories hide the requirement for the user to know where a database actually resides. Users are able to connect to local databases and remote databases (including DRDA databases) by specifying a database name. The directories that make this possible are:
-
System database directory
-
Local database directory
-
Node directory
-
DCS directory
-
Administration node directory
System Database Directory
The system database directory resides in the SQLDBDIR subdirectory in the instance directory. This directory is used to catalog both local and remote databases. The directory contains the database name, alias, type, and node where the database resides. If the database is local, a pointer to the local database directory is located in the system database directory. If the database is remote, there is a pointer to the node directory.
Local Database Directory
The local database directory resides in every drive/path that contains a database. It is used to access local databases in that subdirectory. Each entry in the directory contains the database name, alias, type, and location information about the database.
Node Directory
Each database client maintains a node directory. The node directory contains entries for all instances that the client will access. The node directory contains communication information about the network connection to the instance. If multiple instances exist on a remote machine, then each instance must be cataloged as a separate node before you are able to access any information contained within the instance.
DCS Directory
The connection information for DRDA host databases is different from the information for LAN-connected databases. A separate directory maintains this host information. This directory is the DCS directory. It only exists if the DB2 Connect product is installed on your system. The DCS directory stores information used by the database manager to access databases on a DRDA Application Server.
Administration Node Directory
The administration node directory contains one definition for each remote system that is known to a DB2 client. Most of the entries for this directory are made during product installation, by the Control Center, or by the CA.
Examining DB2 Directories
Consider a scenario with two systems, a database server and a remote client. From the database server, issue the LIST DB DIRECTORY command to list the contents of the system database directory. The output is as follows:
System Database Directory
Number of entries in the directory = 4
Database 1 entry:
Database alias = DB2CERT
Database name = DB2CERT
Local database directory = /home/db2
Database release level = 9.00
Comment = DB2 Certification DB
Directory entry type = Indirect
Catalog node number = 0
Database 2 entry:
Database alias = MYDB
...
The results show that there are four databases cataloged on the server. The first database is the DB2CERT database.
The local database directory is set to /home/db2. If more detail is desired, the local database directory can be examined by using the command: LIST DB DIRECTORY ON /home/db2. This provides more detailed information regarding the location of some of the database files.
Next, examine the contents of two directories on the client workstation: the system database directory and the node directory. A client does not have a local database directory since it does not usually contain local databases. The command to examine the system database directory is LIST DB DIRECTORY. Here is the output:
System Database Directory
Number of entries in the directory = 2
Database 1 entry:
Database alias = MYCERT
Database name = DB2CERT
Node name = DB2AIX
Database release level = 9.00
Comment = DB2 Certification DB
Directory entry type = Remote
Catalog node number = 0
Database 2 entry:
Database alias = OTHERDB
...
The database alias of the database on the client is MYCERT. This name corresponds to the actual database name on the server (DB2CERT). Note that the directory entry type is indirect on the server for the DB2CERT database and remote on the client.
When a database is created, an entry is automatically placed in the system database directory and the local database directory on the server.
When cataloging the remote database on the client, the database name on the client must match the database alias on the server. The database alias specified on the client workstation is used in the CONNECT statement. Therefore, the name used to CONNECT to the DB2CERT database is MYCERT.
There is always an associated node name with a client system database directory entry. The node name (in this example DB2AIX) defines the location of the DB2 server on the network.
To discover more information about the location of the database server, examine the DB2AIX node entry in the node directory using the LIST NODE DIRECTORY command. The output is as follows:
Node Directory
Number of entries in the directory = 1
Node 1 entry:
Node name = DB2AIX
Comment =
Protocol = TCPIP
Hostname = db2aix
Service name = db2tcp1
The DB2AIX node name corresponds to a TCP/IP connection. The TCP/IP host name for the DB2 server is DB2AIX and the service name is DB2TCP1. The TCP/IP information in the client's node directory must match the information in the server's DBM configuration file.
There are other options available when cataloging a database and node, such as where authentication takes place. These options are explained in detail in “Controlling Data Access” on page 135.
Using the CATALOG Commands
You can also use the CATALOG NODE and CATALOG DB commands from the DB2 Command Center or the DB2 Command Line Processor (CLP) to add a remote database.
Before cataloging a remote database, you should check that the client machine can communicate with the remote DB2 server. The client must then catalog the remote node and the remote database.
The format of the CATALOG NODE command depends on the protocol that you use. The TCP/IP, NetBIOS, Named Pipe, and APPC protocols are supported.
Other cataloguing for APPN, LDAP, and APPCLU nodes are not described in this book. For details on these cataloguing options, please refer to the DB2 Command Reference.
Cataloging a TCP/IP Node
When cataloging a TCP/IP node to communicate with a DB2 database server, you must specify a node name after CATALOG TCPIP NODE. This node name will be used in the CATALOG DB command and must be unique in the client node directory.
catalog tcpip node mynode remote billw.ca.ibm.com server 5000
To specify the remote machine, you can use the host name or IP address as the value for the REMOTE parameter.
The SERVER parameter specifies either the service name or the port number used by the database server. These values are located in the /etc/services file (e.g., on AIX) at the server. This identifies which instance to use at the DB2 server instance.
Once the node has been cataloged, the remote database can be cataloged.
catalog db sample as mysamp at node mynode
In this chapter, the basic CATALOG command options are presented. There are many more options you can use - for details on these options, please refer to the DB2 UDB V8.1 Command Reference.
The database name you use after CATALOG DB must match the name of the database alias at the server. You can specify an alias for the remote database by specifying a different name for the value of the AS parameter. You will then use this alias to connect to the remote database. The node name you use for the AT NODE parameter must match the node name you used in the CATALOG TCPIP NODE command (in this example, MYNODE).
Once the remote database has been cataloged, you can test the connection using the CONNECT statement. For example:
connect to mysamp user db2admin using db2admin
Cataloging a NetBIOS Node
When cataloging a NetBIOS node to communicate with a DB2 database server, you must specify a node name after CATALOG NETBIOS NODE. This node name will be used in the CATALOG DB command and must be unique in the client node directory.
catalog netbios node billw remote N01FCBE3 adapter 0
To specify the remote machine, you can use the server workstation name as the value for the REMOTE parameter. You should check that the machine is available on the network.The ADAPTER parameter specifies the outgoing local logical LAN adapter number.
The workstation name of the client (NNAME) must be defined in the client's DBM configuration file. This is usually done during the installation.
Once the node has been cataloged, the remote database can be cataloged (as shown for the TCP/IP node example).
Cataloging a Named Pipe Node
When cataloging a Named Pipe node to communicate with a DB2 database server, you must specify a node name after CATALOG NPIPE NODE. This node name will be used in the CATALOG DB command and must be unique in the client node directory.
catalog npipe node mynode remote billw instance db2
To specify the remote machine, you use the Computer Name of the database server as the value for the REMOTE parameter. This is specified in the Identification Tab of the Network folder in Windows. You should check that the machine is available on the network.
The INSTANCE parameter specifies the instance on the server where the database resides.
Once the node has been cataloged, the remote database can be cataloged (as shown for the TCP/IP node example).
Cataloging an APPC Node
When cataloging an APPC node to communicate with a DB2 database server, you must specify a node name after CATALOG APPC NODE. This node name will be used in the CATALOG DB command and must be unique in the client node directory.
catalog appc node mynode remote db2cpic00 security same
To specify the remote machine, you use the symbolic destination name used in the CPI-C Side Information profile as the value for the REMOTE parameter. You should check that the machine is available on the network.
The level of security can be specified as SAME, SECURITY, or PROGRAM. For details of these security types, please refer to the DB2 UDB V8.1 Command Reference.
Once the node has been cataloged, the remote database can be cataloged (as shown for the TCP/IP node example).
Summary of Configuring Connections
Choosing a client configuration method will depend on the number of database clients, the number of different configurations needed and the network complexity. The following table gives general recommendations on when to use each configuration method.
Table 3-1. Choosing a Configuration Method
|
Environment Considerations |
Configuration Method |
|---|---|
|
Large number of clients to configure Clients may have access to different databases |
Server Access Profile |
|
Large number of clients to configure Clients will have access to the same databases |
Client Access Profile |
|
Large network with many routers and bridges |
Known discovery |
|
Simple network Many clients Dynamic environment, new servers added frequently |
Search discovery |
|
Using APPC protocol Need advanced options |
Manually from CA |
|
Need to be able to redo the setup using scripts |
CATALOG NODE/DB |
Note: In an LDAP-enabled environment, the directory information about DB2 servers and databases is stored in the LDAP directory. When a new database is created, the database is automatically registered in the LDAP directory. It is not necessary to run the Configuration Assistant to configure LDAP protocol information. However, the one may want to use the CA in the LDAP environment to:
-
Manually catalog a database in the LDAP directory.
-
Register a database as an ODBC data source.
-
Configure CLI/ODBC information.
-
Remove a database cataloged in the LDAP directory.