| OS/2 |
The following executables have changed names:
The original executable names will still be accepted; however, some Version 2 functions are not available (such as new PREP and BIND options).
Use the Version 2 executables or commands.
| UNIX | OS/2 |
The parameter BUFF_SIZE has changed for the backup and restore APIs. The minimum is now 16 allocation units (of 4K) instead of 8 units, and the increments must be in steps of 16 instead of 1.
You may receive a SQLCODE of SQL5130N.
Upgrade your application to use a BUFF_SIZE value which is valid for Version 2.
| OS/2 |
In Version 1 there was the ability to backup and restore "Changes Only" to a database. This ability no longer exists. However, applications making the Version 1 API calls will not fail. DB2 simply ignores the second parameter (TYPE) in the sqluback() API call and performs a full backup.
A full backup will be taken when specifying a "Changes Only" backup.
None exist. "Changes Only" backups are no longer supported.
| OS/2 |
Due to the table space capabilities available beginning in Version 2, it is no longer possible to determine the original location of the backup files. For this reason, user exits which use XCOPY or relied on the database sub-directory format in Version 1 will no longer function beginning in Version 2.
If you continue to use User Exits that move the backup files to another location, the restore may not function correctly.
User Exits can still be used for log archiving and retrieving. Use the supported parameters and options on the backup command to define the location the backup files will reside.
| UNIX | OS/2 |
You must have SYSADM, SYSCTRL, or SYSMAINT authority to use the BACKUP command. DBADM authority is no longer sufficient.
If you attempt a backup with DBADM authority only, you will be told that you do not have sufficient authority to perform the backup.
There are two choices:
| UNIX | OS/2 | WIN |
A downlevel client cannot issue an IMPORT REPLACE command to a Version 2 server.
If this is attempted, the application will receive an SQL3188N error.
There are three possible resolutions to this scenario:
|
|
|
| DB2 PE |
The LOAD TERMINATE command has a different function in DB2 UDB than it did in DB2 Parallel Edition Version 1.x. In DB2 Parallel Edition, you could use LOAD TERMINATE if an error occurred during the load operation to ensure that the table data was consistent. In DB2 UDB however, if you use LOAD TERMINATE, the table space is moved into the recovery pending state. (When the table space is in the recovery pending state, you must either restore the table space or drop it.)
Instead of being placed in a consistent state, the table space is placed in a recovery pending state.
Instead of using LOAD TERMINATE to clean up after a failed load operation, you should use LOAD RESTART or LOAD REPLACE. You also have the option of dropping and re-creating the table space.
| UNIX | OS/2 |
The REORG command and API no longer support an "alternate path" as a work area, but rather support the name of a table space to be used as a work area. APIs and commands will not fail, however, this option will be ignored.
REORG invocations from downlevel clients will ignore the alternate work path and arbitrarily choose a temporary table space to use as a work area.
Another symptom is you may run out of disk space.
Your applications will continue to function, but you should consider upgrading to the DB2 Version 5 calls which contain valid options.