Re: Ontape: problem with restore from 0-archive - Log File not found

Contact TS this sounds like a bug. they will probably have to write a new checkpoint record. Superboer. On 18 jun, 21:36, v...@yandex.ru wrote: > I have a surprise problem with restore from 0-archive (IDS 2000 > Version 9.20.UC2. Sun Solaris 8) > > The 0-archive is created by "ontape -s -L 0". But I can't perform cold > restore from it by "ontape -r" > (I do it without logical recovery): > > # . . . > # 22:30:19 Physical Restore of rootdbs, ritblb, basedbs, sbs1, > rapdbs, ritdbs Completed. > # 22:30:19 Checkpoint Completed: duration was 0 seconds. > # 22:30:19 Checkpoint loguniq 27, logpos 0x7ff018 > # > # 22:30:32 Log 27 not found. > # 22:30:32 Cannot change to Quiescent Mode. > # . . . > > It looks like the 0-archive does not contain Log File 27 with > checkpoint 0x7ff018 - start point > for recovery: > > > % onstat -l > > . . .> > address number flags uniqid begin size used %used > > a499cdc 1 F------ 0 1010a7 2048 0 0.00 > > a499cf8 2 F------ 0 1018a7 2048 0 0.00 > > a499d14 3 F------ 0 1020a7 2048 0 0.00 > > a499d30 4 F------ 0 1028a7 2048 0 0.00 > > a499d4c 5 F------ 0 1030a7 2048 0 0.00 > > a499d68 6 F------ 0 1038a7 2048 0 0.00 > > a499d84 7 F------ 0 1040a7 2048 0 0.00 > > a499da0 8 F------ 0 1048a7 2048 0 0.00 > > a499dbc 9 F------ 0 1050a7 2048 0 0.00 > > a499dd8 10 F------ 0 1058a7 2048 0 0.00 > > a499df4 11 F------ 0 1060a7 2048 0 0.00 > > a499e10 12 F------ 0 1068a7 2048 0 0.00 > > If I do it witj logical restory (ontape -l), the result is wrong again > (the backup contains log files > 27-29): > > > % ontape -l > > Please mount tape 1 on <...> and press Return to continue ...> > > > Roll forward should start with log number 28 > > > > Logical restore failed - buc_fe.c : Archive API processing failed > > at line 920 for msgtype > > > > Program over. > > online.log: > # 21:59:09 Checkpoint loguniq 27, logpos 0x7ff018 > # > # 21:59:09 Start Logical Recovery - Start Log 28, End Log ? > # 21:59:09 Starting Log Position - 27 0x7ff018 > # 21:59:33 Logical Recovery ABORTED. > # Log recovery needs to start with log 28. > # > # 21:59:33 Assert Failed: Logical Recovery ABORTED. > # Dynamic Server 2000 must abort > # 21:59:33 Informix Dynamic Server 2000 Version 9.20.UC2 > # 21:59:33 Who: Session(10, informix@dwarf, 21495, 202381548) > # Thread(31, ontape, c0d3cd8, 1) > # File: rslgr.c Line: 1079 > # 21:59:33 stack trace for pid 21446 written to /tmp/af.40792f4 > # 21:59:33 See Also: /tmp/af.40792f4 > # 21:59:54 rslgr.c, line 1079, thread 31, proc id 21446, > # Logical Recovery ABORTED. > # Dynamic Server 2000 must abort. > # 21:59:54 The Master Daemon Died > # 21:59:54 PANIC: Attempting to bring system down > # 21:59:54 semctl: errno = 22 > > -------------------------------------------------------- > > The question: IS ANY WAY TO RESTORE FROM THIS 0-ARCHIVE (wich does > not > include important log file 27 with starting point for recovery)? > > ==============================================================

It's out-of-support. -- Neil Truby t:01932 724027 Director m:07798 811708 Ardenta Limited e:neil.truby@ardenta.com "Superboer" <superboer7@t-online.de> wrote in message news:1182235101.947530.257360@p77g2000hsh.googlegroups.com... > Contact TS this sounds like a bug. they will probably have to write a > new checkpoint record. > > Superboer. > > On 18 jun, 21:36, v...@yandex.ru wrote: >> I have a surprise problem with restore from 0-archive (IDS 2000 >> Version 9.20.UC2. Sun Solaris 8) >> >> The 0-archive is created by "ontape -s -L 0". But I can't perform cold >> restore from it by "ontape -r" >> (I do it without logical recovery): >> >> # . . . >> # 22:30:19 Physical Restore of rootdbs, ritblb, basedbs, sbs1, >> rapdbs, ritdbs Completed. >> # 22:30:19 Checkpoint Completed: duration was 0 seconds. >> # 22:30:19 Checkpoint loguniq 27, logpos 0x7ff018 >> # >> # 22:30:32 Log 27 not found. >> # 22:30:32 Cannot change to Quiescent Mode. >> # . . . >> >> It looks like the 0-archive does not contain Log File 27 with >> checkpoint 0x7ff018 - start point >> for recovery: >> >> > % onstat -l >> > . . .>> > address number flags uniqid begin size used %used >> > a499cdc 1 F------ 0 1010a7 2048 0 0.00 >> > a499cf8 2 F------ 0 1018a7 2048 0 0.00 >> > a499d14 3 F------ 0 1020a7 2048 0 0.00 >> > a499d30 4 F------ 0 1028a7 2048 0 0.00 >> > a499d4c 5 F------ 0 1030a7 2048 0 0.00 >> > a499d68 6 F------ 0 1038a7 2048 0 0.00 >> > a499d84 7 F------ 0 1040a7 2048 0 0.00 >> > a499da0 8 F------ 0 1048a7 2048 0 0.00 >> > a499dbc 9 F------ 0 1050a7 2048 0 0.00 >> > a499dd8 10 F------ 0 1058a7 2048 0 0.00 >> > a499df4 11 F------ 0 1060a7 2048 0 0.00 >> > a499e10 12 F------ 0 1068a7 2048 0 0.00 >> >> If I do it witj logical restory (ontape -l), the result is wrong again >> (the backup contains log files >> 27-29): >> >> > % ontape -l >> > Please mount tape 1 on <...> and press Return to continue ...>> > >> > Roll forward should start with log number 28 >> > >> > Logical restore failed - buc_fe.c : Archive API processing failed >> > at line 920 for msgtype >> > >> > Program over. >> >> online.log: >> # 21:59:09 Checkpoint loguniq 27, logpos 0x7ff018 >> # >> # 21:59:09 Start Logical Recovery - Start Log 28, End Log ? >> # 21:59:09 Starting Log Position - 27 0x7ff018 >> # 21:59:33 Logical Recovery ABORTED. >> # Log recovery needs to start with log 28. >> # >> # 21:59:33 Assert Failed: Logical Recovery ABORTED. >> # Dynamic Server 2000 must abort >> # 21:59:33 Informix Dynamic Server 2000 Version 9.20.UC2 >> # 21:59:33 Who: Session(10, informix@dwarf, 21495, 202381548) >> # Thread(31, ontape, c0d3cd8, 1) >> # File: rslgr.c Line: 1079 >> # 21:59:33 stack trace for pid 21446 written to /tmp/af.40792f4 >> # 21:59:33 See Also: /tmp/af.40792f4 >> # 21:59:54 rslgr.c, line 1079, thread 31, proc id 21446, >> # Logical Recovery ABORTED. >> # Dynamic Server 2000 must abort. >> # 21:59:54 The Master Daemon Died >> # 21:59:54 PANIC: Attempting to bring system down >> # 21:59:54 semctl: errno = 22 >> >> -------------------------------------------------------- >> >> The question: IS ANY WAY TO RESTORE FROM THIS 0-ARCHIVE (wich does >> not >> include important log file 27 with starting point for recovery)? >> >> ============================================================== > >

Hi, sorry, but contacting Tech Support with this problem may be a limited "solution", because this version of IDS has long gone out of support. Support may be provided on a "time & material basis", but usually that is subject to individual negotiation ... I would try to first do physical only restore ("ontape -p"). Then try to bring the server to on-line mode. You may try this by doing "onmode -m", or "onmode -yuk" followed by "oninit" (i.e. bring down the server and start it again). The "ontape -l" after "ontape -p" I think is a scenario you already tried. If there is an open transaction that needs to be rolled back, but there are no log records, then the above will most likely not solve the problem. In that case Tech Support may be able to cut off that transaction so that it will not be rolled back. Then you'd have somewhere a logic inconsistency, but at least you could access most of the data ... Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland GmbH Chairman of the Supervisory Board: Hans Ulrich Märki Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael Diemer Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart, HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940 informix-list-bounces@iiug.org wrote on 19.06.2007 08:38:21: > Contact TS this sounds like a bug. they will probably have to write a > new checkpoint record. > > Superboer. > > On 18 jun, 21:36, v...@yandex.ru wrote: > > I have a surprise problem with restore from 0-archive (IDS 2000 > > Version 9.20.UC2. Sun Solaris 8) > > > > The 0-archive is created by "ontape -s -L 0". But I can't perform cold > > restore from it by "ontape -r" > > (I do it without logical recovery): > > > > # . . . > > # 22:30:19 Physical Restore of rootdbs, ritblb, basedbs, sbs1, > > rapdbs, ritdbs Completed. > > # 22:30:19 Checkpoint Completed: duration was 0 seconds. > > # 22:30:19 Checkpoint loguniq 27, logpos 0x7ff018 > > # > > # 22:30:32 Log 27 not found. > > # 22:30:32 Cannot change to Quiescent Mode. > > # . . . > > > > It looks like the 0-archive does not contain Log File 27 with > > checkpoint 0x7ff018 - start point > > for recovery: > > > > > % onstat -l > > > . . .> > > address number flags uniqid begin size used %used > > > a499cdc 1 F------ 0 1010a7 2048 0 0.00 > > > a499cf8 2 F------ 0 1018a7 2048 0 0.00 > > > a499d14 3 F------ 0 1020a7 2048 0 0.00 > > > a499d30 4 F------ 0 1028a7 2048 0 0.00 > > > a499d4c 5 F------ 0 1030a7 2048 0 0.00 > > > a499d68 6 F------ 0 1038a7 2048 0 0.00 > > > a499d84 7 F------ 0 1040a7 2048 0 0.00 > > > a499da0 8 F------ 0 1048a7 2048 0 0.00 > > > a499dbc 9 F------ 0 1050a7 2048 0 0.00 > > > a499dd8 10 F------ 0 1058a7 2048 0 0.00 > > > a499df4 11 F------ 0 1060a7 2048 0 0.00 > > > a499e10 12 F------ 0 1068a7 2048 0 0.00 > > > > If I do it witj logical restory (ontape -l), the result is wrong again > > (the backup contains log files > > 27-29): > > > > > % ontape -l > > > Please mount tape 1 on <...> and press Return to continue ...> > > > > > Roll forward should start with log number 28 > > > > > > Logical restore failed - buc_fe.c : Archive API processing failed > > > at line 920 for msgtype > > > > > > Program over. > > > > online.log: > > # 21:59:09 Checkpoint loguniq 27, logpos 0x7ff018 > > # > > # 21:59:09 Start Logical Recovery - Start Log 28, End Log ? > > # 21:59:09 Starting Log Position - 27 0x7ff018 > > # 21:59:33 Logical Recovery ABORTED. > > # Log recovery needs to start with log 28. > > # > > # 21:59:33 Assert Failed: Logical Recovery ABORTED. > > # Dynamic Server 2000 must abort > > # 21:59:33 Informix Dynamic Server 2000 Version 9.20.UC2 > > # 21:59:33 Who: Session(10, informix@dwarf, 21495, 202381548) > > # Thread(31, ontape, c0d3cd8, 1) > > # File: rslgr.c Line: 1079 > > # 21:59:33 stack trace for pid 21446 written to /tmp/af.40792f4 > > # 21:59:33 See Also: /tmp/af.40792f4 > > # 21:59:54 rslgr.c, line 1079, thread 31, proc id 21446, > > # Logical Recovery ABORTED. > > # Dynamic Server 2000 must abort. > > # 21:59:54 The Master Daemon Died > > # 21:59:54 PANIC: Attempting to bring system down > > # 21:59:54 semctl: errno = 22 > > > > -------------------------------------------------------- > > > > The question: IS ANY WAY TO RESTORE FROM THIS 0-ARCHIVE (wich does > > not > > include important log file 27 with starting point for recovery)? > > > > ============================================================== > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list

Thanks for replies! >======================================== > I would try to first do physical only restore ("ontape -p"). > > Then try to bring the server to on-line mode. > You may try this by doing "onmode -m", or "onmode -yuk" > followed by "oninit". >======================================== Of course, I tried that. Result is the same: % ontape -pProgram over. % online.log: nothing % onmode -m % online.log: # 18:55:06 Log 27 not found. # 18:55:06 Cannot change to On-Line Mode. >========================================== > If there is an open transaction that needs to be rolled back, > but there are no log records, then the above will most likely > not solve the problem. In that case Tech Support may be able > to cut off that transaction so that it will not be rolled back. Then > you'd have somewhere a logic inconsistency, but > at least you could access most of the data ... >=========================================== Lost transaction and some logic inconsistency are the last things I'm thinking about now. The main point is: this defective 0-archive does not contain any logical log file at all. As a result, after restore (ontape -r) logical log IS EMPTY (see my example with "onstat -l"). And IDS can't begin any work besause there is no starting checkpoint (it cannot finish restore in 'without logical recovery' mode, cannot start logical recovery (see my 1st posting), etc.) Is any special way to "put down" missing data into the empty logical log? (Some special utilities?) As I see, missing information is the log file and the checkpoint with loguniq/logpos fixed in the archive (27/0x7ff018 in my example). ----------------------------------- appendix ----------------------------------- I cleared up circumstances, in wich defective 0-archive (without log file) is creating. The 'archive' checkpoint is THE LAST RECORD in the current log file. This is obvious bug of IDS/ontape. I can stably reproduce this situation (examples above are the results of purposeful experiments): onlog: # log number: 27. # addr len type xid id link # ... # 7fc7e4 56 HUPDAT 6 0 7fc7ac 500030 18e0b 0 128 128 1 # 7fd038 56 HUPDAT 6 0 7fc7e4 500030 18e0c 0 128 128 1 # 7fd070 36 COMMIT 6 0 7fd038 06/13/2007 18:34:32 # 7fe018 32 CKPOINT 1 27 0 0 # 7ff018 32 CKPOINT 1 27 0 0 # # log number: 28. # # 18 52 ARCINFO 9 28 0 0 06/13/2007 18:35:03 0x17454d 27 0x7ff018 # 4c 52 ARCINFO 9 0 18 0 06/13/2007 18:35:03 0x17454d 27 0x7ff018 # 80 52 ARCINFO 9 0 4c 0 06/13/2007 18:35:03 0x17454d 27 0x7ff018 # b4 52 ARCINFO 9 0 80 0 06/13/2007 18:35:03 0x17454d 27 0x7ff018 # e8 52 ARCINFO 9 0 b4 0 06/13/2007 18:35:03 0x17454d 27 0x7ff018 # 11c 52 ARCINFO 9 0 e8 0 06/13/2007 18:35:03 0x17454d 27 0x7ff018 # 150 52 ARCINFO 9 0 11c 0 06/13/2007 18:35:03 0x17454d 27 0x7ff018 # 1018 32 CKPOINT 1 28 0 0 # 2018 52 LOGINFO 6 28 0 26 06/13/2007 20:46:35 0x1745ab # 3018 52 LOGINFO 6 0 2018 27 06/13/2007 20:46:36 0x1745ac log file length = 2048 ( => max.pos is 0x7fffff). CKPOINT(7fe018) - the result of "onmode -c". CKPOINT(7ff018) - the result of starting "ontape -s". -------------------------------------------------------------------------------------------------------------------------------- Vadim Kubrak, DataX/FLORIN

Hi, hmm. If you think that this is a bug in the archiving, then I'm not really contradicting. The version of IDS that you are using is really old. I will not go and try to find out whether such a problem was known in this old version. And I hope you do not expect this bug to be fixed in that version of IDS. You will have to upgrade. Sorry, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland GmbH Chairman of the Supervisory Board: Hans Ulrich Märki Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael Diemer Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart, HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940 informix-list-bounces@iiug.org wrote on 19.06.2007 16:15:10: > Thanks for replies! > > >======================================== > > I would try to first do physical only restore ("ontape -p"). > > > > Then try to bring the server to on-line mode. > > You may try this by doing "onmode -m", or "onmode -yuk" > > followed by "oninit". > >======================================== > > Of course, I tried that. Result is the same: > > % ontape -p> Program over. > % > online.log: nothing > > % onmode -m > % > online.log: > # 18:55:06 Log 27 not found. > # 18:55:06 Cannot change to On-Line Mode.> > >========================================== > > If there is an open transaction that needs to be rolled back, > > but there are no log records, then the above will most likely > > not solve the problem. In that case Tech Support may be able > > to cut off that transaction so that it will not be rolled back. Then > > you'd have somewhere a logic inconsistency, but > > at least you could access most of the data ... > >=========================================== > > Lost transaction and some logic inconsistency are the last things > I'm thinking about now. > > The main point is: this defective 0-archive does not contain any > logical log file at all. > As a result, after restore (ontape -r) logical log IS EMPTY (see my > example with "onstat -l"). > And IDS can't begin any work besause there is no starting checkpoint > (it cannot finish > restore in 'without logical recovery' mode, cannot start logical > recovery (see my 1st posting), etc.) > > Is any special way to "put down" missing data into the empty logical > log? (Some special > utilities?) > As I see, missing information is the log file and the checkpoint > with loguniq/logpos > fixed in the archive (27/0x7ff018 in my example). > > ----------------------------------- appendix > ----------------------------------- > I cleared up circumstances, in wich defective 0-archive (without log > file) is creating. > The 'archive' checkpoint is THE LAST RECORD in the current log file. > This is obvious bug of IDS/ontape. > I can stably reproduce this situation (examples above are the results > of purposeful experiments): > > onlog: > # log number: 27. > # addr len type xid id link > # ... > # 7fc7e4 56 HUPDAT 6 0 7fc7ac 500030 18e0b 0 128 128 > 1 > # 7fd038 56 HUPDAT 6 0 7fc7e4 500030 18e0c 0 128 128 > 1 > # 7fd070 36 COMMIT 6 0 7fd038 06/13/2007 18:34:32 > # 7fe018 32 CKPOINT 1 27 0 0 > # 7ff018 32 CKPOINT 1 27 0 0 > # > # log number: 28. > # > # 18 52 ARCINFO 9 28 0 0 06/13/2007 18:35:03 0x17454d 27 > 0x7ff018 > # 4c 52 ARCINFO 9 0 18 0 06/13/2007 18:35:03 0x17454d 27 > 0x7ff018 > # 80 52 ARCINFO 9 0 4c 0 06/13/2007 18:35:03 0x17454d 27 > 0x7ff018 > # b4 52 ARCINFO 9 0 80 0 06/13/2007 18:35:03 0x17454d 27 > 0x7ff018 > # e8 52 ARCINFO 9 0 b4 0 06/13/2007 18:35:03 0x17454d 27 > 0x7ff018 > # 11c 52 ARCINFO 9 0 e8 0 06/13/2007 18:35:03 0x17454d 27 > 0x7ff018 > # 150 52 ARCINFO 9 0 11c 0 06/13/2007 18:35:03 0x17454d 27 > 0x7ff018 > # 1018 32 CKPOINT 1 28 0 0 > # 2018 52 LOGINFO 6 28 0 26 06/13/2007 20:46:35 0x1745ab > # 3018 52 LOGINFO 6 0 2018 27 06/13/2007 20:46:36 0x1745ac > > log file length = 2048 ( => max.pos is 0x7fffff). > CKPOINT(7fe018) - the result of "onmode -c". > CKPOINT(7ff018) - the result of starting "ontape -s". > -------------------------------------------------------------------------------------------------------------------------------- > > Vadim Kubrak, > DataX/FLORIN > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list

>============================================== > hmm. If you think that this is a bug in the archiving, then > I'm not really contradicting. The version of IDS that you > are using is really old. I will not go and try to find out > whether such a problem was known in this old version. > And I hope you do not expect this bug to be fixed > in that version of IDS. > > You will have to upgrade. >============================================== Hi! Of course, I don't need to fix this bug. The only thing I want now is to salvage data from this IDS instance. Vadim Kubrak, DataX/FLORIN

On Jun 19, 1:40 pm, v...@yandex.ru wrote: > >============================================== > > hmm. If you think that this is a bug in the archiving, then > > I'm not really contradicting. The version of IDS that you > > are using is really old. I will not go and try to find out > > whether such a problem was known in this old version. > > And I hope you do not expect this bug to be fixed > > in that version of IDS. > > > You will have to upgrade. > >============================================== > > Hi! > > Of course, I don't need to fix this bug. The only thing I want now > is to salvage data from this IDS instance. One possibility, get and install the IDS10 demo version from IIUG. It contains the latest archecker version which can extract data from any archive (IB that it ignores the versioning on the tapes) and can use SQL to insert the data it finds into tables in an existing DB. If that works for you you can extract the data, table by table, from the tape and restore to an empty database. Art S. Kagel

Art S. Kagel wrote: > On Jun 19, 1:40 pm, v...@yandex.ru wrote: > >>>============================================== >>>hmm. If you think that this is a bug in the archiving, then >>>I'm not really contradicting. The version of IDS that you >>>are using is really old. I will not go and try to find out >>>whether such a problem was known in this old version. >>>And I hope you do not expect this bug to be fixed >>>in that version of IDS. >> >>>You will have to upgrade. >>>============================================== >> >> Hi! >> >> Of course, I don't need to fix this bug. The only thing I want now >>is to salvage data from this IDS instance. > > > One possibility, get and install the IDS10 demo version from IIUG. > It contains the latest archecker version which can > extract data from any archive (IB that it ignores the versioning on > the tapes) and can use SQL to insert the data it finds > into tables in an existing DB. If that works for you you can extract > the data, table by table, from the tape and restore to > an empty database. > > Art S. Kagel > > > Just for laughs ... Show us the output from where you run the ontape -r. For example do typescript ontape -r and then at the end post the full recorded yypescript file. I am interested what you enter for the questions from ontape