Starting a DB2 Instance in a Quiesced State

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.

Ember Crooks
Ember Crooks

Ember is always curious and thrives on change. She has built internationally recognized expertise in IBM Db2, spent a year working with high-volume MySQL, and is now learning Snowflake. Ember shares both posts about her core skill sets and her journey learning Snowflake.

Ember lives in Denver and work from home

Articles: 554


Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.