A number of parameters can help you manage your database manager instances. These are grouped into the following categories:
The following parameters allow you to control diagnostic information available from the database manager:
The type of diagnostic errors recorded in the error log file is determined by this parameter. Valid values are:
0 - No diagnostic data captured
1 - Severe errors only
2 - All errors
3 - All errors and warnings
4 - All errors, warnings and informational messages
It is the diagpath configuration parameter that is used to specify the directory that will contain the error log file, event log (on Windows NT only), alert log file, and any dump files that may be generated based on the value of the diaglevel parameter.
Recommendation: You may wish to increase the value of this parameter to gather additional problem determination data to help resolve a problem.
This parameter allows you to specify the fully qualified path for DB2 diagnostic information. This directory could possibly contain dump files, trap files, an error log and an alert log file, depending on your platform.
If this parameter is null, the diagnostic information will be written to files in one of the following directories or folders:
| Note: | The directory does not have to be named SQLLIB. |
Recommendation: Use the default or have a centralized location for the diagpath of multiple instances.
In a multinode environment, the path you specify must reside on a shared file system.
The following parameter allows you to control various aspects of the database system monitor:
This parameter is unique in that it allows you to set a number of switches which are each internally represented by a bit of the parameter. Depending on the interface you are using to update the database manager configuration, you may be able to update this parameter directly. You may also update each of these switches independently by setting the following parameters:
Changes to any of these database system monitor switches take effect immediately; that is, you do not have to stop and restart the database manager.
| Note: | An existing monitoring application will not automatically use the new default value for a switch. To use the new value (or values), the application must terminate and re-attach to the instance. |
For more information about the snapshot monitor and how it uses monitor switches, see the System Monitor Guide and Reference.
Recommendation: Any switch that is turned ON instructs the database manager to collect monitor data related to that switch. Collecting additional monitor data increases database manager overhead which can impact system performance.
All monitoring applications inherit these default switch settings when the application issues its first monitoring request (for example, setting a switch, activating the event monitor, taking a snapshot). You should turn on a switch in the configuration file only if you want to collect data starting from the moment the database manager is started. (Otherwise, each monitoring application can set its own switches and the data it collects becomes relative to the time its switches are set.)
The following parameters relate to system management:
A value of -1 causes the parameter value to be reset to the default. The default value is calculated based on whether a high speed switch is being used.
The value calculated for the communications bandwidth, in megabytes per second, is used by the SQL optimizer to estimate the cost of performing certain operations between the database partition servers of a partitioned database system. The optimizer does not model the cost of communications between a client and a server, so this parameter should reflect only the nominal bandwidth between the database partition servers, if any.
You can explicitly set this value to model a production environment on your test system or to assess the impact of upgrading hardware.
Recommendation: You should only adjust this parameter if you want to model a different environment.
The communications bandwidth is used by the optimizer in determining access paths. You should consider rebinding applications (using the REBIND PACKAGE command) after changing this parameter.
The CPU speed, in milliseconds per instruction, is used by the SQL optimizer to estimate the cost of performing certain operations. The value of this parameter is set automatically when you install the database manager based on one of the following:
| Note: | You may update the db2spec.dat file if you have SYSADM authority. You should carefully follow the instructions contained in that file. |
You can explicitly set this value to model a production environment on your test system or to assess the impact of upgrading hardware. By setting it to -1, cpuspeed will be re-computed.
Recommendation: You should only adjust this parameter if you want to model a different environment.
The CPU speed is used by the optimizer in determining access paths. You should consider rebinding applications (using the REBIND PACKAGE command) after changing this parameter.
This parameter specifies the number of local databases that can be concurrently active (that is, have applications connected to them). In a partitioned database environment, it limits the number of active database partitions on a database partition server, whether that server is the coordinator node for the application or not.
Since each database takes up storage and an active database uses a new shared memory segment, you can reduce system resource usage by limiting the number of separate databases on your machine. However, arbitrarily reducing the number of databases is not the answer. That is, putting all data, no matter how unrelated, in one database will reduce disk space, but may not be a good idea. It is generally a good practice to only keep functionally related information in the same database.
Recommendation: It is generally best to set this value to the actual number of databases that are already defined to the database manager and to add a reasonable increment to account for future growth in the number of databases over the short term (for example, 6 months to 1 year). The actual increment should not be excessively large, but it should allow you to add new databases without having to frequently update this parameter.
Changing the numdb parameter may impact the total amount of memory allocated. As a result, frequent updates to this parameter are not recommended. When updating this parameter, you should consider the other configuration parameters that can allocate memory for a database or an application connected to that database, including:
This parameter identifies the name of the transaction processing (TP) monitor product being used. If applications are run in a CICS environment, this parameter should be set to "CICS"; if Encina Monitor is being used, this parameter should be set to "ENCINA".
In OS/2 and NT environments, this parameter contains the path and name of the DLL in an external transaction manager product containing functions ax_reg and ax_unreg, if an XA Distributed Transaction Processing environment is being used. Specify "dll-name:C" for CICS, or "dll-name:E" for ENCINA. The maximum length of the string that can be specified for this parameter is 19 characters.
This parameter provides information about the DB2 products which you have installed on your machine and, as a result, information about the type of database manager configuration. The following are the possible values returned by this parameter and the products associated with that node type:
The API constant for this node type is SQLF_NT_SERVER. The numeric value is 1.
The API constant for this node type is SQLF_NT_REQUESTER. The numeric value is 2.
The API constant for this node type is SQLF_NT_STAND_REQ. The numeric value is 3.
The API constant for this node type is SQLF_NT_MPP. The numeric value is 4.
With each application connect request, an accounting identifier consisting of a DB2 Connect-generated prefix and the user supplied suffix is sent from the application requester to a DRDA application server. This accounting information provides a mechanism for system administrators to associate resource usage with each user access.
The suffix is supplied by the application program calling the sqlesact() API or the user setting the environment variable DB2ACCOUNT. If a suffix is not supplied by either the API or environment variable, DB2 Connect uses the value of this parameter as the default suffix value. This parameter is particularly useful for down-level database clients (anything prior to version 2) that do not have the capability to forward an accounting string to DB2 Connect.
Recommendation: Set this accounting string using the following:
This parameter specifies the directory under which the Java Development Kit 1.1 is installed. The CLASSPATH and other environment variables used by the Java interpreter are computed from the value of this parameter.
Because there is no default for this parameter, you should specify a value for this parameter when you install the Java Development Kit.
The following parameters relate to security and administration of your database manager instance:
System administration (SYSADM) authority is the highest level of authority within the database manager and controls all database objects. This parameter defines the group name with SYSADM authority for the database manager instance.
SYSADM authority is determined by the security facilities used in a specific operating environment. The following considerations apply when system security (that is, authorization) is CLIENT, SERVER, or DCS. Considerations for DCE security are described below.
This parameter must be "NULL" for Windows 95 clients when system security is used because the Windows 95 operating system does not store group information, thereby providing no way of determining if a user is a member of a designated SYSADM group. When a group name is specified, no user is considered to be a member of it and no user is considered to have administration authority.
If the value is not "NULL", the SYSADM group can be any valid UNIX group name.
If a group name is specified for this parameter, only users who belong to the group have SYSADM authority. The group specified can be any of the User Profile Management (user profile management) groups. For more information on User Profile Management groups, see your Quick Beginnings for OS/2 book.
If DCE security is used and sysadm_group is "NULL", the default DCE group name DB2ADMIN is used. A valid DCE principal whose authid mapping is DB2ADMIN must already exist. You can specify a different group name (this also applies for Windows 95 clients).
To restore the parameter to its default (NULL) value, use UPDATE DBM CFG USING SYSADM_GROUP NULL. You must specify the keyword "NULL" in uppercase. You can also use the Configure Instance notebook in the DB2 Control Center.
This parameter defines the group name with system control (SYSCTRL) authority. SYSCTRL has privileges allowing operations affecting system resources, but not allowing direct access to data.
Attention: This parameter must be NULL for Windows 95 clients when system security is used (that is, authorization is CLIENT, SERVER, or DCS). This is because the Windows 95 operating system does not store group information, thereby providing no way of determining if a user is a member of a designated SYSCTRL group. When a group name is specified, no user is considered to be a member of it and no user is considered to have system control authority. This is not true when DCE authentication is used. In this situation, group names can be specified.
To restore the parameter to its default (NULL) value, use UPDATE DBM CFG USING SYSCTRL_GROUP NULL. You must specify the keyword "NULL" in uppercase. You can also use the Configure Instance notebook in the DB2 Control Center.
This parameter defines the group name with system maintenance (SYSMAINT) authority. SYSMAINT has privileges to perform maintenance operations on all databases associated with an instance without having direct access to data.
Attention: This parameter must be NULL for Windows 95 clients when system security is used (that is, authorization is CLIENT, SERVER, or DCS). This is because Windows 95 does not store group information, thereby providing no way of determining if a user is a member of a designated SYSMAINT group. When a group name is specified, no user is considered to be a member of it and no user is considered to have system control authority. This is not true when DCE authentication is used. In this situation, group names can be specified.
To restore the parameter to its default (NULL) value, use UPDATE DBM CFG USING SYSMAINT_GROUP NULL. You must specify the keyword "NULL" in uppercase. You can also use the Configure Instance notebook in the DB2 Control Center.
This parameter determines how and where authentication of a user takes place. If authentication is SERVER, then the user ID and password are sent from the client to the server so authentication can take place on the server. A value of CLIENT indicates that all authentication takes place at the client, so no authentication needs to be performed at the server. For a client-only node, CLIENT, SERVER, and DCS are effectively the same. A value of DCE means that authentication is performed using DCE Security Services. If you are using APPC and a communications product that does not expose the client's password to the DB2 server, you can specify DCS to obtain:
For more information on when and why to use DCE or DCS, see "Authentication".
The following show the constants to use for possible values for this parameter:
Recommendation: Typically, the default (SERVER) is adequate. If you have incoming requests that are handled by either DB2 Connect or DCE, refer to "Authentication".
This parameter specifies whether users are able to catalog and uncatalog databases and nodes, or DCS and ODBC directories, without SYSADM authority. The default value (0) for this parameter indicates that SYSADM authority is required. When this parameter is set to 1 (yes), SYSADM authority is not required.
This parameter contains the default file path used to create databases under the database manager. If no path is specified when a database is created, the database is created under the path specified by the dftdbpath parameter.
In a partitioned database environment, you should ensure that the path on which the database is being created is not an NFS-mounted path (on UNIX-based platforms), or a network drive (in the Windows NT environment). The specified path must physically exist on each database partition server. To avoid confusion, it is best to specify a path that is locally mounted on each database partition server. The maximum length of the path is 205 characters. The system appends the node name to the end of the path.
Given that databases can grow to a large size and that many users could be creating databases (depending on your environment and intentions), it is often convenient to be able to have all databases created and stored in a specified location. It is also good to be able to isolate databases from other applications and data both for integrity reasons and for ease of backup and recovery.
For UNIX-based environments, the length of the dftdbpath name cannot exceed 215 characters and must be a valid, absolute, path name. For OS/2 and Windows NT, the dftdbpath can be a drive letter, optionally followed by a colon.
Recommendation: If possible, put high volume databases on a different disk than other frequently accessed data, such as the operating system files and the database logs.
This parameter is applicable to the OS/2 environment only. By accepting the default for this parameter, a LOGON user ID and password is required before issuing a DB2START or DB2STOP.
This parameter is only active when the authentication parameter is set to CLIENT.
This parameter and trust_clntauth are used to determine where users are validated to the database environment.
By accepting the default of "YES" for this parameter, all clients are treated as trusted clients. This means that the server assumes that a level of security is available at the client and the possibility that users can be validated at the client.
This parameter can only be changed to "NO" if the authentication parameter is set to CLIENT. If this parameter is set to "NO", the untrusted clients must provide a userid and password combination when they connect to the server. Untrusted clients are operating system platforms that do not have a security subsystem for authenticating users.
For more information on trusted clients, see "Selecting an Authentication Method for Your Server".
This parameter specifies whether a trusted client is authenticated at the server or the client when the client provides a userid and password combination for a connection. This parameter (and trust_allclnts) is only active if the authentication parameter is set to CLIENT. If a user ID and password are not provided, the client is assumed to have validated the user, and no further validation is performed at the server.
If this parameter is set to "CLIENT" (the default), the trusted client can connect without providing a userid and password combination, and the assumption is that the operating system has already authenticated the user. If it is set to "SERVER", the user ID and password will be validated at the server.
The numeric value for CLIENT is 0. The numeric value for SERVER is 1.
For more information on trusted clients, see "Selecting an Authentication Method for Your Server".