DB2 tablespaces in 'offline' status

Cause

On the first connection to a database (also called database activation), DB2 checks a control block in each database container (pTag) and compares what is found with metadata stored elsewhere within DB2 (iTag). If the pTag and iTag do not match, then DB2 assumes that the container has been corrupted and sets the tablespace state to '0x4000' which means 'offline and not accessible' (SQLB_OFFLINE).

In this instance, the Encryption Expert File System Agent was not running when the first connection to the database was attempted. When the File System Agent is not running, data is returned to DB2, but it is in encrypted format. The result is that DB2 compared the encrypted pTag from the containers to the un-encrypted iTag data, and found a mismatch which resulted in the tablespaces being marked 'offline' in the LIST TABLESPACES command output.

Inspection of the db2diag.log will show entries with the contents of both the pTag and iTag. Both entries will have a Level of 'Severe', and the following function description:
DB2 UDB, buffer pool services, sqlbContainerTagIsValid
The pTag entry will have a probe value of '100', the iTag will have '200'.

There will also be additional entries in the db2diag.log file with a message similar to this:
ZRC=0x8402001E=-2080243682=SQLB_CONTAINER_NOT_ACCESSIBLE
"Container not accessible"

You will also see entries for SQLCODE -290 and SQLCODE -293 in the db2diag.log file.

It is also important to note that no data corruption occurs with this problem.