load transaction failed in high availability system

[[e-mail]]

We have a system of high availability between the main and standby
system, synchronization between both servers (12.5.3 Unix 32bits) is
insured by dump and load transaction.
Some times load transaction failes due to some user performing a dump
transaction with truncate on the main server leading to full dump and
load.
In such cases the original dump is so big that the network cant hold
the capacity needed to transfert the dump file.
We thought about an artificial synchronization but still we need to
synchronize the last transaction load date in the standby server to re-
initialise the sequence.
Can someone tell me how to re-initialize the stand by server with the
right value so the transaction load sequence can start again?

Thans a lot in advance

[Mark A. Parsons]

Unless someone at Sybase has a magic traceflag, I'm not aware of any way to 're-sync' the logs so that you can pick up
where you left off. The only procedure I know of is to perform a complete database dump-n-load in order to sync the
main and standby databases.

-----------

When someone truncates the log (in the main database) they are, in essence, throwing away data.

Even if there were some way to get a follow-on 'dump transaction' command to complete against the main database, loading
said log into the standby database would lead to data inconsistencies; your standby database would be missing the
transactional data that had been discarded when the log was truncated in the main database.

For example ...

Assume the main database log had the details for creating a new bank account with an opening balance of $100. Someone
comes along, truncates the main database log, and the details of that new bank account are now gone from the log.
Assuming you could somehow get a 'dump transaction' to complete successfully against the main database. Upon loading
the follow-on log dump in the standby database you would find that a) the new bank account exists in the main database
but b) the new bank account does *not* exist in the standby database (ie, your databases are now out of sync).

-----------

Your best bet is to track down the processes (or people) performing the log truncations and have said operations halted.

Other options:

- beef up your hardware and/or network to allow for the quicker completion of a complete database dump-n-load cycle

- synchronous database writes against the main and standby databases as part of a 2-phase commit environment; this
should not be affected by the untimely/undesired truncation of the log in your main database

- a transactional replication system (eg, Sybase's Replication server); this should not be affected by the
untimely/undesired truncation of the log in your main database

Post by ***@dmateck.com
We have a system of high availability between the main and standby
system, synchronization between both servers (12.5.3 Unix 32bits) is
insured by dump and load transaction.
Some times load transaction failes due to some user performing a dump
transaction with truncate on the main server leading to full dump and
load.
In such cases the original dump is so big that the network cant hold
the capacity needed to transfert the dump file.
We thought about an artificial synchronization but still we need to
synchronize the last transaction load date in the standby server to re-
initialise the sequence.
Can someone tell me how to re-initialize the stand by server with the
right value so the transaction load sequence can start again?
Thans a lot in advance

[zionassedo]

On 31 אוגוסט, 00:12, "Mark A. Parsons"

Post by Mark A. Parsons
Unless someone at Sybase has a magic traceflag, I'm not aware of any way to 're-sync' the logs so that you can pick up
where you left off.  The only procedure I know of is to perform a complete database dump-n-load in order to sync the
main and standby databases.
-----------
When someone truncates the log (in the main database) they are, in essence, throwing away data.
Even if there were some way to get a follow-on 'dump transaction' command to complete against the main database, loading
said log into the standby database would lead to data inconsistencies; your standby database would be missing the
transactional data that had been discarded when the log was truncated in the main database.
For example ...
Assume the main database log had the details for creating a new bank account with an opening balance of $100.  Someone
comes along, truncates the main database log, and the details of that new bank account are now gone from the log.
Assuming you could somehow get a 'dump transaction' to complete successfully against the main database.  Upon loading
the follow-on log dump in the standby database you would find that a) the new bank account exists in the main database
but b) the new bank account does *not* exist in the standby database (ie, your databases are now out of sync).
-----------
Your best bet is to track down the processes (or people) performing the log truncations and have said operations halted.
- beef up your hardware and/or network to allow for the quicker completion of a complete database dump-n-load cycle
- synchronous database writes against the main and standby databases as part of a 2-phase commit environment; this
should not be affected by the untimely/undesired truncation of the log in your main database
- a transactional replication system (eg, Sybase's Replication server); this should not be affected by the
untimely/undesired truncation of the log in your main database

Post by ***@dmateck.com
We have a system of high availability between the main and standby
system, synchronization between both servers (12.5.3 Unix 32bits) is
insured by dump and load transaction.
Some times load transaction failes due to some user performing a dump
transaction with truncate on the main server leading to full dump and
load.
In such cases the original dump is so big that the network cant hold
the capacity needed to transfert the dump file.
We thought about an artificial synchronization but still we need to
synchronize the last transaction load date in the standby server to re-
initialise the sequence.
Can someone tell me how to re-initialize the stand by server with the
right value so the transaction load sequence can start again?
Thans a lot in advance-הסתר טקסט מצוטט-

-הראה טקסט מצוטט-

Thanks a lot Mark,
I wasnt surprised by the answer , but I had to give an answer to my
chief, .
We heard good knews from the last version of replication server but we
should upgrad to 15 which dont depend on me.