Loading...
Loading...
NetWorker Module for Databases and Applications (NMDA) backup of DB2 databases are impacted: HH/MM/YY HH:MM:SS (pid 54460472): HH/MM/YY HH:MM:SS nw_ddcl_fsync: dfd=2998496 HH/MM/YY HH:MM:SS (pid 54460472): HH/MM/YY HH:MM:SS DDP LOG: [33F0038:110CB3210] ddcl_ddcp_commit(): Commit forcing close of ddcp file //MTREE/DEVICE_FOLDER/active/LONG-SSID on hostname DD_NAME; pid=54460472 HH/MM/YY HH:MM:SS (pid 54460472): HH/MM/YY HH:MM:SS DDP LOG: [33F0038:110CB3210] ddcl_ddcp_close(): Closing File //MTREE/DEVICE_FOLDER/active/LONG-SSID via ddcp on hostname DD_NAME, pid is 54460472 HH/MM/YY HH:MM:SS (pid 54460472): HH/MM/YY HH:MM:SS DDP LOG: [33F0038:110CB3210] ddp_fsync() failed, Err: 5057-File handle is stale HH/MM/YY HH:MM:SS (pid 54460472): HH/MM/YY HH:MM:SS fsys_fsync(): Sync'ing a file failed [5057] ([54460472] [1] DAY MONTH DD HH:mm:SS YYYY ddp_fsync() failed, Err: 5057-File handle is stale Db2diag.log shows similar messaging. YYYY-MM-DD-HH.mm.SS I179696A735 LEVEL: Error PID : 30277794 TID : 61164 PROC : db2sysc 0 INSTANCE: db2inst1 NODE : 000 EDUID : 61164 EDUNAME: db2med.55250.0 (EDWPROD) 0 FUNCTION: DB2 UDB, database utilities, sqluMapVend2MediaRCWithLog, probe:655 DATA #1 : String, 120 bytes Vendor error: rc = 25 returned from function sqluvput. Return_code structure from vendor library /usr/lib/libnsrdb2.o:YYYY-MM-DD-HH.mm.SS E180432A384 LEVEL: Error PID : 30277794 TID : 61164 PROC : db2sysc 0 INSTANCE: db2inst1 NODE : 000 EDUID : 61164 EDUNAME: db2med.55250.0 (EDWPROD) 0 FUNCTION: DB2 UDB, database utilities, sqluMCWriteToDevice, probe:995 MESSAGE : Media controller -- problem writing to vendor device. rc = -2025YYYY-MM-DD-HH.mm.SS E180817A420 LEVEL: Error PID : 30277794 TID : 61164 PROC : db2sysc 0 INSTANCE: db2inst1 NODE : 000 EDUID : 61164 EDUNAME: db2med.55250.0 (EDWPROD) 0 FUNCTION: DB2 UDB, database utilities, sqluMCWriteToDevice, probe:995 MESSAGE : SQL2025N An I/O error occurred. Error code: "". Media on which this error occurred: "".
The Issue is due to large backup window which runs more than 3 hours causing a data domain default timeout. DB2 backup file was opened, but not written to in 3 hours (10,800 seconds). The file was abandoned and deleted by Data Domain File System as per OST_ABANDON_TIMEOUT design.
A Data Domain support request is required. The OST_ABANDON_TIMEOUT system parameter can be adjusted on the Data Domain to allow more time for these large backups to complete. This change requires bash mode access on the data domain. It is not recommended to access bash mode without DD support.
Click on a version to see all relevant bugs
Dell Integration
Learn more about where this data comes from
BugZero Plan
Streamline upgrades with automated vendor bug scrubs
BugZero Prevent
Wish you caught this bug sooner? Get proactive today.