I see this message in the diag.log, v8.2. Its an OLTP database. When I searched the net, I've seen that it might be due to redirected restore or false alarm. Not everything matches my message and the ones I have seen are related to 9.7. Appreciate any help.

2010-11-14-00.55.43.676566-300 I36037641A604 LEVEL: Error
PID : 5894282 TID : 1 PROC : db2bp
INSTANCE: pajzgr0 NODE : 000
APPID : *LOCAL.pajzgr0.101114052447
FUNCTION: DB2 UDB, oper system services, sqlowrite, probe:200
MESSAGE : ZRC=0x850F000C=-2062614516=SQLO_DISK "Disk full."
DIA8312C Disk was full.
DATA #1 : File handle, PD_TYPE_SQO_FILE_HDL, 8 bytes
0x0FFFFFFFFFFFD9B0 : 0000 0005 0000 0000 ........
DATA #2 : unsigned integer, 8 bytes
7605
DATA #3 : signed integer, 8 bytes
6686
DATA #4 : signed integer, 4 bytes
2

Hi,

i guess that you didn't had a Tablespace-Container that ran full, right? There might be several reasons:
- dbcfg-Filesystem ran full, due to a load writing a lot of error messages into this filesystem.
- DB2 was not able to archive log-file fast enough (into TSM). Logfilesystem might ran full. Also TSM might be unavailable for a short time, which may cause the same issues.

There was no filesystem or tablespace issue. No data was being loaded. We also have groundworks monitoring. If TSM is not available, probably it would say that it couldn't establish connection with the TSM serverr. Isn't that right?

R u trying to do a restore redirect or or u just saw this in ur diag log ?
when u faced this issue .

please provide version tablespaces details
regds
paul

These were just things that happened to me. You might found another one.

To your question: Yes, if TSM is down, you'll get messages that DB2 was not able to archive to TSM and that DB2 will try it in 5 Minutes again. But if DB2 couldn't archive fast enough than you don't get messages.

Ahh Disk full is a filesystem issue last time I checked

So, you were not loading data. What were you doing at the time then? There could be multiple reasons on why it happened. More details needed.

What jobs were running at that time? Something that creates a file. Maybe export, backup? Check AIX error log (errpt -a) if this is AIX. If this is AIX and you're using JFS, then it could be due to hitting a max file limit (64 GB).

No reorgs, no redirected restores are being run. The filesystems are just 40% full. Except for the regular transactions, no other processes were running.An IBM guy with whom I spoke said it is most likely a false alarm.

To Bella's question, yes its AIX. I already checked errpt and file limits

False alarm? I have never seeing false alarm at 100%. It might have been a complex SQL that took all of your temp space.

If it is your prod box. for your sake you better have home grown scripts that monitor ALL of your drives regularly.

Could have also been secondary logs that were released after the transaction completed/aborted.

Were there any other messages logged in the db2diag.log at that time?

The reason I said it MIGHT be a false alarm is after I spoke to an IBM guy.

There were no application errors.

The only messages before and after this error were related to log archiving to TSM. Those were successful.