How to completely stop DB2

On Linux and Unix anyway. This is actually a common request during build when OS-level patches are applied or other OS-level work needs to be done, especially any related to disks.

Stop Commerce (and/or any other applications)

I’m not going to go into detail on this one – it is not my area of expertise. If I end up doing it myself, I ask the WebSphere Commerce Admin how.

Stop the db2 instance

First log in to the database server as the db2instance owner(su – is fine if you’re coming from root). This is the id you specified as the DBA on commerce build. Frequently the default is db2inst1.

Try stopping db2 cleanly using simply

$ db2stop
01/05/2011 21:14:41     0   0   SQL1064N  DB2STOP processing was successful.
SQL1064N  DB2STOP processing was successful.

This will fail if there are any connections left. If it does fail, do:

$ db2 list applications

This provides a list of connections to your database. If there are many, go back and make sure you stopped all applications properly. For any remaining connections, make sure there’s no reason you can see that forcing the connections off will fail. Then try this:

> db2stop force
10/01/2008 22:11:53     0   0  SQL1064N  DB2STOP processing was successful.
SQL1064N  DB2STOP processing was successful.

If that doesn’t succeed, there’s one more drastic command you can find that will work, but it’s rare that db2stop force doesn’t work. It may take a bit longer on an active database, as it has to make any remaining connection roll-back their units of work.

Stop the DB2 Administration Server (DAS)

I rarely actually use the DAS, but I always create it on build so it’s out there if I or anyone else needs it. To stop it, you must login as the DAS owner or su – to the DAS owner, and issue the following:

>db2admin stop

I’ve never seen that one fail

For all instances including the DAS, stop the db2 fault monitor

As the das owner (or su’d to it), issue:

db2fm -i <dasowner> -D

ignore any failures, as the failure usually just indicates that the fault monitor was not running in the first place.

As the instance owner (or su’d to it), issue:

db2fm -D

ignore any failures, as the failure usually just indicates that the fault monitor was not running in the first place.

Comment out db2 entry in /etc/inittab and kill any remaining processes

So there’s always one, and sometimes many processes hanging around at this point. One of these is owned by root, and is actually the result of a respawn in inittab. The line looks something like this:

fmc:2:respawn:/usr/opt/db2_08_01/bin/db2fmcd #DB2 Fault Monitor Coordinator

Comment out that line, and (if needed) refresh inittab in memory (I think this varies by OS).

The line above is obviously from DB2 version 8, but the version 9 ones are similar. This is a line added automatically by db2 on install, so even if you never thought it was there, it probably is.

Only after you have done that will the processes stay killed. At this point it is safe to issue kill -9 commands on any remaining db2 processes.

 

And db2 should be completely down. Might be a bit basic for some, but useful for some who are either new to DB2 or have only been on the logical side before.

You may also like...

12 Responses

  1. Alex Markley says:

    Most Linux distributions support the following: “telinit q”. When run as root, this will perform something similar to “kill -HUP 1”

    Note that the “telinit q” method is going to be preferable to other methods (at least for Linux) because it works even if your system is not using System V-style init. If, for example, you’re using the new Upstart boot system, compatibility wrappers like telinit should still be available, even though the internals of the system may have changed.

  2. raju says:

    How do we know who stopped DB2 services from another user who are having all db2 admin rights. At lease can we get IP address for any log files.?

    • Ember Crooks says:

      I’m not sure. We never start/stop db2 with a user other than the instance owner. I imagine auditing would provide you with the ability to track that. Might also ask on one of the forums.

  3. D says:

    your blog is very helpful – I typed “db2stop” into Google, and this page came up, and told me what I needed to know

  4. Norberto Gasparotto Filho says:

    Hi Ember,
    I’ve had issues with db2fmcd on Linux RedHat 6.6 (it changed the way it uses inittab).
    After trying everything I know, a friend of mine that is a Linux specialist told me I should run the following (as root):
    initctl stop db2fmc
    I did it and it worked fine. Just wanted to share here. Thanks for all the valuable info you share in your blog!

    • Esther Burwell says:

      I think the full command for RedHat 6.6 should be (previous had a missing d on the end)
      initctl stop db2fmcd

  5. Gorakh says:

    Hi Ember,

    We usually stop db2 by deactivating the database followed by db2stop and ipclean to clean the memory area used by db2process.

    db2 deactivate (issue when apps are down)

    db2stop

    ipclean (we make sure instance is successfully stopped before issuing ipclean).

    your method is bit different. Is this the correct way what we are following?

    • Ember Crooks says:

      db2stop force will also deactivate the database for you. Deactivating the database may allow db2stop to work without the force parameter. You may have to force remaining applications off if they are still connected. Your method is certainly valid if it works, though if you are stopping db2 for something like a fixpack or upgrade, or OS maintenance, you’ll need to include stopping the DAS(if you have one), the fault monitor, and commenting out the inittab entry.

  6. no says:

    Hi,
    Issuing command “db2fm -D” with a still running db2fmcd has little effect; “db2fm -D” will sequentially send kill, kill -15 and kill -9 to the fault monitor daemon, which then will be killed, but after a short while will be started again by the db2fmcd. So you have to issue the “db2fm -D” command(s) after removing the fmc-entry from the inittab.

  1. July 11, 2012

    […] How to completely stop DB2 Share this:ShareEmailPrintFacebook If you enjoyed this article, please consider sharing it! Tagged with: db2 • ibm • linux  Cancel Reply […]

  2. April 25, 2013

    […] [Side Note: Ember has a really good article on stopping DB2 in preparation for an upgrade. Check out the article here – Link] […]

Leave a Reply

Your email address will not be published. Required fields are marked *