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]

Reply via email to