Tilo, I got the error when I was using autorecover to recover a data backup, which is an approach I've abandoned - I'm only going to use autorecover log.
I'm sorry, but I can't post the error because I've dropped and recreated the database, and lost all the history. If the problem happens with autorecover log, I will post. David > -----Original Message----- > From: Heinrich, Tilo [mailto:[EMAIL PROTECTED] > Sent: 30 January 2007 16:04 > To: [email protected] > Subject: RE: Recover from lost log volume > > Hello David, > > The autorecover command uses the backup history to determine > the needed external backup IDs (EBIDs). The command does not > have no parameter for any EBID's. You can however specify an > internal backup ID (IBID) of a certain data backup that you > want the recovery to start with. EBIDs and IBIDs are not the > same thing. Any backup is identified by exactly one IBID but > can have more then one EBID. The number of EBIDs depends on > the number of devices used and of the number of copies that > were made of the backup. > > Can you please post the complete command and the resulting error. > > Best regards, > Tilo Heinrich > SAP Labs Berlin > > -----Original Message----- > From: David Lane > Sent: Dienstag, 30. Januar 2007 16:29 > To: Heinrich, Tilo; [email protected] > Subject: RE: Recover from lost log volume > > Thanks again, Tilo. I've been experimenting, and come to the > same conclusion. > > One more question :) > > I did try using autorecover to recover a data backup, and I > got the error "The list of external backup ID's contains more > than 1 ID's." > If I do 'autorecover log', it is fairly sure to need to > restore more than one log. Can you confirm that it will do > the right thing and feed the EBIDs to me one by one - i.e. it > will do the equivalent of: > > recover_start EBID1 > recover_replace EBID2 > ... > > rather than > > recover_start EBID1,EBID2 > > Thanks > > David > > > -----Original Message----- > > From: Heinrich, Tilo > > Sent: 30 January 2007 15:20 > > To: [email protected] > > Subject: RE: Recover from lost log volume > > > > Hello David, > > > > Autorecover should restore the database to the last > possible database > > state using the information of the backup history. > > However, detection of a needed data backup can be tricky. > So I would > > currently suggest: > > > > db_activate recover ... > > autorecover log ... > > > > The command should be available in 7.5. You can check for > availability > > as follows: "dbmcli -d <db_name> help autorecover" > > > > Best regards, > > Tilo Heinrich > > SAP Labs Berlin > > > > -----Original Message----- > > From: David Lane > > Sent: Dienstag, 30. Januar 2007 14:02 > > To: Heinrich, Tilo; [email protected] > > Subject: RE: Recover from lost log volume > > > > Thanks, Tilo. > > > > Two questions: > > - How does autorecover relate to db_activate? Where the log > volume is > > lost, do I do: > > > > db_activate recover ... > > autorecover > > > > - Is autorecover available in MaxDB 7.5? > > > > Thanks > > > > David Lane > > > > > > > -----Original Message----- > > > From: Heinrich, Tilo > > > Sent: 30 January 2007 12:42 > > > To: [email protected] > > > Subject: RE: Recover from lost log volume > > > > > > Hello David, > > > > > > As you are using an external backup tool, you might want to > > give the > > > DBM command autorecover a try. > > > > > > Recover_replace must be in the same session as the initial > > > recover_start. So db_activate and "recover_start log..." > > must not be > > > in the same session. You can even restore the log backups > > in more then > > > one sesion, but you have the start all these sessions with a > > > "recover_start log...". If you do so, you must be prepared > > to restore > > > a small parts of the log more then once. The DBM command > > > db_restartinfo helps you to determine the next log backup needed. > > > > > > "save_skipped" means that you tried a log backup that is > > not needed at > > > the moment. > > > > > > Best regards, > > > Tilo Heinrich > > > SAP Labs Berlin > > > > > > -----Original Message----- > > > From: David Lane > > > Sent: Dienstag, 30. Januar 2007 13:32 > > > To: Brunzema, Martin; [email protected] > > > Subject: RE: Recover from lost log volume > > > > > > I'm following a previous thread (I/O error trying to recover log > > > backup, earlier in January), where the sequence that worked is: > > > > > > db_connect > > > db_activate recover medium data ... > > > recover_start logmedium log ... > > > > > > Does the whole recovery have to be done in one dbmcli > > session, or can > > > I do the db_activate in one session, then the recover_start in a > > > second session, then recover_replace in a third session, > and so on: > > > > > > db_connect > > > db_activate recover medium data externalbackupid "EBID" > > autoignore ... > > > db_connect > > > recover_start logmedium log externalbackupid "EBID" > > > > > > What I see is that the db_activate works, but the recover_start > > > restore of the log hangs. In the database messages > (verbose) I see: > > > > > > 2007-01-30 12:13:17 Log 0: no update of > > LogInfoPage: > > > DeviceState = Cleared, LogIsEmpty = true > > > 2007-01-30 12:13:17 KernelComm 6: k38headmaster, > > Errorcode > > > 4306 "save_skipped" > > > 2007-01-30 12:13:17 KernelComm 6: RestoreLog, > > > Errorcode 4306 > > > "save_skipped" > > > > > > I know that the dbmgui can do all this for me, but we have > > a customer > > > who wants to do restores through our backup console, which uses > > > dbmcli, so I need to work out the right sequence of > dbmcli commands. > > > > > > Thanks > > > > > > David Lane > > > > > > > -----Original Message----- > > > > From: Brunzema, Martin > > > > Sent: 30 January 2007 12:07 > > > > To: [email protected] > > > > Cc: David Lane > > > > Subject: RE: Recover from lost log volume > > > > > > > > Hi David, > > > > > > > > in order to recreate the logvolumes it is not sufficient > > to restore > > > > data/restore log. Instead of a restore data you has to > > "reactivate" > > > > the instance with the dbmcli-command > > > > db_activate RECOVER <your databackupmedium> > > > > > > > > The dbmgui offeres this option by using "recovery with > > > initialization" > > > > > > > > But be aware that all data in the data- and logvolumes is > > > cleared by > > > > this step. > > > > > > > > Kind regards, Martin > > > > > > > > > -----Original Message----- > > > > > From: David Lane > > > > > Sent: Tuesday, January 30, 2007 11:03 AM > > > > > To: Hahn, Uwe; [email protected] > > > > > Subject: RE: Recover from lost log volume > > > > > > > > > > Uwe, > > > > > > > > > > Thanks for your reply. I have tried that. > > > > > - Restore full - works ok > > > > > - Restore pages - works ok > > > > > - Restore log - fails. > > > > > > > > > > Dbmcli reports > > > > > -24920,ERR_BACKUPOP: backup operation was unsuccessful > > > The database > > > > > was unable to fulfill a request (-902, I/O error). > > > > > > > > > > Database messages (verbose) shows: > > > > > 2007-01-30 09:51:47 IO 11597: Open > > > > > '/var/opt/sdb/data/MAXDB1/log/DISKL0001' successfull, fd: 17 > > > > > Thread 0x1A > > > > > 2007-01-30 09:51:47 ERR IO/READ 11987: read error: rc=0, > > > > > wanted=8192, 'NO ERROR(0)', try again Then > > > > > Thread 0x14 Task 97 > > > > > 2007-01-30 09:51:49 vattach 11000: > > > > > '/var/opt/sdb/data/MAXDB1/log/DISKL0001' T97 failed > > > > > Thread 0x14 Task 97 > > > > > 2007-01-30 09:51:49 ERR IOMan 26: Attach error on > > > > > Log volume > > > > > 1: Could not open volume > > > > > Thread 0x14 Task 97 > > > > > > > > > > The problem is that the log volume > > > > > /var/opt/sdb/data/MAXDB1/log/DISKL0001 was lost. > > > > > I have tried the log restore with > > > > > /var/opt/sdb/data/MAXDB1/log/DISKL0001 > > > > > missing, and it fails. > > > > > I also tried creating an empty > > > > /var/opt/sdb/data/MAXDB1/log/DISKL0001 > > > > > file, but it still fails. > > > > > > > > > > I cannot find any way to recreate > > > > > /var/opt/sdb/data/MAXDB1/log/DISKL0001. > > > > > > > > > > Your help will be much appreciated. > > > > > > > > > > Thanks > > > > > > > > > > David Lane > > > > > > > > > > > -----Original Message----- > > > > > > From: Hahn, Uwe > > > > > > Sent: 29 January 2007 17:54 > > > > > > To: David Lane; [email protected] > > > > > > Subject: RE: Recover from lost log volume > > > > > > > > > > > > Hi David, > > > > > > > > > > > > you have to reinstall your database instance with your last > > > > > > data- and log-backups. > > > > > > > > > > > > Kind regards > > > > > > Uwe > > > > > > > > > > > > -----Original Message----- > > > > > > From: David Lane > > > > > > Sent: Montag, 29. Januar 2007 15:43 > > > > > > To: [email protected] > > > > > > Subject: RE: Recover from lost log volume > > > > > > > > > > > > I forgot to mention: I am running MaxDB 7.6 on solaris 9. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: David Lane > > > > > > > Sent: 29 January 2007 14:37 > > > > > > > To: [email protected] > > > > > > > Subject: Recover from lost log volume > > > > > > > > > > > > > > How do I recover from total loss of my log volume? I > > > > can restore > > > > > > > database backups ok, but when, after restoring > the backups, > > > > > > I try to > > > > > > > change the database to online mode (from > > > > > > > dbmgui) I get > > > > > > > > > > > > > > -24988 sql error [db_online -f] -902,I/O error. > > > > > > > > > > > > > > In knldiag: > > > > > > > > > > > > > > 2007-01-29 14:23:20 0x14 11000 vattach > > > > > > > '/var/opt/sdb/data/MAXDB1/log/DISKL0001' T92 failed > > > > > > > 2007-01-29 14:23:20 0x14 ERR 26 IOMan Attach > > > > > > error on Log > > > > > > > volume 1: Could not open volume > > > > > > > > > > > > > > /var/opt/sdb/data/MAXDB1/log/DISKL0001 is the lost log > > > > > > volume. I have > > > > > > > tried creating the file (just an empty file) and that > > > makes no > > > > > > > difference. I found something in the mailing > archive about > > > > > > > 'util_execute clear log' to reinit the log, but that > > > > crashes the > > > > > > > database. > > > > > > > > > > > > > > What am I missing? > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > David Lane > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _____________________________________________________________________ > > > > > > > BridgeHead Software is pleased to confirm this e-mail has > > > > > > been scanned > > > > > > > for viruses by MessageLabs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _____________________________________________________________________ > > > > > > BridgeHead Software is pleased to confirm this e-mail > > has been > > > > > > scanned for viruses by MessageLabs. > > > > > > > > > > > > -- > > > > > > MaxDB Discussion Mailing List > > > > > > For list archives: http://lists.mysql.com/maxdb > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _____________________________________________________________________ > > > > > BridgeHead Software is pleased to confirm this e-mail has > > > > been scanned > > > > > for viruses by MessageLabs. > > > > > > > > > > -- > > > > > MaxDB Discussion Mailing List > > > > > For list archives: http://lists.mysql.com/maxdb > > > > > > > > > > > > > > > > > > > > > > > _____________________________________________________________________ > > > BridgeHead Software is pleased to confirm this e-mail has > > been scanned > > > for viruses by MessageLabs. > > > > > > -- > > > MaxDB Discussion Mailing List > > > > > > -- > > > MaxDB Discussion Mailing List > > > For list archives: http://lists.mysql.com/maxdb > > > > > > > > > > > _____________________________________________________________________ > > BridgeHead Software is pleased to confirm this e-mail has > been scanned > > for viruses by MessageLabs. > > > > -- > > MaxDB Discussion Mailing List > > For list archives: http://lists.mysql.com/maxdb > > > > > > _____________________________________________________________________ > BridgeHead Software is pleased to confirm this e-mail has > been scanned for viruses by MessageLabs. > > -- > MaxDB Discussion Mailing List > For list archives: http://lists.mysql.com/maxdb > To unsubscribe: > http://lists.mysql.com/[EMAIL PROTECTED] > > _____________________________________________________________________ BridgeHead Software is pleased to confirm this e-mail has been scanned for viruses by MessageLabs. -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
