Hello everyone...
Markus wrote (in part):
> Did you try to use db_activate recover <backup medium>.... to
restore the DB?
Tilo wrote (in part):
> The actual problem is "RETURNCODE -7075", which means that the
selected log
> backup does not match your data backup. Do you
mind sending the files dbm.knl
> and dbm.ebf of the original database to this
list?
I have not yet tried to use the "db_activate recover" command as
Markus
suggested, because I'm attempting to run the
restore from Data Protector's
restore GUI. As such, DP issues
all of the dbmcli commands. I have an open
call to Hewlett-Packard regarding this
issue, so if "db_activate recover" turns
out to be something critical, I'll update them so
that they can incorporate
this command into DP.
As Tilo requested, I am attaching the dbm.knl & dbm.ebf files from
the original
database to this message for your
review.
The full backup being used in this test corresponds to these
lines:
422D4D750030|DAT_00065|...
The log backup being used in this test corresponds to this
line:
422E94660032|LOG_00168|...
From the source database's backup
history, I can see where backup DAT_00065's
next log page is 10,137,567. I can also see
where backup LOG_00168 contains
log pages from 10,136,969 to 10,194,017.
As soon as DAT_00065 is restored, if the database expects log page
10,137,568,
how do I tell DP (or any other external backup tool for that matter) that
that
log page is in the middle of LOG_00168?
We perform a log backup every morning at 1:15 am, and then perform a
full
backup twice each week at 2:00 am. Is this backup methodology
causing some
problem? If so, how do I solve it?
Thanks,
~Fred
-- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
