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.