topic Re: Replication and Geodatabase Compress - strange behavior in Data Management Questions

Replication and Geodatabase Compress - strange behavior

rajeshc — Wed, 26 Jun 2013 05:28:39 GMT

Hi,
Here is the situation:
Environment: ArcGIS 10.1 SP1 on Win 2008 server R2, Oracle 11 G on HP Unix, SDE Geodtabase
We have a production SDE geodatabase and another geodatabase used for ArcGIS Server web application.
The secondary GDB is updated on a daily basis using geodatabase replica synchronization. The secondary geodatabse was created using an oracle dump re-store from the production geodatabase, and the replica were created using "register existing data" option in the Create replica wizard. The replica is a one way child replica, both the parent and child are pointing to the SDE.DEFAULT version. On the child geodatabase we do not have any other versions (other than the Synch_send** versions). The synchronization is run using a scheduled python script
arcpy.SynchronizeChanges_management (***_ewagisprod_sde, "***.WebU2_WaterReplica", ***_ewagisweb_sde, "FROM_GEODATABASE1_TO_2", "IN_FAVOR_OF_GDB1", "BY_OBJECT", "TRUE")

Note: The replica datasets are having geometric networks.

Problem
The synchronization is working perfect and all the data is being pushed to the secondary database on a daily basis. On the parent geodatabase we have a maintenance schedule wherein we delete all versions and compress the database and then we run the synchronization process and again compress the parent geodatabase. The SDE.Default version is brought to state 0, implying a full compress.

On the child geodatabase there are no other versions other than SDE.Default as i mentioned earlier. We have a compress schedule on the child geodatabase that is running after the synchronization is finished. The problem we are facing is that the SDE.Default version on the child geodatabase is never brought to zero and the delta tables are growing everyday. This implies the compress process has not done any benefit to the child geodatabase. Eventually the performance on the child geodatabase is getting slower due to the huge number of records in the delta tables.

Can anyone tell us where we are going wrong? Is it a right strategy to create replicas on the SDE.default versions?
Thanks in advance,
Rajesh
Sr. GIS Specialist

Re: Replication and Geodatabase Compress - strange behavior

MarcoBoeringa — Wed, 26 Jun 2013 13:13:38 GMT

You probably already know it, but this White Paper might be of some help:

Compressing ArcSDE Geodatabases That Contain Replicas -Best Practices

As per the document referenced above, it almost sounds like your replication setup is Two-Way, instead of One-Way. The document describes a situation where this may result in no changes being compressed on the Child, unless the Child is synchronized with the Parent with changes being sent from Child to Parent (even if no changes were made), see page 11.

Re: Replication and Geodatabase Compress - strange behavior

rajeshc — Thu, 27 Jun 2013 05:08:17 GMT

You probably already know it, but this White Paper might be of some help:

Compressing ArcSDE Geodatabases That Contain Replicas -Best Practices

As per the document referenced above, it almost sounds like your replication setup is Two-Way, instead of One-Way. The document describes as situation where this may result in no changes being compressed on the Child, unless the Child is synchronized with the Parent with changes being sent from Child to Parent (even if no changes were made), see page 11.

Thanks for your reply. Our replication is one way parent to child.
Please see the replica property screens.
Moreover, the synchronize dialog shows only one option for the direction, i.e from parent to child, confirming that ours is one way parent to child replica

thanks

[ATTACH=CONFIG]25519[/ATTACH][ATTACH=CONFIG]25520[/ATTACH]