This chapter provides detailed information concerning the operation of Control Center, including the Control Center-to-database server communication interface necessary to effectively manage the Control Center environment and resolve problems that can occur. Although it is intended primarily for those involved in the management and administration of Control Center itself, all users can benefit from the material presented.
Chapter 9, Getting Started introduces you to the Control Center panel interface and provides enough information to get you started using Control Center in your environment.
Information presented in this section assumes that you have read the DB2 Server for VM Control Center Program Directory.
Control Center supports command mode operation and panel mode operation. This section deals primarily with panel mode operation. Additional information for command mode operation, including command line syntax, is provided in Appendix G, "Command Mode Interface".
Finally, throughout this section we've included specific database information also found in the DB2 Server for VM manual set. It is provided for convenience and should not be used as a reference. The proper reference for database information is the database manual set for the level of DB2 Server for VM that you are using.
The Control Center Administrator is responsible for the configuration and operation of Control Center's virtual machines. There can be more than one administrator defined to a given machine ID. This authority is given to a user by inserting a USER statement in the SQLMSTR PROFILE file with a privilege level of 5 (during installation or later through the panel interface). This privilege level will enable that user to perform any function that is available within Control Center, including all DBA function for all databases under a service machine's control. A Control Center Administrator must therefore be given DB2 Server for VM DBA authority to be able to successfully exploit all available Control Center functions.
At installation time at least one user ID will become Administrator. With the Control Center panel interface, the Administrator can also promote other users to be administrator. The Control Center Administrator will automatically acquire Control Center DBA authority over all databases controlled by a given service machine. There is one special user who is called the owner of the service machine. This user will automatically have Administrator authority and will receive the SQLMSTR CONSOLE file that is closed and transferred from the service machine each day at midnight.
Administrator authority is required to install a new database under a service machine. This function is normally performed by using the New Database Setup (N) option from the Control Center Main Menu.
Each Administrator user ID identified to Control Center will receive many notes and messages during operation. Many of these will pertain to database activities and others will pertain to the Control Center operation itself. Each time Control Center is started, a report on current disk usage will be sent to the Administrators. If Control Center's 191 A-disk approaches 90% full, then the Administrator should take some action to remove files that are not needed or should increase the size of the disk.
Messages are the central form of communication between the Control Center service machines and users. The service machine will perform specific actions upon the receipt of predefined command messages from authorized users. These predefined messages are generated by the Control Center interface program, either in command mode or panel mode.
Messages are also received from the database machines through the Single Console Interface Facility (SCIF). These messages are analyzed by the service machine to determine what action should be performed and whether any Control Center user(s) should be alerted. These messages are usually issued by the database manager itself as part of archiving, recovery, operator commands, or some other database activity. The Control Center code contains the logic necessary to respond to these messages with an appropriate action, thereby completing any administration function without DBA intervention.
Control Center is designed to recognize two distinct types of interrupts, scheduled and unscheduled.
Scheduled interrupts are controlled by the SQLMSTR TIMES file on the service machines's 191 A-disk. This file is updated whenever authorized users schedule new events or remove old ones. Three entries are included in the SQLMSTR TIMES file for normal Control Center operation and must not be removed.
Unscheduled interrupts occur in two basic forms: messages and reader files. All interrupts are controlled by the SQLMSTR PROFILE file, which defines all actions that Control Center will perform when an unscheduled interrupt occurs. Specific actions are defined for known types of messages and reader files. General actions are defined for any unexpected messages or files.
Control Center is ready to be started after all control files and execs have been customized. To make sure that the correct disks are accessed, the PROFILE EXEC should be executed first. After setting up the environment, the PROFILE EXEC will leave the service machine in native CMS.
The startup process will read the values from several control files from the 191 A-disk and place them in memory for the current session. This enables Control Center to repeatedly access these values without performing any additional disk I/O. The control files that are read into memory during startup are:
Remember that when any of the previously mentioned files are changed on the service machine's 191 A-disk, the new values will not be recognized by the machine until they are again read into memory. This is done when the service machine reinitializes itself each day (by stopping and then restarting) at midnight, or when explicitly specified by the SQM NEWPROF command.
While logged onto the service machine, the SQLMSTR EXEC can be executed to start the Control Center facility. The first step of the SQLMSTR EXEC is to disconnect the virtual machine. This will allow the service machine to run in disconnected mode. It will take Control Center a few minutes from the disconnection to become fully operational.
If for some reason there is a need to watch the startup procedure, the SQLMSTR EXEC file can be modified to suspend the disconnection by commenting out the CP DISC line. To then manually disconnect the service machine after startup, enter #CP DISC while the service machine is in RUNNING mode.
The PROFILE EXEC is designed to detect whether a terminal is present at startup. If the service machine has been AUTOLOGed and there is no terminal, the PROFILE EXEC will automatically call the SQLMSTR EXEC, which will start up the Control Center facility. This is the preferred way to start the service machine.
Once Control Center has started, communications with each database is established through the SCIF. Communications with Control Center users is also possible through the panel interface.
Part of the normal service machine startup routine will perform maintenance of its environment. The previous SQLMSTR CONSOLE file will be closed and sent to the OWNER identified within the SQLMSTR PROFILE. The DATABASE MESSAGES file, SQLMSTR CONTROL file, and each database PARMS file will be read and their parameter values will be stored in memory for access until the next startup. Old copies of the SQLMSTR LOGyyddd files will be purged, based on the parameter value of Log_copies in the SQLMSTR CONTROL file. Old archives within the database ARCHHIST file of each database will also be purged.
The service machine is designed to run continuously (although it stops and restarts itself daily) if for some reason it must be stopped, the administrator should check that no archives, coldlogs, recoveries, or other special functions are active for any database. If the service machine is stopped during one of these activities, it is highly probable that the activity will fail.
The service machine can be stopped from another user ID by using the SQM STOP command. The user ID must have Administrator authority.
The service machine will then be left at the CMS ready level. Note that once the stop command has been issued, no further communications with it is possible. To restart the service machine, log onto the machine and follow the instructions discussed in the preceding paragraphs.
The service machine can also be stopped by logging onto it. After logging on, the ENTER key must be depressed twice to provide a console interrupt that will stop the Control Center code and leave the user in CMS. This method of stopping a service machine may leave it in an abnormal state. To restore the normal CMS environment, it may be necessary to IPL CMS. If a periodic RUNNING condition prevents typing on the keyboard, use the SET BLIP OFF command. (It can be difficult to type the command in between blips.)
The Control Center support machines function primarily as vehicles for running Database Administration jobs such as reorganizations. They do not control or communicate directly with any databases with the SCIF connection. The primary consideration to stopping and starting a support machine is that the machine must be available (logged on and in disconnected state) when the service machine sends a job to it to run. If the support machine is not available, the job will fail.
The methods of starting and stopping a service machine apply to a support machine as well, since the code executed is the same, with the exception of a tailored PROFILE EXEC which does not do as much as the service machine's.
DB2 Server for VM database machines should be stopped and started solely through the managing Control Center.
If a database machine has to be stopped, it should be done through Control Center. If you log onto the database machine and issue a SQLEND command, Control Center would no longer be synchronized with the database, since it would not receive any database manager messages.
| Note: |
|---|
|
Do not log onto a database machine since this cuts the SCIF communication with the Control Center service machine. All database functions (operator commands) and any CP commands can be issued through the Control Center panel interface. |
If it is necessary for whatever reason to restart a database machine when logged onto it, execute the PROFILE EXEC, then respond to the prompt to enter DBSTART. This will ensure that the database is resynchronized with the service machine.
New users may need to be added as users, DBAs, or administrators during the life of Control Center. Others may need to be deleted or have their authorities changed. This should be done in the following manner:
Administrator additions, changes, or deletions should be handled through the SQLMSTR Authorization (AU) option on the SQM panel interface. This option also allows you to get a list of all current authorizations on a service machine. This list is helpful in determining current levels of accessibility to the service machine. The SQLMSTR PROFILE is changed by this function.
Use the Database Parameters tool to add, delete, or change DBA administrators, operators, and general users to a specific database. The database PARMS file is changed by this function.
| Note: |
|---|
|
Updates to the affected files will not become effective until the service machine is stopped and restarted. A convenient way to effect the changes is to use the SQM NEWPROF command, which causes the service machine to stop and restart. |
There are several types of maintenance involved in running Control Center. Most are automatic. Some control file maintenance or modification may be required to tailor an installation's needs when running Control Center.
Control Center is mostly self-maintaining. It routinely purges back copies of files from the 191 A-disk and will maintain only the most recent information within log files. The SQLMSTR CONSOLE file of the service and support machine's console output is closed and sent to the Administrator machine owner each time the machine is brought down.
If the service or support machine's 191 A-disk begins to become full, you may need to reduce the number of versions that are retained of the log files (Log_copies parameter of the SQLMSTR CONTROL file) and the number of backup copies that are kept of files that are changed (Backup_copies parameter of the SQLMSTR CONTROL file). Another file that may need to be purged periodically is the machine NETLOG file. This file has a filename the same as the service or support machine name. It is maintained by CMS to record when files are sent and received by the machine.
When installing the Control Center system, the installation process will build and modify several control files. In this section a general description of the most important ones are given to provide a better understanding of the things that play an important role during the service machine operation.
These control files reside on the service machine's 191 A-disk (except the SQLMSTR DIRECTRY and the DBINIT CONTROL files, which are kept on the 195 code disk).
The SQLMSTR PROFILE file is a fundamental part of the disconnected virtual machine architecture. It controls the interface to users and database machines by defining valid commands and designating the corresponding code segment for each command. A secondary purpose of this file is to identify the special Administrator privileged users. These USER entries are normally the only portion of this file changed for the local installation. Advanced users can also modify the MESSAGE command privilege levels to change the default command privileges for the DBA, OPERATOR, and USER authority levels.
This file must be modified to add or remove authorized Control Center administrators. This function is automated within Control Center panel interface with the SQLMSTR Authorization (AU) option.
The SQLMSTR PROFILE file can also be modified if an installation wants to change the commands that are authorized for the various types of users (Administrators, Database Operators, Database Users). Each command is indicated within the SQLMSTR PROFILE by one of the MESSAGE entries. Each MESSAGE entry contains a single-digit number between 1 and 5 which indicates the authority level required to execute the associated command.
With proper precautions (including a backup copy of the original version), the authority levels of these MESSAGE entries can be modified for local preferences. See Appendix E, Authorizations.
Note that authority levels are hierarchical, such that someone with Database Administrator authority to a database would be able to execute all MESSAGE commands with a privilege level of 1, 2, or 3. A Database Operator would be able to execute commands with a privilege level of 1 or 2.
Figure 27 is an example of the SQLMSTR PROFILE. All uppercase entries are keywords that are required. All lowercase entries must be replaced with installation-specific values.
Figure 27. Example SQLMSTR PROFILE File
OWNER sqmowner LOG HOLD 7 USER ALL 3 USER cntrlid AT node1 5 USER userb AT nodeb 5 USER userc AT nodec 5 MESSAGE CMD 5 ( .MS MESSAGE CMS 5 ( EXEC SQMCMD .US .NO .MS MESSAGE SQMPROFU 5 ( EXEC SQMPROFU .US .NO .MS MESSAGE SQMQPROF 5 ( EXEC SQMQPROF .US .NO .MS MESSAGE RDRLIST 5 ( EXEC SQMRDRL .US .NO MESSAGE SQMCONS 5 ( EXEC SQMCONS .US .NO .MS MESSAGE SDRESTRT 3 ( EXEC SDRUSTRT .MS MESSAGE SQMDBU 5 ( EXEC SQMDBUR .US .NO .MS MESSAGE SDRELOAD 3 ( EXEC SDRELOAD .US .NO .MS MESSAGE SDLISTLG 3 ( EXEC SDLISTLG .US .NO .MS MESSAGE SDAPLYLG 3 ( EXEC SDAPLYLG .US .NO .MS MESSAGE SDUNLOAD 3 ( EXEC SDUNLOAD .US .NO .MS MESSAGE SDRTRANS 3 ( EXEC SDRTRANS .US .NO .MS MESSAGE SDSHOWDB 3 ( EXEC SDSHOWDB .US .NO .MS MESSAGE SHOWDBS 3 ( EXEC SDSHOWDB .US .NO .MS MESSAGE SQMACCES 3 ( EXEC SQMACCES .US .NO .MS MESSAGE SQMFLIST 3 ( EXEC SQMFLIST .US .NO .MS MESSAGE TRACE 3 ( EXEC SQMTRACE .US .NO .MS MESSAGE SQMDBCMS 3 ( EXEC SQMDBCMS .US .NO .MS MESSAGE SQMDCHKQ 3 ( EXEC SQMDCHKQ .US .NO .MS MESSAGE SQMADBSP 3 ( EXEC SQMADBSP .US .NO .MS MESSAGE SQMADBEX 3 ( EXEC SQMADBEX .US .NO .MS MESSAGE SQMCDBEX 3 ( EXEC SQMCDBEX .US .NO .MS MESSAGE SQMDDBEX 3 ( EXEC SQMDDBEX .US .NO .MS MESSAGE SQMCIREO 3 ( EXEC SQMCIREO .US .NO .MS MESSAGE SQMCOLDL 3 ( EXEC SQMCOLDL .US .NO .MS MESSAGE SQMEVENT 3 ( EXEC SQMEVENT .US .NO .MS MESSAGE SQMEVDEL 3 ( EXEC SQMEVDEL .US .NO .MS MESSAGE SQMJDONE 3 ( EXEC SQMJDONE .US .NO .PR .MS MESSAGE SQMJEXEC 3 ( EXEC SQMJEXEC .US .NO .MS MESSAGE SQMJSTRT 3 ( EXEC SQMJSTRT .US .NO .MS MESSAGE SQMFLDEL 3 ( EXEC SQMFLDEL .US .NO .MS MESSAGE SQMREORF 3 ( EXEC SQMREORF .US .NO .MS MESSAGE SQMREORG 3 ( EXEC SQMREORG .US .NO .MS MESSAGE SQMREOTI 3 ( EXEC SQMREOTI .US .NO .MS MESSAGE SQMMNRPR 3 ( EXEC SQMMNRPR .US .NO .MS MESSAGE SQMMNSN 3 ( EXEC SQMMNSN .US .NO .MS MESSAGE SQMMNSL 3 ( EXEC SQMMNSL .US .NO .MS MESSAGE SQMMNSR 3 ( EXEC SQMMNSR .US .NO .MS MESSAGE SQMTAPEU 3 ( EXEC SQMUTAPE .US .NO .MS MESSAGE SQMDFDEF 2 ( EXEC SQMDBREQ .US .NO .MS MESSAGE FDEFSQL 2 ( EXEC SQMDBREQ .US .NO .MS MESSAGE START 2 ( EXEC SQMDBREQ .US .NO .MS MESSAGE STOP 2 ( EXEC SQMDBREQ .US .NO .MS MESSAGE SET 2 ( EXEC SQMDBREQ .US .NO .MS MESSAGE RESET 2 ( EXEC SQMDBREQ .US .NO .MS MESSAGE FORCE 2 ( EXEC SQMDBREQ .US .NO .MS MESSAGE CANCEL 2 ( EXEC SQMCANCL .US .NO .MS MESSAGE SQMDBEND 2 ( EXEC SQMDBEND .US .NO .MS MESSAGE SQMDBEGN 2 ( EXEC SQMDBEGN .US .NO .MS MESSAGE SQMMODEU 2 ( EXEC SQMMODEU .US .NO .MS MESSAGE SQMSTATU 2 ( EXEC SQMUSTAT .US .NO .MS MESSAGE SQMARCH 2 ( EXEC SQMARCH .US .NO .MS MESSAGE SQMRECOV 2 ( EXEC SQMRECOV .US .NO .MS MESSAGE SQMRECQT 2 ( EXEC SQMRECQT .US .NO .MS MESSAGE SQMRECST 2 ( EXEC SQMRECST .US .NO .MS MESSAGE SQMRECTQ 2 ( EXEC SQMRECTQ .US .NO .MS MESSAGE SQMDBINI 2 ( EXEC SQMDBINI .US .NO .MS MESSAGE SQMMNSVU 2 ( EXEC SQMMNSVU .US .NO .MS MESSAGE SQMTAPEA 2 ( EXEC SQMTAPEA .US .NO .MS MESSAGE SQMCUARC 2 ( EXEC SQMCUARC .US .NO .MS MESSAGE SQMQUARC 2 ( EXEC SQMQUARC .US .NO .MS MESSAGE SHOW 1 ( EXEC SQMUSREQ .US .NO .MS MESSAGE COUNTER 1 ( EXEC SQMUSREQ .US .NO .MS MESSAGE SQMQSTAT 1 ( EXEC SQMQSTAT .US .NO .MS MESSAGE SQMDBLST 1 ( EXEC SQMDBLST .US .NO .MS MESSAGE SQMEVDIS 1 ( EXEC SQMEVDIS .US .NO .MS MESSAGE SQMSFILE 1 ( EXEC SQMSFILE .US .NO .MS MESSAGE VERSION 1 ( EXEC SQMVERSN .US .NO .MS MESSAGE SQMGCTRL 1 ( EXEC SQMGCTRL .US .NO .MS MESSAGE ? ( EXEC SQMMSG .US .NO .PR .CO .MM MESSAGE ON READER * * 1 ( EXEC SQMRDR .US .NO .PR .SP .FN .FT READER ? ( HOLD CLASS * |
The SQLMSTR CONTROL file is |built during the Control Center installation process and is used for |housekeeping purposes.
Figure 28. Sample SQLMSTR CONTROL File
+--------------------------------------------------------------------------------+ | mm/dd/yyyy Control Center hh:mm:ss | | *--------------------- SQLMSTR CONTROL File Parameters --------------------* | | | Command ==> CTRLID: MSTRSRV1| | | | NODE: VMSYSTM1| | | | Sqlmstr-userid ==> SQLDBA | | | | Log-copies ==> 5 (Number of Days to keep LOG files) | | | | Spool-console ==> Y (Y or N, spool Control Center console | | | | Backup-copies ==> 3 (Old copies to keep of modified files | | | | Tape-manager ==> VMTAPE (e.g. DYNAMT, VMTAPE) | | | | Dynamt-method ==> ________ (specify DYNOPEN, if used w/DYNAMT) | | | | Tape-manager-userid ==> VMTAPE (Disconnected machine id) | | | | Tape-code-userid ==> $MAINT (Tape manager code disk id) | | | | Tape-code-address ==> 19E (Tape code disk virtual address) | | | | Tape-code-filemode ==> Y (Tape code disk link filemode) | | | | Disk-warn ==> 80 (Control Center disk full warn percnt)| | | | Disk-full ==> 81 (Seriously full warn percent) | | | | Disk-access-options ==> _______________________________________ | | | | Jobout-retention-days ==> 30 (Number of days to keep Job output | | | | Date-time-format ==> USA (USA, EUR, ISO, JIS) | | | | | | | | Press Enter to process changes | | | | | | | *---------------------------------------------------------------SQMCTR-----* | | PF: 1 Help 3 End | +--------------------------------------------------------------------------------+
The service machine will receive many messages and will produce many listings and logs. To prevent the 191 A-disk from being filled, only a limited number of copies will be held, specified by the Log_copies and Backup_copies parameters. Keep these numbers to the minimum needed. A full discussion of all fields is in the DB2 Server for VM Control Center Program Directory.
This file is normally configured during installation and will not need to be changed. If modifications need to be made after installation, |use the General Utility Functions (G) option on the main menu and |pick the SQLMSTR CONTROL file (S) function.
| |All screen displays and Control Center reports now use a full 4 digit |year. In addition, you can choose from four different DATE/TIME display |formats - ISO, JIS, USA, and EUR.
|A format is chosen at Control Center installation, or migration. If |none is chosen, USA is the default.
|To change the DATE/TIME format: |
The SQLMSTR DIRECTRY file provides the interface with a directory of all database and service machines at a given installation. It is used to make a unique identification for each database in the system (local and remote nodes), and to make switching easier within the panel and command mode interfaces. When this file is properly built and available to Control Center users, only the database name needs to be supplied in commands. The user interface will reference the SQLMSTR DIRECTRY file to automatically direct the communication to the correct service machine.
In this file each database is described in terms of:
The service machine's node ID must be the same as the database node ID. If a database resides on a remote node ID, a service machine user ID at that node ID is required (see example). With this information, every database, even if it resides on a remote node, will be unique for the system.
This file will be updated when a new database is identified to Control Center. If the machine on which the database is identified owns the code disk, the file will be replaced on the code disk. Otherwise, the updated (merged) file is sent back to the user who defined the database with instructions to send the file to the service machine which owns the code disk, so that the file can be properly replaced. This must be done by a Control Center Administrator. Note that this must also be done for any SQLMSTR DIRECTRY files on remote nodes.
A helpful tip for installations with database virtual machine names that are different from the dbname of the database is to use the dbname as the nickname within the SQLMSTR DIRECTRY file. This will allow users to specify either the machine name or the dbname when using the Control Center interface (the service machine will understand either name). If the same DBNAME is used within multiple database machines, then an alternate naming scheme must be chosen to keep the nicknames within the SQLMSTR DIRECTRY file unique. The following example illustrates this point:
Figure 29. Sample SQLMSTR DIRECTRY File
SQLDBA1 SQLMACH1 MSTRSRV1 VMSYSTM1 SQLDBA2 SQLMACH2 MSTRSRV1 VMSYSTM1 SQLDBA3 SQLMACH3 MSTRSRV1 VMSYSTM1 SQLDBA4 SQLMACH4 MSTRSRV1 VMSYSTM1 SQLDBA5 SQLMACH5 MSTRSRV2 VMSYSTM2 |
If multiple service machines are being used at the installation, then manual updates to each SQLMSTR DIRECTRY file will be required to include entries within each file for databases that are not defined to the corresponding service machine. For example, if you have two service machines, one on node X and one on node Y, manually add the databases on node Y to the SQLMSTR DIRECTRY file on node X. Also manually add the databases on node X to the SQLMSTR DIRECTRY file on node Y. A single common SQLMSTR DIRECTRY file should contain entries for all databases accessible within the enterprise and should be made available to users through a common disk. Another example is where several service machines share the code disk of another service machine. In this case, the code disk of the owning service machine should be updated to reflect all databases of all service machines. The disk should then be relinked by each service machine to pick up the new copy of the file.
The following example shows a SQLMSTR DIRECTRY file that contains entries for two databases. Both databases have the same machine name but reside on different nodes. In order to identify each database, we needed to give them a nickname (SQLDBA1 and SQLDBA2). The first database exists on VMSYSTM1 and communicates through the MSTRSRV1 machine on that node. The second database exists on VMSYSTM2 and communicates through the MSTRSRV2 machine, also located on VMSYSTM2. A database SHOW command could be issued for the first database in command mode as:
SQM SQLDBA1 SHOW USERS
Figure 30. Nickname Example with SQLMSTR DIRECTRY File
SQLDBA1 SQLMACH1 MSTRSRV1 VMSYSTM1 SQLDBA2 SQLMACH1 MSTRSRV2 VMSYSTM2 |
| Operational Note: | If the same database machine name exists on two different nodes, you must always use the nickname to direct communication to the correct database. In the previous example, if a command was issued to SQLMACH1, the results would be unpredictable. If you had previously been communicating with the database on VMSYSTM2, then Control Center would direct your new command to the same node. If you were previously communicating with a third (different) database and directed a command to SQLMACH1, the command cannot be directed to your desired database. The best policy is to always qualify the database name with the node ID or use the established unique nickname. |
The DBINIT CONTROL file is used |by the DBINIT EXEC to link and access the appropriate 195 minidisk when using a Database Administration tool.
This file can be manually updated using Xedit or automatically updated using appropriate options (either New Database Setup or Database Parameters).
Each database is described in terms of:
This file will be updated when a new database is identified to Control Center. If the machine on which the database is identified owns the code disk, the file will be replaced on the code disk. Otherwise, the updated (merged) file is sent back to the user who defined the database with instructions to send the file to the service machine which owns the code disk, so that the file can be properly replaced. This must be done by a Control Center Administrator. The file will require manual updating by the DBA to include RXSQL Control Center disk information if desired for user availability. This file should be made available to all users who will be executing the Database Administration tools of Control Center.
Figure 31. Sample DBINIT CONTROL File
SQLDBA1 SQLDBA1 195 5FF E RXSQL22 198 * * SQLDBA2 SQLDBA2 195 5FF E RXSQL22 198 * * SQLDBA3 SQLMACH3 195 * * RXSQL31 198 * * SQLMACH3 |
Figure 32. Sample DBINIT CONTROL File Using SFS
DB261VM SFSPOOL1:DB261VM.SQL.PRODUCTION SFS * * * * * * * SQLDBA SQLMACH 195 * * * * * * SQLMACH DB2PROD DB2PROD 195 * * SFSPOOL1:DB261VM.SQL.RXSQL SFS * * * |
With this information, the Database Administration tools of Control Center will be able to automatically link and access the correct database server production disks and RXSQL code disks (if available) for each database. This is especially important for certain functions, such as migrating data between databases. The user ID must also have authority to LINK and ACCESS the indicated disks in READ mode without supplying a READ password. This must be attended to according to your installation authorization procedures.
On a VM/ESA system, DB2 Server for VM can be installed in a CMS Shared File System (SFS) environment. With SFS, the database service and production files are located in directories rather than on minidisks. To access code within an SFS file structure, the appropriate directory names together with a file mode must be used. In the following example, the filepoolid, SFSPOOL1, contains the production and service code for SQLMACH.
SFSPOOL1:SQLMACH.SQL.SERVICE SFSPOOL1:SQLMACH.SQL.PRODUCTION
There are two ways to set up a database with SFS:
If your database name is not the same as the virtual machine name, be sure to follow the format shown in Table 6 for the DBINIT Control file.
You must also specify the database name in the dbname field of the
Database Startup Parameters file, see Database Startup Parameters. In addition, make sure that the dbmachid
(virtual machine) name is designated as the filename for both the database
PARMS and TAPES files.
Table 6. DBINIT Control File Format
Please note from Table 6 above, to allow DBAs to use either VM machine names (IDs) or database server names with various Control Center tools, the DBINIT CONTROL file MUST contain the correct entries for those databases which have different names from the VM machine id. The "optional nickname" field MUST be the database VM machine id; (SQLMACH3). If there are no RXSQL parameters, the "optional nickname" parameter can be the 6th parameter.
The DATABASE MESSAGES file contains message identifiers that will cause the service machine to perform a predefined function when those messages are received from a database machine through the SCIF communication interface. Each message that needs to be trapped for the normal database functions (such as archiving, recovery and adding dbspaces) is included with the Control Center installation package.
The DATABASE MESSAGES file is the single point of control for all database communications and automated operations functions. It provides a list of message IDs (ARI0043I) that the service machine is programmed to expect from a database machine. Each message ID within the DATABASE MESSAGES file has a corresponding name of a module that will be executed by the service machine when the message is received from any database machine.
Figure 33 is an abbreviated example of the DATABASE MESSAGES file. The file supplied with the Control Center code provides all entries needed for supported database functions.
| Important: |
|---|
|
An experienced user can insert additional entries for messages not currently included, but existing entries must not be changed. |
Figure 33. Sample DATABASE MESSAGES File
ARI0016I SQMA015I I Database is starting up (parameters)
ARI0025I SQMA025I I Database is starting up
ARI0029I SQMA029I I Still N active communication links
ARI0043I SQMA043I I The database came down
ARI0045I SQMA045I I The database just started
DMSTLM428I SQMD428I I EOV tape mark encountered/Tape filled
HCPCFC003E SQMDUMMY I Unknown CP command option
HCPQCS150A SQMH150A I Database machine issued a VM or CP read
HCPSEC068E SQMUDONE I End of Message from database OP command (ERROR)
LOGOFF SQMDBDWN I Database machine was logged off
An installation can want to add new messages and action routines to the DATABASE MESSAGES file for some function that is not included with Control Center. The first step would be to create an exec (or module) that will be invoked when the message is received by the service machine. The database machine name and message will be passed to the exec as arguments when the exec is invoked by the service machine. This exec should be placed on the service machine's 195 code disk. The second step is to add a new line to the DATABASE MESSAGES file on the service machine. Do this by stopping the service machine, log onto it, update the file, then start the machine back up. This can also be done using the Control Center command mode interface with the MESSAGE option. See SQM: Control Center.
The format of each line of the DATABASE MESSAGES file is:
Figure 34. Database Message Format
POSITION VALUE DESCRIPTION
-------- ----- ----------------------------------------------------
1-12 Msgid A message identifier that will be the first token
(blank-delimited word) of the message received
14-21 Exec An executable module name (may be an exec or module)
23 Msgtype A one-character indication of the type of message,
I for Information, D for DB status, E for Error,
S for Severe Error
29-255 Descr Any text description of this message and action
The SQLMSTR HOLIDAYS file is an optional component of the Job Scheduling tool. It allows an installation to define special days that should not be considered by Control Center for scheduled job execution. For example, if the local installation is closed for an entire week in July, Control Center can be instructed to avoid scheduling jobs on any of these days. For each day that Control Center should avoid, an alternate day |can be provided, which the Job Scheduler will use instead. When the SKIP option is used, the job does not run; it is postponed until the next normally scheduled date.
See SQLMSTR HOLIDAYS File for a detailed explanation of the SQLMSTR HOLIDAYS file setup and processing.
The SQLMSTR TIMES file is initialized with three entries for a service machine and one entry for a support machine. These entries must not be changed. Other entries are dynamically added when jobs are scheduled or monitors are added, as well as when other internal service machine events need to be scheduled. In general, you should |never modify this file. |Scheduling changes are made through the job scheduling and monitor panels. |Refer to Chapter 10, Job Scheduling Tool for detailed information about |scheduling.
Each database must have a TAPES file to allow Control Center to initiate and manage database archive activity. The filename is equal to the database virtual machine name; the filetype is TAPES.
The database TAPES file consists of a number of entries dealing with the archive process. This file is used to set up archiving for each particular database. It does not imply that tapes will be the medium for all archiving. The file is updated using the Database Tapes Menu option on the Control Center main menu. See Chapter 11, Tape Management Tool for a detailed description of tape file setup and management.
The most significant parameter in this file is the SERIES parameter. This parameter is used by the service machine to set up different sets of archive copies. |You should have at least three different sets of restorable copies of the database; the database TAPES file will reflect that by having three different values for the series parameter. Each series describes a set of tapes or files, which as a total, restores the database to a given point in time. |Control Center will NOT work properly if less than two tape series |are used.
Figure 35. Sample Database TAPES File
100 ARCHIVE 00000 00:00:00 FILDEF VOL100
100 LOG 00000 00:00:00 UNUSED SQL31DB 03269101 F 501
100 LOG 00000 00:00:00 UNUSED SQL31DB 03269102 F 501
100 LOG 00000 00:00:00 UNUSED SQL31DB 03279102 F 501
100 TRACE 00000 00:00:00 FILDEF VOLT01
200 ARCHIVE 97086 11:09:58 FILLED VOL200
200 LOG 97086 11:34:56 FILLED SQL31DB 03279103 G 502
200 LOG 00000 00:00:00 UNUSED SQL31DB 03269105 G 502
200 LOG 00000 00:00:00 UNUSED SQL31DB 03279101 G 502
200 TRACE 00000 00:00:00 UNUSED VOLT02
300 ARCHIVE 97086 11:49:02 FILLED VOL300
300 LOG 00000 00:00:00 UNUSED SQL31DB 03269106 H 503
300 LOG 00000 00:00:00 UNUSED SQL31DB 25039107 H 503
300 LOG 00000 00:00:00 UNUSED SQL31DB 25039108 H 503
300 TRACE 00000 00:00:00 UNUSED VOLT03
Figure 35 is an example of a database TAPES file with three different series of archives. In this example, database archives are directed to tape, log archives to disk, and trace data to tape. The database has log archiving enabled. Archive series 200 is completed. The database archive for series 300 is also completed, but no log archive has been taken yet. That means the next log archive will be in series 300, because in that series the latest archive has been taken, to which the new log archive logically belongs for recoverability.
|An ARCHIVE entry must exist for every series, even if Data Restore |BACKUPs are used.
The FILEDEF for this log archive is not mentioned in this file because it can be done dynamically when the log archive takes place (see database PARMS file). If another database archive is taken, it will be directed to series 100, which was FILEDEFed when the database was started. The system will update this file (and the database PARMS file) every time an archive is taken.
Each database has a database PARMS file. The filename is equal to the database virtual machine name; the filetype is PARMS. This file describes many characteristics of the particular database. The general types of parameters within this file include:
See About the Database Parameters Tool for a complete description of these parameters.
The first section, Authorization/Notification, provides a list of users authorized to issue database manager commands for the database and additional users who will be notified of various database errors and status changes.
The second section defines some operational parameters and preferences which are used during database operation. For example: Do you want an automatic archive to be performed after adding a DBEXTENT? If your preference is YES, the Archive_addextent parameter will equal Y.
The third section provides information about tape mounting and tape handling for the database, such as tape density, retention period, and whether scratch tapes or predefined tapes should be used.
The fourth section provides the link with the database TAPES file (described above). This section is also initially filled during the installation of Control Center, but will be maintained by Control Center when an archive is taken.
In Sample Database PARMS File, the archive_series parameter is set to |200, which matches the FILEDEF for the |next database archive in the database TAPES file. The Logarch_series is set to |100 |because the next log archive is associated with the last full database archive.
| Important: |
|---|
|
In the initial setup it is very important that the Archive_series parameter has a different value than the Logarch_series parameter. |
The fifth section of the PARMS file consists of the database startup parameters, which can be changed by the Administrators and DBAs when the database is up. They become effective the next time the database is started.
The sixth section of the PARMS file consists of parameters that must be specified for Data Restore functions such as BACKUP, TRANSLATE, RESTORE, UNLOAD, and RELOAD. These new parameters are described in further detail in Data Restore Parameters in the Database PARMS File.
****************************************************************** * SQLDBA PARMS (Sample) * ****************************************************************** :Nick.SQLDBA :Version.|7.1.0 | :Ccversion.7.1.0 :Administrators.DBA1 DBA2 AT NODE3 :Operators.OPER1 AT NODE2 OPER2 :Users.USER1 AT NODE2 USER2 :Notify_error.DBA1 DBA2 :Notify_severe.DBA1 :Notify_dbstatus.DBA1 :Notify_operator. ****************************************************************** *** Utility Parameters *** :S_Disk_Userid_Directory.SFSPOOL1:SQLDBA.SQL.SERVICE :S_Disk_Address_or_SFS.SFS :S_Disk_Userid_Directory_filemode.V :P_Disk_Userid_Directory.SFSPOOL1:SQLDBA.SQL.PRODUCTION :P_Disk_Address_or_SFS.SFS :P_Disk_Userid_Directory_filemode.Q :Archive_addspace.N :Archive_addextent.N :Uarchive_enabled.N :Submit_routine. :Cancel_routine. :Spool_console_option.N :Sqlend_quick.N ****************************************************************** *** Tape parameters *** :Tape_density.38K :Scratch_tape_option.N :Tape_retention.365 :Tape_archive_dsn.IU.SQLDBA.ARCHIVE :Tape_log_dsn.IU.SQLDBA.LARCH :Tape_trace_dsn. :Scratch_pool.SPSQLDBA :Logtape_premount.N ****************************************************************** *** Archiving/Tracing parameters *** :Archive_media.TAPE :Archive_blksize.28672 :Archive_series.|200 :Logarch_media.TAPE :Logarch_blksize.28672 :|Logarch_series.100 :Trace_media.DISK :Trace_blksize.4096 :|Trace_series.100 ****************************************************************** *** STARTUP parameters *** :Dbname.SQLDBA :Dcssid. :Sumdcssid. :Sysmode.M :Dbmode. :Logmode.L :Startup.W :Ncusers.8 :Npagbuf.500 :Ndirbuf.500 :Nlrbu. :Nlrbs. :Dispbias. :Ncscans. :Chkintvl. :Slogcush. :Archpct.75 :Soslevel. :Charname. :Ltimeout. :Account.D :Dumptype. :Extend. :Syncpnt. :Tracebuf.10 :Tracdbss.00010000100 :Tracrds.020000 :Tracdsc.00 :Tracconv.0 :Tracwum.0 :Tracdrrm.0000 :Tracstg.1 :Progname. :Tracing.OFF :Amode. :Protocol. :Npackage. :Npackpct. :Tcpport. :Tcpportr. :Sectype. :Secalver. :Ptimeout. :Procmxab. ****************************************************************** *** VMDSS parameters *** :Mapping. :Saveintv. :Sepintdb. :Targetws. ****************************************************************** *** Data Restore parameters *** :Drmstr_enabled.N :Data_restore_machine. :Drtape_premount.N :Data_restore_lang.S001 :Dual_backup.N :Backup_wrksize.2048 :Backup2_media. :Backup2_scratch_tape. :Incbackup_enabled. :Incbackup_series.|100.01 :Auto_full. :Current_increference. :Translate_media. :Translate_scratch_tape. :Tape_translate_dsn. :Tape_unload_dsn. :Tape_backup_dsn. :Tape_backup2_dsn.
This file is updated by Control Center or by an administrator. When a database archive occurs, the series parameters for archives and log archives will be updated by the service machine. Startup parameters will normally be changed by authorized users (Administrator, DBA).
Due to the asynchronous operation of Control Center, it is sometimes difficult to determine the cause of problems when they occur. When it is necessary to debug a problem, there are several sources of information available.
Each service machine keeps a running log on the 191 A-disk of every interrupt that occurs. This log can be viewed by linking the service machine's 191 A-disk in READ mode and using XEDIT or BROWSE to examine the current SQLMSTR LOGyyddd file (where yyddd is the Julian format date; yy is the year and ddd is the day of the year).
This file shows the sequence of interrupts that have occurred on the service machine for the day indicated by the Julian date. Control Center keeps logs of prior days' activities up to the number specified by the Log_copies parameter of the SQLMSTR CONTROL file.
A more detailed source of information is available in the SQLMSTR CONSOLE file of the service machine. This spool file records every screen I/O that is normally displayed on a terminal (console) if the machine was not running in disconnected mode. By viewing the SQLMSTR CONSOLE file, you see everything that you would see if you were logged onto the service machine during the entire time period covered by the console file.
Similar to the SQLMSTR LOGyyddd file, the SQLMSTR CONSOLE file is normally kept on a daily basis. Each night at midnight, the console is closed and the file transferred to the user ID specified on the OWNER statement in the SQLMSTR PROFILE file. The OWNER finds a new SQLMSTR CONSOLE file in their virtual reader each day, where it can be examined for possible errors and purged as desired.
At any given time, a user with Control Center's Administrator authority can have the current SQLMSTR CONSOLE closed and transferred to the requestor for debugging purposes. This is done in Control Center's command mode by using the SQM CONSOLE command, or in panel mode by selecting the CONSOLE CLOSE (CO) option under the General SQLMASTR commands (G) option on the Control Center main menu.
For problems related to a specific database, the machine's 191 A-disk contains several files which can help in debugging. Each file has a file name of the database machine name. The file type differs depending on the information within it. |For example, there is an SQLSTART file that is the CONSOLE output of the database machine| from the last time the database was started.
Each single user mode activity is also recorded in a separate file on the machine's 191 A-disk.:
The most common problems encountered with Control Center are related to the communication interface between the Control Center virtual machine and the database virtual machine. When the SCIF interface is not set up properly, then the Control Center virtual machine does not receive the database messages that are necessary for correct service machine operation. This will further result in the database not receiving the commands from Control Center to perform the expected operations.
The SCIF interface is tested during database startup and an error message will be sent to Control Center users if the interface is not operational. When this type of problem occurs, VM and SCIF expertise will be required to debug the cause and provide a solution.