SQL Anywhere Mobile - Fallout of a consolidated restore

Author

Fallout of a consolidated restore

Doug

2005-05-04, 9:24 am

We have a consolidated database and about 300 remotes that synch nightly.

Now lets say our consolidated database failed for some reason and we had to
restore from a backup made 24 hours previous. But lets also say we lost the
syncs from about 150 remote sites when our consolidated failed and we had to
restore.

This sounds like a real scary scenario and I'm seeking comfort. In my mind,
the next time these 150 sites sync, they will fail because of an old offset
in the consolidated. Am I right about that? And if that is the case then
we'll need to go through the process of dropping the remote synch
definitions, then recreating, deleting from ml_user and all that.

Am I reading this right?

We're using 7.0.0.313. (That wouldn't be my choice)

David Fishburn

2005-05-04, 9:24 am

"Doug" < doogie414removethis@
yahoo.com> wrote in
news:4278c635$1@foru
ms-1-dub of sybase.public.sqlanywhere.mobilink:

D> We have a consolidated database and about 300 remotes that synch
D> nightly.
D>
D> Now lets say our consolidated database failed for some reason and we
D> had to restore from a backup made 24 hours previous. But lets also say
D> we lost the syncs from about 150 remote sites when our consolidated
D> failed and we had to restore.
D>
D> This sounds like a real scary scenario and I'm seeking comfort. In my
D> mind, the next time these 150 sites sync, they will fail because of an
D> old offset in the consolidated. Am I right about that? And if that is
D> the case then we'll need to go through the process of dropping the
D> remote synch definitions, then recreating, deleting from ml_user and
D> all that.

Yes, you are right. This is exactly why you should never let this
happen. You can easily prevent this from happening by have a "proper"
backup and recovery procedure in place.

It all boils down to how "important" is it to you that is never happens?

If it is important enough, then by simply having a second physical hard
drive on the machine that is running the consolidated database and using
a mirrored ASA transaction log, this type of situation can be prevented.

D> We're using 7.0.0.313. (That wouldn't be my choice)

Have you heard of dinosaurs ...

I don't know why this is necessary, but I would strongly urge you to
change this, at least for the consolidated database.

--
David Fishburn
Certified ASA Developer Version 8
iAnywhere Solutions - Sybase
Professional Services
Please only post to the newsgroup
Please ALWAYS include version and MORE importantly BUILD number with
EACH post (dbeng9 -v).

EBFs and Maintenance Releases
http://downloads.sybase.com/swx/sdmain.stm

Developer Community / Whitepapers
http://www.ianywhere.com/developer

CaseXpress - to report bugs
http://casexpress.sybase.com

CodeXchange - Free samples
[url]http://ianywhere.codexchange.sybase.com/servlets/ ProjectDocumentList[
/url]

Sponsored Links