Backward compatibility

3 3 3

Alternate FixPaks (Linux and UNIX)

3 3

Prior to DB2^(R) Universal Database Version 8, FixPaks functioned only as updates 3to installed DB2 Universal Database^(TM) packages or file sets in one fixed location. 3Essentially, this meant that the installation of FixPaks replaced existing 3files with the updated ones provided within the FixPaks, and multiple DB2 3FixPak levels on a single system was not possible. Now, DB2 UDB (ESE) can 3exist at multiple fix pack levels in the same system. This feature, supported 3in production operating environments since Version 8.1.2, is achieved using 3the following two FixPak types:

regular FixPaks

33 3

Are available not only for ESE, but for all supported DB2 Version 8 products 3for the related platforms

Can be installed directly on top of the existing installation either in 3the /usr/opt/db2_08_01 directory on AIX^(R) 3or the /opt/IBM/db2/V8.1 directory on other platforms

alternate FixPaks

33 3

Can be installed as completely new copies of DB2 Universal Database ESE

Are installed in a predefined location other than the location used for 3a regular DB2 Universal Database installation

3 3 3

Notes:

You are not required to perform a multiple FixPak 3installation if it is unnecessary for your environment.

3Starting with IBM^(R) DB2 Universal Database Enterprise Server Edition 3(ESE) for Linux and UNIX^(R), Version 8.1.2, fix packs are supported in 3production operating environments when they are installed as Multiple fix 3packs.3

7On Linux, alternate FixPaks are available on the following platforms 7only: 7
- x86 (32-bit)
- S/390^(R) (31-bit)
3

To update a multiple FixPak instance to a different FixPak level, perform 3one of the following operations:

Install the appropriate regular FixPak on the General Availability (GA) 3installation and update the instance by running db2iupdt from the existing GA path.

Install the appropriate alternate FixPak to its own unique path and update 3the instance by running db2iupdt from this path.

For further information regarding downloading alternate FixPaks, visit 3the IBM support site at http://www.ibm.com/software/data/db2/udb/winos2unix/support.

Data Warehouse Center previous server support restrictions

The following limitations exist for previous server support for DB2 Universal Database (DB2 UDB) Enterprise Server Edition Version 8 Data Warehouse Center:

Large Object (LOB) support

If you are using a warehouse control database on a server that is earlier than DB2 UDB Enterprise Server Edition Version 8 you cannot work with LOBs. You must upgrade the warehouse control database to the correct level, or you can move the control database to the system on which the DB2 UDB Enterprise Server Edition Version 8 warehouse server is installed and use the warehouse control database locally from that system.
To move LOBs between the Data Warehouse Center and DB2 UDB, you must upgrade to DB2 UDB Enterprise Server Edition, Version 8.

Systems Network Architecture (SNA) support

If you use SNA to connect to your warehouse sources and targets, you must change the configuration to TCP/IP over SNA or use the Windows^(R) NT warehouse agent.

Support for EXPORT and LOAD utilities

The Data Warehouse Center Version 8 LOAD utility does not support a Version 7 target database. If you want to keep your target as a Version 7 database, then you must change the LOAD step to a SQL Select and Insert step. SQL Select and Insert steps use a DELETE* statement followed by SELECT and INSERT statements. SQL Select and Insert steps require the database to log all transactions. As a result, the performance for SQL Select and Insert steps is not as efficient as it is for the EXPORT and LOAD utilities.

2Development Center APARs required for SQLJ and SQL Assist 2support on DB2 UDB for OS/390, Version 6 and DB2 UDB for z/OS, Version 7

2When using the Development Center on an Application Development 2client for DB2 Universal Database Version 8 on Windows or UNIX operating systems, 2the following APARs need to be installed on the server to enable SQLJ and 2SQL Assist support:

2DB2 UDB for z/OS^(TM), Version 7

2PQ65125 - Provides SQLJ support for building Java^(TM) SQLJ stored 2procedures
6PQ76858 - Provides SQL Assist support

2DB2 UDB for OS/390^(R), Version 6

6PQ76858 - Provides SQL Assist support

Two versions of SQL Assist are launched from DB2 UDB

You can invoke both version 7 and version 8 of SQL Assist from within DB2 Universal Database, Version 8. You can start version 7 from the DB2 Data Warehouse Center. All other centers start the latest version 8. The product online help has additional information for SQL Assist, Version 7.

Change in Unicode server behavior

In version 7, Unicode servers ignored any graphic code pages sent by applications at connect time and assumed that UCS2 Unicode (code page 1200) was being used. Version 8 Unicode servers now respect the code page sent by the client.

7 7 7

Change in output for the db2move command

In Version 8.2, the summary output generated by the db2move command is more descriptive than in earlier versions. This change 7can cause errors in scripts that analyze the output.

7When db2move is executed with the IMPORT option 7

Output prior to Version 8.2

77 7

IMPORT: -Rows read: 5; -Rows committed: 5; Table "DSCIARA2"."T20"

Output starting with Version 8.2

77 7

* IMPORT:  table "DSCIARA2"."T20"
7  -Rows read:          5
7  -Inserted:           4
7  -Rejected:           1
7  -Committed:          5

7When db2move is executed with the LOAD option 7

Output prior to Version 8.2

77 7

* LOAD:  table "DSCIARA2"."T20"
7  -Rows read: 5 -Loaded: 4 -Rejected 1 -Deleted 0 -Committed 5

Output starting withVersion 8.2

77 7

* LOAD:  table "DSCIARA2"."T20"
7  -Rows read:          5
7  -Loaded:             4
7  -Rejected:           1
7  -Deleted:            0
7  -Committed:          5

7 7 7

Health registry changes when migrating from DB2 UDB Version 8.2 back 7to DB2 UDB Version 8.1

Any registry changes made at the DB2 UDB Version 8.2 level are lost when 7you migrate back to DB2 UDB Version 8.1. The registry reverts to the version 78.1 HealthRules.reg file that contains the settings that existed before you 7upgraded to DB2 UDB Version 8.2 and started using the settings in the HealthRules2.reg 7file.

7 7 7

db2diag.log format message enhancements

The db2diag.log file format has been improved in a number of ways for version 78.2. The log file is now easier to read manually and easier to parse in software. 7The improvements include:

Each entry has a complete set of header information

Message and data portions of the logging record are clearly marked, making 7the logging record easier to use and to understand

Timestamps with time zone are included for each record

Each field has a clear field name in uppercase letters

Header and message field line lengths are restricted to 80 characters

New fields have been added, most notably a severity-level field to help 7you find the most important entries

Other changes have been made as well, such as changing the database field name to DB.

Event records have been added as diagnostic messages to the db2diag.log 7file. Examples of such events are:

Updates to the profile registry

Updates to configuration parameters

Event records have "Event" specified in the LEVEL field. Although events are not errors, they might be logged at 7diagnostic levels higher than 4 (Informational) or 3 (Warning) depending on 7their importance.

7 7 7

db2set profile registry variables and DB or DBM configuration parameters 7are now logged

Starting with version 8.2, db2set profile registry updates and DB and DBM 7configuration parameters and are logged in the db2diag.log file. These messages 7are logged at high diagnostic levels due to their importance.

The following types of db2set profile registry updates are logged:

Modify

77The db2set variableName=value command yields a db2diag.log entry such as: 7

2004-04-22-19.19.14.156959-240 I79582C286         LEVEL: Event
7PID     : 2437242              TID  : 1           PROC : db2set
7INSTANCE: db2user              NODE : 000
7FUNCTION: DB2 UDB, oper system services, db2set_main, probe:40
7CHANGE  : CFG DB2SET: DB2DBDFT: From: "OLDDB" To: "SAMPLE"

Delete

77The db2set -r command yields a db2diag.log entry such as: 7

CHANGE  : CFG DB2SET: DB2DBDFT: From: "SAMPLE" To: ""

7 7

Note:

The header information is omitted in the preceding example.

Reset

77The db2set variableName=value command 7yields a db2diag.log entry such as: 7

CHANGE  : CFG DB2SET: Profile registry was reset

7 7

Note:

The header information is omitted in the preceding example.

7 7

Examples for DB and DBM configuration parameter updates are

CHANGE  : CFG DB SAMPLE: "Maxlocks" From: "10" To: "20"
7
7CHANGE  : CFG DBM: "Diaglevel" From: "3" To: "1"
7
7CHANGE  : CFG DBM: Reset to the system defaults

7 7

Note:

The header information is omitted in the preceding examples.

To find these configuration update messages, use db2diag tool. For example:

To select all events: db2diag -level event

To select change events: db2diag -g "changeevent="

[ Top of Page |Previous Page | Next Page | Contents ]