DB2 10.5 for Linux, UNIX, and Windows
DB2 10.5 for Linux, UNIX, and Windows
You use the system environment variables to pass configuration values to running applications in the DB2® environment. Some system environment variables only apply to specific operating system environments.
db2set -i db2inst1 0 DB2_CPU_BINDING="NUM_CORES=1"db2set -i db2inst1 DB2_CPU_BINDING="NUM_CORES=2.5"db2set -i db2inst1 128 DB2_CPU_BINDING="NUM_CORES=4"db2set -i db2inst1 0 DB2_CPU_BINDING="PROCESSOR_LIST=2,10,6,14"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 platform.
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.
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 it is picked up by the DB2 service.
Connection to DB2 is denied to users who are denied AIX login by rlogin or telnet. This option is equivalent to the S_RLOGIN option of the loginrestrictions() API.
Connection to DB2 is denied to users who are denied by AIX to become a substitute user with the su command. This option is equivalent to the S_SU mode of the loginrestrictions() API.
Connection to DB2 is denied to users who are denied AIX login. This option is equivalent to the S_LOGIN option of the loginrestrictions() API.
The restrictions that affect the REMOTE, SU, or LOCAL options are not considered with the NONE option. This option is equivalent to the mode 0 option of the loginrestrictions() API.
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 will be 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 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, five 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 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 dedicated to it, setting the registry variable might result in contention on those disks because the two prefetchers will be accessing each of the two disks at once. 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 once.
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 aids users in identifying the system that contains the database they wish to access. A value for DB2SYSTEM is set at installation time as follows:
DB2_UPDDBCFG_SINGLE_DBPARTITION enables you to revert to the behavior of previous versions of DB2, in which updates to a database configuration apply only to the local database partition or the database partition that is set by the DB2NODE registry variable. This allows for backward compatibility support for any existing command scripts or applications that require this behavior.
When set to 1, TRUE, or, YES, this registry variable allows you to specify that any updates and resets to your database affect only a specific partition. If the variable is not set (the default), updates or changes to a database configuration act across all database partitions, when you do not specify a partition clause.
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 need to access more physical disks than would be optimal. Users are strongly advised against enabling this registry variable unless you have very 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.
When you have set DB2_WORKLOAD=SAP, the user table space SYSTOOLSPACE and the user temporary table space SYSTOOLSTMPSPACE are not automatically created. These table spaces are used for tables created automatically by the following wizards, utilities, or functions:
Without the SYSTOOLSPACE and SYSTOOLSTMPSPACE table spaces, you cannot use these wizards, utilities, or functions.
To be able to use these wizards, utilities, or functions, do either of the following:
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 mentioned earlier.