G
gus bjorklund
Guest
While the counters dont get updates, a kind of buffer locks /are/ instantiated on the replication target. But they are different from the ones on the source because the target is open in single-user mode so simpler locking primitives can be used and there is no waiting. New transaction identifiers are not generated during normal roll-forward processing and not during replication processing on the target(s). Instead, the orgional identifier that was generated at the source must be used. Correct. transaction state is only active or none. Transaction state change from begin to active is not replicated. But two-phase active to ready-to-commit changes should be. Tx start tinme should be time on source. > On Jun 30, 2019, at 6:48 AM, George Potemkin wrote: > > Update from Progress Community > > George Potemkin > > > By the way, what is Trans id that is reported for RPLA? > > Empirical observations: > > 'Trans id' seems to be a Trid of the last processed note. In other words it's an id of transaction that was in Active state on source database. By the way, RL_TMSAVE notes do sent to a target db but they are ignored by replication agent. It's likely that these notes do not affect 'Trans id' on target db. > > 'Trans State' on target db is either Active or None (a.k.a. Dead). 'Status: Active Transactions' screen in promon seems always to contain one and only one row. > > 'BI Rwrites' reported for "transaction" is in fact the total number of recovery notes written by replication agent since its startup (so it's not per transaction). > > I don't have enough data to say if 'Tx start time' is a transaction start time on source or on target db. > > > View online > > > You received this notification because you subscribed to the forum. To unsubscribe from only this thread, go here. > > Flag this post as spam/abuse. >
Continue reading...
Continue reading...