Compress an SDE geodatabase without removing replicas

362
1
03-29-2011 10:30 AM
Status: Open
Labels (1)
JacksonTrappett1
New Contributor II

Due to edits, the adds and deletes table in an SDE geodatabase can grow quickly, which affects performance and can quickly bring normal operations to a standstill.  The solution is to compress the geodatabase to remove the adds and deletes that are building up.  The problem is if you have replicas set up, you must delete your replicas or else the tables that participate in those replias will not compress completely.  Rebuilding replication is a pain.  The child features must be completely deleted and recreated via a new replica, which means if there are any services, users, etc using those features, they must all be disconnected or stopped in order to perform a compress on the parent geodatabase.  This means downtime.

Please provide a fix which will allow a compress to occur correctly with replicas in place.

Tags (2)
1 Comment
JoeRutkowski
I know this doesn't help you, but we use many replicas in our shop and haven't had this issue. Running the compress tool seems to do the job. (This is based off viewing the GDBT versioning lineage diagram before and after a compress. v10 SP2)