cancel
Showing results for 
Search instead for 
Did you mean: 

warm standby synch up

Former Member
0 Kudos

i have a question regarding sybase replication warm standby sync up and appreciate the clarification.

let us suppose in a warm standby setup, the standby data has gone out of sync with the primary database.

the log contains committed as well as uncommitted data.

but even uncommitted data is sent to rep server.

so in a tran log let us suppose there are 12 transactions. till transaction 7, it has been committed on the primary database (that i think is the primary truncation point).

and let us suppose that the secondary truncation point is at the 9th transaction - till which data has been sent to the rep server.

but we do the dump database at the 12th transaction, where the dump marker is inserted.

so when we load the database dump into the primary, it will start accepting replicated transactions from the 12th transaction - from where the dump marker starts.

so in this case won't the transactions from 7 to 12 be missed?

the above case assumes a scenario where the sync up can be done without doing a dump tran of the primary database. or does a warm standby sync up always require a dump tran with truncateonly/nolog, of the primary database (and also the related rs_zeroltm etc)?

I think with 15.6 there is a new way to do the sync up. but here I am referring to the pre-15 versions.

appreciate the clarification.

thanks,

nanda chandran

Former Member
0 Kudos

mark, thanks for the reply.

so just to be clear : dump/clear the transaction log and zeroltm is  not mandatory for warm standby resync? you can simply take the dump of the primary and load it into the standby? btw I have done these refreshes somewhere in the past - but specifics have slipped off my mind.

and if transaction 7 and 8 are open transactions - for which commit was not received at the time of the dump - so the commits coming later through the DSI will be processed and transaction integrity maintained?

and btw is there any chance of the dbgenid going out of sync during this and needing to be upped?

appreciate the clarification.

Mark_A_Parsons
Active Participant
0 Kudos

No need to clear the PDB log or run rs_zeroltm.

There should be no genid issues because you aren't rolling the PDB back to an earlier point in time.

As for 'simply take the dump of the primary and load it into the standby' ... first you have to put the DSI (of the standby) into a mode of waiting for a dump marker.  While this is fairly easy with RS 15.6+ (due to some new resync capabilities), I'm a bit rusty on how to get a pre-15.6 DSI into the mode of waiting for a dump marker (short of dropping/recreating the connection).  I'm sure there's a way to force the mode by updating the RSSD but I don't know the details off the top of my head.

Former Member
0 Kudos

mark, btw not sure if you noticed the question about uncommitted transactions before the dump marker. appreciate your clarification on that.

>and if transaction 7 and 8 are open transactions - for which commit was not received at the time of the dump - so the commits coming later through >the DSI will be processed and transaction integrity maintained?

thanks.

Mark_A_Parsons
Active Participant
0 Kudos

1 - Uncommitted txns in the dump file will be rolled back upon loading in the RDB.

2 - Repserver plays transactions against the RDB in the order in which they were committed (not the order in which they were started).

3 - The dump marker is basically a tiny 'committed' transaction (w/ its own commit time).

If your 'uncommitted' transactions complete at some later time then they will have a commit time that's later than the dump marker's commit time sooo ...they won't come across in the db dump (ie, they're uncommitted so they'll be rolled back) ... and since they would be committed after the dump marker is created (ie, after the dump marker's commit time) means they'll be applied against the RDB once the DSI is resumed.

------------------

Put another way ...

Any transactions committed before the dump marker's commit time will come across in the database dump file.

Any transactions committed after the dump marker's commit time will come through replication, build up in the DSI/outbound queue, and when the DSI is resumed said transactions will be played against the RDB.

Former Member
0 Kudos

ok mark, but when the commit (post dump marker) comes in through the DSI, will the replicate dataserver have access to the  original transaction (which was rolled back)? is there a transaction id or something else, by which it keeps track of past transactions?

Mark_A_Parsons
Active Participant
0 Kudos

Each transaction has a unique oqid, which consists of the gen id, source database info, etc, etc, etc.

When a transaction is successfully applied/committed in the RDB the local rs_lastcommit table is updated.

Other than that I'm not sure what you're asking re: rolled back transactions.

Former Member
0 Kudos

oqid is used in replication - using the dbgenid, timestamp of log page, transaction id etc.

but we are talking about the uncommitted transactions in the  database dump and how they are reconciled during warm standby resync - or rather post sync up, when the commit comes thru the DSI.

so how is the linkup done between uncommitted transactions in the database dump (which are rolled back during db load) and their related commits coming in later through the DSI. so when the ASE gets a commit through the DSI, how does it link that commit to its actual transaction (which it has actually rolled back during database load because they didn't have a commit then)?


Mark_A_Parsons
Active Participant
0 Kudos

There is no 'link' between what was rolled back (from the db dump) and what actually shows up later as a committed transaction that's applied via the DSI.

What comes across in the db dump is an incomplete copy of what's still in the PDB.  The incomplete transaction is rolled back and discarded by the RDB.

When the transaction finally commits in the PDB it is forwarded to, and applied by, the DSI.

Former Member
0 Kudos

>The incomplete transaction is rolled back and discarded by the RDB.

>When the transaction finally commits in the PDB it is forwarded to, and applied by, the DSI.

wouldn't that mean that the same transaction shows up in the transaction log twice?

an open transaction even without commit, is forwarded to the rep server. it sits in the inbound queue till its commit comes through, upon which it is moved to the outbound queue by the sqm.

so if a part of the transaction has already come in the tran log, how can it come again in the tran log upon commit? wouldn't that lead to duplicates?

Former Member
0 Kudos

mark, let us suppose there is a tran with 3 statements. first does a 1000 row update. then there is a select with a lot of computation (which takes a while to run). then with the result of the select there is an update of another 2000 rows.

so let us suppose that the first update of 1000 rows is done. then when the select with the computation is happening, the dump database is done on the primary and it completes while the select is still running.

so the first update statement is prior to the dump marker. upon db load, this is rolled back at the replicate because there is no commit for it.

so after the second update of 2000 rows, if that statement and the commit comes through the dsi, how will there be any reference to the first 1000 rows? because the transaction in the log for the first update was already rolled back. how can that first update of 1000 rows come again in the log?

sorry if I am not getting your logic - but not able to understand this.

Mark_A_Parsons
Active Participant
0 Kudos

There are no duplicate trans.  The transaction that is rolled back is a *COPY* brought over in the database dump file (just like everything else in the dump file is a *COPY* of what was in the primary).  Copies of completed transactions are kept, copies of incomplete transactions are rolled back and discarded.

Mark_A_Parsons
Active Participant
0 Kudos

Assuming your 3-part transaction is of the form: begin tran, 1K update, select, DM, 2K update, commit tran

A *COPY* of the 1K update comes across in the dump file (everything in the dump file is a copy of something from the PDB, right?).  Because this *COPY* is part of an incomplete transaction it is rolled back and discarded.  In the mean time the 1K update is still processed by the repagent and sent to the repserver.

The DM reaches the repserver and causes the DSI to go down.  The 1K update is still in the repserver's queues as it doesn't yet have a commit.

The 2K update completes and a commit is issued.  The repagent sends the 2K update and commit to the repserver.  The commit time is later than the DM marker's time so the committed transaction (1K update + 2K update) is maintained in the DSI queue, and will be applied against the RDB when the DSI is resumed.

--------------

I think you're concentrating too much on transaction start times as opposed to the more important transaction commit times.

Also keep in mind that as far as the repagent is concerned there's nothing special about the DM.  The repagent will continue to send all transactional activity to the repserver regardless of whether it sees 0,.1 or a million DMs.

Also keep in mind that as far as the repagent is concerned the actual dump of a database (or log) means nothing.  The act of performing a database/log dump does not eliminate/mask/drop/discard any of the transactions in the log, said transactions are still processed by the repagent like normal and sent to the repserver.

When the DSI is configured to wait for a DM it will discard all committed transactions until it sees the DM; this eliminates the possibility of the DSI applying copies of committed transactions that will come across in the database dump.  When the DM is received the DSI will shutdown so that the DBA can perform a 'load database' command; at this point any committed transactions sent to the DSI will a) have a commit time after the DM was generated and b) build up in the DSI queue and be applied to the RDB when the DSI is resumed.

Accepted Solutions (0)

Answers (0)