问题：在 Oracle 中压缩地理数据库会导致 ArcGIS 中出现阻止情况，从而导致其停止响应

描述

在压缩版本化地理数据库时，编辑版本化类的用户可能会在 Oracle 中遇到阻止情况。 当 Oracle 会话被阻止时，ArcGIS 的用户体验是该应用程序没有响应。

注： ArcSDE 软件（包括应用程序服务器、命令工具以及带有 C 和 Java API 的 SDK）在 ArcGIS 10.2.2 中已弃用，不再进行分发。

仅当编辑用户针对地理数据库当前正在压缩的同一版本化类执行版本化更新或删除，或者压缩进程本身被阻止等待压缩时，才会发生这种情况。

阻止情况的持续时间取决于编辑会话的持续时间，该会话当前保持对版本化类的锁定，或者特定类的压缩操作事务的持续时间。

原因

当用户在编辑和执行压缩操作时，要确保版本化数据的一致性，必须在版本化类的 deletes 表上获得锁，以确保读取一致性。

由于 Oracle 使用一种积极的锁定模型，在该模型中，写入者将不会阻止读取者，因此要确保一个会话在第二个会话更新行时不会读取该行，该应用程序必须实施一种锁定模型以防止出现竞争条件。

在执行更新或删除时，ArcGIS 将通过在版本化类的 deletes 表上放置行排他锁以防止出现竞争状况，而在修剪表时，压缩操作可在版本化类的 deletes 表上获得共享模式锁。 仅在执行事务期间保持这两个锁。 当应用程序执行更新或删除时，事务的持续时间为编辑操作的生命周期（调用 stopeditoperation 提交事务，并调用 aborteditoperation 回滚事务）。 压缩仅在压缩单个表时才保持锁，而非整个压缩操作的生命周期。

当多位用户编辑版本化类时，行排他锁将不会导致阻止情况。 它仅阻止压缩操作，压缩操作的锁也将阻止编辑器执行更新和删除。

当压缩获得共享模式锁后，将不会阻止编辑器执行更新或删除操作。 最终用户的体验是该应用程序没有响应。 阻止的持续时间完全取决于进行压缩以修剪版本化表所需的时间，该时间与要修剪及移除的类中的行数量直接相关（如果组织频繁/每晚进行压缩，则该数量应该最小）。

另一种可能导致阻止情况的情况是，编辑器已获得类上的行排他锁，但尚未停止其编辑操作（由此导致提交及移除锁）。 如果执行编辑的会话长时间保留锁（可能是由于要更新或删除的数据量较大），则编辑器的会话将阻止压缩操作。 压缩操作被阻止后，Oracle 将会维护请求锁的会话的先进/先出队列。 因此，编辑会话将阻止压缩，并且压缩的请求将阻止其他请求锁的编辑会话。 这种级联效果是 Oracle 中的预期行为（确保按顺序处理锁请求的唯一机制）。

锁定行为的最终结果是它将对请求锁定以确保数据一致性时，可能对编辑器和扩展等待产生影响。

解决方案或解决方法

安排在较少用户编辑版本化类时的非高峰生产时间内执行压缩操作。

如果发现压缩操作正在导致 Oracle 实例中出现阻止情况，从而阻止用户进行编辑，则可以安全地结束执行压缩命令的会话。

已写入压缩操作在事务上保持一致，以确保进程异常终止时的数据完整性。