A problem with two-way geodb replicaitons among 3 ArcSDE databases

2385
4
12-05-2012 07:21 AM
by Anonymous User
Not applicable
Original User: aguan@hess.com

I have been playing with geodatabase replications with our GIS team to evaluate performance and understand the functionalities as this is new to us. One test I did for two-way replication among 3 enterprise SDE databases give me some results that I can not understand.  All databases are ArcSDE 10.0 SP3, and all edits are in default version. I can not understand why in the last step, 5.), the SDE2 does not show any changes on map that are made in SDE1, and also the compression of SDE1, SDE2, and SDE3 does not compress the A and D tables at all in any of them.

1.) copy a polygon feature class FC from SDE1 (Oracle) to SDE2 (Oracle),
set up two-way replica  between them by
registering replica data only. Make edits in both.
and sync them starting with SDE1 as parent.
The map shows changes between them are identical. But note internally,
SDE1 still has a hidden system replica version, which is not cleaned up at the end of sync, that is referenced by the default version.

2.) copy FC from SDE1 to SDE3 (SQL Server). This only copies the base table with the original version before the edits in 1.), not the changed data in A and D tables as the default version in SDE1 is still referenced by the hidden system version. The copy/paste seems to only apply to non-referenced default version. As a result, the FC does not match between SDE1 and SDE3 in ArcMap. To prove this, I performed the next step.

3.) resync FC between SDE1 and SDE2 to clean up the hidden replica system version in SDE1, and perform 2.) again. This time, all default version in SDE1 is copied over to SDE3 and the FC is identical between SDE1, SDE2 (and SDE3) in Arcmap.

4.) register FC in SDE3 as versioned and create a two-way replica for it between SDE1 and SDE3 using "register data only". Make edits in SDE1 and sync with SDE3, the FC immediately matches between them in ArcMap.

5.) sync between SDE1 and SDE2, but FC in Arcmap for SDE3 does not change. Resync between SDE1, SDE2, and SDE3 does not help resolve the difference. The A&D tables for FC in SDE2 do show increased counts that matches the counts in A&D tables in SDE1. Attempts to compress all three SDEs do not help reducing the A & D tables in all of them and help resolving the difference.

Thanks and regards!


Allen Guan
Information Management System Advisor
Hess Corporation
713-496-5751
832-282-6473 (Mobile)
0 Kudos
4 Replies
MarcoBoeringa
MVP Regular Contributor
Can't help you in detail with this, but I did notice you didn't mention reconciling and posting during synchronization, and whether you do a manual or automatic conflict resolution. If the changes aren't reconciled and posted, the synchronization version will persist next to the actual replication version, see:

Synchronization and versioning

I really also recommend reading and printing out any other Help pages regarding replication and synchronization, it simply can be a mind boggling subject as soon as you start using more than two databases in a replication setup, like you do.
0 Kudos
by Anonymous User
Not applicable
Original User: 4175

Hi Allen,

I'd like to first recommend you read the following white paper. 
http://blogs.esri.com/esri/arcgis/2008/11/25/geodatabase-replication-and-compress/

It discusses how to get an effective compress when your system has replicas.  At a high level we describe the hidden systems versions that replication uses.  These system versions are not something we want users to have to think about - but we know that when working in a versioned environment it is important to understand how to manage the presense of effectively within your versioned environment.

Now - for the things you reported in your description....


I can not understand why in the last step, 5.), the SDE2 does not show any changes on map that are made in SDE1,

I'm not entirely clear I understand what the exact scenario is.   I'll explain the behavior of the The Sync command and maybe through this you'll be able to get some insight?  The Sync command, if called from ArcMap will refresh the workspaces that were involved in replication that are in that ArcMap Session.  So if you have SDE1 and SDE2 in the session - and call sync - you should see the updates reflected in the map.  If you call sync from a different session it does not. So imagine you have SDE3's data open in ArcMap - you sync in a separate ArcMap session - the data in your first map session will not automatically fresh, however, the underlying data has changed.  To see the current state of the data you would just need to call "Refresh Version" which is available off the versioning toolbar.  Note that if you start editing, this would also refresh the data in your map so you are editing the current state.


and also the compression of SDE1, SDE2, and SDE3 does not compress the A and D tables at all in any of them.

I think reading the white paper linked above will help your understanding here - please ask a follow on question if it does not.


One of the things you don't specifically ask about - is one that peaked my interest the most.  Why the copy/paste did not result in the copy exactly what was in default?  This sounds like a bug to me.


2.) copy FC from SDE1 to SDE3 (SQL Server). This only copies the base table with the original version before the edits in 1.), not the changed data in A and D tables as the default version in SDE1 is still referenced by the hidden system version. The copy/paste seems to only apply to non-referenced default version. As a result, the FC does not match between SDE1 and SDE3 in ArcMap. To prove this, I performed the next step.


Can you describe more about this scenario?  My inkling is that it's not that the system versions are hanging onto the state, but rather that whichever workspace connection you used to copy the data from didn't reference the current state of the data which changed via the sync.  My guess is that if you called "Refresh" off the context menu of that workspace before copying, you may have gotten the correct data. Or if you closed the Map sessions and reopened that this would work too.

Can you try that? Understanding this repro case for this one and sharing it with support would be ideal.

Thanks,
Heather
0 Kudos
by Anonymous User
Not applicable
Original User: aguan@hess.com

Heather,

Thanks for the information. Actually I read this classic article you cited before doing the tests, but I don't see anything that can help explain the behavior that I see which can be summarized in short - if  one SDE1 that has two-way replications to two other SDEs, say, SDE2 and SDE3, sync changes from SDE1 to SDE2 will immediately see the same changes in SDE2, but then sync from SDE1 to SDE3 will not show the same changes in SDE3. All are in default session and are in the same arcmap session.

Allen
0 Kudos
MarcoBoeringa
MVP Regular Contributor
Heather,

Thanks for the information. Actually I read this classic article you cited before doing the tests, but I don't see anything that can help explain the behavior that I see which can be summarized in short - if  one SDE1 that has two-way replications to two other SDEs, say, SDE2 and SDE3, sync changes from SDE1 to SDE2 will immediately see the same changes in SDE2, but then sync from SDE1 to SDE3 will not show the same changes in SDE3. All are in default session and are in the same arcmap session.

Allen


One interesting aspect you don't mention but probably have checked: does ArcGIS report any conflicts between SDE1 and SDE3? To synchronize, potential conflicts need reconciling, either automatically, or manually.

Knowing if there are any conflicts, may help explain the behaviour (if you haven't run into some sort of bug).

This Help topic may be of use: Resolving synchronization conflicts manually
0 Kudos