Keep an eye on your Versions table after dropping replications

[ChrisMathers1]

For the second time when investigating why our primary production database is slow I found that the edit tables are not compressing. The version tree from GDBTools is showing a pretty good compression each time but those edits still remain. It turns out that once again when I removed two replications they are taken out of all database tables except SDE_Versions. These two versions are acting as blocking states keeping 2 months worth of edits from compressing. The only way I've found to fix this is to back up the database and delete the rows from the table directly. I deleted them in descending order of creation date compressing between deletes. After the last compress all the edit tables were clean and empty and the database had updated all the state lineage numbers automatically. No edits were lost as far as we have been able to tell. I don't know if its just our database but DBA's may want to keep this in mind.

[ChrisMathers1]

The compression that runs at midnight each night is a script that kicks all users, blocks new connections, and syncs before compressing. Does deleting those hidden sync versions not affect the replications? I have 7 replications currently off this database so the version table is holding onto 7 SYNC_SEND versions and states. I say 7 states but in reality all 7 have the same state ID.

[Robert_LeClair]

Best workflow to remove hidden synchronization versions is to synchronize back to the data receiver replica, resolve any conflicts (if any), unregister replicas (which will delete hidden sync versions), rep/post/rec to DEFAULT, and compress.  From there, you can rebuild replica workflow.  Not required certainly but you could do this if you think there is state pinning going on.

[TamiOnstad]

I am dealing with a somewhat similar problem, but unfortunately I did NOT sync before rec/posting all of our versions back to Default and running compress.  This is a development environment so not fatal, but how do you recover from a state  where you have deleted the sync versions and you now have a parent and child database without in-sync data?  I assumed I could just unregister the replica (had to since I had somehow blown away the replica versions) and create a new replica.  The globalid values still match between the databases, so I created the replica with existing data option.  It syncs, but the changes are not being propagated to the child database.  

Any thoughts?  There has to be a way to recover from something like this without recopying all the data back over to the child database, which could take a day or more.

Tami O.

[Robert_LeClair]

Hi Tami - when you unregister the replica pairs, it removes the connection between the parent/child geodatabases.  Further, the hidden synchronization versions that are in the parent/child geodatabases are used to compare what's been added, updated, and/or deleted are also deleted.  The only way I can think of getting those lost edits back would be from an incremental backup of the parent/child geodatabase.  Could be wrong but that's my guess.

[TamiOnstad]

Thanks Robert, that's what I was afraid of. I think the archiving option might be safer for us since our version and rec/post/compress is so customized.

Appreciate your input!

Tami O.

[Robert_LeClair]

You could use the Archive Option on One-Way replication via the DEFAULT version to decouple versioning from replication but this a pretty niche workflow.  Good luck!