It doesn’t happen as often as it used to, but it is still possible that you might miss installing a custom install component when you install DB2 and need to go back and install it later. I recently had to do this with the
APPLICATION_DEVELOPMENT_TOOLS feature, and thought I’d share the experience and how to do it. This is all on a Linux system on which I have a typical root install of DB2 ESE 10.1 fixpack 3.
My problem was that I needed the application development tools. I’m working on changing one of my build scripts from Perl to Ruby, and I’m attempting to make use of the IBM_DB gem to connect to the database. I’ll be blogging about that in the near future. A problem I turned out to have was that there were files I needed in /opt/IBM/db2/V10.1/include that were not there. Research and friends led me both to this conclusion and to the conclusion that to get those files, I needed to install the application development tools component.
Methods for Installing a Single Component
It has been years since I’ve had to do this, and in working through the options, I found there were three.
The Hack-it Method
On Linux, one of my options was simply to untar the file from where I have the fixpack code into the right location. This was a bit of a hacky way to go about it, and I wouldn’t recommend it unless you have a driving need, an ability to really thoroughly test it, and an ability to revert the changes. I did not choose this method, and I do not recommend it. This would involve the file universal/db2/linuxamd64/FILES/APPLICATION_DEVELOPMENT_TOOLS_10.1.0.3_linuxamd64_x86_64.tar.gz and a command that would look something like this:
cat APPLICATION_DEVELOPMENT_TOOLS_10.1.0.3_linuxamd64_x86_64.tar.gz | ( cd /opt/ibm/db2/V10.1 ; tar xzvfBp - )
Again, that is an un-tested method, and not recommended, but may work.
The GUI Method
If you’ve read other blog entries that I have written, you have probably learned that I really don’t like GUIs for most things. But I’m pretty sure you could set up x-windows or whatever and run db2setup in interactive method to do this. I don’t think you can use db2_install to add a single component. I also suspect that db2_install includes this component if you used it to install DB2 in the first place.
The db2setup Method With a Response File
The method I settled on was using db2setup with a tailored response file. This fit my command-line sensibilities and also avoided any tweaking outside of the normal supported stuff.
In order to use db2setup to install a single component, you’ll have to create a tailored response file. Response file options can change with versions so make sure you’re using one for the correct version. A sample response file is included in the DB2 base code, but not in Fixpack code. It can be found in ese/db2/linuxamd64/samples/db2ese.rsp for DB2 ESE – with the ‘linuxamd64’ changing depending on your platform.
The file I used for this tailored purpose was quite short:
PROD = ENTERPRISE_SERVER_EDITION FILE = /opt/IBM/db2/V10.1 LIC_AGREEMENT = ACCEPT INSTALL_TYPE = CUSTOM COMP = APPLICATION_DEVELOPMENT_TOOLS ** Base application development tools
FILE value must be changed to match wherever you have the code installed.
After you have that, running db2setup with it (as root) is simple:
cd /path/where/fixpack/code/is/universal ./db2setup -r /path/where/rsp/file/is/db2ese_10_1.app_dev.rsp
It is important that this be executed from the same fixpack code that the rest of DB2 is using. If you try to execute it from the base code or wrong fixpack, you’ll get an error like this:
DBI1191I db2setup is installing and configuring DB2 according to the response file provided. Please wait. The install location "/opt/IBM/db2/V10.1" contains an installed DB2 product that is not at the same level as the DB2 product you are attempting to install. Specify another location.
When it runs successfully, it will look like this:
Requirement not matched for DB2 database "Server" "". Version: "10.1.0.3". Summary of prerequisites that are not met on the current system: DBT3514W The db2prereqcheck utility failed to find the following 32-bit library file: "/lib/libpam.so*". DBI1191I db2setup is installing and configuring DB2 according to the response file provided. Please wait. A minor error occurred while installing "DB2 Enterprise Server Edition " on this computer. Some features may not function correctly. For more information see the DB2 installation log at "/tmp/db2setup.log".
Some Interesting Notes
I executed the above on a server with one database that was actively serving an application (development database for IBM WebSphere Commerce). I noticed this in the setup log (always read your setup logs):
The instance "db2inst2" has been updated successfully. WARNING: The install is unable to update the instance "db2inst1" because it is currently in use. Ensure the instance is not active and update the instance post install using the command "db2iupdt". WARNING: One or more errors occurred while updating the instances on the system. This usually occurs because some instances are currently active. The following instances were successfully updated: db2inst2 An error occurred while updating the instances. The following instances were not updated successfully: db2inst1 You must update the instances manually. If you are performing a root installation, use the db2iupdt command. If you are performing a non-root installation, use the db2nrupdt command. If the manual instance update also failed, contact DB2 Customer Service. Updating existing DB2 instances :.......Failure
The interesting thing to me here, is that using db2setup, DB2 took it upon itself to update db2inst2 for me. db2inst2 was started, but all the databases were inactive. I did not expect this. I expected to have to update both instances myself.
After you’ve installed a component, you’ll want to run a db2iupdt on any instances to make sure they are using the new code. This requires you to stop the instance and run the db2iupdt command as root, which causes a database outage. That looks something like this:
[root@server instance]# su - db2inst1 [db2inst1@server ~]$ db2stop force 02/06/2014 21:32:30 0 0 SQL1064N DB2STOP processing was successful. SQL1064N DB2STOP processing was successful. [db2inst1@server ~]$ ipclean Application ipclean: Removing DB2 engine and client IPC resources for db2inst1. [db2inst1@server ~]$ exit logout [root@server instance]# cd /opt/IBM/db2/V10.1/instance [root@server instance]# ./db2iupdt -k db2inst1 DBI1446I The db2iupdt command is running. DB2 installation is being initialized. Total number of tasks to be performed: 4 Total estimated time for all tasks to be performed: 309 second(s) Task #1 start Description: Setting default global profile registry variables Estimated time 1 second(s) Task #1 end Task #2 start Description: Initializing instance list Estimated time 5 second(s) Task #2 end Task #3 start Description: Configuring DB2 instances Estimated time 300 second(s) Task #3 end Task #4 start Description: Updating global profile registry Estimated time 3 second(s) Task #4 end The execution completed successfully. For more information see the DB2 installation log at "/tmp/db2iupdt.log.18853". Required: Review the following log file also for warnings or errors: "/tmp/db2iupdt_local.log.*" DBI1070I Program db2iupdt completed successfully. [root@server instance]# su - db2inst1 [db2inst1@server ~]$ db2start 02/06/2014 21:33:24 0 0 SQL1063N DB2START processing was successful. SQL1063N DB2START processing was successful.
Looking at the log file from db2iupdt, it appears to be calling db2setup to do the instance update. The file starts out:
DB2 Setup log file started at: Thu Feb 6 21:32:45 2014 EST ============================================================
Just like a db2setup log. I find it interesting that IBM seems to be merging instance updating and installing of code into the same commands.
And my problem that required the application development tools was solved.