Tips for Compressing with Existing Geodatabase Replicas
5599
3
03-24-2015 04:42 AM
In a versioned environment, all edits are stored in what we call delta tables, or Adds and Deletes tables, and these tables are assigned to a unique state ID. Edits are held in the delta tables to handle any conflicts in a multi-user enterprise geodatabase. A compress operation trims the delta tables of any unreferenced state ids, consolidating the states lineage down to one state. If a state is still being referenced, it will remain in the delta tables, resulting in a partial compress.
In a fully compressed geodatabase, there are no rows in the delta tables, and the state tree is trimmed back to one state, state_id=0. Although a full compress is ideal, it is not always necessary and in some cases may not even be practical. For example, if there are many multi-generation replicas in your geodatabase that are not unregistered before the compress, you will need to send changes for all of these replicas to achieve a full compress. If there are many Two-way replicas, and you intend to fully compress both the parent and the child geodatabases, this process of synchronization will need to be done separately from both geodatabases, even if there are no changes to be sent.
Two important things are needed to get a full compress on a geodatabase that still has replicas registered.
This means that for Two-way replicas, there can be no SYNC_RECEIVE or SYNC_RECEIVE_REC versions in the geodatabase that need to be compressed.
The example below shows the parent geodatabase versions table. All versions associated with a single replica will contain a synchronization version id number in the version names. There are two replicas in this versions table. The One way replica, represented by the synchronization version ID number 10554, is a parent to child replica. Notice the DEFAULT state_id is 398, while this synchronization version is only at state_id 395. One-way replicas will only contain an associated replica version in the data sending geodatabase.
Going on, the replica with synchronization version 10552 is a two-way replica. Two-way replicas can be more complicated since the edits may travel in either direction, frequently switching the data sender and receiver roles. Notice that this two-way replica does have the SYNC_RECEIVE and SYNC_RECEIVE_REC versions associated with it, meaning that this version is in the data receiver role.
This example is making the assumption that there are no named child versions, and that connected synchronization is being used.
To prepare this geodatabase for a full compress, I must do the following.
The results of these two steps are shown in the image below.
With all of my versions set as acknowledged data senders and with the state_id equal to the DEFAULT version, my geodatabase is ready for a full compress.
Note that it is common to see these two requirements met, and yet only get a partial compress. If this is the case, synchronize the replicas in the geodatabase that need a full compress again. Even though no changes are being sent, acknowledgements are being sent that will tell the geodatabase that the edits are recognized and can be flushed from the delta tables.
In general, look to achieve some level of compress rather than a full compress. Attempting to achieve a full compress may lead to many additional synchronizations which may not be practical in your particular business workflow.
Tina M. - Geodata Support Analyst
In a fully compressed geodatabase, there are no rows in the delta tables, and the state tree is trimmed back to one state, state_id=0. Although a full compress is ideal, it is not always necessary and in some cases may not even be practical. For example, if there are many multi-generation replicas in your geodatabase that are not unregistered before the compress, you will need to send changes for all of these replicas to achieve a full compress. If there are many Two-way replicas, and you intend to fully compress both the parent and the child geodatabases, this process of synchronization will need to be done separately from both geodatabases, even if there are no changes to be sent.
Two important things are needed to get a full compress on a geodatabase that still has replicas registered.
- The existing replicas must be the data sender in the replica relationship.
- Every replica version must be at the same state as DEFAULT version.
This means that for Two-way replicas, there can be no SYNC_RECEIVE or SYNC_RECEIVE_REC versions in the geodatabase that need to be compressed.
The example below shows the parent geodatabase versions table. All versions associated with a single replica will contain a synchronization version id number in the version names. There are two replicas in this versions table. The One way replica, represented by the synchronization version ID number 10554, is a parent to child replica. Notice the DEFAULT state_id is 398, while this synchronization version is only at state_id 395. One-way replicas will only contain an associated replica version in the data sending geodatabase.
Going on, the replica with synchronization version 10552 is a two-way replica. Two-way replicas can be more complicated since the edits may travel in either direction, frequently switching the data sender and receiver roles. Notice that this two-way replica does have the SYNC_RECEIVE and SYNC_RECEIVE_REC versions associated with it, meaning that this version is in the data receiver role.
This example is making the assumption that there are no named child versions, and that connected synchronization is being used.
To prepare this geodatabase for a full compress, I must do the following.
- Synchronize the one-way replica.
- Synchronize the two-way replica, sending changes from this geodatabase to its partner geodatabase. The image above shows the versions table in the parent geodatabase, and tells me that this parent is currently set as the data receiver; therefore, I will synchronize parent to child, in effect making this geodatabase the data sender.
The results of these two steps are shown in the image below.
With all of my versions set as acknowledged data senders and with the state_id equal to the DEFAULT version, my geodatabase is ready for a full compress.
Note that it is common to see these two requirements met, and yet only get a partial compress. If this is the case, synchronize the replicas in the geodatabase that need a full compress again. Even though no changes are being sent, acknowledgements are being sent that will tell the geodatabase that the edits are recognized and can be flushed from the delta tables.
In general, look to achieve some level of compress rather than a full compress. Attempting to achieve a full compress may lead to many additional synchronizations which may not be practical in your particular business workflow.
Tina M. - Geodata Support Analyst
3 Comments