Posted by Some friends on Twitter were commenting that db2_install is not just deprecated in DB2 10, but is fully discontinued and not available. Melanie Stopfer mentioned this on her webcast on June 22. I do dozens of installs a year, and most of them are using a response file. The same response file, actually, since a standard starting point makes sense at that level for WebSphere Commerce installs. Still, I created the file myself.
If you’re not familiar with db2_install, it was a command line script that seemed to work when other install methods failed, and just did the most basic tasks of getting DB2 code installed on a system.
What is a Response File?
A response file is simply a text (ASCII) file that you use to provide inputs to db2setup instead of providing inputs via GUI. Most DBAs I know are command line geeks like me and tend to avoid GUIs. I have actually set up Xwindows and done a GUI install on a Linux system, but as we say where I work, my X-fu is not strong. I haven’t done it in years.
And honestly, why would I? I install enough very similar servers every year that response files make sense for me. I have used db2_install in the last 18 months, so I definitely see the use case for it, but I can survive without it.
A response file actually goes a bit beyond what you do with db2_install. It will acutally let you create instances and databases and set most instance and database level settings at the same time. When I personally do an install myself, I tend to keep things separate – I do the db2_install first, then go out and create instances, and then databases. You don’t have to do any of the extra work with the response file – you can use it for strictly the task of installing DB2. In our normal scripted installs, I use the response file to install DB2, create an instance, and set some of the most common instance level settings.
When to Use a Response File
The perfect use case for a response file is when you do multiple similar installs. It makes it very easy to script installs too. But a response file can really be used for any install. It’s perfect for use when you don’t want to or cannot use a GUI. If you’re scripting an install, the response file is the only way to go.
Where to get a Response File
To get a response file, there are two main methods:
- Do a gui install using db2setup and click the box to create a response file
- Pull the sample file from the installation media and edit it manually
Surprise, surprise, I’m actually a fan of the second. Either one will work, but since I avoid GUIs, the last time I actually used the db2setup GUI was about 3 years ago for a windows install.
Response files can change between versions of DB2 and between operating systems (though I find the same file seems to work across various Linux and UNIX distributions). You can find the sample file on your installation media under db2/<platform>/samples. That’s right, it’s not in your installed code, so you cannot just grab one from another server, you have to go to your downloaded installation media or your DVD.
Response files are finicky on syntax, and don’t always give the best error messages. That is the most difficult part about them. If you’re like me and can’t seem to write a 20-line script that runs right on the first execution, you may have to try several times to get the install to run with an response file. If a client is running an install, I prefer to only hand them a tested and proven response file for this reason.
What does a response file look like?
Here’s essentially the one that I use most frequently(some names may have been changed to protect the innocent – I don’t actually recommend some of the settings like /home for an instance home):
** Response File for ESE ** Also creates and starts db2 instance and makes entry in /etc/services ** Configures all required instance-level parameters except SYSMON_GROUP, which must still be set manually ** Additional DB2 work is still required after Commerce instance creation PROD = ENTERPRISE_SERVER_EDITION FILE = /opt/IBM/db2/V9.7 LIC_AGREEMENT = ACCEPT ** ACCEPT or DECLINE INSTALL_TYPE = TYPICAL ** TYPICAL, COMPACT, CUSTOM INSTALL_TSAMP = YES ** YES or NO. Valid for root install only INSTANCE = db2inst1 db2inst1.NAME = db2inst1 ** real name of the instance db2inst1.GROUP_NAME = db2grp ** char(30) no spaces db2inst1.HOME_DIRECTORY = /home/db2inst1 ** char(64) no spaces. Valid for root install only db2inst1.AUTOSTART = YES ** YES or NO db2inst1.START_DURING_INSTALL = NO ** YES or NO db2inst1.SVCENAME = db2c_db2inst1 ** BLANK or char(14). Reserved for root install only db2inst1.PORT_NUMBER = 50000 ** 1024 - 65535, Reserved for root install only db2inst1.TYPE = ESE ** ESE WSE STANDALONE CLIENT db2inst1.AUTHENTICATION = SERVER ** CLIENT, SERVER, or SERVER_ENCRYPT db2inst1.FENCED_USERNAME = db2fenc ** char(8) no spaces, no upper case letters db2inst1.FENCED_GROUP_NAME = db2fgrp ** char(30) no spaces db2inst1.FENCED_HOME_DIRECTORY = /home/db2fenc ** char(64) no spaces db2inst1.DFTDBPATH = /data ** any valid path db2inst1.DFT_MON_BUFPOOL = ON ** ON or OFF db2inst1.DFT_MON_LOCK = ON ** ON or OFF db2inst1.DFT_MON_SORT = ON ** ON or OFF db2inst1.DFT_MON_STMT = ON ** ON or OFF db2inst1.DFT_MON_TABLE = ON ** ON or OFF db2inst1.DFT_MON_UOW = ON ** ON or OFF db2inst1.DFT_MON_TIMESTAMP = ON ** ON or OFF db2inst1.HEALTH_MON = OFF db2inst1.DIAGPATH = /diag ** BLANK or char(215) db2inst1.INSTANCE_MEMORY = AUTOMATIC ** AUTOMATIC or a number in range [0, 1000000] for 32-bit and [0, 68719476736] for 64-bit db2inst1.HEALTH_MON = OFF ** default is ON; ON or OFF db2inst1.SHEAPTHRES = 50000 ** 250 - 2097152 db2inst1.SPM_NAME = NULL ** BLANK or char(8) db2inst1.SYSADM_GROUP = db2adm ** BLANK or char(30) db2inst1.DB2BIDI = ON ** BLANK, 0, 1, YES, NO, ON, OFF, Y, N, TRUE, FALSE, T or F db2inst1.DB2_PARALLEL_IO = * ** BLANK, * or 0-4095,0-4095,... db2inst1.DB2_INLIST_TO_NLJN = YES ** BLANK or YES, NO db2inst1.DB2_USE_ALTERNATE_PAGE_CLEANING = ON ** BLANK or ON, OFF db2inst1.DB2_WORKLOAD = WC ** BLANK, SAP db2inst1.DB2COMM = TCPIP DAS_USERNAME = dasusr ** char(8) no spaces, no upper case letters DAS_GROUP_NAME = dasgrp ** char(30) no spaces
I discovered the hard way that at least for 9.7 FixPack 3 and before, you cannot set the SYSMON group in the response file. It may have changed, I haven’t tried it on FixPacks 4 or 5 because I have additional scripting that makes it easy for me to set parameters manually while I’m doing some other database level set up work. There may be other random settings like that missing.
Note that most of the parameters are prefixed with the instance name – one thing that does is make it so I could create multiple instances using a single response file, and have differing settings for them.
Comments in this file are done by using a double asterix (**), and many of the comments that I’ve left in here are ones that come with the sample file, reminding us of ranges and so forth.
I think you could get by with just the following minimal settings:
- PROD
- FILE
- LIC_AGREEMENT
- INSTALL_TYPE
- INSTALL_TSAMP
But you would have to test it before relying on that advice, and you would also have to do the basics like setting DB2COMM and SVCENAME manually
How to use the response file
This is truly the easy part. To use a response file, all you have to do is execute db2setup as you normally would, but add the -r flag and specify the full path to the response file. Obviously you’re running it as root. It looks something like this:
# ./db2setup -r /downloads/scripts/response_files/my_db2ese_9_7.rsp
Anything I’m missing here? anything else you’d like to know about installing DB2 using a response file?
References
Good developerWorks Article on response files:http://www.ibm.com/developerworks/data/library/techarticle/0302gao/0302gao.html
Info Center entry on response file considerations (links to other good info center entries on response files): http://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.qb.server.doc/doc/c0007502.html
Info Center entry on response file keywords: http://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.qb.server.doc/doc/r0007505.html
Thanks so much for such a great help
I am being forced to use a response file for the first time ever… nice write-up. thanks !
any information/thoughts on the other keywords, and why you might want to use or not use them would be appreciated.
I tend to be a fan of doing a minimal amount of work with the response file, and then doing things manually after that – assuming I’m not building the same database time after time. I haven’t created a database using the response file in years, but it can be done. You can even catalog databases in a response file. I think response files might make sense for PureScale as well.
I do recommend verifying each keyword works as expected at least the first time you use it – I’ve seen issues in the past with a keyword not setting a value as expected, though that was a long time ago.
Here’s a link to the keywords for 10.5: http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.qb.server.doc/doc/r0007505.html