Compressing MSSQL SDE with replica

[AllenJones]

I have a ArcGIS enterprise SDE Geodatabase that will not compress all edits to the default.  All versions have been reconciled, posted and deleted.  I stop all web services that use this database and confirm in ArcCatalog that there are no connections to the database except the one being used by the client to do the compress.  The only thing left is a replica. This replica is used for a  two way geodata service and i cant (and should'nt) need to delete it to get all edits to base and  get the compress log to state_count to1.  I still have records in the delta tables and the end_state_count in the compress log is still 2.

Now, even though all versions are reconciled, posted and deleted, there are still 2 versions in the [versions] table.  i have the Default and a SYNC_SEND_xxx_xx, im assuming this is a system version used to sync changes from the replica.  i have synchronized the replica so there should be no outstanding edits in either direction for the replica.  I know if I call support they are going to want me to unregister that replica then run the compress, which will probably work but then I will need to rebuild the replica and everything attached to it on the other end.  I don't want to do that!! Furthermore it should not be necessary...  I'm not sure that the "SYNC_SEND_xxx_xx" version i see in the versions table is legit, and that could be holding it up but I'm afraid to delete that record without knowing for sure.  Any suggestions?

[JoshuaBixby]

I don't have an answer for your overall problem, but I can offer some documentation about your "SYNC_SEND_xxx_xx" version question.  Although dated, I believe the following is still correct:

FAQ: What are the SYNC_SEND and SYNC_RECEIVE versions in the versions table?​

In geodatabase replication, on a successful synchronization between parent and child replicas, SYNC_RECEIVE and SYNC_SEND versions are recorded in the sde versions table. These temporary versions are managed by ArcSDE and should not be manually deleted from the table. They are deleted when the replica is unregistered by way of the Replica Manager dialog box in ArcCatalog or ArcMap.

Not sure if the following applies, but it can't hurt to check:

HowTo:  Determine if there are orphaned replica system versions in the geodatabase​

[AllenJones]

Thanks for the link, that confirms my suspicion that this version is related to the replica.  I hope the answer isn't that you cannot fully compress a replicated database.  If that is the case i need a workflow that allows all edits to get to base without deleting replicas.

Thanks!

[George_Thompson · Accepted solution]

Allen,

Here is a blog and a white paper that reviews compressing the enterprise geodatabase with replicas. The process is a little more complicated than normal, but it can be done. The white paper may look old, but the principals are still the same.

https://blogs.esri.com/esri/supportcenter/2015/03/24/tips-for-compressing-with-existing-geodatabase-...

*This blog was written by an analyst on the Geodata team.

Compressing ArcSDE Geodatabases That Contain Replicas—Best Practices: http://downloads.esri.com/support/whitepapers/ao_/J9842_GDB_Compress_With_Replicas.pdf

If this is not possible or you need more guidance, I would recommend contacting Technical Support and talk to the Geodata team. This team specializes in this type of question.

I think this should get you going in the right direction.

-George

Managing Data​ Esri Technical Support​

[AllenJones]

It took multiple synchronizations to get the replica stateID to match the stateID of the default.  I just needed to keep synchronizing over and over.  I cant see why it took so many sync operations to get to the default stateID, but it worked none-the-less.  I'll have to experiment on a workflow that does this programatically.  Thanks for the link George!

~Allen

[George_Thompson]

If the sync message was not received it may have caused you to have to sync multiple times. If the sync counts are not the same, I believe that that they will not be "in sync" either and require multiple syncs.

http://desktop.arcgis.com/en/desktop/latest/manage-data/geodatabases/synchronizing-connected-replica...

http://desktop.arcgis.com/en/desktop/latest/manage-data/geodatabases/synchronization-and-versioning....

I am glad to hear that you were able to get it completed and compressed. I know that when you have replicas that a full compress becomes a more challenging prospect.

-George

[MatthewStull1]

We ran into this same issue.  We are going to use Archiving to sync updates to our replica.  This should eliminate this issue.  Our replica is a one-way parent to child replica.