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信息

1. C:\Users\Administrator>sdemon -o info -I users -s 192.168.220.165 -i 5151 -p sde  
2.   
3. ArcSDE Instance 5151 Registered Server Tasks on 192.168.220.165 at Mon Mar 12 15:44:16 2012  
4. ------------------------------------------------------------------------------  
5. S-ID  S-PID  User    Conn  Client Machine:OS                Started  
6. ----- ----- -------- ---- -------------------------------- -------------------  
7. 1057  6027  SDE       AS  esrimakl:Win32:XDR               Thu Mar 01 08:35:56  
8. 1114  14260 SDE       AS  esrimakl:Win32:XDR               Mon Mar 12 11:39:20  
9. 1070  10634 SDE       AS  esrimakl:Win32:XDR               Mon Mar 05 08:23:43  
10. 1043  26301 SDE       AS  esrimakl:Win32:XDR               Wed Feb 29 09:49:48  
11. 1088  7564  SDE       DC  w2008s101:Win32                  Wed Mar 07 16:48:10  
12. 1102  24604 SDE       AS  esrimakl:Win32:XDR               Fri Mar 09 10:12:28  
13. 1039  27577 SDE       AS  esrimakl:Win32:XDR               Tue Feb 28 16:54:20  
14. 1053  3936  SDE       AS  esrimakl:Win32:XDR               Wed Feb 29 15:16:11  
15. 1063  11507 SDE       AS  esrimakl:Win32:XDR               Thu Mar 01 11:35:35  
16. 1090  840   SDE       AS  esrichinazs:Win32:XDR            Wed Mar 07 17:57:48  
17. 1068  6631  SDE       AS  esrichinazs:Win32:XDR            Fri Mar 02 16:44:03  
18. 1069  10632 SDE       AS  esrimakl:Win32:XDR               Mon Mar 05 08:23:43  
19. 1109  12864 SDE       AS  esrimakl:Win32:XDR               Mon Mar 12 10:52:52  
20. 1036  13221 SDE       AS  esrimakl:Win32:XDR               Tue Feb 28 09:01:50  
21. 1112  9664  SDE       DC  esrimakl:Win32                   Mon Mar 12 11:38:54  
22. 1062  11477 SDE       AS  esrimakl:Win32:XDR               Thu Mar 01 11:34:38  

我们查看其他锁定表的信息

1. SQL> select * from layer_locks;  
2.   
3. 未选定行  
4.   
5. SQL> select * from object_locks;  
6.   
7. 未选定行  
8.   
9. SQL> select * from state_locks;  
10.   
11.     SDE_ID   STATE_ID A L  
12. ---------- ---------- - -  
13.       1114        100 N S  
14.       1057        100 N S  
15.       1070        100 N S  
16.       1043        100 N S  
17.       1088        100 N S  
18.       1102        100 N S  
19.       1039        100 N S  
20.       1053        100 N S  
21.       1063        100 N S  
22.       1090        100 N S  
23.       1068        100 N S  
24.   
25.     SDE_ID   STATE_ID A L  
26. ---------- ---------- - -  
27.       1069        100 N S  
28.       1109        100 N S  
29.       1036        100 N S  
30.       1112        100 N S  
31.       1062        100 N S  
32.   
33. 已选择16行。  
34.   
35. SQL> select * from table_locks;  
36.   
37.     SDE_ID REGISTRATION_ID LO  
38. ---------- --------------- --  
39.       1112             263 S  
40.       1112             264 S  
41.       1112             265 S  
42.       1062             248 S  
43.       1062             252 S  
44.       1062             249 S  
45.       1062             250 S  
46.       1062             251 S  
47.       1062             253 S  
48.       1062             254 S  
49.       1062             255 S  
50.   
51. ..........  
52.   
53.     SDE_ID REGISTRATION_ID LO  
54. ---------- --------------- --  
55.       1062             256 S  
56.       1062             257 S  
57.       1062             258 S  
58.       1062             259 S  
59.       1062             260 S  
60.       1062             261 S  
61.       1062             262 S  
62.       1062             263 S  
63.       1062             264 S  
64.       1062             265 S  
65.   
66. 已选择241行。  

那么有相关的S-ID，如果你知道某个同事的主机名IP等可以查看S-ID，那么不认识的S-ID就可以使用SQL语句的Where条件进行删除了。

而且ArcSDE也提供了相关的存储过程来对相关的锁类型表进行删除

1. begin  
2.   -- Call the procedure  
3.   lock_util.delete_layer_locks_by_sde_id(sde_id => :sde_id);  
4. end;  
5.   
6. begin  
7.   -- Call the procedure  
8.   lock_util.delete_table_locks_by_sde_id(sde_id => :sde_id);  
9. end;  
10.   
11. begin  
12.   -- Call the procedure  
13.   lock_util.delete_object_locks_by_sde_id(sde_id => :sde_id);  
14. end;  
15.   
16. begin  
17.   -- Call the procedure  
18.   lock_util.delete_state_locks_by_sde_id(sde_id => :sde_id);  
19. end;  
20.   
21. begin  
22.   -- Call the procedure  
23.   lock_util.delete_all_locks_by_sde_id(sde_id => :sde_id);  
24. end;  
25. --直接清空所有的孤儿锁  
26. begin  
27.   -- Call the procedure  
28.   lock_util.delete_all_orphaned_locks;  
29. 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.