Log archive failed on TSM with rc= -2045837302

deepak.s...@gmail.com

unread,

Mar 26, 2008, 5:22:20 AM3/26/08

to

I receive following error in db2diag.log file.. 
 
2008-03-23-00.29.12.820888+060 I189543237A313 LEVEL: Warning 
PID : 2123 TID : 1 PROC : db2logmgr (WOGR) 0 
INSTANCE: diniogr NODE : 000 
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogFile, probe:3108 
MESSAGE : Started archive for log file S0000466.LOG. 
 
2008-03-23-00.29.12.821359+060 I189543551A374 LEVEL: Error 
PID : 2123 TID : 1 PROC : db2logmgr (WOGR) 0 
INSTANCE: diniogr NODE : 000 
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogVendor, probe:1630 
RETCODE : ZRC=0x860F000A=-2045837302=SQLO_FNEX "File not found." 
DIA8411C A file "" could not be found. 
 
2008-03-23-00.29.12.822047+060 E189543926A395 LEVEL: Warning 
PID : 2123 TID : 1 PROC : db2logmgr (WOGR) 0 
INSTANCE: diniogr NODE : 000 
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogFile, probe:3150 
MESSAGE : ADM1848W Failed archive for log file "S0000466.LOG" to "TSM chain 3" 
from "/u03/db2data/diniogr/WOGR/NODE0000/". 
 
2008-03-23-00.29.12.822698+060 I189544322A398 LEVEL: Error 
PID : 2123 TID : 1 PROC : db2logmgr (WOGR) 0 
INSTANCE: diniogr NODE : 000 
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogFile, probe:3160 
MESSAGE : Failed to archive log file S0000466.LOG to TSM chain 3 from 
/u03/db2data/diniogr/WOGR/NODE0000/ with rc = -2045837302. 
 
2008-03-23-00.29.12.823102+060 I189544721A329 LEVEL: Error 
PID : 2123 TID : 1 PROC : db2logmgr (WOGR) 0 
INSTANCE: diniogr NODE : 000 
FUNCTION: DB2 UDB, data protection services, sqlpgArchivePendingLogs, probe:1500 
MESSAGE : Log archive failed with rc -2045837302 for LOGARCHMETH1. 

I have following configurations for this database: 
 
Path to log files = /u02/db2data/diniogr/WOGR/ 
Mirror log path (MIRRORLOGPATH) = /u03/db2data/diniogr/WOGR/NODE0000/ 
First active log file = S0000473.LOG 
Log retain for recovery enabled (LOGRETAIN) = RECOVERY 
User exit for logging enabled (USEREXIT) = OFF 
First log archive method (LOGARCHMETH1) = TSM 
Second log archive method (LOGARCHMETH2) = OFF 
Options for logarchmeth2 (LOGARCHOPT2) = 
Failover log archive path (FAILARCHPATH) = /u11/db2data/diniogr/DB/WOGR/failarch/ 
 
We have DB2 version 9 with fix pack 4. 
 
Problem started when i kill instance forcefully and start the instance but TSM server was down, 
i started the TSM serve in between log archiving occured so DB2 put this archive file on failarchpath but TSM server is not archiving this log file from failarchpath. 
We have this archive log file("S0000466.LOG") on FAILARCHPATH path and TSM server is not considering it. 
Any one has face such problem.. any idea ?? 
 
Thanks in advance...

Steve Pearson

unread,

Jun 25, 2008, 1:35:48 PM6/25/08

to

An answer from elsewhere in DB2 development:

>--
DB2 is supposed to move files from the FAILPATH to TSM when TSM is available
again (this should also happen if DB2 is recycled with files in FAILPATH.
We have recently found a bug where files are left in the failpath and never
moved to the archive location. So this is a known problem.
<--

I haven't heard back what the APAR number is; if you need further help on
this, please send me an email and I'll hook you up directly with someone in
L3 support.

Regards,
- Steve P.
--
Steve Pearson, DB2 for Linux, UNIX, and Windows, IBM Software Group
"Portland" Development Team, IBM Beaverton Lab, Beaverton, OR, USA

dbm...@ups.com

unread,

Jun 27, 2008, 11:37:05 AM6/27/08

to

Steve,

We are suffering with the same error code using DB2 V8.1 FP14 and archiving to Legato.

2008-06-24-13.23.41.474406-240 I3637237G297 LEVEL: Warning

PID : 15768 TID : 4096297856 PROC : db2logmgr (P585CMOD) 0

INSTANCE: odbinstp NODE : 000

FUNCTION: DB2 UDB, data protection, sqlpgolf, probe:4440

MESSAGE : Ignore error -2045837302 when closing file

After this error occurred, our archive process is hung with the following message.

2008-06-27-08.06.34.831977-240 I70119055G407 LEVEL: Warning

PID : 15768 TID : 4096297856 PROC : db2logmgr (P585CMOD) 0

INSTANCE: odbinstp NODE : 000

FUNCTION: DB2 UDB, data protection, sqlpgRetryFailedArchive, probe:4780

MESSAGE : Still unable to archive log file 16843 due to rc -2062614522 for

LOGARCHMETH1 using method 3 and target /usr/lib/libnsrdb2.so.

IS there any possible resolution besides a stop/restart of DB2?

Do you know the impact of the following command in efforts to restart or reset the db2logmgr command? Is killing the db2logmgr process an option while DB2 is up and functional? Would that crash the instance/database?

kill -36 15768

Any insight would be very helpful.. Thanks, Ray

Steve Pearson

unread,

Jul 15, 2008, 6:14:37 PM7/15/08

to

Hi Ray.

My first recommendation is to engage IBM support. The appropriate experts
should take a look. (And hopefully already have by now...the forum is not
always the fastest route to an answer :-)

It doesn't look to me like the same scenario, so I wouldn't jump to
conclusions regarding what stop/restart might or might not do here.

The error code -2045837302 means "file not found" which is a general kind of
problem that could occur pretty much anywhere one attempts to interact with
a file system. As such, matching this code doesn't mean matching a specific
problem scenario unless other things are the same. Here, that code seems to
be reported from a different place in DB2.

Another interesting tidbit is the error that follows it (-2062614522).
Looks like it stands for "too many open files".

(from: http://www-1.ibm.com/support/docview.wss?uid=swg21066178&aid=1)
-2045837302 SQLO_FNEX -980 file does not exist
-2045837277 SQLO_FHSL -931 TOO MANY OPEN SYSTEM FILES

Possibly (wild guess) something unhappy occurred in the interface between
DB2 and Legato and for some reason DB2 was not able to successfully close a
file handle; this potentially (continued guessing) caused later grief in
future archiving attempts. I have no idea what medicine would clear it up,
but support may be able to help with a diagnosis and resolution.

Re: "kill -36", on some of the platforms DB2 LUW runs on, this will cause
the EDU/thread/process to perform a stack dump. That is usually fairly
harmless, though occasionally some downstream affect occurs, such as seg
faulting in the stack tracing code if things are in too bad a shape. Not
sure how it would help in your situation unless/until expert investigation
occurs. If it does happen to seg fault in a critical process (and probably
the log manager would be one such), then I guess it could bring down your
instance. Note: "db2pd -stack" is now preferred instead of "kill -36" and
should issue the signal appropriate to the platform (which is not 36 in all
cases !!).