Limitations

| | |

db2look - Limitation for automatic storage table space

|

With databases using an automatic storage table space, the db2look command will complete successfully. However, it will not show |table space information specific to automatic storage table spaces.

SNAP_GET_DB table function returns incomplete results

When invoked in a database partitioning feature (DPF) environment with -2 (global snapshot) provided as input, the SNAP_GET_DB table function returns incomplete results for the following four columns:

These elements cannot be aggregated for a global snapshot. To retrieve the complete set of values for these snapshot elements, the SNAP_GET_DB table function should be called individually on each partition.

IMPORT REPLACE does not honor the Not Logged Initially clause

The IMPORT command's REPLACE option does not honor the CREATE TABLE statement's NOT LOGGED INITIALLY (NLI) clause or the ALTER TABLE statement's ACTIVATE NOT LOGGED INITIALLY clause.

If an import with the REPLACE action is performed within the same transaction as a CREATE TABLE or ALTER TABLE statement where the NLI clause is invoked, the import will not honor the NLI clause. All inserts will be logged.

Workaround 1
Delete the contents of the table using the DELETE statement, then invoke the import with INSERT statement.
Workaround 2
Drop the table and recreate it, then invoke the import with INSERT statement.

This limitation applies to DB2 UDB Version 7 and DB2 UDB Version 8.

Long field and LOB data cannot be reorganized with inplace table reorganization

During inplace, or online, table reorganization, long field and LOB data cannot be reorganized. Long field and LOB data can be reorganized with a classic, or offline, table reorganization by specifying the LONGLOBDATA parameter with the REORG TABLE command. However, it should be noted that while reorganization of long field and LOB data does allow free space to be reclaimed, it does not improve clustering and can significantly increase the time required to complete the reorganization.

Locking behavior in blocking cursors can appear inconsistent in client applications

In cursor stability (CS) isolation, the row associated with the current cursor position on the database server is always locked. During a blocked fetch, multiple rows can be returned in a single buffer. In most cases, the last row processed on the server side will not fit exactly and will be split across two buffers. The application will not see this split row until the second buffer is received. Therefore, none of the rows returned to the application will be locked.

In the rare case that the last row processed on the server side is an exact fit, the cursor position will remain on the last row inside the buffer, which means that the last row returned to the application will be locked.

Data export with ODBC to file warehouse program

The Data export with ODBC to file warehouse program does not support the following Sybase data types:

Data types that are not supported in the Development Center's integrated SQL debugger

The following data types are not supported in the SQL Debugger that is integrated into Development Center:

Structured types in the Development Center

The Development Center no longer supports the creation of structured types.

Development Center limitations for 64-bit operating systems

Debugging of Java stored procedures against a 64-bit server is not supported by the Development Center. Debugging SQL stored procedures is supported on 64-bit Windows operating systems. Developing OLE DB or XML User Defined Functions is not supported for 64-bit servers.

Development Center (Linux)

You cannot use the Development Center to debug Java stored procedures running on any of the Linux distributions (32-bit, 64-bit, Intel, zSeries, or iSeries).

Debugging stored procedures with double quotation marks

The Development Center does not support debugging for any stored procedure with double quotation marks (") in the stored procedure name, schema, or specific name.

Path settings needed to enable Java routines to compile in the Development Center

The Development Center cannot compile Java routines unless it knows where your developer kit versions are installed. Default directories for your developer kit versions are written to your $HOME/.ibm/db2/dc/DB2DC.settings file when the Development Center starts for the first time. You can copy these directories into your $USER.settings file and modify them with a Unicode editor, or you can create symbolic links to your developer kit directories in the default locations.

Development Center limitations to run and debug Java stored procedures simultaneously

The Development Center does not support running and debugging Java stored procedures simultaneously. In the Development Center, you can either run multiple Java stored procedures at the same time or debug a single Java stored procedure; you cannot run a Java stored procedure while debugging another Java stored procedure. By default, the KEEPFENCED database manager configuration keyword is set to KEEPFENCED=YES as required for debugging SQL stored procedures. When the keyword KEEPFENCED has the default value YES, the routine process is kept active and JVM port conflicts will occur. Java stored procedures will cause a JVM exception and will fail in any of the following circumstances when the default KEEPFENCED=YES database manager configuration setting is used:

To work around this limitation, ensure that the KEEPFENCED database manager configuration keyword is set to KEEPFENCED=NO by running the following commands:

   db2 update dbm cfg using KEEPFENCED NO
   db2stop
   db2start

When KEEPFENCED is set to NO, the db2fmp process will shut down when a Java stored procedure call is finished, and DB2 Universal Database will start a new db2fmp process to handle the next routine call. This ensures that there will be no existing JVM in debug mode when you start to debug a Java stored procedure.

The KEEPFENCED=YES setting is required to build SQL stored procedures for debugging and to debug SQL stored procedures. When KEEPFENCED=NO, you can still build and execute SQL stored procedures but you cannot debug them.

DB2SystemMonitor.getServerTimeMicros method not supported

The DB2(R) Universal JDBC Driver method DB2SystemMonitor.getServerTimeMicros() is currently not supported by DB2(R) Universal Database(TM) for Linux(TM), UNIX(R), and Windows(R) servers. The DB2SystemMonitor.getServerTimeMicros() method returns 0 when connecting to DB2(R) Universal Database(TM) for Linux, UNIX, and Windows(R) servers.

IBM XL C/C++ compiler run time must be installed (Linux on iSeries and pSeries systems, 64-bit)

The following requirements must be met before installing 64-bit DB2 for Linux on iSeries(TM) and pSeries(R) systems:

Universal JDBC Driver Type 2 not supported on DB2 UDB Version 8.2.2 (Linux AMD64 )

DB2 Universal Database(TM) (UDB) Version 8.2.2 (equivalent to Version 8.1 FixPak 9) on Linux AMD64 does not support the Universal JDBC Driver Type 2. Support is planned for a future fixpak. JDBC support in Version 8.2.2 is available using Universal JDBC Driver Type 4 and the Legacy JDBC Type 2 driver (COM.ibm.db2.jdbc.app.DB2Driver).

Cursors in PHP applications

When the PHP interpreter creates a cursor on behalf of an application, it is created by default as a Scrollable Keyset-driven cursor. In certain cases, this might cause unexpected results to be returned. In order to avoid this situation, explicitly specify the "FOR READ ONLY" clause for all SELECT statements that are used to update data. Other alternatives include setting the CLI Configuration parameters "Patch2=6", "Patch2=42", or "DisableKeysetCursor=1". However, each of these might have other consequences. Refer to the CLI Guide and Reference documentation for details regarding these configuration keywords.

ConnectNode CLI/ODBC configuration keyword limitation

The ConnectNode keyword does not affect the Control Center. The Control Center always connects to the catalog node referred to by the SQL_CONN_CATALOG_NODE setting.

SQLColumns function (CLI) restriction

The SQLColumns() function does not support returning data from an alias of an alias. When called against an alias of an alias, the SQLColumns() function returns an empty result set.

Bind option limitations for CLI packages

Some bind options might not take effect when binding CLI packages with any of the following list files: db2cli.lst, ddcsmvs.lst, ddcs400.lst, ddcsvm.lst, or ddcsvse.lst. Because CLI packages are used by CLI, ODBC, JDBC, OLE DB, .NET, and ADO applications, any changes made to the CLI packages affect all applications of these types. Only a subset of bind options are therefore supported by default when binding CLI packages. The supported options are: ACTION, COLLECTION, CLIPKG, OWNER, and REPLVER. All other bind options that impact CLI packages are ignored.

To create CLI packages with bind options that are not supported by default, specify the COLLECTION bind option with a collection ID that is different from the default collection ID, NULLID. Any bind options specified are then accepted. For example, to create CLI packages with the KEEPDYNAMIC YES bind option, which is not supported by default, issue the following command:

db2 bind @db2cli.lst collection newcolid keepdynamic yes

In order for CLI/ODBC applications to access the CLI packages created in the new collection, set the CurrentPackageSet CLI/ODBC keyword in the db2cli.ini initialization file to the new collection ID.

To overwrite CLI packages that already exist under a particular collection ID, perform either of the following actions:

CLI LOAD utility restrictions

The CLI LOAD utility does not support parameter markers if the prepared SQL statement for inserting data contains a SELECT clause.

Prior to Version 8.2 FixPak 3 (equivalent to V8.1 Fixpak 10), the CLI LOAD utility did not allow target columns to be specified if the INSERT statement included a VALUES clause.

However, starting with Version 8.2 FixPak 3 (equivalent to V8.1 Fixpak 10), the CLI LOAD utility allows target columns to be specified in an INSERT statement with a VALUES clause. For example, the following statement is now supported by CLI LOAD:

INSERT into tableA (col1, col2, col3) VALUES (?, ?, ?)

Tools catalog database creation not supported (Linux for AMD64)

The creation of the tools catalog database under a 64-bit DB2 Universal Database (UDB) instance on Linux (AMD64) is not supported. Do not attempt to create the tools catalog under a 64-bit instance using any of the following methods:

The creation of the tools catalog database under a 32-bit instance on Linux (AMD64) is supported as of Version 8.1.4.

Tools catalog database creation not supported (AIX, Solaris Operating Environments, and HP-UX)

The creation of the tools catalog is not supported during the installation of DB2 Universal Database (UDB) against 64-bit instances on the hybrid 64-bit platforms. The hybrid platforms are:

If you want to create a tools catalog against a 64-bit instance, this can be done after the installation of DB2 UDB either through the Command Line Processor using the CREATE TOOLS CATALOG CLP command or using the Control Center. You will also need to install a 64-bit IBM Developer Kit for Java for this operation. Refer to the DB2 Administration Server section of the DB2 Administration Guide for more details.

Memory limitations for DB2 UDB Express and DB2 Workgroup Server Edition V8.2

There are memory limitations for the following products:

Scheduling a warehouse process to run at intervals

When scheduling a warehouse process to run at intervals, you must determine the longest time it takes to run all the production steps in the process and schedule the intervals accordingly. If a process exceeds the scheduled time interval, all subsequently scheduled occurrences of that process will not run and will not be rescheduled.

SNA support limitations in Version 8

The following support has been withdrawn from DB2 Universal Database (UDB) Enterprise Server Edition (ESE) Version 8 for Windows and UNIX operating systems, and from DB2 Connect Enterprise Edition (CEE) Version 8 for Windows and UNIX operating systems:

Security plug-in problem and restriction for DB2 UDB clients (Windows)

When developing security plug-ins that will be deployed in DB2 clients on Windows operating systems, do not unload any auxiliary libraries in the plug-in termination function. This restriction applies to all types of client security plug-ins, including group, user ID and password, Kerberos, and GSS-API plug-ins.

This restriction is caused by DB2 Universal Database's problem unloading security plug-ins in DB2 clients on Windows operating systems.

Failures when reporting a successful login during a connection attempt (AIX)

When using OS authentication on AIX, DB2 Universal Database (UDB) attempts to report a successful login to AIX upon successful authentication during a connection attempt. Prior to Version 8 FixPak 5, if DB2 UDB was unable to report a successful login, the connection would fail despite the user being authenticated. Starting with Version 8 FixPak 5, the connection is allowed to continue and the failure is logged in the db2diag.log file.

Two-part user ID not supported (Windows ME)

The two-part user ID for the CONNECT statement and ATTACH command, such as domainname\username, is not supported on Windows ME.

Load and Import Columns page does not support DBCS characters in IXF files

If you use the Load wizard or Import notebook to set up a load or import from an IXF input file containing DBCS characters, the Columns page will not correctly display the column names contained in the file.

| | |

GUI tools for Linux operating systems on AMD64

|

The GUI tools that come with DB2 Universal Database (UDB) are Java-based |graphical utilities. Examples of DB2 UDB GUI tools are:

| |

Since Linux operating systems on AMD64 do not currently have a 64-bit |Java(TM) SDK or Runtime Environment, running these tools requires that you |do so from a 32-bit DB2 UDB instance.

|

You can still use these tools to manage databases in local and remote 64-bit |instances. For example, to use the Control Center you must create a 32-bit |instance first. After a 32-bit instance is created, you need to manually |catalog the local 64-bit instance that you want to administer.

|

More information on DB2 for Linux on AMD64 can be found at the following |URL:

|

ftp://ftp.software.ibm.com/software/data/pubs/papers/linuxamd64.pdf

Minimum display settings for GUI tools

For the GUI tools such as the Control Center to work properly, you must have a screen resolution of at least 800 by 600 and use a display palette of at least 32 colors.

Improper display of GB18030 characters in the title bar of a window

If you have characters from the GB18030 Chinese character encoding standard in the title bar of a window, they might appear as questions marks or squares.

Do not partition Information Catalog Center tables

Tables that the Information Catalog Manager uses must be contained within a single database partition. Numerous methods are available to put the tables within a single partition. The following procedure is one approach that works.

  1. Open a DB2 Command Line Processor and issue these commands:
    1. CREATE DATABASE PARTITION GROUP partition_group_name 
           ON DBPARTITIONNUM partition_number
    2. CREATE REGULAR TABLESPACE tablespace_name 
           IN DATABASE PARTITION GROUP partition_group_name
           MANAGED BY SYSTEM USING ('cname')
    where partition_group_name is the same in both commands.
  2. Click Start -> Programs -> IBM DB2 -> Set-up Tools -> Manage Information Catalog Wizard.
  3. On the Options page, specify the table space name in the Table space field.

Query Patroller limitations when DYN_QUERY_MGMT is disabled

Query Patroller cannot perform the following actions if the database configuration parameter DYN_QUERY_MGMT is disabled:

If you attempt to release a query from held state, or change a foreground query to a background query when DYN_QUERY_MGMT is set to DISABLE, an error message will be displayed and the state of the query will not change. If held queries are scheduled to run and DYN_QUERY_MGMT is disabled at the time they start running, an error message is written to the qpdiag.log file and the queries are left in held state.

Query Patroller result tables now use DB2QPRT schema

Starting with FixPak 5, all new result tables are created in the schema DB2QPRT rather than in the schema of the submitter.

DROPIN privilege on the DB2QPRT schema is granted to operators whose profiles were created prior to installation of FixPak 5 and had either:

DROPIN privilege on the DB2QPRT schema is granted the first time Query Patroller creates a result table in this schema.

Operators who are given MONITORING privilege with edit authority or HISTORICAL ANALYSIS privilege with edit authority after the installation of FixPak 5 are also granted DROPIN privilege on the DB2QPRT schema upon creation or update of their profiles.

Health indicator restrictions

The health monitor is unable to execute actions for the db2.db2_op_status health indicator if the indicator enters the down state. This state can be caused, for example, when an instance that the indicator is monitoring becomes inactive because of an explicit stop request or an abnormal termination. If you want to have the instance restart automatically after any abnormal termination, you must configure the fault monitor to keep the instance highly available.

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