在版本化的地理数据库中，增量表和状态树对查询性能有何影响？

我们有一个版本化的arcsde地理数据库（oracle 10g上的arcgis 9.3.1），具有相当复杂的数据模型，其中包括大约100个要素类和非空间表，一个几何网络以及许多关系类。

每天有5或6个arcmap用户使用sde版本控制编辑数据。此外，还通过自动服务创建了版本，这些服务与其他业务系统连接以在地理数据库中执行编辑。查询性能在一天中明显下降，因此我们实施了每晚脚本来实现完全压缩。在执行相对大量的编辑的情况下，系统可能要等到完全压缩后才能使用。

有人建议，面对这些易失的增量表，配置的oracle无法提出合理的执行计划。这是合理的解释吗？应该采取什么方法解决呢？

更新以回应评论

• 到最后，状态树非常线性，只有很少的分支。
• 我们每晚压缩（通过删除所有版本获得完整压缩）。
• 定期分析业务表。
• 不分析增量表。它们被锁定（尝试分析返回错误“ ORA-20005对象统计信息已锁定”）。sde模式中的易失性表也不是-STATES，STATE_LINEAGES。

增量表和状态树对您的查询有直接的性能影响。

首先，您需要了解版本控制；我对状态树和版本标签之间的关系做了一个简短的解释，答案是不同的。我认为这将帮助您解决问题。

阅读完该答案后，您可以意识到长状态ID分支（从根到标签所指的状态ID）将如何影响性能。为什么？因为您使用更复杂的联接来重新创建版本的“当前”视图。由于压缩正在修剪树，因此内部联接变得更容易被基础数据库处理，并且ArcMap会话也变得更快。

查看ESRI 的“ 版本控制工作流”文档，该文档将教您如何保持版本状态树在合理的控制之下。使用GDBT前后查看状态树，以便了解良好的工作流程如何影响状态树。

其次，如果您不必在大多数用例中都使用几何网络，那么就可以这样做。它会减慢所涉及，因为它使用复杂消息的每一行::店电话（而不是仅仅存储行中的表和正在用它做）的FeatureClasses。

要更新统计信息，请使用数据管理工具的“分析”功能（将其全部标记）。它会知道如何处理必要的增量表（和其他表）。

[第一次道歉：这是一个评论，而不是一个明确的答案。]如果您有任何相对较旧且尚未发布的编辑版本，则应将其删除，发布或协调。旧的未对帐版本保留了默认的旧视图，这防止了属于较新版本的增量记录被压缩到基表中。这些未压缩的增量记录可能有大量固定到旧版本，由于所有版本都是增量表和基表的视图，因此性能会受到影响。自上次协调（或创建）每个版本以来，系统性能与编辑次数有关。简而言之 如果有您无法发布的任何版本，请定期对其进行协调并进行压缩。