Error Message
SQL0968C The file system is full.This is frequently an error that is returned to an application and reported simply as -968
When You Might Encounter This Error Message
This error typically is encountered when updating or inserting data, though in some cases, it could be encountered when simply querying data.
What is Really Happening?
The most common cause of this error is quite simple – either the disk (filesystem) that holds the database data or the disk (filesystem) that holds transaction logs has become full.
In some situations, the filesystem is being filled up by DB2’s temporary tablespaces or active transaction logs, and as soon as the error is encountered, the transaction will roll back and release the space, making it hard to catch the filesystem at 100% full.
In some rare situations, there may be a limit on the file size for a user, and that may cause this error even when the filesystem is not full. The most common size to see for that is 2 GB. On UNIX and Linux, you can use ulimit -a to find any limits on the DB2 instance owner.
The DB2 Diagnostic Log will have very detailed information on what exactly is filling up. It should give you a specific path to investigate.
How to Resolve
If the disk/filesystem has become full, you either need to add space to the filesystem in question, or remove unneeded files to free up space. If the filesystem in question is filled up with database data, you can consider deleting data from the database, but keep in mind that deletions require log space to complete, and also reorgs to free up space from tables. Depending on the tablespace type, the tablespace may also have to have an ALTER TABLESPACE run for the space to be fully released.
If the space is being filled up by a temporary tablespace, consider analyzing the query or queries running to see if their access plans can be improved. Often a query that is handling more data than it should uses a lot more temporary space than it should – whether the query is a mistaken cartesian product or just one that is table scanning instead of using an appropriate index.
If the space being filled is the active transaction logs, you will need to check to be sure that the archiving of transaction logs is happening appropriately, and also that commits are being issued on an appropriate basis. Verify that LOGFILSIZ * (LOGPRIMARY + LOGSECOND) will fit on the active log disk. These are all database configuration parameters and can be found using:
$ db2 get db cfg for SAMPLE |grep LOG
Catalog cache size (4KB) (CATALOGCACHE_SZ) = (MAXAPPLS*5)
Log buffer size (4KB) (LOGBUFSZ) = 256
Log file size (4KB) (LOGFILSIZ) = 1000
Number of primary log files (LOGPRIMARY) = 3
Number of secondary log files (LOGSECOND) = 10
...
Where SAMPLE is replaced with the database name in question.
If transactions are filling up the active log space without reaching filesystem or disk limits, SQL0964C will be returned instead.