> -----Original Message----- > From: JUNG, Christian [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 17, 2003 7:09 PM > To: MaxDB (E-Mail) > Subject: RE: Timestamp Recovery > > > Hi! > > > -----Original Message----- > > From: Heinrich, Tilo [mailto:[EMAIL PROTECTED] > > Sent: Thursday, December 11, 2003 3:29 PM > > To: MaxDB (E-Mail) > > Subject: RE: Timestamp Recovery > > > > > > Hello Christian, > > > > if transaction B was committed at 11:59:58 and transaction A > > was committed at 12:00:00 then your restore sequence with a > > slightly modified recover_start until ("recover_start ... > > until 20031211 115959") should restore the database into a > > state, such that the results of B is in the database, the > > results from A are not. It is not possible to restore/erase > > results of single transactions. So if would finish at > > 12:00:01 instead of 11:59:58, you would have a problem. > > > > [...] > > Thanks Tilo! I've realized that my xsqls were running without > the option "-z". So they had automatically committed which > led to unpredictable results... ;) Timestamp-recovery works > as expected. > > Now I've got another problem... > > First: Forget the scenario mentioned in my previous mail. Now > I've got three parallel working users: "A" inserts 1,000 > entries into a table, "B" 10,000 entries into another table > and "C" 100,000 entries into a third table. > > Afterwards they all delete the half of the inserted entries > (500, 5,000 and 50,000 entries). SAP DB has created two log > backups during all these operations (AutoLog is turned on and > there was only one full backup previous to these operations). > > The DELETE-statements were committed at 14:49:11 ("A"), > 14:49:09 ("B") and 14:49:21 ("C"). The "DB Stamp 2" of the > last log backup is 20031217 144921. The transaction of user > "C" was committed at 14:49:21 so it should be completely in > the log backup. > > I've created a new instance and recovered the full backup and > the two log backups with the following commands: > > util_connect > recover_start full data > recover_start autolog log 001 until 20031217 144921 > recover_replace autolog /var/opt/sapdb/bkp/test/log/01.002 > > Afterwards the database was online and user "C" had 100,000 > instead of 50,000 entries in his table. > > I've tried to increase the timestamp to 14:49:22 and above > but the problem persisted. recover_replace returned with > error -8020 (next volume required). First I entered > recover_ignore but "C" has got 100,000 entries in his table. > I also tried "recover_cancel" and "db_restart -u 20031217 144922".
Hi Christian, when you perform a recover/restart until, then all LogEntries which are younger than the until-timestamp are deleted from the LogVolume. Your first try had the until-timestamp 14:49:21, which means to recover all logEntries older than this timestamp. If the commit of user C had taken place at 14:49:21 it will not be recovered, but deleted afterwards. So any subsequent recoveries will also not be able to redo this commit. You also have to take into account, that autosave does not save the complete log. There may remain unsaved LogPages on the LogVolume if a LogSegment cannot be filled. Also the last written LogPage cannot be saved in releases < 7.5 if the DB is online. regards, Martin -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
