As of Version 6, Version 1.x clients, including the clients packaged with DB2 Parallel Edition Version 1.2 servers, are no longer supported.
The distributed join installation feature and associated federated system functionality, as documented, are not currently supported with DB2 UDB Version 6.1.
The following has been added to the section "Before Creating a Database/DB2 Administration Server (DAS)/Setting Up DAS with EEE Systems/Discovery of Administration Servers, Instances, and Databases":
The Other Systems (Search the network) icon will only appear if the client's discover parameter is set to SEARCH. This is the default setting.
The following has been added to the section "Creating a Database/Creating a Table Space/RAW I/O":
In addition to the Linux operating system, the Windows 95 and Windows 98 operating systems do not allow you to attach a direct disk access (raw) device to the DB2 Universal Database system.
The following has been added to the section "DB2 Universal Database Version 5 Incompatibilities/Application Programming/NS, NW and NX Locks":
The incompatibility described in this section has been removed in Version 6.
The following has been added to the section "Collecting and Using Distribution Statistics":
Distribution statistics can be removed by updating SYSSTAT.COLDIST and setting all the COLVALUE and VALCOUNT values to either 0 or -1 for the columns for which distribution statistics are no longer needed.
The reference in the section "SQL Advise Facility" to a table called "EVALUATE_INDEXES" is incorrect. The correct name of the table is "ADVISE_INDEX".
The following information is missing from the Administration Guide - Design and Implementation, Appendix N. Lightweight Directory Access Protocol (LDAP) Directory Services:
Before you can use DB2 in the IBM LDAP environment, you must configure the following on each machine:
db2set DB2LDAPHOST=hostname[:port]
where hostname is the LDAP server's TCP/IP hostname, and [port] is the port number.
If a port number is not specified, DB2 will use the default LDAP port (389).
db2set DB2LDAP_BASEDN=baseDN
where baseDN is the name of the LDAP suffix that is defined at the LDAP server.
This LDAP suffix will be used to contain DB2 objects.
DB2 supports setting DB2 registry variables and CLI configuration at the user level. User level support provides user-specific settings in a multi-user environment, such as Windows NT Terminal Server, where each logon user can customize his own environment without interfering with the system environment or another user's environment.
When using the IBM LDAP directory, you must define an LDAP user (or person) before you can store user level information in LDAP. You can create an LDAP user in one of the following two ways:
An LDIF file containing the attributes for a person object will look similar to the following:
File name: newuser.ldif dn: cn=Mary Burnnet, ou=DB2 UDB Development, ou=Toronto, o=ibm, c=ca objectclass: ePerson cn: Mary Burnnet sn: Burnnet uid: mburnnet userPassword:password telephonenumber: 1-416-123-4567 facsimiletelephonenumber: 1-416-123-4568 title: Software Developer
Following is an example of the LDIF command to import an LDIF file using the IBM LDIF import utility:
ldif2db -i newuser.ldif
Notes:
Before running DB2, you must configure the LDAP user distinguished name (DN) and password for the current logon user. This can be done using the db2ldcfg utility:
db2ldcfg -u <userDN> -w <password> -> set the user's DN and password
-r -> clear the user's DN and password
For example:
db2ldcfg -u "cn=Mary Burnnet,ou=DB2 UDB Development,ou=Toronto,o=ibm,c=ca" -w password
In the section "Database Log Activity", the following change is needed to the "Number of Commits to Group (mincommit)" database configuration parameter.
Add the following information at the beginning of the "Recommendation" section of the parameter description:
Recommendation: The value for this parameter should be the default (1). Only increase this parameter by one for every 500 users; or, increase this parameter if you determine you have a high transaction rate.
In Chapter 2 ("Application Considerations") of the Administration Guide (Performance), in the section titled "Parallel Processing of Applications", change the following:
There is a database manager configuration parameter, intra_parallel, that enables or disables instance parallelism support. The default is "NO" for a uni-processor system and "YES" for SMP machines.
to
There is a database manager configuration parameter, intra_parallel, that enables or disables instance parallelism support.
Agents from the agent pool (num_poolagents) will be reused as coordinator agents:
Otherwise, remote applications will always create a new agent.
The Transaction Processor Monitor Name (tp_mon_name) default should be changed to <no default> for all operating systems.
This parameter specifies the maximum number of application programs (both local and remote) that can connect to the database at one time. The upper limit for this parameter has been increased from 5000 to 64000.
The default value for this parameter is incorrectly documented as 40 on UNIX based systems, and 20 on Windows NT and OS/2. The default value is actually 40 on UNIX based systems and Windows NT, and 20 on OS/2.
The minimum size of buffpage (and any buffer pool that is sized through SQL) is now 2 pages. However, the suggested minimum size of any buffer pool is at least 2*maxappls*dft_degree, to reduce the chances of not being able to fix a page because the buffer pool is full.
In the table under DB2_LIKE_VARCHAR, the values shown should be changed to:
Default=NO Values: YES, NO, or a floating point constant between 0 and 5.0.
In the table under DB2_BINSORT, the default value shown should be changed to YES.
This new registry variable applies to DB2 UDB EEE configurations only. If DB2 UDB is configured for high availability, and a node fails, this node can be restarted as a second logical node on a different host. The new registry variable allows a user to specify how much memory to reserve for FCM resources for failover nodes. For example, host A has two logical nodes, (1) and (2), and host B has two logical nodes, (3) and (4). Assume the user has set DB2_NUM_FAILOVER_NODES=2. The high availability configuration specifies that, in the event of node failure, the node(s) will be restarted on the other machine. During db2start, both A and B will reserve enough memory for the FCM component to run up to 4 logical nodes. Therefore, if B were to fail, we could successfully restart nodes (3) and (4) on host A, and vice-versa.
The default value for this registry variable is 2. It can be set to a value of less than 2, and there is no maximum value. The only limitation is the amount of physical memory on each machine.
The following statement should be added to the Unicode support section of this appendix:
Connection of a UTF-8 (code page 1208) client to a non-Unicode database is not supported.
The table of string types under section "Bidirectional-specific CCSIDs" of the National Language Support appendix in the Design and Implementation volume contains the following line:
4 Visual Arabic LTR Shaped OFF
This line should be changed to:
4 Visual Passthrough LTR Shaped OFF
The last table in the "National Language Support" appendix contains the following line:
055 Brazil dd.mm.yy JIS LOC LOC, USA, EUR, ISO
This line should be changed to:
055 Brazil dd/mm/yyyy JIS LOC LOC, EUR, ISO
Following are two new entries for this table:
355 Albania yyyy-mm-dd JIS LOC LOC, USA, EUR, ISO 084 Vietnam dd/mm/yyyy JIS LOC LOC, EUR, ISO
When adding nodes to partitioned databases, two problems may surface under the conditions described below. A number of suggested "workarounds" are discussed in the context of a sample database with two partitions (MPP1 with node numbers 0 and 1). Nodegroup NG1 includes nodes 0 and 1, and table space TS1 uses a page size of 8KB.
When adding nodes to partitioned databases that have temporary table spaces of 8KB, 16KB, or 32KB pages, DB2 will return "SQL6073N Add Node operation failed", because only the IBMDEFAULTBP bufferpool exists (with a page size of 4KB) at the time of creating this node.
PROBLEM: The db2start command is used to add a node to the current partitioned database.
Example:
db2start nodenum 2 addnode hostname NEWHOST port 2
which normally returns:
SQL6075W The start database manager operation successfully added the node.
The node is not active until all nodes are stopped and started again.
will now return:
SQL6073N Add Node operation failed. SQLCODE = "<-902>"
PROBLEM: The ADD NODE command is used on the new node after the db2nodes.cfg file is manually updated with
the new node description.
Example:
Edit db2nodes.cfg to add the node information for the new node.
db2 add node
which normally returns:
DB20000I The ADD NODE command completed successfully.
will now return:
SQL6073N Add Node operation failed. SQLCODE = "<-902>"
One workaround is to run "db2set DB2_HIDDENBP=16" before issuing db2start or the ADD NODE command. This will enable DB2 to allocate hidden 8KB, 16KB, and 32KB bufferpools of 16 pages each, and enable the add node operation to proceed successfully by creating the non-4KB page size table spaces on the new node. Another workaround is to specify the WITHOUT TABLESPACES option with the ADD NODE or the db2start command, and later to manually create the bufferpools using the CREATE BUFFERPOOL statement, and the temporary table spaces using the ALTER TABLESPACE statement.
When adding a node to an existing nodegroup through the ALTER NODEGROUP ADD NODE statement, where the existing nodegroup has table spaces with 8KB, 16KB, or 32KB pages, DB2 will return "SQL0647N Bufferpool '' is not currently active", because the non-4KB bufferpools created on the new node have not yet been activated for the table spaces.
PROBLEM: The ALTER NODEGROUP statement is used to add a node to a nodegroup.
Example:
db2start
db2 connect to MPP1
db2 alter nodegroup NG1 add node (2)
which normally returns:
SQL1759W Redistribute nodegroups required to change data partitioning for objects in nodegroup.
will now return:
SQL0647N Bufferpool '' is currently not active.
The workaround is to create 8KB, 16KB, or 32KB page size bufferpools, and then to reconnect to the database before issuing the ALTER NODEGROUP statement.
Example:
db2start
db2 connect to MPP1
db2 create bufferpool BP1 size 1000 pagesize 8192
db2 connect reset
db2 connect to MPP1
db2 alter nodegroup NG1 add node (2)
or
db2set DB2_HIDDENBP=16
db2start
db2 connect to MPP1
db2 alter nodegroup NG1 add node (2)
PROBLEM: The ALTER TABLESPACE statement is used to add a table space to a node.
Example:
db2start
db2 connect to MPP1
db2 alter nodegroup NG1 add node (2) without tablespaces
db2 alter tablespace TS1 add ('TS1') on node (2)
which normally returns:
SQL1759W Redistribute nodegroups required to change data partitioning for objects in nodegroup.
will now return:
SQL0647N Bufferpol '' is currently not active.
The workaround is to reconnect to the database after the ALTER NODEGROUP WITHOUT TABLESPACES statement.
Example:
db2start
db2 connect to MPP1
db2 alter nodegroup add node (2) without tablespaces
db2 connect reset
db2 connect to MPP1
db2 alter tablespace TS1 add ('TS1') on node (2)
or
db2set DB2_HIDDENBP=16
db2start
db2 connect to MPP1
db2 alter nodegroup add node (2) without tablespaces
db2 alter tablespace TS1 add ('TS1') on node (2)
Under most versions of Linux, using DB2's default buffer sizes for backup and restore to a SCSI tape device will result in an SQL2025, reason code "75". To prevent the overflow of Linux internal SCSI buffers, use the following formula:
bufferpages <= ST_MAX_BUFFERS * ST_BUFFER_BLOCKS / 4
where bufferpages is the value of BACKBUFSZ or RESTBUFSZ. ST_MAX_BUFFERS and ST_BUFFER_BLOCKS are defined in the Linux kernel under drivers/scsi.