SQL1042C error caused by invalid installation

Technote (FAQ)


Question

This technote provides troubleshooting information related to the occurrence of the following error in DB2 UDB: SQL1042C An unexpected system error occurred.

Cause

The SQL1042C error might be generated when:

  1. Upgrading to a new FixPak image.
  2. A special build is installed on top of an existing FixPak image.
  3. A FixPak image is reverted back to an older FixPak image or version.

If db2iupdt was not executed on the instance, this will result in inconsistency between the instance executable and the library files located in the DB2® Universal Database™ (DB2 UDB) install directory. For example, on HP-UX, $INSTHOME/sqllib/lib is a link to /opt/IBMdb2/V7.1/lib. However, $INSTHOME/sqllib/adm/db2sysc is a local file and can be different from the file in /opt/IBMdb2/V7.1/adm/db2sysc. As a result, db2start will fail with SQL1042C error and in some cases a core dump will be generated.

Diagnosis details
Use the commands below to ensure there is no inconsistency between the DB2 UDB executable and library files. The output will include search paths that contain a directory from the DB2 UDB build tree. This information can be used to identify the DB2 UDB code level on which the library and executable files in question were built.

AIX®:
dump -H $INSTHOME/sqllib/lib/libdb2e.a
dump -H $INSTHOME/sqllib/adm/db2sysc

AIX (64-bit):
dump -H -X64 $INSTHOME/sqllib/lib/libdb2e.a
dump -H -X64 $INSTHOME/sqllib/adm/db2sysc

HP-UX:
chatr $INSTHOME/sqllib/lib/libdb2e.sl
chatr $INSTHOME/sqllib/adm/db2sysc

Linux®:
objdump -p $INSTHOME/sqllib/lib/libdb2.so
objdump -p $INSTHOME/sqllib/adm/db2sysc

Solaris:
/usr/ccs/bin/dump -Lv $INSTHOME/sqllib/lib/libdb2e.so
/usr/ccs/bin/dump -Lv $INSTHOME/sqllib/adm/db2sysc

For example, you can use the chatr command on HP-UX to print the file attributes for ~db2inst5/sqllib/lib/libdb2e.sl and ~db2inst5/sqllib/adm/db2sysc. In this example, db2inst5 is a DB2 UDB Version 7 instance. The sample output below shows that the two files came from two different DB2 UDB code levels.

root@tester:/users/root $ chatr ~db2inst5/sqllib/lib/libdb2e.sl
chatr(warning): dl_header_ext.size != sizeof(dl_header_ext). Please
update your version of the linker.
/u/db2/db2inst5/sqllib/lib/libdb2e.sl:
shared library
shared library dynamic path search:
SHLIB_PATH enabled first
/opt/IBMdb2/V7.1/lib:/opt/IBMdb2/V7.1/adsm:/wsdb/db2hp_v72/s010415/engn/
lib:/wsdb/db2h0
shared library list:
dynamic /wsdb/db2hp_v72/s010415/engn/lib/libdb2hp.sl
dynamic /usr/lib/libpthread.1
dynamic /usr/lib/librt.2
dynamic /usr/lib/libsec.2
dynamic /usr/lib/libm.2
dynamic /usr/lib/libc.2

root@tester:/users/root $ chatr ~db2inst5/sqllib/adm/db2sysc
chatr(warning): dl_header_ext.size != sizeof(dl_header_ext). Please
update your version of the linker.
/u/db2/db2inst5/sqllib/adm/db2sysc:
shared executable
shared library dynamic path search:
SHLIB_PATH disabled second
/opt/IBMdb2/V7.1/lib:/opt/IBMdb2/V7.1/adsm:/wsdb/db2hp_v72/s021110/engn/
lib:/wsdb/db2h0
shared library list:
dynamic /wsdb/db2hp_v72/s021110/engn/lib/libdb2e.sl
dynamic /usr/lib/libm.2
dynamic /usr/lib/libcl.2
dynamic /usr/lib/libsec.2
dynamic /usr/lib/libpthread.1
dynamic /usr/lib/libstd.2
dynamic /usr/lib/libstream.2
dynamic /usr/lib/libCsup.2
dynamic /usr/lib/libc.2
static /usr/lib/libdld.2


Thus the libdb2e.sl came from DB2 UDB Version 7.2 GA with build level signature of "s010415" and db2sysc came from DB2 UDB Version 7.2 FP8 with a build level signature of "s021110".

In this case, db2level output will be misleading. It will not show the actual tokens for the FixPak and build levels since they are built into the db2level executable itself.

/home/db2inst5>$ db2level
DB21085I Instance "db2insti" uses DB2 code release "SQL07020" with
level identifier "03010105" and informational tokens "DB2 v7.1.0.40", "s010415" and "U475379".

Note that these examples came from DB2 UDB Version 7. In DB2 UDB Version 8, the DB2 UDB installation directory will be different (/usr/opt/IBM/db2_08_01 on AIX, and /opt/IBM/db2/V8.1 on other UNIX® platforms).


Answer

Ultimately, using the db2iupdt command will resolve the problem. The instance update utility will copy the contents of the $DB2INSTDIR/adm to the $INSTHOME/sqllib/adm directory and update all of the links to point to the correct DB2 UDB code level.

Related information

Updating instance configuration on UNIX

Rate this page:

(0 users)Average rating

Document information


More support for:

DB2 for Linux, UNIX and Windows
DBA/System Administration - db2start/db2stop

Software version:

7, 8

Operating system(s):

AIX, HP-UX, Linux, Solaris

Software edition:

Enterprise

Reference #:

1175758

Modified date:

2011-04-14

Translate my page

Machine Translation

Content navigation