Home > Archive > SQL Anywhere database > April 2005 > Recovery problem...









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Recovery problem...
Troy Coombs

2005-04-09, 8:24 pm

I'm attempting to recover a corrupt database from several days ago using the
'a' switch.

I've successfully applied 5 daily log files. Wonderful! However when I
attempt to apply the 6th daily log file I get an error which reads,
"Database cannot be started - C:\recovery\dealer6.log is an invalid
transaction log."

Anyone know what this means or could be resulting from?

Using ASA 8.0.2.

We suspect the corruption came from a failed load table as the weekly
validation reported an error. Any attempt to drop that table results in an
Assertion error.

A few files were loaded into that table on day 6 which is the log file I'm
haing the issues with. However I converted the log file to a sql file so I
could look at the sql around the load tables and all looks fine. ????

Troy


Greg Fenton

2005-04-09, 8:24 pm

Troy Coombs wrote:
>
> I've successfully applied 5 daily log files. Wonderful! However when I
> attempt to apply the 6th daily log file I get an error which reads,
> "Database cannot be started - C:\recovery\dealer6.log is an invalid
> transaction log."
>


Try running dbtran against the dealer6.log file and see if it translates
successfully. If not, post the error message.

greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/
Troy Coombs

2005-04-11, 7:23 am

I've done this using the utility in Sybase Central and the it translates
just fine. The sql file looks fine. I've even found the LOAD TABLE
statements that loads the text file into the troubled table and it looks
fine. ?????

Troy


"Greg Fenton" <greg. fenton_NOSPAM_@ianyw
here.com> wrote in message
news:42571e28$1@foru
ms-1-dub...
> Troy Coombs wrote:
>
> Try running dbtran against the dealer6.log file and see if it translates
> successfully. If not, post the error message.
>
> greg.fenton
> --
> Greg Fenton
> Consultant, Solution Services, iAnywhere Solutions
> --------
> Visit the iAnywhere Solutions Developer Community
> Whitepapers, TechDocs, Downloads
> http://www.ianywhere.com/developer/



Alex Whitney

2005-04-11, 8:24 pm

Have you tried just running the exported SQL from the transaction log
directly into the database?

Different path but same effect

Alex


"Troy Coombs" <coombst@quorumis.com> wrote in message
news:425a5b40$1@foru
ms-1-dub...
> I've done this using the utility in Sybase Central and the it translates
> just fine. The sql file looks fine. I've even found the LOAD TABLE
> statements that loads the text file into the troubled table and it looks
> fine. ?????
>
> Troy
>
>
> "Greg Fenton" <greg. fenton_NOSPAM_@ianyw
here.com> wrote in message
> news:42571e28$1@foru
ms-1-dub...
I[color=darkred]
>
>



Troy Coombs

2005-04-12, 1:23 pm

Yes, I just did that (took 27 hours) and it worked fine. No errors!
However I think it probably through the checkpoints out of whack because now
I can not apply the next log file using the 'a' switch. I guess it was
because I had to start the database without a log file in order to allow
ISQL to READ the sql file.

Any ideas on what I should or can do to get those other log files applied?
Don't say convert to sql as it would take about a week to apply the
remainder of the log files.

Troy


"Alex Whitney" <alexw55@pdq.net> wrote in message
news:425ad0b2$1@foru
ms-1-dub...
> Have you tried just running the exported SQL from the transaction log
> directly into the database?
>
> Different path but same effect
>
> Alex
>
>
> "Troy Coombs" <coombst@quorumis.com> wrote in message
> news:425a5b40$1@foru
ms-1-dub...
when[color=darkred]
> I
translates[color=dar
kred]
>
>



Alex Whitney

2005-04-13, 11:23 am

Sorry, but that's the only other solution I have.

Alex
"Troy Coombs" <coombst@quorumis.com> wrote in message
news:425c0a28@forums
-2-dub...
> Yes, I just did that (took 27 hours) and it worked fine. No errors!
> However I think it probably through the checkpoints out of whack because

now
> I can not apply the next log file using the 'a' switch. I guess it was
> because I had to start the database without a log file in order to allow
> ISQL to READ the sql file.
>
> Any ideas on what I should or can do to get those other log files applied?
> Don't say convert to sql as it would take about a week to apply the
> remainder of the log files.
>
> Troy
>
>
> "Alex Whitney" <alexw55@pdq.net> wrote in message
> news:425ad0b2$1@foru
ms-1-dub...
translates[color=dar
kred]
looks[color=darkred]

> when
reads,[color=darkred
]
invalid[color=darkre
d]
> translates
>
>



Troy Coombs

2005-04-13, 11:23 am

Thanks for your effort Alex. I'm going to log a case with Sybase.

"Alex Whitney" <alexw55@pdq.net> wrote in message
news:425d43ed$1@foru
ms-2-dub...
> Sorry, but that's the only other solution I have.
>
> Alex
> "Troy Coombs" <coombst@quorumis.com> wrote in message
> news:425c0a28@forums
-2-dub...
> now
applied?[color=darkred]
> translates
> looks
> reads,
> invalid
>
>



Erik Anderson

2005-04-13, 1:23 pm

If you want to play around with this database some more (and you have plenty
of backups of the database at each step that you've done on this) and the
transaction log you manually applied has no DDL, you *may* be able to get
away with re-aligning your database's transaction log offset with the
starting offset of your next transaction log (read instructions on manually
reloading a database involved in DBRemote-style replication).

This *may* get dbsrv9 -a to work with the succeeding transaction logs. It
may also corrupt your database, as you are kind of tricking the engine into
doing something that it really shouldn't be doing. At the least you will
probably be missing some transactions that fall in the "gap" between your
manually applied transaction log and any logs applied thereafter.

Note that I've tried this method with a previous database of mine and had it
fail miserably. However, the other alternatives I can think of are to
translate and manually apply the remaining transaction logs, somehow have
sybase correct the corrupt transaction log you do have (through a tech
support case), or manually recover the missing data somehow.

"Alex Whitney" <alexw55@pdq.net> wrote in message
news:425d43ed$1@foru
ms-2-dub...
> Sorry, but that's the only other solution I have.
>
> Alex
> "Troy Coombs" <coombst@quorumis.com> wrote in message
> news:425c0a28@forums
-2-dub...
> now
> translates
> looks
> reads,
> invalid
>
>



Sponsored Links





Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive | Programming forum archive

Copyright 2008 droptable.com