This is a discussion on Ontape: problem with restore from 0-archive - Log File not found within the Informix forums, part of the Database Server Software category; --> I have a surprise problem with restore from 0-archive (IDS 2000 Version 9.20.UC2. Sun Solaris 8) The 0-archive is ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| 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)? ================================================== ============ |
| |||
| 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.googlegr oups.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)? >> >> ================================================== ============ > > |
| |||
| 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 |
| |||
| >============================================== > 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 |
| |||
| > Just for laughs ... do not kick the man, he is already down... If archecker does work, it would be great, you may get away with it and do not have to spent a penny. However it does require that one knows what tablenames etc are in the database. Still spl triggers permissions need to be pulled out too??? if that is unknown, then contact TS and negotiate that they hack your system so you can access your data. Superboer. |
| |||
| >================================================= = > If archecker does work, it would be great, you may get away with it > and do not have to spent a penny. > However it does require that one knows what tablenames etc are in the > database. > Still spl triggers permissions need to be pulled out too??? >================================================= == Hi! We know the precise structure of the databases we need to salvage. Spl, triggers and so on is not a problem -- we have its full sources (including script with CREATE TABLE statements). We need only the contents of the tables. So, the plan based on archecker seems very attractive (but time- consuming). Does anybody have experience on retrieving data with archecker? ---------------------------------------------- At the same time we try to contact with TS in order to "revive" the IDS inctanse... Vadim Kubrak, DataX/FLORIN |
| ||||
| >=============================================== == > One possibility, get and install the IDS10 demo version from IIUG. >=============================================== == Sorry, I cannot find the demo version in IIUG (www.iiug.org?). Where is it? Vadim Kubrak, DataX/FLORIN |