topic Re: Compression and exclusive state locks? in Geodatabase Questions

Compression and exclusive state locks?

MartinAmeskamp — Mon, 29 Feb 2016 12:54:33 GMT

Hi, we have a customer with around 50 concurrent editors on ArcGIS 10.0 SP5 (yes, I know), and Oracle 11.2.04. Editing is done using work order versions, and the number of versions is near the number of users. The typical versions lives a couple of hours: gets created off DEFAULT, edited, passed on to a QC person, and then gets reconciled, posted, and deleted by a dedicated service (ArcGIS Server + Java ArcObjects API). A (reasonably) full compress is done every night after shutting down various services, and this typically gets the number of states very close to the number of open versions.

We keep seeing the effect, though, that a large number of version have a very long state lineage (hundreds), and the state tree (viewed with GDBT) looks a bit like a palm tree: A long (hundreds) linear chain of states with no versions pointing to them.

After looking into the situation, I found that there seem to be a large number of exclusive state locks:In one specific instance, most users have few shared state locks, but some users have 20 to 30 exclusive state locks each.

I assume that these exclusive locks have something to do with the long uncopmpressed chains of states, and the question is. Where do they come from? What can I do with ArcMap to generate 20 exclusive state locks??

This seems to be a recurring problem, so I'm interested in finding out how it comes about. As night, when theer are no users, the database behaves as expected and compresses quite nicely...

Thanks, Martin

Re: Compression and exclusive state locks?

SamuelTompsett — Mon, 29 Feb 2016 15:08:03 GMT

Hi Martin,

Maybe the following would help out.

35794 - Obtain a listing of user processes and locks from a geodatabase when there is no ArcSDE service

A shared state lock is acquired anytime a versioned representation of a dataset is open in ArcGIS. - Meaning anytime anyone is actively editing something

Geodatabase locks—Help | ArcGIS for Desktop

-Sam

Re: Compression and exclusive state locks?

MartinAmeskamp — Mon, 29 Feb 2016 20:48:45 GMT

Hi Sam,

thanks for your reply. The shared locks I understand - it's the exclusive locks I'm having trouble with. I haven't checked yet whether they're all very close together, i.e. created by one edit session, or whether they're distributed all over the state tree.

Martin

Re: Compression and exclusive state locks?

SamuelTompsett — Mon, 29 Feb 2016 20:57:58 GMT

Hi Martin,

Exclusive locks are also outlined in the documentation I pasted above. In general, they arent anything to worry about unless you start seeing persistent exclusive locks.

-Sam

Re: Compression and exclusive state locks?

BlakeTerhune — Mon, 29 Feb 2016 21:24:18 GMT

Are you forcibly disconnecting all users when you do the compress? Are you also reconciling the versions that are still left (if any) before the compress?

Re: Compression and exclusive state locks?

MartinAmeskamp — Tue, 01 Mar 2016 08:47:04 GMT

Hi Blake,

no, we don't forcibly or otherwise disconnect users, and yes, we reconcile versions using a background python script. The point is not to achieve a full compress, but rather to keep performance acceptable during the day.

Martin

Re: Compression and exclusive state locks?

MartinAmeskamp — Tue, 01 Mar 2016 08:51:03 GMT

Hi Sam & Blake,

thanks for taking the time to look at this. I've done some more looking at states, state locks etc. and came to the conclusion that I have to look elsewhere for a solution to my palm tree problem (long persistent chains of uncompressed states). The exclusive locks are all very recent and belong to recent states in open edit sessions. Specifically, they are nowhere near my "problem area". In short, they are perfectly harmless, like Sam said.

Martin

Re: Compression and exclusive state locks?

BlakeTerhune — Tue, 01 Mar 2016 20:48:01 GMT

What I was getting at is that if you disconnect all users when you do the reconcile and compress, it might help eliminate the long state lineages because nobody will be able to lock up the states in an ArcMap session.

Re: Compression and exclusive state locks?

MartinAmeskamp — Tue, 01 Mar 2016 20:55:48 GMT

True - that's what happens at night. The problem is that these long chains reappear during the day, and I have yet to find out why compress doesn't collapse them. Most days, they're relatively harmless with 200-300 states, but we recently had over 1000 states in one of those chains, meaning that almost every version has a state lineage of over 1000 states - that slows down things significantly.

Martin

Re: Compression and exclusive state locks?

BlakeTerhune — Tue, 01 Mar 2016 21:29:51 GMT

Since you can't clear them up over night, maybe it's just compounding again during the day. I would try to get everyone disconnected when you do your maintenance and see if that makes a difference.

Re: Compression and exclusive state locks?

SamuelTompsett — Wed, 02 Mar 2016 13:56:32 GMT

Hi Martin,

You also could have one orphaned state lock that is holding up a whole entire lineage. It would be important to reconcile/post all versions, delete all versions, then make sure each and every lock is out of the geodatabase.

OBJECT_LOCKS

LAYER_LOCKS

STATE_LOCKS

TABLE_LOCKS

After that, compress to state 0.

-Sam

Re: Compression and exclusive state locks?

MartinAmeskamp — Wed, 02 Mar 2016 14:18:17 GMT

Hi Sam,

I'm afraid that's not an option. We get a chance to delete all versions about twice a year. As I tried to say above, we still get the database into a reasonable state every night - ~ 1 state per version, no chains, short state lineages, so mornings are fine. The chain effect keeps building up during the day. The oldest locked state right now (3 pm local time) is from yesterday morning.

Martin

Re: Compression and exclusive state locks?

SamuelTompsett — Wed, 02 Mar 2016 14:25:32 GMT

Hi Martin,

Understandable. Do you have any services or anything that would aquire that lock at 3PM? You should also be able to track who is acquiring that lock. The sde_id column in the state_locks table corresponds to the sde_id column in the process_information table. At least you can start tracking who specifically it is.

-Sam

Re: Compression and exclusive state locks?

RebeccaStrauch__GISP — Wed, 02 Mar 2016 16:38:29 GMT

Also make sure that the actual Oracle database is not being backed up (server/network side) which most likely could create a lock (if that was mentioned in the docs already, my apologies ..I didn't read thru them yet).