About SSSE File Maintenance

SSSE stores information about data changes to synchronize in the S_SD_SYNC_INFO table. Due to technical limitations, this information is collected for all users, not just users for whom synchronization has been enabled. Therefore, this table can accumulate a large number of rows in a short time.

SSSE automatically removes rows that are associated with sync-enabled users (users who have synchronization enabled) from the S_SD_SYNC_INFO table when the applicable synchronization takes place. SSSE also automatically removes rows that are associated with users who have never synchronized, on a schedule that is determined by the configuration parameter DispCycleCount for GC (Dispatcher Cycle Count for Garbage Collection).

Rows are preserved indefinitely for users who are not currently sync-enabled, but who have synchronized in the past. Preserving these rows allows for correct synchronization if synchronization is later reenabled for one of the users in question. However, if a large number of users have synchronization temporarily disabled, SSSE performance can decline as the size of the S_SD_SYNC_INFO table grows.

For best results, it is recommended that you minimize the number of users who have synchronization disabled after previously synchronizing.

CAUTION: Do not delete rows from the S_SD_SYNC_INFO table manually, as this can cause data corruption. You can help control the size of the S_SD_SYNC_INFO table by deleting User Map records for users who have previously synchronized but are not currently sync-enabled.

If you want to reenable synchronization for such users at a later time, you must create a new User Map record for each such user. When you add a User Map record for a user and reenable synchronization for that user, SSSE automatically performs a new initial extract operation for that user. During this initial extract, Exchange contact records are checked for duplication before being added as Siebel records. Unfortunately, technical constraints do not allow Exchange calendar records to be checked for duplication, so a repeat of an initial extract for a given user is likely to result in duplicate Siebel Calendar records. For more information about working with the User Map, see Mapping Individual Users.