ArcGIS锁的介绍
在 ArcSDE 地理数据库中，多个用户可以同时读取和编辑相同数据。为了能在应用程序（例如 ArcMap）中使用地理数据库中的数据，应用程序必须按照特定原则工作，即地理数据库架构在使用地理数据库内容的任何时候均保持固定，不发生更改。例如，将要素类从地理数据库添加到地图时，您和其他用户都不能更改其架构。从地图中删除该要素类并且没有其他用户查询或编辑该要素类后，可以更改其架构。
-----------------------------锁概念讲解------------------------------------------------------
架构锁定概述
地理数据库及其数据集很少是静态的。多数数据集会随时间编辑和更新。有时，会因为多种原因添加新数据集和删除现有数据集。此外，还会对现有数据集进行架构更改 - 添加属性列、更改拓扑中的规则、添加制图表达等等。
如果使用单用户地理数据库，则很容易进行这些更改，而且无需考虑操作可能对其他用户的影响。但是，如果其他用户正在访问和使用要对其进行更改的同一个地理数据库，则需要建立一些工作流以进行架构更改。例如，要在不影响其他用户的情况下进行更改，可安排在其他用户离开系统时执行架构工作。
ArcGIS 提供一些自动架构锁定机制来帮助管理地理数据库更改。计划工作时考虑这些机制非常有用。
共享锁
ArcGIS 将自动获取使用中的单个数据集上的共享锁，例如，当用户编辑或查询要素类或表的内容时。使用该机制可以使其他用户无法对使用中的基础数据集及其架构进行更改。
可以在任何时间对单个要素类或表建立任何数量的共享锁。当使用 ArcGIS 修改地理数据库架构（例如，添加字段或更改规则）时，ArcGIS 会尝试在被更改的数据上建立排他锁。但是，如果该数据集上有共享锁，则无法建立排他锁。
排他锁
排他锁用于锁定地理数据库中的数据集以防止其他用户使用，以便对数据集进行必要的更改，例如，更改数据集的架构。当具有适当权限的用户开始更改地理数据库中的数据集时，ArcGIS 会自动在单个属性表、要素类表、栅格表或其他数据集上建立排他锁。
如果用户想更改地理数据库架构，则该用户使用的特定数据集不能被其他用户使用。换句话说，要对数据集进行更改，该数据集上就不能存在共享锁。
-----------------------------锁问题的解决------------------------------------------------------
从上面的信息我们可以看到，尽管ArcSDE有版本的概念，但是在编辑数据，编辑结构还是使用了锁的概念，往往有用户会有这样的疑问，为什么我的服务器并没有其他用户连接，怎么我在做一些操作的时候，仍然会有一些图层被锁定，状态被锁定的提示。
其实在SDE用户下有这么关于锁的四张表：
- OBJECT_LOCKS
- STATE_LOCKS
- LAYER_LOCKS
- TABLE_LOCKS
一般在多用户编辑或者一个用户开启多个ArcMap对同一个同层或者多个图层进行编辑时都会在这些表里面的写东西，一般我们将图层加载到ArcMap中会往TABLE_LOCKS里面写信息，如果我们进行版本编辑事务的开启，会往STATE_LOCKS表里面写信息，其他两个表什么时候写信息具体不详.....
感兴趣在后面有介绍............
情况一：如果该数据库只有你自己这个用户来操作出现了锁的问题，用户如果可以重启ArcSDE服务，可以尝试重启ArcSDE服务，看是否可以解决，如果不能解决，那么可以将这四个表中的信息直接使用数据库的方法删除即可。
注意：重启ArcSDE服务的方式仅限定于你的测试库或者你肯定知道只有你一个人进行编辑而没有多用户的操作，但是现实业务中往往是多用户并发，如果出现锁现象，首先要搞清楚状况，不能盲目的去重启服务，如果确定是无效的锁的问题，可以使用下面的方法处理。
情况二：如果是多用户并发编辑，在你操作时提示锁的问题，用户可以查看连接用户的信息，自己来设置条件删除。
比如我们可以查看某个SDE服务下的用户信息主要是查看SDE_ID信息
C:\Users\Administrator>sdemon -o info -I users -s 192.168.220.165 -i 5151 -p sde ArcSDE Instance 5151 Registered Server Tasks on 192.168.220.165 at Mon Mar 12 15:44:16 2012 ------------------------------------------------------------------------------ S-ID S-PID User Conn Client Machine:OS Started ----- ----- -------- ---- -------------------------------- ------------------- 1057 6027 SDE AS esrimakl:Win32:XDR Thu Mar 01 08:35:56 1114 14260 SDE AS esrimakl:Win32:XDR Mon Mar 12 11:39:20 1070 10634 SDE AS esrimakl:Win32:XDR Mon Mar 05 08:23:43 1043 26301 SDE AS esrimakl:Win32:XDR Wed Feb 29 09:49:48 1088 7564 SDE DC w2008s101:Win32 Wed Mar 07 16:48:10 1102 24604 SDE AS esrimakl:Win32:XDR Fri Mar 09 10:12:28 1039 27577 SDE AS esrimakl:Win32:XDR Tue Feb 28 16:54:20 1053 3936 SDE AS esrimakl:Win32:XDR Wed Feb 29 15:16:11 1063 11507 SDE AS esrimakl:Win32:XDR Thu Mar 01 11:35:35 1090 840 SDE AS esrichinazs:Win32:XDR Wed Mar 07 17:57:48 1068 6631 SDE AS esrichinazs:Win32:XDR Fri Mar 02 16:44:03 1069 10632 SDE AS esrimakl:Win32:XDR Mon Mar 05 08:23:43 1109 12864 SDE AS esrimakl:Win32:XDR Mon Mar 12 10:52:52 1036 13221 SDE AS esrimakl:Win32:XDR Tue Feb 28 09:01:50 1112 9664 SDE DC esrimakl:Win32 Mon Mar 12 11:38:54 1062 11477 SDE AS esrimakl:Win32:XDR Thu Mar 01 11:34:38我们查看其他锁定表的信息
SQL> select * from layer_locks;
未选定行
SQL> select * from object_locks;
未选定行
SQL> select * from state_locks;
SDE_ID STATE_ID A L
---------- ---------- - -
1114 100 N S
1057 100 N S
1070 100 N S
1043 100 N S
1088 100 N S
1102 100 N S
1039 100 N S
1053 100 N S
1063 100 N S
1090 100 N S
1068 100 N S
SDE_ID STATE_ID A L
---------- ---------- - -
1069 100 N S
1109 100 N S
1036 100 N S
1112 100 N S
1062 100 N S
已选择16行。
SQL> select * from table_locks;
SDE_ID REGISTRATION_ID LO
---------- --------------- --
1112 263 S
1112 264 S
1112 265 S
1062 248 S
1062 252 S
1062 249 S
1062 250 S
1062 251 S
1062 253 S
1062 254 S
1062 255 S
..........
SDE_ID REGISTRATION_ID LO
---------- --------------- --
1062 256 S
1062 257 S
1062 258 S
1062 259 S
1062 260 S
1062 261 S
1062 262 S
1062 263 S
1062 264 S
1062 265 S
已选择241行。
那么有相关的S-ID，如果你知道某个同事的主机名IP等可以查看S-ID，那么不认识的S-ID就可以使用SQL语句的Where条件进行删除了。
而且ArcSDE也提供了相关的存储过程来对相关的锁类型表进行删除
begin -- Call the procedure lock_util.delete_layer_locks_by_sde_id(sde_id => :sde_id); end; begin -- Call the procedure lock_util.delete_table_locks_by_sde_id(sde_id => :sde_id); end; begin -- Call the procedure lock_util.delete_object_locks_by_sde_id(sde_id => :sde_id); end; begin -- Call the procedure lock_util.delete_state_locks_by_sde_id(sde_id => :sde_id); end; begin -- Call the procedure lock_util.delete_all_locks_by_sde_id(sde_id => :sde_id); end; --直接清空所有的孤儿锁 begin -- Call the procedure lock_util.delete_all_orphaned_locks; end;
使用以上方法，就可以非常方便的对指定的某个SDE连接进行锁的删除了。
四个表的相关介绍：
TABLE_LOCKS
Table locks are obtained by the geodatabase when an object class (table) or feature class, or layer, which is a table in its self, are opened by ArcCatalog, ArcMap or referenced by an ArcObjects application. Based upon the operation, a shared or exclusive lock is obtained. Exclusive locks are typically only acquired when the intention is to modify the table's properties. An exclusive lock can only be obtained by the owner of the table and if no shared locks currently exist for the table. As well, shared locks can not be obtained if any exclusive locks are present.
The geodatabase acquires shared table locks when the class is opened to ensure the table's properties do not change. Because the geodatabase caches the table properties within the client application. For example, if a shared table lock was not obtained and the geodatabase had cached a table's properties, if a second session modified the table, the cache would no longer be synchronized with the table. Ultimately leading to various errors when working with the table.
LAYER_LOCKS
Layer locks maintain information for each session which has acquired a full layer shared or exclusive lock and area locks.
The geodatabase only acquires exclusive layer locks on all feature classes participating in a topology when validating a non-versioned topology dataset. Sometimes non-geodatabase applications use layer locks to lock a specific area of a layer to prevent multiple sessions from modifying the features within the specified envelope. Again the application determines if the lock type should be shared or exclusive.
OBJECT_LOCKS
Object locks are an application maintained locking mechanism exposed by ArcSDE.
The geodatabase uses object locks to acquire shared and exclusive locks on version objects during editing and reconciling. The geodatabase acquires a shared object lock for a session on start editing. Because the lock type is shared, multiple sessions can edit the same version simultaneously. When a session starts a reconcile, the shared locked is promoted to an exclusive lock, succeeding only if no other shared locks are present. Promoting the shared lock to exclusive ensures no other sessions are currently editing and no sessions can start editing while the reconcile proceeds. The lock is not released until the post operation or stop editing.
STATE_LOCKS
State locks are maintained by ArcSDE to prevent states from being deleted or modified while a client application is accessing or using the state. States can be locked in shared or exclusive mode.
The geodatabase acquires exclusive state locks for the new state during each edit operation. The exclusive lock prevents the state from being deleted or trimmed if the compress operation is executed. The lock is released by the geodatabase on the stop editing event.
The ArcSDE server configuration parameter stateautolocking controls if ArcSDE automatically applies shared state locks for applications which have not explicitly set a state lock when accessing the state. By default, the parameter is disabled, implying no auto locking will take place. This improves application performance and database scalability.
It is not recommended that any lock tables are modified directly with SQL. Removing or changing lock values can potentially lead to application errors and data corruption. ArcSDE maintains these locks and validates if locks are valid when a lock collision is encountered. An example of a lock collision is when one session attempts to acquire an exclusive lock when shared locks are present.
Table locks are obtained by the geodatabase when an object class (table) or feature class, or layer, which is a table in its self, are opened by ArcCatalog, ArcMap or referenced by an ArcObjects application. Based upon the operation, a shared or exclusive lock is obtained. Exclusive locks are typically only acquired when the intention is to modify the table's properties. An exclusive lock can only be obtained by the owner of the table and if no shared locks currently exist for the table. As well, shared locks can not be obtained if any exclusive locks are present.
The geodatabase acquires shared table locks when the class is opened to ensure the table's properties do not change. Because the geodatabase caches the table properties within the client application. For example, if a shared table lock was not obtained and the geodatabase had cached a table's properties, if a second session modified the table, the cache would no longer be synchronized with the table. Ultimately leading to various errors when working with the table.
LAYER_LOCKS
Layer locks maintain information for each session which has acquired a full layer shared or exclusive lock and area locks.
The geodatabase only acquires exclusive layer locks on all feature classes participating in a topology when validating a non-versioned topology dataset. Sometimes non-geodatabase applications use layer locks to lock a specific area of a layer to prevent multiple sessions from modifying the features within the specified envelope. Again the application determines if the lock type should be shared or exclusive.
OBJECT_LOCKS
Object locks are an application maintained locking mechanism exposed by ArcSDE.
The geodatabase uses object locks to acquire shared and exclusive locks on version objects during editing and reconciling. The geodatabase acquires a shared object lock for a session on start editing. Because the lock type is shared, multiple sessions can edit the same version simultaneously. When a session starts a reconcile, the shared locked is promoted to an exclusive lock, succeeding only if no other shared locks are present. Promoting the shared lock to exclusive ensures no other sessions are currently editing and no sessions can start editing while the reconcile proceeds. The lock is not released until the post operation or stop editing.
STATE_LOCKS
State locks are maintained by ArcSDE to prevent states from being deleted or modified while a client application is accessing or using the state. States can be locked in shared or exclusive mode.
The geodatabase acquires exclusive state locks for the new state during each edit operation. The exclusive lock prevents the state from being deleted or trimmed if the compress operation is executed. The lock is released by the geodatabase on the stop editing event.
The ArcSDE server configuration parameter stateautolocking controls if ArcSDE automatically applies shared state locks for applications which have not explicitly set a state lock when accessing the state. By default, the parameter is disabled, implying no auto locking will take place. This improves application performance and database scalability.
It is not recommended that any lock tables are modified directly with SQL. Removing or changing lock values can potentially lead to application errors and data corruption. ArcSDE maintains these locks and validates if locks are valid when a lock collision is encountered. An example of a lock collision is when one session attempts to acquire an exclusive lock when shared locks are present.