Select to view content in your preferred language

Enterprise geodatabase states will not compress.

5114
11
Jump to solution
09-18-2014 06:15 AM
ChrisMathers
Deactivated User

state_id

ownercreation_timeclosing_timeparent_state_idlineage_name
0sde2010-03-29 14:59:50.0002010-03-29 14:59:50.00000
118506"BAY\KMCDONALD"2013-12-03 15:42:41.0302013-12-03 15:43:32.8830118229
118621"BAY\DCOLE"2013-12-13 10:43:42.2002013-12-13 10:43:44.273118506118229
118869"BAY\JDOMICO"2014-01-02 07:57:54.9672014-01-02 07:57:55.583118621118229
119777"BAY\JDOMICO"2014-01-28 09:25:56.3502014-01-28 09:26:03.150118869119772
163687SDE2014-06-12 10:06:57.2432014-06-12 10:10:43.783119777163687
163705"BAY\GISINTERN"2014-06-12 10:19:07.5232014-06-12 10:19:07.593163687163687
169619"BAY\CMATHERS"2014-07-01 08:00:01.8732014-07-01 08:00:10.057163705169546
185464"BAY\DCOLE"2014-08-21 15:48:49.3202014-08-21 15:52:17.930169619185415
187638"BAY\DCOLE"2014-08-27 16:00:03.0602014-08-27 16:00:06.247185464187554

191938

"BAY\JDOMICO"2014-09-17 15:52:26.2102014-09-17 15:52:35.060187638191826

This table is the sde.sde.SDE_states in our production database. For some reason we cannot seem to compress away those states. Ive kicked everyone off the database including myself so that all state locks will be released and then compress but they just wont go away! We compress nightly and always drop back to these same states. Its a 10.1 EGDB on SQL Server 2008R2 without the SDE application server. Is there anything I can do from SSMS instead of Catalog to solve this?

0 Kudos
1 Solution

Accepted Solutions
ChrisMathers
Deactivated User

I was searching for something else and this knowledge base article came up. I had 6 hidden versions from old replications that were unregistered that are just sitting out there in sde.SDE_versions. Their dates and state_ids were the same as the ones in the sde.SDE_states that wouldn't compress away. I used the Delete Version tool to drop them from this table safely. I did it in reverse chronological order to on the versions create date on a whim because it seemed safest, compressed, and BOOM! errant states gone. I'm hoping this will resolve some other issues I've been having. Please back up your geodatabase before you do this in case something goes haywire. None of my users have noticed anything amiss on the client end since this was done last Friday.

The table below shows the comparison of the two tables. Rows in green are versions/replicas that are current, rows in red are versions/replicas that should have been dropped but weren't. You can see that while they still appeared in sde.SDE_versions they had already been removed from sde.GDB_ITEMS. Item ID is in the name of the replica version.

sde.SDE_versions

sde.GDB_ITEMS

name

state_id

ID

Replica Name

DEFAULT

205718

SYNC_SEND_3_0

0

SYNC_SEND_5910_1

118506

SYNC_SEND_7110_0

118621

SYNC_SEND_8312_1

118869

SYNC_SEND_8312_2

119777

SYNC_SEND_5910_2

163687

ParcelEditing

205712

SYNC_SEND_20028_5

205591

20028

  1. SDE.ProductionToPub

SYNC_SEND_19649_4

205591

19649

  1. SDE.ProductionToFO

SYNC_SEND_9919_162

205591

9919

  1. SDE.ProductionToROK

SYNC_SEND_18851_7

205591

18851

  1. SDE.ParcelsToPub

SYNC_SEND_18848_11

205591

18848

  1. SDE.ParcelsToFO

SYNC_SEND_20450_2

205718

20450

  1. SDE.ProToFO_Supp1

SYNC_SEND_20453_1

205718

20453

  1. SDE.ProToPub_Supp1

View solution in original post

0 Kudos
11 Replies
AsrujitSengupta
Deactivated User

How many versions are there in that geodatabase?

Do you reconcile/post all versions, delete the Versions and then perform compress?

Do you have replicas in that geodatabase?

enterprise gis sde‌compress‌data management‌sde administration‌

Managing DataGeodatabase‌ Move this thread to any of these groups for better response.

0 Kudos
ChrisMathers
Deactivated User

We have very few editors here so all edits are done to the base version,

We do have replicas, all one-way going out from this database.

0 Kudos
AsrujitSengupta
Deactivated User

Have the replicas been synchronized before compressing?

0 Kudos
ChrisMathers
Deactivated User

Yes. A script runs nightly that syncs all of the replicas and then compresses and runs stats on the geodatabase.

0 Kudos
AsrujitSengupta
Deactivated User

Try the same things manually and check if that makes any difference:

Synchronize replica-->Make sure there are no other users connected (If there are Server Services running, stop them as well)-->Perform  a compress

0 Kudos
JuanOrozco
Regular Contributor

I agree with Asrujit. We always delete versions before compressing, otherwise we get this error. Give it a try.

ChrisMathers
Deactivated User

Ok Ill try that early tomorrow morning. When I kick all users I am switching to refuse new connections so no one can get back on before Im done. There isnt a Server site on the production server but I can stop the ones on our publication and fail over machines.

0 Kudos
MartinAmeskamp
Frequent Contributor

Hi, we frequently have similar problems with compress mysteriously refusing to get rid of states, and mostly it's either state locks (through logged in users or services) or replica versions that don't show up in the GUI. What I find helpful:

Martin

AsrujitSengupta
Deactivated User

Martin Ameskamp‌ just in case you would like to get the GDBT working with 10.1 or later release

Using our favourite GDBT toolset with Desktop 10.1 or later release

0 Kudos