DB2 Version 9.7 for Linux, UNIX, and Windows
DB2 Version 9.7 for Linux, UNIX, and Windows
This variable can be used to fine-tune the address space layout of DB2 processes. This variable changes the location of the instance shared memory from its current location at virtual address 0x10000000 to the new value.
db2set DB2DBMSADDR= 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, a notification file, and an alert log file, depending on your operating system.
Setting this environment variable has the same effect for ODBC and CLI applications in the scope of that environment as setting the DB2 database manager configuration parameter diagpath, and as setting the CLI/ODBC configuration keyword DiagPath.
This variable is effective only when CLIENT authentication is set in the database manager configuration. It is needed if a single sign-on from a Windows desktop is required in a Windows domain environment.
DB2 servers versions 7.1 or later support DB2DOMAINLIST, but only in a pure Windows domain environment. Starting with Version 8 Fix Pack 15 and Version 9.1 Fix Pack 3, DB2DOMAINLIST is supported if either the client or the server is running in a Windows environment.
On Windows operating systems, this variable should be set in the global system environment to ensure that it is picked up by the DB2 service.
DB2 enforces login restrictions to verify that the account can be used for remote logins through the rlogind or telnetd programs only.
DB2 Version 9.1 enforces su restrictions to verify that the su command is permitted, and that the current process has a group ID that can start the su command to switch to the account only.
DB2 does not enforce any login restrictions.
DB2 enforces login restrictions to verify that local logins are permitted for this account only. This is the normal behavior when you log in.
No matter which one of these options you set, user accounts or IDs that have the specified privileges are able to use DB2 successfully both locally on the server and from remote clients. For a description of the loginrestrictions() API, refer to AIX documentation.
You can replace TablespaceID with an asterisk (*) to specify all table spaces. For example, if DB2_PARALLEL_IO=*, all table spaces use six as the number of disks per container. If you specify both an asterisk (*) and a table space ID, the table space ID setting takes precedence. For example, if DB2_PARALLEL_IO =*,1:3, all table spaces use six as the number of disks per container, except for table space 1, which uses three.
You might want to set the registry variable if the individual containers in the table space are striped across multiple physical disks or if the container in a table space is created on a single RAID device that is composed of more than one physical disk.
If this registry variable is not set, the degree of parallelism of any table space is the number of containers of the table space. For example, if DB2_PARALLEL_IO is set to NULL and a table space has four containers, four extent-sized prefetch requests are issued; or if a table space has two containers and the prefetch size is four times the extent size, the prefetch request for this table space will be broken into two requests (each request is for two extents).
If this registry variable is set, and the prefetch size of the table is not AUTOMATIC, the degree of parallelism of the table space is the prefetch size that is divided by the extent size. For example, if DB2_PARALLEL_IO is set for a table space that has a prefetch size of 160 and an extent size of 32 pages, 5 extent-sized prefetch requests are issued.
| Prefetch size of table space | DB2_PARALLEL_IO Setting | Parallelism is equal to: |
|---|---|---|
| AUTOMATIC | Not set | Number of containers |
| AUTOMATIC | Table space ID | Number of containers * 6 |
| AUTOMATIC | Table space ID:n | Number of containers * n |
| Not AUTOMATIC | Not set | Number of containers |
| Not AUTOMATIC | Table space ID | Prefetch size/extent size |
| Not AUTOMATIC | Table space ID:n | Prefetch size/extent size |
Disk contention might result by using this variable in some scenarios. For example, if a table space has two containers and each of the two containers have each a single disk that is dedicated to it, setting the registry variable might result in contention on those disks because the two prefetchers are accessing each of the two disks at the same time. However, if each of the two containers was striped across multiple disks, setting the registry variable would potentially allow access to four different disks at the same time.
To activate changes to this registry variable, issue a db2stop command and then enter a db2start command.
When specified, DB2 issues the SetProcessAffinityMask() API. If unspecified, the db2syscs process is associated with all processors on the server.
This name is displayed in the system level of the Control Center's object tree to aid administrators in the identification of server systems that can be administered from the Control Center.
When you are using the Search the Network function of the Configuration Assistant, DB2 discovery returns this name and it is displayed at the system level in the resulting object tree. This name aids users in identifying the system that contains the database they want to access. A value for DB2SYSTEM is set at installation time as follows:
However, if you set this registry variable to ON when you use RAID devices for containers, I/O performance might degrade. Because for RAID devices you create table spaces with an extent size equal to or a multiple of the RAID stripe size, setting the DB2_USE_PAGE_CONTAINER_TAG to ON causes the extents not to line up with the RAID stripes. As a result, an I/O request might must access more physical disks than would be optimal. Users are advised against enabling this registry variable unless you have tight space constraints, or you require behavior consistent with pre-Version 8 databases.
To activate changes to this registry variable, issue a db2stop command and then enter a db2start command.
Without the SYSTOOLSPACE and SYSTOOLSTMPSPACE table spaces, you cannot use these wizards, utilities, or functions.
CREATE REGULAR TABLESPACE SYSTOOLSPACE
IN IBMCATGROUP
MANAGED BY SYSTEM
USING ('SYSTOOLSPACE')CREATE USER TEMPORARY TABLESPACE SYSTOOLSTMPSPACE
IN IBMCATGROUP
MANAGED BY SYSTEM
USING ('SYSTOOLSTMPSPACE')Once the table space SYSTOOLSPACE and the temporary table space SYSTOOLSTMPSPACE are created, you can use the wizards, utilities, or functions that are mentioned earlier.