3700 means e_hostfile_error (ggg00) it is the internal error for -903. -104 means that cancel is not possible because the restore was already aborted.
Please switch on the knltrace with dbmcli: db_admin trace_on default trace_on topiclogtrans 9 trace_on checklogtrans 9 util_connect recover_start ..... After the restore is aborted use dbmcli ... trace_prot akbx this creates a file <dbname>.prt. I would like to look into the trace file. regards, uwe >-----Original Message----- >From: Filip Sergeys [mailto:[EMAIL PROTECTED] >Sent: Wednesday, October 13, 2004 4:36 PM >To: Hahn, Uwe >Cc: [EMAIL PROTECTED] >Subject: RE: log file consistency check > > >Ok, I had a look in the different log files: > >The knldiag file mentions error 3700. I had a look in the >error messages >but there is nothing about error 3700 > >The dbm.utl file mentions return code -903 en -104. 903 is hostfile I/O >error and 104 is command not possible at this time. > >So the file can be opened (according to knldiag, see below), but >somewhere halfway there seems to be an error (according to dbm.utl code >903) > >Are my assumptions correct? > >Is there a way to dissect the log file and try to understand what is >wrong, maybe to prevent it from happening again? > >This is in the knldiag file > >2004-10-13 11:05:40 30910 11597 IO Open >'/var/maxdb/prd/logs/arch.091' successfull, fd: 30 >2004-10-13 11:05:40 25160 11000 vasynope >'/var/maxdb/prd/logs/arch.091' devno 34 T40 succeeded >2004-10-13 11:05:40 30910 11565 startup DEVi started >2004-10-13 11:05:40 25160 52101 RESTORE Filetype: file >2004-10-13 11:05:40 25161 52024 RESTORE 200 pages <- >"r/maxdb/prd/logs/arch.091" >2004-10-13 11:05:40 25161 2 Restart recovering log from tape >from IOSeq '234899' until IOSeq: 'NIL' >2004-10-13 11:05:40 25161 WNG 4 Restart REDO: Aborted >2004-10-13 11:05:40 25161 WNG 4 Restart REDO: Aborted >2004-10-13 11:05:40 25161 WNG 24 Admin Redo error '3700' occured >2004-10-13 11:05:40 25160 11000 vasynclo >'/var/maxdb/prd/logs/arch.091' devno 34 T40 > > >This is in the dbm.utl file > >2004-10-13 11:05:39 416CEFE3000C 0000 RLG RESTORE LOG FROM >'/var/maxdb/prd/logs/arch.091' FILE MEDIANAME 'ARCH' >2004-10-13 11:05:40 416CEFE3000C 0001 RET RETURNCODE -903 >2004-10-13 11:05:40 416CEFE3000C 0002 TAP DATE.............. - - >2004-10-13 11:05:40 416CEFE3000C 0003 TAP TIME.............. ar:/m:ax >2004-10-13 11:05:40 416CEFE3000C 0004 TAP SERVERDB.......... >b/prd/logs/arch.09 >2004-10-13 11:05:40 416CEFE3000C 0005 TAP SERVERNODE........ >2004-10-13 11:05:40 416CEFE3000C 0006 TAP KERNEL VERSION.... >2004-10-13 11:05:40 416CEFE3000C 0007 TAP PAGES TRANSFERRED. >*********** >2004-10-13 11:05:40 416CEFE3000C 0008 TAP PAGES LEFT........ >*********** >2004-10-13 11:05:40 416CEFE3000C 0009 TAP NO OF VOLUMES..... >*********** >2004-10-13 11:05:40 416CEFE3000C 000A TAP MEDIA NAME........ >2004-10-13 11:05:40 416CEFE3000C 000B TAP TAPE NAME......... >2004-10-13 11:05:40 416CEFE3000C 000C TAP TAPE ERRORTEXT.... >2004-10-13 11:05:40 416CEFE3000C 000D TAP TAPE LABEL........ >2004-10-13 11:05:40 416CEFE3000C 000E TAP IS CONSISTENT..... TRUE >2004-10-13 11:05:40 416CEFE3000C 000F TAP FIRST IO SEQUENCE. >*********** >2004-10-13 11:05:40 416CEFE3000C 0010 TAP LAST IO SEQUENCE.. >*********** >2004-10-13 11:05:40 416CEFE3000C 0011 TAP DBSTAMP1 DATE..... - - >2004-10-13 11:05:40 416CEFE3000C 0012 TAP DBSTAMP1 TIME..... : : >2004-10-13 11:05:40 416CEFE3000C 0013 TAP DBSTAMP2 DATE..... - - >2004-10-13 11:05:40 416CEFE3000C 0014 TAP DBSTAMP2 TIME..... : : >2004-10-13 11:05:40 416CEFE3000C 0015 TAP BD PAGE COUNT..... >*********** >2004-10-13 11:05:40 416CEFE3000C 0016 TAP TAPEDEVICES USED.. >*********** >2004-10-13 11:05:40 416CEFE3000C 0017 TAP DB_IDENT.......... >2004-10-13 11:05:40 416CEFE3000C 0018 TAP MAX USED DATA PNO. >*********** >2004-10-13 11:05:56 0019 RLG RESTORE LOG CANCEL >2004-10-13 11:05:56 001A RET RETURNCODE -104 > > > >On Wed, 2004-10-13 at 15:58, Hahn, Uwe wrote: >> Please look into the knldiag[.err] and dbm.utl and dbm.knl. >> There you find more hints why the file cannot be accessed. >> May it be a permission problem ? >> >> recover_check since 74 does not work for log backups yet it >will come again with 76. >> The "consistent" flag is null because it has only a meaning >for data backups >> in versions 73 or older. >> >> regards, >> Uwe >> >> >> >-----Original Message----- >> >From: Filip Sergeys [mailto:[EMAIL PROTECTED] >> >Sent: Wednesday, October 13, 2004 11:25 AM >> >To: [EMAIL PROTECTED] >> >Subject: log file consistency check >> > >> > >> >Hi, >> > >> >How can I check the consistency of an archived log file? >> >I get an error when issueing a recover_start arch log 091 >> >ERR >> >-24988,ERR_SQL: sql error >> >-903,Host file I/O error >> > >> >So I performed a recover_check arch log 091 on that log file. >> >The return >> >is: >> > >> >OK >> >Returncode 0 >> >Date 20041013 >> >Time 00104818 >> >Server masterdb >> >Database ECCENTXD >> >Kernel Version Kernel 7.5.0 Build 014-121-073-298 >> >Pages Transferred 2152 >> >Pages Left 0 >> >Volumes 1 >> >Medianame ARCH >> >Location /var/maxdb/prd/logs/arch.091 >> >Errortext >> >Label LOG_00091 >> >Is Consistent >> >First LOG Page 214668 >> >Last LOG Page 266826 >> >DB Stamp 1 Date 20041012 >> >DB Stamp 1 Time 00112918 >> >DB Stamp 2 Date 20041012 >> >DB Stamp 2 Time 00170552 >> >Page Count 52158 >> >Devices Used 1 >> >Database ID masterdb:ECCENTXD_20041011_233634 >> >Max Used Data Page >> > >> >The "Is Consistent" field is not filled in, but it gives >the impression >> >that the file is OK. >> >Something is not right: the file seems ok, but I can't use it for >> >recover_start. >> > >> >Anybody an idea how I can check things differently? >> > >> >Regards, >> > >> >Filip >> > >> > >> >-- >> >*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* >> >* System Engineer, Verzekeringen NV * >> >* www.verzekeringen.be * >> >* Oostkaai 23 B-2170 Merksem * >> >* 03/6416673 - 0477/340942 * >> >*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* >> > >> > >> >-- >> >MaxDB Discussion Mailing List >> >For list archives: http://lists.mysql.com/maxdb >> >To unsubscribe: >http://lists.mysql.com/[EMAIL PROTECTED] >> > >> > >-- >*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* >* System Engineer, Verzekeringen NV * >* www.verzekeringen.be * >* Oostkaai 23 B-2170 Merksem * >* 03/6416673 - 0477/340942 * >*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
