Some applications are really good at continually trying to re-establish connections to a database. This can be useful when I want to quickly bounce the database and have the app reconnect without also having to bounce the app. It is problematic when I need DB2 to be down and stay down, but still allow me to work with it. This can be needed to kick off a backup or to keep things down during an upgrade. When upgrading to DB2 8.1, there was actually a point in time where, if an application connected, the entire upgrade was hosed.
The trick I’ve used for years for this is simply to unset SVCENAME – as long as all connections are remote, applications will not be able to connect. If local applications were in the mix, I could catalog the database under an alias, and then uncatalog the name everyone knew about.
I used this trick because some of my clients get lazy and allow their applications to have DBADM level authority, and this levels of authority blows right past the limitations on a quiesced database.
I recently learned a new trick that has apparently been available at least since 9.7. Different options on the db2start command restrict users to those who have a SYSADM, SYSCTRL, or SYSMAINT and are specified in the start command itself. This is different than a traditional quiesce where users with certain authorities can always bypass the quiesce.
This means I can use the following to restrict access to both the instance and the database to just me on start:
db2start admin mode user ecrooks restricted access
The admin mode portion of this causes the instance to be quiesced as it is started. Adding user ecrooks means that only the user ecrooks will be able to connect to any local database (assuming ecrooks has SYSADM, SYSCTRL, or SYSMAINT and authority to connect to the database). restricted access means that DB2 will not even perform authorization checking for IDs without SYSADM, SYSCTRL, or SYSMAINT.
Note that IDS with SYSADM will always be able to access the quiesced instance/database. This is necessary so a user doesn’t lock everyone out and then there is no method to allow access without that user’s ID.
As much time as I spend with the info center, I admit to not having looked at the db2start page much. It is worth a look.
Had this problem recently, needing to a quick backup, and revoked connect privs from public and other roles.
Thanks Ember, in addition to this method, there is another unofficial method which uses a special db2trc command to block all incoming application db-connections (coming through tcp), allowing only db-connections local to the host (which happen to come through ipc).
You can read about that in this technote: http://www-01.ibm.com/support/docview.wss?uid=swg21673436