Ryan Steele wrote:
I guess the
question that remains in my mind, then, is why keep
more than one contextCSN per database? Aren't we only concerned with
the last write made to it (in this case, SID 001's
write)? Thanks again for the insight.
It's for a multi-master setup.
So the database with the SID of 001 updates the relevant contextCSN -
meanwhile database 002 is updating it's own contextCSN.
Later the DBs connect and exchange updates so database 001 compares it's
last contextCSN value stored for 002 with the current value from 002. If
they're different then it has data to transfer based on the differences in
the timestamps. At the same time DB 002 is comparing the contectCSN it has
stored for 001 with the current 001 value and transferring records amended
Hope that makes more sense.