Unanswered: Online backup terminating with SQL2025N
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.
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".
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.
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.
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.
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.