Hello,

we are experiencing a strange behaviour on our online backups terminating with

SQL2025N An I/O error "243" occurred on media ... filename ...

Until a week ago we had no problems (for at least 2 years), size of last succesful backup 10.255.105.148 bytes, free space on E: 31 GB. No changes were made in the environment (hardware, locally or in the Active Directory), backups terminate approximately after 15 or 20 minutes, after about 2-3 GB being backed up (information taken from directory sizing). Checked all event logs for error of any type (system, security, application, directory services) in the backup time frame, nothing interesting found (neither locally nor on nearby AD domain controllers). Checked for normal server load and disk activity.

Environment:
DB2 WE, v7, FP6 running on member Win2000 Server + SP3

Executed SQL statements (from backup script log)

02-10-2005 06:15:02 backup database dbname user ??? using ??? online to E:\backup_dir\dbname without prompting
02-10-2005 06:36:36 SQL2025N An I/O error "243" occurred on media "E:\backup_dir\dbname\DBNAME.0\DB2\NODE0000\CATN00 00\20050210\0615".

db2diag.log excerpt:

2005-02-10-06.15.03.097000 Instance:DB2 Node:000
PID:1216(db2syscs.exe) TID:1636 Appid:*LOCAL.DB2.050210051502
database_utilities sqlubcka Probe:0 Database:DBNAME

Starting a full database backup.

2005-02-10-06.36.26.927000 Instance:DB2 Node:000
PID:1216(db2syscs.exe) TID:1040 Appid:none
database_utilities sqluWriteToFileDevice Probe:86

Media controller -- device and file access denied: ffffe60a

2005-02-10-06.36.27.208000 Instance:DB2 Node:000
PID:1216(db2syscs.exe) TID:1040 Appid:none
database_utilities sqluMCWriteToDevice Probe:40

Media controller -- Problem writing to local device E:\backup_dir\dbname

2005-02-10-06.36.27.443000 Instance:DB2 Node:000
PID:1216(db2syscs.exe) TID:1636 Appid:*LOCAL.DB2.050210051502
database_utilities sqlubMWResponse Probe:5 Database:DBNAME

DiagData
17f8 ffff 3234 33ff 453a 5c00 0000 0000 .ř˙˙243˙E:\backup
0000 0000 0000 0000 0000 0000 0000 0000 _dir\dbname \DBNAME
0000 002e 305c 4442 325c 4e4f 4445 3030 .0\DB2\NODE00
3030 5c43 4154 4e30 3030 305c 3230 3035 00\CATN0000\2005
3032 3130 5c30 3631 3500 0210\0615.

2005-02-10-06.36.27.896000 Instance:DB2 Node:000
PID:1216(db2syscs.exe) TID:1636 Appid:*LOCAL.DB2.050210051502
database_utilities sqlubMWResponse Probe:10 Database:DBNAME

DiagData
17f8 ffff .ř˙˙

2005-02-10-06.36.35.850000 Instance:DB2 Node:000
PID:1216(db2syscs.exe) TID:1636 Appid:*LOCAL.DB2.050210051502
oper_system_services sqlormdir Probe:37 Database:DBNAME

9100 0000 ‘...

2005-02-10-06.36.36.475000 Instance:DB2 Node:000
PID:1216(db2syscs.exe) TID:1636 Appid:*LOCAL.DB2.050210051502
database_utilities sqlubcka Probe:0 Database:DBNAME

Backup terminated.

Database names were obfuscated (company policy).

Thanks very much in advance,

Beno

The file might be in use by a virus check or filesystem backup.

Hello,

unfortunately, this is not the problem (we also disabled the antivirus momentarily). I am still searching through the net for the solution, found one in newsgroups, which considers setting the DB2NTNOCACHE, but our DB2 adm already resolved this before (http://dbforums.com/t582416.html).

I have encountered such scenario on few occasions on unix servers. The issue had been the max filesize limits that were set on the filesystems. Example on some filesystems 2GB will be the max hard limit allocated for a file. I am not quite sure how it works on Windows. See if the max File size limit has been altered on the disk. Hope this helps.

- Raj

Thanks for the suggestion Raj and you gave me an idea of an experiment to confirm your theory. I will to create a database size of the approximate values of the last succesful backup at home. Meanwhile I'am going to seek some information about the single filesize limit in Windows 2000. Will report back.

Thanks again,

Beno

After trying to locate the source of the problem we decided to replace the DB2 server in question (hardware). All the problems disappeared, so the problem was obviously in hardware malfunction, despite there were no indications in any error or event log available on the system. Through the analysis of DB2 system monitor snapshots we found that inserting into the database was terribly slow, choking the disk subsystem. So, if you have problems, don't forget to check the hardware, although there is no clear evidence of malfunctioning.

Thanks for help,
Beno

Hello again,

as we changed the hardware, I had the possibility to test various elements at the old server. I found, that after taking the drive defragmentation (we had an IBM ServerRAID 4L and a RAID5 array with 3 and 1 spare SCSI UW160 disk subsystem) the problem with the backup went away. The backup procedure took 57 minutes as compared to approximately 2 hours backup when the server was operational. Anyway we found, that there were some disk errors recorded in the system event log during the defragmentation process and we will bring the server to the IBM service to further diagnose the problem with the disk array.

Have a nice and calm day,
Beno