Cataloging Remote Databases with the Add Database Wizard


As you can see, cataloging a local database is a relatively simple process. However, cataloging a remote database is a little more involved, because both the database and the node the database is stored on must be cataloged to gether. (The entry in the system database directory must have a corresponding entry in the node directory.) That's why the Add Database Wizard (not to be confused with the Add Database dialog that is invoked from the Control Center) was created. This tool, which is activated from the Configuration Assistant, is designed to capture information about the characteristics of databases that are to be cataloged, then use that information to make the appropriate entries in the database and node directories. Figure 4-9 shows the Configuration Assistant menu items that must be selected in order to activate the Add Database Wizard; Figure 4-10 shows what the first page of the Add Database Wizard looks like when it is activated.

Figure 4-9. Invoking the Add Database Wizard from the Configuration Assistant.

graphics/04fig09.gif

Figure 4-10. The first page of the Add Database Wizard.

graphics/04fig10.jpg

The first thing you will notice when you activate the Add Database Wizard is that there are three methods that you can use to catalog a database. They are:

  • Automated configuration using an access profile

  • Automated configuration using network discovery

  • Manual configuration

From a user's perspective, using an access profile or network discovery is the easiest way to catalog a database; manual configuration requires knowledge of where the database is physically located, along with the characteristics of the communications protocols used on both the client and the server. However, before a user can take advantage of either of the automated configuration options available, the database administrator must either generate a set of access profiles or set up the DB2 Discovery services on each appropriate DB2 UDB server.

Access Profiles

An access profile contains the information a client workstation needs to catalog a remote database stored on a DB2 UDB server. Two types of access profiles exist: server access profiles and client access profiles . Server access profiles are created on DB2 UDB server workstations and contain information about all instances and databases that have been cataloged on the server. Client access profiles, on the other hand, are used to copy information about the cataloged databases and/or the settings (DB2 Database Manager configuration, CLI/ODBC settings, etc.) found on one client workstation to other client workstations. Both types of profiles can then be exported from one DB2 system and imported to another.

Since you do not need to provide detailed communications information when access profiles are used, they are ideal for configuring a large number of clients. If you have a large number of clients to configure, you should also consider making use of LDAP (the Lightweight Directory Access Protocol). LDAP lets you store catalog information in one centralized location. Each client just needs to be able to access the centralized location to connect to any database that has been made available in the network.

DB2 Discovery

DB2 Discovery also allows you to easily catalog a remote server and a database without having to know any detailed communication-specific information. Here's how DB2 Discovery works. When invoked from a client workstation, DB2 Discovery broadcasts a discovery request over the network, and each DB2 server on the network that has been configured to support the discovery process responds by returning a list of instances found on the server, information about the communication protocol each instance supports, and a list of databases found within each instance. The Control Center and the Configuration Assistant can then use this information to catalog any instance or database returned.

To process a discovery request, DB2 Discovery can use one of two methods: search and known . When the search discovery method is used, the entire network is searched for valid DB2 servers/databases, and a list of all servers, instances, and databases found is returned to the client, along with the communications information needed to catalog each one. In contrast, when the known discovery method is used, the network is searched for a specific server using a specific communications protocol. (Since the client knows the name of the server and the communications protocol used, the server is said to be "known" by the client.) Again, when the specified server is located, a list of all instances and databases found on the server is returned to the client, along with the information needed to catalog each one.

graphics/caution_icon.gif

A search discovery can take a very long time (many hours) to complete if the network the client and server are on contains hundreds of machines. Furthermore, some network devices, such as routers, may actually block a search discovery request.


Manual Configuration

If you know the details of the communications setup between a client and a server, you can manually configure a database connection using the Add Database Wizard. In this case, you are prompted by a series of wizard pages to provide information similar to that required by the CATALOG DATABASE and CATALOG NODE commands. This information includes the communications protocols supported by the server instance containing the database to be cataloged, the communications protocol information needed to configure a connection to the server instance, the name of the server, and the name of the database on the server.



DB2 Universal Database V8.1 Certification Exam 700 Study Guide
DB2 Universal Database V8.1 Certification Exam 700 Study Guide
ISBN: 0131424653
EAN: 2147483647
Year: 2003
Pages: 68

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net