IBM Support

75 ways to demystify DB2: #8 : Tech Tip: db2iupdt fails with DBI1167E "DPF instance cannot be updated from non instance owning nodes."

Technical Blog Post


Abstract

75 ways to demystify DB2: #8 : Tech Tip: db2iupdt fails with DBI1167E "DPF instance cannot be updated from non instance owning nodes."

Body

Have you ever wondered why during a DB2 fixpack upgrade on a DPF environment, db2iupdt fails with DBI1167E "DPF instance cannot be updated from non instance owning nodes."?

Beginning in DB2 V9.5, fixpack upgrade was enhanced on Unix and Linux platforms to only run db2iupdt on instance owning node. Prior to DB2 V9.5, db2iupdat didn't do a hostname check. This was first introduced in DB2 V9.5. This check was done to ensure that the instance update only happens on the node defined on the first line of db2nodes.cfg for DPF instances. The enhancement done in DB2 V9.5 is to run db2iupdt on behalf of user during the installFixPack so that you don't need to manually run db2iupdt after the fixpack update.

We expect the second column of the db2nodes.cfg file to use the canonical hostname for the checking. The design was really to require users to install all the needed products on the instance owning node. Any other node should not have any DB2 products installed which are not installed on the instance owning node. By doing so, the db2iupdt running on the instance owning node should be always correct. This avoids the problem if users run db2iupdt or installFixPack on the non-instance owning node where there are less DB2 products installed compared to the instance owning node.

This is the reason why users didn't face this issue when executing a db2iupdt prior to DB2 Version 9.5. Db2iupdt is required to run from the first node mentioned in the db2nodes.cfg file only when there is a fixpack update. The first entry in the db2nodes.cfg is considered the instance owning node. It is the node from which db2icrt was executed from. It doesn't have to be the node which contains the file system or owns the mount point; for example /home/<instance>. The mount point origin could be a machine that is not part of the DB2 DPF set of machines.

To resolve the problem :
===================
After installation, users can run the db2iupdt command with undocumented "-N" option for all those DPF instances related to the DB2 install path to bypass the checking of instance owning node and update those DPF instances. Users have to ensure that the current node running  "db2iupdt -N <instancename>" has no missing DB2 products installed in the related install path compared to any of other nodes.

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

UID

ibm11141216