버전이 지정된 지오 데이터베이스에서 델타 테이블과 상태 트리는 쿼리 성능에 어떤 영향을 줍니까?

우리는 약 100 개의 피쳐 클래스와 비 공간 테이블, 기하학적 네트워크 및 많은 관계 클래스를 포함하는 상당히 복잡한 데이터 모델을 가진 버전이 지정된 arcsde 지오 데이터베이스 (오라클 10g의 arcgis 9.3.1)를 가지고 있습니다.

sde 버전 관리를 사용하는 5 명 또는 6 명의 아크 맵 사용자가 매일 데이터를 편집합니다. 또한 버전은 다른 비즈니스 시스템과 인터페이스하여 지오 데이터베이스에서 편집을 수행하는 자동 서비스에 의해 작성됩니다. 하루 중 쿼리 성능이 눈에 띄게 저하되므로 전체 압축을 달성하기 위해 야간 스크립트를 구현했습니다. 비교적 많은 수의 편집이 수행되는 경우 전체 압축이 완료 될 때까지 시스템을 사용할 수 없게됩니다.

이러한 휘발성 델타 테이블에 직면 할 때 구성된 Oracle은 적절한 실행 계획을 제시 할 수 없습니다. 이것이 합리적인 설명입니까? 그것을 해결하기 위해 어떤 접근법을 취해야합니까?

의견에 대한 응답으로 업데이트

• 하루가 끝날 무렵 상태 트리는 분기가 거의없는 매우 선형입니다.
• 우리는 매일 밤 압축합니다 (모든 버전을 삭제하여 완전히 압축하십시오).
• 비즈니스 테이블은 정기적으로 분석됩니다.
• 델타 테이블은 분석되지 않습니다. 잠겨 있습니다 (분석 시도가 "ORA-20005 개체 통계가 잠겨 있음"오류를 리턴 함). sde 스키마 (STATES, STATE_LINEAGES)의 소멸성 테이블도 아닙니다.

델타 테이블과 상태 트리는 쿼리에 직접적인 성능 영향을 미칩니다.

먼저, 버전 관리를 이해해야합니다. 나는 다른 답변에서 상태 트리와 버전 레이블 의 관계에 대한 간단한 설명을했다 . 나는 당신이 그것을 극복하는 데 도움이 될 것이라고 생각합니다.

이 답변을 읽은 후에는 레이블에서 참조하는 루트에서 상태 ID까지의 긴 상태 ID 분기가 성능에 어떤 영향을 미치는지 알 수 있습니다. 이유는 버전의 "현재"보기를 다시 만들기 위해 더 복잡한 조인이 있기 때문입니다. 압축이 트리를 트리밍하기 때문에 기본 db로 내부 조인을 처리하기가 더 쉬워지고 ArcMap 세션이 더 빨라집니다.

ESRI 의 Versioning Workflows 문서를 살펴보고 버전 상태 트리를 제대로 제어하는 ​​방법을 알려줍니다. GDBT 를 사용하여 전후 의 상태 트리를 확인하여 올바른 워크 플로가 트리에 미치는 영향을 확인할 수 있습니다.

둘째, 대부분의 사용 사례에 기하 네트워크를 사용할 필요가없는 경우에는 그렇게하십시오. 이 것 이 모든 행 :: 상점 호출 복잡한 메시지를 사용하기 때문에 (단지 테이블의 행을 저장하고 그것으로 수행되고 반대) 포함되는 FeatureClasses을 늦출.

통계를 업데이트하려면 데이터 관리 도구의 분석 기능을 사용하십시오 (모두 표시). 필요한 델타 테이블 (및 기타 테이블)을 처리하는 방법을 알게됩니다.

[첫 번째 게시물 사과 : 이것은 명확한 답변이 아닙니다.] 상대적으로 오래되고 게시되지 않은 편집 버전이 있으면 삭제, 게시 또는 조정해야합니다. 조정되지 않은 이전 버전은 이전 버전의 기본보기를 유지하므로 최신 버전에 속하는 델타 레코드가 기본 테이블로 압축되지 않습니다. 이전 버전에 고정 된 압축되지 않은 델타 레코드는 엄청나게 많을 수 있으며 모든 버전이 델타 및 기본 테이블의 뷰이기 때문에 성능에 영향을 미칩니다. 시스템 성능은 각 버전이 마지막으로 조정 (또는 생성) 된 이후 편집 횟수와 관련이 있습니다. 간단히 말해서; 게시 할 수없는 버전이 있으면 정기적으로 조정하고 압축하십시오.