У перетвореній базі геоданих, який вплив мають дельта-таблиці та дерево стану на ефективність запитів?

Ми маємо базу геоданих арксде (arcgis 9.3.1 на oracle 10g) з досить складною моделлю даних, яка включає близько 100 функціональних класів та непросторових таблиць, геометричну мережу та багато класів взаємозв'язків.

Дані щодня редагують 5 або 6 користувачів аркмапу, що використовують версію sde. Крім того, версії створюються автоматичними службами, які взаємодіють з іншими бізнес-системами для виконання змін у базі даних геоданих. Продуктивність запитів помітно знижується протягом дня, тому ми реалізували нічний сценарій, щоб досягти повного стиснення. У випадках, коли виконується відносно велика кількість правок, система може стати непридатною до повного стиснення.

Висловлено припущення, що в налаштованому Oracle не можна придумувати гідних планів виконання при зіткненні з цими мінливими таблицями дельта. Це розумне пояснення? Який підхід слід застосувати для його вирішення?

Оновлення у відповідь на коментарі

• До кінця дня дерево штату дуже лінійне, з невеликим розгалуженням.
• Ми стискаємо щоночі (отримуємо повний компрес, видаляючи всі версії).
• Бізнес-таблиці регулярно аналізуються.
• Дельта-таблиці не аналізуються. Вони заблоковані (спроба аналізу помилки повернення "Статистика об'єктів ORA-20005 заблокована"). Немає змінних таблиць у схемі sde - STATES, STATE_LINEAGES.

Таблиці дельти та дерево стану безпосередньо впливають на ефективність ваших запитів.

Спочатку потрібно зрозуміти версію; Я зробив коротке пояснення взаємозв'язку міток дерева та версій в іншій відповіді . Я думаю, це допомогло б вам перейти через це.

Прочитавши цю відповідь, ви зможете зрозуміти, як довга гілка ідентифікатора стану (від кореня до ідентифікатора стану, на яку посилається мітка, впливатиме на продуктивність. Чому? Тому що у вас є більш складні об'єднання для відтворення "поточного" перегляду версії. Оскільки компрес обрізає дерево, внутрішні з'єднання стають легшими в обробці базовим db, і ваші сеанси ArcMap стають швидшими.

Подивіться на документ Версії робочих потоків від ESRI, який навчить вас тримати дерево стану версії під правильним контролем. Використовуйте GDBT, щоб переглянути дерево стану до і після, щоб ви могли побачити, як хороший робочий процес впливає на дерево.

По-друге, якщо ви можете піти від того, що не потрібно використовувати Геометричну мережу для більшості випадків використання, тоді зробіть це. Це призведе до уповільнення залучених FeatureClasses, оскільки він використовує складні повідомлення для кожного виклику Row :: store (на відміну від того, щоб просто зберігати рядок у таблиці та робити з ним).

Для оновлення статистики використовуйте функцію аналізу інструментів управління даними (позначте їх усі). Він буде знати, як поводитися з дельта-таблицями (та будь-якими іншими таблицями), які необхідні.

[Вибачення першого повідомлення: Це означає, що це коментар, а не остаточна відповідь.] Якщо у вас є версії для редагування, які є відносно старими і не розміщені, їх слід видалити, опублікувати або узгодити. Стара непримирена версія зберігає старий вигляд за замовчуванням, що запобігає стисканню записів дельти, що належать до нових версій, у базові таблиці. Існує велика кількість цих нестиснених дельта-записів, прикріплених до старої версії, і на їх ефективність впливає, оскільки всі версії - це перегляди на дельта та базові таблиці. Продуктивність системи пов'язана з кількістю редагувань, оскільки кожна версія була остаточно узгоджена (або створена). Так коротше; якщо є якісь версії, які ви не можете опублікувати, то регулярно їх узгоджуйте та стискайте.