Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've never got this working the first time, but now I can't seem to do i at all.

There is a connection pool somewhere using the database, so trying to drop the database when an application is using the database should give this error. The problem is there are no connection to the database when I issue these commands:

db2 connect to mydatabase
db2 quiesce database immediate force connections
db2 connect reset
db2 drop database mydatabase

This allways give:

SQL1035N  The database is currently in use.  SQLSTATE=57019

running this command shows no connections/applications

DB2 list applications

I can even deactivate the database, but still can't drop it.

db2 => deactivate database mydatabase
DB20000I  The DEACTIVATE DATABASE command completed successfully.
db2 => drop database mydatabase
SQL1035N  The database is currently in use.  SQLSTATE=57019
db2 =>

Anyone got any clues? I'm running the cmd-windows as the local administrator (windows 2008) and this is also the admin for DB2. The connectionpool-user cannot connect during quiesce-state.

share|improve this question
up vote 9 down vote accepted

Just as a tip if Arun's tip does not work, because an remote app is instantly reconnecting to the db.

db2 force applications all 
db2 terminate 

db2set DB2COMM= 

db2 force applications all 
db2 terminate 

... do your stuff here ...


Not sure if the db2 force and the db2 terminate is necessary, though. It's just our best practice.

share|improve this answer
I don't get why remote connections are allowed when the database is "quiesce"'ed and the remote users don't have that authority... – Tommy Feb 12 '10 at 22:59
From IBMs documentation:… -- RESET - Equivalent to an explicit connect to the default database if it is available. If a default database is not available, the connection state of the application process and the states of its connections are unchanged. -- Looks like you connected to the database by calling DB2 connect reset – Peter Schuetze Feb 15 '10 at 15:57
Setting DB2COMM= was the only way to kick out all the connection pools connecting to the database. I just love DB2... – Tommy Feb 20 '10 at 15:21

I just use 'db2stop force', then 'db2start' , then drop db. This way is better than quiesce command which is asynchronous by nature.

share|improve this answer
I must correct my accepted answer. This worked one time, but it must have been luck. Had to turn to Peter's "trick" – Tommy Feb 20 '10 at 15:22

Your problem might occur because of the differences of connect reset and terminate. Have a look at this discussion. You can also have a look at the IBM documentation. So it might work for you if you run a db2 terminate instead of a db2 connect reset.

share|improve this answer

The quiesce will prevent the drop from working. We were involved in a large cleanup effort and after running revoke/connect and quiescing the databases we waited a few months to drop the test dbs. Our drop command wouldn't work unless we unquiesced the db then dropped.

share|improve this answer

Do these steps from command line. This will drop the db:

Force applications all;

deactivate db ;

drop db ;

share|improve this answer

When a db is quiesced it is still on the chain of databases with the db manager, albeit marked as quiesced. When you try to drop it, we will check to see if it is on this chain; if so, then it is still in use ==> You cant drop it.

You have to issue an unquiesce db or issue a db2stop and db2start and then try to drop it. It should work.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.