Cannot connect to DB2 database after restoring an offline backup This is for DB2 9.7 Enterprise Server Edition on AIX.

I had a full, offline backup taken of several databases within our instance in a performance environment.

I wanted to restore these databases to our integration environment.

I ran the command

db2 restore database database_name from 
/bkp/instance_name/OfflineBackups/RestorePoint/my_restore_point 
taken at 20120321103846 into database_name without prompting;


for each of my databases (modifying the database name and timestamp appropriately of course).

Each database restored successfully according to DB2. However, now when I wish to check if the database did indeed restore what I thought, I try to connect to a database and I get the error 

    SQL1117N  A connection to or activation of database "database_name" cannot be made 
because of ROLL-FORWARD PENDING.  SQLSTATE=57019


I didn't have any in process transactions in the previous database because all connections were forced off and the database was down for an offline backup. What do I do?
Found the answer here.

I needed to run the command

db2 rollforward db database_name to end of backup and complete;


This commits everything to the logs and places the database in a no longer pending state, thus allowing connection to it. I needed to do this for each database restored.


  EDIT: Found this nifty nugget while attending a DB2NightShow episode. With 9.7 FP2, they introduced a registry variable called
  DB2_RESTORE_GRANT_ADMIN_AUTHORITY. This is handy if you are restoring
  a backup from one instance to another, as it automatically grants
  instance owner SECADM, DBADM, DATAACCESS, and ACCESSCTRL on the
  databases restored. With 9.7 FP5, the setting is dynamic and does not
  require bouncing of the instance. I realize my original question had
  nothing to do with security, but it can be encountered and thought
  that this would be a handy tidbit placed here.





  EDIT #2: I recently found out that if the backup is an offline backup based on an archival logged database, I could have included the
  clause WITHOUT ROLLING FORWARD in my RESTORE command. This would
  have taken the database out of roll forward pending state immediately
  upon successful restore, which would mean that I would not have had to
  then issue the ROLLFORWARD DB command.