View figure.This chapter provides an overview of some of the many possible configurations. (For detailed information on how to establish any particular configuration, see the DB2 Server for VM System Administration manual.) It also contains information on VSE Guest Sharing, and on the VM/ESA operating environment.
The following terms are used in the descriptions of the DB2 Server for VM configurations that follow:
The database manager controls any updates or deletes made to the database, and maintains its security and integrity.
To protect the integrity of the database, users do not have direct access to it. Rather, their requests are sent to the database manager, which processes them and returns the results to the users.
Notes:
User machines cannot make changes directly to the database. They must send SQL statements to the database manager.
The database machine can run in two modes of operation: multiple user or single user. The DB2 Server for VM operator (the person logged onto the database machine) selects the mode when he or she starts up the database machine.
In multiple user mode, the most common mode of operation, one or more users or applications concurrently access the same database. The database manager runs in its own virtual machine, while one or more DB2 Server for VM applications run in other virtual machines.
In single user mode, the database manager and an application program run in a single VM machine, and no other users are allowed access. Some maintenance tasks, such as adding auxiliary storage to the database, require this mode.
It is also possible to operate more than one DB2 Server for VM database machine in multiple user mode: that is, multiple databases are being accessed by many users concurrently. This is called "multiple database mode".
The following configurations all assume that the database machines are operating in multiple user mode.
In the simplest configuration, there is one database machine and one database. (This environment is created by the installation process.)
Figure 47 shows an example. Here, all virtual machines reside on the same processor.
Figure 47. Example of One Database Machine Running One Database
| View figure. |
Points (1) and (2) in the figure are as follows:
The operator selects a database when the database machine is started.
SQLINIT DBNAME(DB01)
to specify DB01 as the default database. Then, when they invoke ISQL, the DBS Utility, or an application program, this default database will be accessed. See SQLINIT EXEC for information on the SQLINIT EXEC.
In Figure 48, all virtual machines reside on the same processor.
Figure 48. One Database Machine that Owns More than One Database
 View figure. |
Points (1) and (2) in the figure are as follows:
The operator selects a database when the database machine is started. In this example, the operator had the choice of selecting the DB01 or DB02 database. The DB01 database was chosen.
Note that a database machine can only access one database at a time. To access the DB02 database, the operator must restart the SQLMACH database machine, specifying the DB02 database.
SQLINIT DBNAME(DB01)
to specify DB01 as the default database. Then, when they invoke ISQL, the DBS Utility, or an application program, this default database will be accessed. (See SQLINIT EXEC for information on the SQLINIT EXEC.)
Here, users cannot access the DB02 database. If they entered "SQLINIT DBNAME(DB02)" and then tried to access DB02 (using ISQL, the DBS Utility, or an application program), an SQL error would occur.
If users need to access DB02, the operator will have to restart the SQLMACH database machine, specifying that DB02 is to be accessed. DB01 must be stopped before DB02 can be restarted.
In Figure 49, all virtual machines reside on the same processor.
Figure 49. Two Database Machines with Three Databases
 View figure. |
Points (1), (2), and (3) of the figure are as follows:
The SQLMACH operator selects a database when the database machine is started. In this example, the operator had the choice of selecting the DB01 or DB02 database. The DB01 database was chosen.
Note that a database machine can only access one database at a time. To access the DB02 database, the operator must restart the SQLMACH database machine, specifying the DB02 database.
Note that it is possible for one database machine to access a database "owned" by another database machine, as long as the virtual machines reside on the same processor. For example, the SQLMFB database machine could access the DB02 database, provided that the SQLMFB operator knows the minidisk passwords for the DB02 database minidisks.
| Note: | A database machine "owns" a database if its virtual machine directory contains the MDISK statements for the database minidisks. |
SQLINIT DBNAME(DB01)
to specify DB01 as their default database, while MIKE and MARY must enter:
SQLINIT DBNAME(DB03)
to specify DB03 as their default database. (See SQLINIT EXEC for information on the SQLINIT EXEC.)
Here, users cannot access the DB02 database. If they entered "SQLINIT DBNAME(DB02)" and then tried to access DB02 (using ISQL, the DBS Utility, or an application program), an SQL error would occur.
If users need to access DB02, the SQLMACH database machine operator will have to restart the SQLMACH database machine, specifying that DB02 is to be accessed. Restarting the SQLMACH database machine to access DB02 will stop users from accessing DB01.
Users can change the database they are accessing in two ways:
For example, suppose MARYLOU is accessing DB01 using ISQL. She can switch to DB03 by entering the following SQL statement:
CONNECT TO DB03
See Connecting to an Application Server in VM for more information.
Users can access a database that resides on another processor, provided both processors are running on VM/ESA systems, and are connected in TSAF, SNA or TCP/IP network. (Refer to the DB2 Server for VM System Administration manual for information about network configurations.)
Figure 50 shows an example of accessing a database located on another processor.
Figure 50. User Accessing a Database on Another Processor
 View figure. |
Points (1), (2), and (3) of the figure are as follows:
The SQLMACH operator selects a database when the database machine is started. In this example, the operator had the choice of selecting the DB01 or DB02 database. The DB01 database was chosen.
Note that a database machine can only access one database at a time. To access the DB02 database, the operator must restart the SQLMACH database machine, specifying the DB02 database.
The database is established as a global resource.
| Note: | Databases can be classified as either local or global. A local database can only be accessed by users located on the same processor as itself, while a global one can also be accessed by users located on other processors within the collection. |
The SQLREM operator specified the DB04 database at startup.
It is possible for a database machine to access a database "owned" by another database machine, provided the virtual machines reside on the same processor. The SQLREM database machine cannot access the DB01 database (owned by SQLMACH), because SQLMACH and DB01 are on a different processor.
MARYLOU and STEVE enter:
SQLINIT DBNAME(DB01)
to specify DB01 as their default database, while CINDY and RALPH enter:
SQLINIT DBNAME(DB04)
to specify DB04 as their default database.
Note that although CINDY is on a different processor from RALPH, both access the DB04 database in the same way, and CINDY is able to specify DB04 as her default database.
Users can change the database they are accessing in two ways:
After establishing a new default database, the user could then access the database using ISQL, the DBS Utility, or application programs.
This can be done from within an application (ISQL, the DBS Utility or application program).
For example, suppose MARYLOU is accessing DB01 using ISQL. She can switch DB04 by entering the following SQL statement:
CONNECT TO DB04
Refer to Connecting to an Application Server in VM for more information.
Users on processors that do not have a database machine or a database can access a database on another processor. (The processors must be running on VM/ESA systems, and all user IDs must be unique between processors.) Figure 51 shows an example.
Figure 51. Accessing a Database from Another Processor
 View figure. |
Points (1), (2), and (3) of the figure are as follows:
The SQLMACH operator selects a database when the database machine is started. This database is established as a global resource.
SQLINIT DBNAME(DB01)
to specify DB01 as their default database.
When MARYLOU, STEVE, CINDY, or JOHN invoke ISQL, the DBS Utility, or an application program, DB01 will be accessed.
JOHN must have a link to the service machine disk in order to access the database on Processor 1. This service machine must be installed on Processor 2.
Most of the processing time for any transaction is spent in the database machine and not in an application program. It is possible to have users on one processor accessing data stored on another processor if the operating systems are VM/ESA systems. However, because of the processor overhead of inter-processor communication, a database should be placed on a processor that is closest to its greatest number of users, preferably on the same one.
If you plan to have users on one processor accessing a database on another processor, you should consider the overhead of inter-processor communication. Most message traffic between the user and the database machine should flow within a single processor. Only a small percentage of messages should flow between processors, as happens when users infrequently access data located on other processors.
Although the end user does not need to know the physical location of a database, you must have a good understanding of user-group requirements in a particular business environment. Users should first be grouped according to the business tasks they perform. Databases and tables can then be arranged so that they are always accessed by most users in a particular group. A good understanding of the business environment and the needs of various user groups can aid in determining whether users on one processor are allowed to access databases on other processors.
When planning your database configuration, you should generally avoid:
Database configurations should be designed so that:
For more information on performance considerations, see the DB2 Server for VM System Administration manual.
If you have VSE/AF 4.1.0 or higher running as a guest under a VM/ESA system, VSE users can access DB2 Server for VM databases through VSE Guest Sharing. The database accessed can be on the same VM/ESA system as the one that supports the VSE guest, or on another VM/ESA system in the same TSAF collection, SNA or TCP/IP network. A VSE guest user can use database switching to target another database. An example of a DB2 Server for VM database with VSE Guest Sharing support is shown in Figure 52.
Figure 52. VSE Guest Sharing Configuration
 View figure. |
In a VSE Guest Sharing environment, VM/ESA users and applications can use the same functions they use in a VM/ESA environment without being aware of guest sharing.
For more information on VSE Guest Sharing, and on the DB2 Server for VM configurations that you can implement, see the DB2 Server for VM System Administration manual.