Backward compatibility
3
3
3Alternate FixPaks (Linux and UNIX)
3
3Prior 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:
3
3- regular FixPaks
3-
3
3- Are available not only for ESE, but for all supported DB2 Version 8 products
3for the related platforms
3- 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
3
3- alternate FixPaks
3-
3
3- Can be installed as completely new copies of DB2 Universal Database ESE
3- Are installed in a predefined location other than the location used for
3a regular DB2 Universal Database installation
3
3
3
3Notes:
3
3- You are not required to perform a multiple FixPak
3installation if it is unnecessary for your environment.
3- 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
3- 7On Linux, alternate FixPaks are available on the following platforms
7only:
7
7- x86 (32-bit)
7- S/390(R) (31-bit)
3
3
3To update a multiple FixPak instance to a different FixPak level, perform
3one of the following operations:
3
3- Install the appropriate regular FixPak on the General Availability (GA)
3installation and update the instance by running db2iupdt from the existing GA path.
3- Install the appropriate alternate FixPak to its own unique path and update
3the instance by running db2iupdt from this path.
3For further information regarding downloading alternate FixPaks, visit
3the IBM support site at http://www.ibm.com/software/data/db2/udb/winos2unix/support.
3
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
7Change in output for the db2move command
7In 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.
7
7When db2move is executed with the IMPORT option
7
7
7- Output prior to Version 8.2
7-
7
IMPORT: -Rows read: 5; -Rows committed: 5; Table "DSCIARA2"."T20"
7
7- Output starting with Version 8.2
7-
7
* IMPORT: table "DSCIARA2"."T20"
7 -Rows read: 5
7 -Inserted: 4
7 -Rejected: 1
7 -Committed: 5
7
7
7
7When db2move is executed with the LOAD option
7
7
7- Output prior to Version 8.2
7-
7
* LOAD: table "DSCIARA2"."T20"
7 -Rows read: 5 -Loaded: 4 -Rejected 1 -Deleted 0 -Committed 5
7
7- Output starting withVersion 8.2
7-
7
* LOAD: table "DSCIARA2"."T20"
7 -Rows read: 5
7 -Loaded: 4
7 -Rejected: 1
7 -Deleted: 0
7 -Committed: 5
7
7
7
7
7Health registry changes when migrating from DB2 UDB Version 8.2 back
7to DB2 UDB Version 8.1
7Any 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
7db2diag.log format message enhancements
7The 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:
7
7- Each entry has a complete set of header information
7- Message and data portions of the logging record are clearly marked, making
7the logging record easier to use and to understand
7- Timestamps with time zone are included for each record
7- Each field has a clear field name in uppercase letters
7- Header and message field line lengths are restricted to 80 characters
7- 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.
7Event records have been added as diagnostic messages to the db2diag.log
7file. Examples of such events are:
7
7- Updates to the profile registry
7- 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
7db2set profile registry variables and DB or DBM configuration parameters
7are now logged
7Starting 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.
7The following types of db2set profile registry updates are logged:
7
7- Modify
7- The 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"
7
7- Delete
7- The db2set -r command yields a db2diag.log entry such as:
7
CHANGE : CFG DB2SET: DB2DBDFT: From: "SAMPLE" To: ""
7
7Note:
7The header information is omitted in the preceding example.
7
7- Reset
7- The db2set variableName=value command
7yields a db2diag.log entry such as:
7
CHANGE : CFG DB2SET: Profile registry was reset
7
7Note:
7The header information is omitted in the preceding example.
7
7
7Examples for DB and DBM configuration parameter updates are
7CHANGE : 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
7Note:
7The header information is omitted in the preceding examples.
7To find these configuration update messages, use db2diag tool. For example:
7
7- To select all events: db2diag -level event
7- To select change events: db2diag -g "changeevent="
[ Top of Page |Previous Page | Next Page | Contents ]