Version 9.0.2

I am attempting to recover a database in which the only backup is corrupt
and multiple log files need to be applied.

I have successfully unloaded and reloaded the corrupt database into a new
database file but when attempting to apply the log files I get the error
"cannot open transaction log xyz.log belongs to a different database"

Any words of wisdom please!

Thanks

Jim

Applying log files relies on log offsets, once a backup has been
started, or rebuilt you can no longer apply existing log files to that
database.

You could translate the log files and execute the SQL against your new
database using the dbtran utility.

Jim Diaz wrote:

Thanks.

My thought was if I rebuilt IAW the process for "Rebuilding databases
involved in replication" and then applied the log files I would be all set.



So if a user performs a full backup of a corrupt database and then several
incremental backups there is no way to recover? In this case the normal
database validation did not discover the corruption it was discovered when
we initially tried to recover from the full backup.



Thanks



Jim




"Kory Hodgson (Sybase iAnywhere)" <khodgson (AT) A_SPAM_FREE_sybase (DOT) com> wrote in
message news:4acceaea$1 (AT) forums-1-dub (DOT) ..

In order to be able to apply logs to a backup, the full backup version
of the database cannot be started until after all log files from
incremental backups have been applied.

So the only way you can start the database without damaging your
recovery strategy is to run dbengXX\dbsrvXX with the -a option to apply
the logs.

Doing a "Rebuilding databases involved in replication" would preserve
log offsets, but they last offset would get modified when the database
was started I believe causing this not to match what the recovery would
expect.


Question: If you have an original copy of your backup, can you try
applying the log files to it?

Then after that do a rebuild?


Jim Diaz wrote:

A corrupt backup cannot be used in a recovery - it can be used in a data
salvage which may result in 0-100% salvage. A recovery requires a clean
backup image and clean transaction logs. Any damage to the inputs can
impede a successful recovery.

The primary database may not have been damaged initially but it is
always possible that the backup was damaged when created i.e., a failing
disk drive. I assume that at some point your primary database started
failing validation or was there some other indicators of corruption?
Where was the backup relative to the primary database? Have you
determined the potential source of the corruption i.e., failing hardware?

I generally recommend validation of the backup as part of your recovery
test and verification process. "Firedrilling" the recovery process
allows for practice (when not under the pressure of a real production
down) and tweaking of the process so that it is realiable. This also
verifies that the backup image is usable.




Jim Diaz wrote:

On 7 Oct 2009 12:59:33 -0700, "Jim Diaz"
<nospam (AT) emprisecorporation (DOT) com> wrote:

FWIW, validation should be performed against the copy, not the
original, to ensure that the backup copy is valid. You do this by
using read-only mode or by validating a copy of the backup database.
If the backup proves to be valid, then you know the original is valid
as well.

I'm not saying this affects you, I'm just making a point for the
benefit of folks in general.

Breck

--
Breck Carter http://sqlanywhere.blogspot.com/

RisingRoad SQL Anywhere and MobiLink Professional Services
breck.carter (AT) risingroad (DOT) com

Thank you all.

First, this error has occured during a desaster recovery scenerio and is not
present on our actual production system. I wanted to follow it through to
see if we could recover in a time frame which allowed us not to go to tape
which are stored off-site and requires an act of god to retrieve. Our
scenerio requires a 72 hour recovery time.

The database in question is a very large consolidated with roughly 100
remotes. In our design the consolidated is only used as a replication hub
another full subscription handles local application access and the remotes
(SQL Remote) are partial subscriptions which provide remote application
access. We perform incremental backups after each SQL Remote run and full
offline backups to a seperate network server weekly. We then perform a full
validation on the offline backup by starting in read only mode as suggested.

The problem here occured when applying the log files to the last validated
full offline backup. We received an assertion error. I believe the server
had an NTFS error which caused the corruption of the backup file. In an
attempt to recover I unloaded the database, which failed on a specific
table. I then unloaded all tables but this one and retrieved the data for
this table from the full subscription. I then ran a unload of structure
only and pasted in the load table sections. Finally I rebuilt the database
with this new script and data and followed the "Rebuilding databases
involved in replication" process with one exception I kept the relative
offset the same as in the original corrupt database, since the active log
file for this database had no transactions. I used these og files for the
rebuilt database.

Next I started the rebuilt and currupt databases in read only mode and
verified all remote user offset values. In these two databases the only
value that I can see that was not the same was the SQL Remote Truncation
Offset.

I then said well Jim thats a great job all you have to do now is apply the
log files....... You know the rest of the story.

I don't know how the server knew it was a different database. I suspect its
because of some header value that is different or perhaps the truncation
offset value. It would be nice to be able to force the application of these
log files.

Jim








"Jim Diaz" <nospam (AT) emprisecorporation (DOT) com> wrote

On 8 Oct 2009 05:51:34 -0700, "Jim Diaz"
<nospam (AT) emprisecorporation (DOT) com> wrote:

As soon as you start a database normally (accepting connections, as
opposed to -a recovery mode), it becomes a "new database" as far as
applying log files is concerned. You can no longer apply an older log
file because the database has "moved on" to a different state.
Applying log files via -a is strictly a sequential affair... if it
wasn't, then people could get into enormous difficulties applying the
wrong log files, in the wrong order, to the wrong databases... it has
to check correctness... I am guessing that would be The Party Line
response

The alternative, to "force" application of the logged data, is to
dbtran the log file into SQL commands, and then run the SQL commands
in a normal client-server (dbisql) manner.

Forcing -a recovery would be a new feature... try asking for it in
product_futures_discussion, see what the reaction is. I'm curious too.

Breck

--
Breck Carter http://sqlanywhere.blogspot.com/

RisingRoad SQL Anywhere and MobiLink Professional Services
breck.carter (AT) risingroad (DOT) com