SQL1277W Connection fails because a previous restore operation is still in progress

If you get an SQL1277W after having performed a DB2 redirected restore while trying to connect to the database, one possible cause could be that the backup was taken as a different user (such as root) instead of the instance owner. For databases that use automatic storage, you will likely first get warnings during the restore process saying that tablespaces using automatic storage can get their containers redefined at the end of the restore process.
In short, if you are doing a redirected restore of a database using automatic storage and the restore is not successful completely and you are unable to connect to the db after restoring, it is worth checking if the backup was taken as instance owner or not. Other symptoms could be that one or more tablespaces go offline in drop pending state.

SQL1031N if some data files go missing

Sometimes, people inadvertently delete containers belonging to a DB2 database directly from the file system instead of dropping the database. In such cases, it can be frustrating to try and restore the database from a backup because the restore command fails as does the attempt to first try and drop the database.
The following might help...

$ db2 drop db cogcondb
SQL1031N The database directory cannot be found on the indicated file system.
SQLSTATE=58031

That could mean that the entry for the db is present in the system db directory but it could not be found in the local db directory (which will be in DFTDBPATH by default). So, let us uncatalog it from the system db directory and manually remove any leftover files for this db (including its logs) from the local db directories.

Go to each local db directory (such as C: , D: etc on Windows and /home/db2inst1, etc on Unix. Any directory that contains NODE0000 is two levels under a db directory).
Run the command "db2 list db directory on c:" or "db2 list db directory on /home/db2inst1" for example and make a note of what database is present under which home directory.
Next, issue a db2 list db directory command which will list all the databases that the system as such is aware of. If you find that there are databases which got listed on local but which are not present in the system directory, you can first catalog them (by issuing a catalog database on /home/db2inst1 for example). Cataloguing will create an entry for the database in the system directory after which you can drop it with the usual DROP database command.