The format of the names for the containers has changed in such a way that the table space ID and the container ID have also changed. The new format is:
<storage path>/<instance>/NODE#### /T####### /C#######.<EXT>
where:
Starting with DB2(R) Universal Database Version 8.2.2 (equivalent to Version 8.1 FixPak 9), generated columns can be used in unique indexes.
Generated columns cannot be used in constraints, referential constraints, primary keys, and global temporary tables. A table created with LIKE and materialized views does not inherit generated column properties.
When you have set DB2WORKLOAD=SAP, the user table space SYSTOOLSPACE and the user temporary table space SYSTOOLSTEMPSPACE are not automatically created. These table spaces are used for tables created automatically by the following wizards, utilities, or functions:
Without the SYSTOOLSPACE and SYSTOOLSTEMPSPACE table spaces, you cannot use these wizards, utilities, or functions.
To be able to use the wizards, utilities, or functions, do either of the following:
CREATE REGULAR TABLESPACE SYSTOOLSPACE
IN IBMCATGROUP
MANAGED BY SYSTEM
USING ('SYSTOOLSPACE')After completing at least one of these choices, create a user temporary table space (also on the catalog node only, if using DPF). For example:
CREATE USER TEMPORARY TABLESPACE SYSTOOLSTMPSPACE
IN IBMCATGROUP
MANAGED BY SYSTEM
USING ('SYSTOOLSTMPSPACE')
Once the table space SYSTOOLSPACE and the temporary table space SYSTOOLSTEMPSPACE are created, you can use the wizards, utilities, or functions mentioned earlier.
The authentication type DATA_ENCRYPT_CMP is designed to allow clients from a previous release that do not support data encryption to connect to a server using SERVER_ENCRYPT authentication instead of DATA_ENCRYPT. This authentication does not work when the following three statements are true:
In this case, the client cannot connect to the server. To allow the connection, you must either upgrade your client to Version 8, or have your gateway level at Version 8 FixPak 6 or earlier.
Direct I/O (DIO) improves memory performance because it bypasses caching at the file system level. This process reduces CPU overhead and makes more memory available to the database instance.
Concurrent I/O (CIO) includes the advantages of DIO and also relieves the serialization of write accesses.
DB2 Universal Database(TM) (UDB) supports DIO and CIO on AIX(R); and DIO on HP-UX, Solaris Operating Environment, Linux(TM), and Windows(R).
The keywords NO FILE SYSTEM CACHING and FILE SYSTEM CACHING are part of the CREATE and ALTER TABLESPACE SQL statements to allow you to specify whether DIO or CIO is to be used with each table space. When NO FILE SYSTEM CACHING is in effect, DB2(R) UDB attempts to use concurrent I/O wherever possible. In cases, where CIO is not supported (for example, if JFS is used), DIO is used instead.
For more information, refer to the article "Improve database performance on file system containers in IBM(R) DB2 UDB Stinger using Concurrent I/O on AIX" located at the following URL:
http://www.ibm.com/developerworks/db2/library/techarticle/dm-0408lee/
The following information is part of the Administration Guide: Implementation Appendix B "Using automatic client rerouting":
The DB2 Universal Database for Linux, UNIX(R), and Windows automatic client reroute feature allows client applications to recover from a loss of communication with the server by automatically reestablishing the database connection from the client to the server, so that the application can continue to work with minimal interruption.
When a client to server connection fails, the client's requests for reconnection are distributed to a defined set of systems by a distributor or dispatcher, such as WebSphere(R) EdgeServer
You may be using Distributor Technology in an environment similar to the following:
Client --> Distributor Technology --> (DB2 Connect(TM) Server 1 or DB2 Connect Server 2) --> DB2 z/OS(R)
where:
The client is catalogued using DThostname in order to utilize the distributor technology to access either of the DB2 Connect Servers. The intervening distributor technology makes the decision to use GWYhostname1 or GWYhostname2. Once the decision is made, the client has a direct socket connection to one of these two DB2 Connect gateways. Once the socket connectivity is established to the chosen DB2 Connect server, you have a typical client to DB2 Connect server to DB2 z/OS connectivity.
For example, assume the distributor chooses GWYhostname2. This produces the following environment:
Client --> DB2 Connect Server 2 --> DB2 z/OS
The distributor does not retry any of the connections if there is any communication failure. If you want to enable the Automatic Client Reroute feature for a database in such an environment, the alternate server for the associated database or databases in the DB2 Connect Server (DB2 Connect Server 1 or DB2 Connect Server 2) should be set up to be the distributor (DThostname). Then, if DB2 Connect Server 1 locks up for any reason, Automatic Client Reroute is triggered and client connection is retried with the distributor as both primary and alternate server. This option allows you to combine and maintain the distributor capabilities with the DB2 Automatic Client Reroute feature. Setting the alternate server to a host other than the distributor host name will still provide the clients with the Automatic Client Reroute feature. However, the clients will establish direct connections to the defined alternate server and bypass the distributor technology, which eliminates the distributor and the value that it brings.
Automatic Client Reroute will intercept the following sqlcodes:
Consider the following two items involving alternate server connectivity with DB2 Connect server:
Applications running under the context of the local system account (LSA) are supported on all Windows platforms, except Windows ME.
The CONNECT statement and ATTACH command support two-part user IDs. The qualifier of the SAM-compatible user ID is the NetBIOS style name which has a maximum length of 15 characters. This feature is not supported on Windows ME.
You can override the Kerberos server principal name used by the DB2(R) Universal Database (UDB) server on UNIX(R) and Linux(TM) operating systems. Set the DB2_KRB5_PRINCIPAL environment variable to the desired fully qualified server principal name. The instance must be restarted because the server principal name is only recognized by DB2 UDB after db2start is run.
The prerequisites for Linux Kerberos support are inaccurately reported in the documentation. The provided DB2 Kerberos security plug-in is supported with Red Hat Enterprise Linux Advanced Server 3 with the IBM Network Authentication Service (NAS) 1.4 client.
For connections to zSeries and iSeries, the database must be cataloged with the AUTHENTICATION KERBEROS parameter and the TARGET PRINCIPAL parameter name must be explicitly specified.
Neither zSeries nor iSeries support mutual authentication.
Furthermore, in all cases, the DB2 administration log or db2diag.log will indicate "Logon failed" or "Logon denied."
The Local Security Authority cannot be contactedThe error is a result of Windows locating the local user first. The solution is to fully qualify the user in the connection string. For example:
name@DOMAIN.IBM.COM
To determine if Windows accounts are configured to use DES encryption, look under Account properties in the Active Directory. A restart might be required if the account properties are changed.
host/<server hostname>@<server domain name>For example:
host/myhost.domain.ibm.com@DOMAIN.IBM.COMOtherwise, you must start the DB2 service under a valid domain account.