У нас есть версионная база геоданных arcsde (arcgis 9.3.1 на oracle 10g) с довольно сложной моделью данных, которая включает в себя около 100 классов объектов и непространственных таблиц, геометрическую сеть и множество классов отношений.
Данные редактируются ежедневно 5 или 6 пользователями arcmap с использованием sde-версий. Кроме того, версии создаются автоматическими службами, которые взаимодействуют с другими бизнес-системами для редактирования в базе геоданных. Производительность запросов заметно снижается в течение дня, поэтому мы реализовали ночной сценарий для достижения полного сжатия. В случаях, когда выполняется относительно большое количество правок, система может стать непригодной для использования до полного сжатия.
Было высказано предположение, что oracle в том виде, в котором оно настроено, не может придумать достойных планов выполнения, когда сталкивается с этими изменчивыми дельта-таблицами. Это разумное объяснение? Какой подход должен быть предпринят, чтобы решить это?
Обновление в ответ на комментарии
- К концу дня дерево состояний очень линейное, с небольшим ветвлением.
- Мы сжимаем каждую ночь (получим полный компресс, удалив все версии).
- Бизнес-таблицы регулярно анализируются.
- Дельта-таблицы не анализируются. Они заблокированы (попытка проанализировать возвращает ошибку «Статистика объекта ORA-20005 заблокирована»). В схеме sde нет изменчивых таблиц - STATES, STATE_LINEAGES.
Ответы:
Дельта-таблицы и дерево состояний напрямую влияют на производительность ваших запросов.
Во-первых, вы должны понимать управление версиями; Я сделал краткое объяснение взаимосвязи дерева состояний и меток версий в другом ответе . Я думаю, что это поможет вам пройти через это.
Прочитав этот ответ, вы сможете понять, как длинная ветвь идентификатора состояния (от корневого до идентификатора состояния, на которую указывает метка) будет влиять на производительность. Почему? Потому что у вас есть более сложные объединения для воссоздания «текущего» представления версии. Поскольку сжатие обрезает дерево, внутренние объединения становятся легче обрабатывать с помощью нижележащей базы данных, и ваши сеансы ArcMap становятся быстрее.
Взгляните на документ Versioning Workflows из ESRI, в котором вы узнаете, как держать дерево состояний версий под разумным контролем. Используйте GDBT для просмотра дерева состояний до и после, чтобы увидеть, как хороший рабочий процесс влияет на дерево.
Во-вторых, если вы можете избежать необходимости использовать геометрическую сеть в большинстве случаев, сделайте это. Это будет замедлять FeatureClasses, которые участвуют , поскольку он использует сложный обмен сообщениями для каждой строки :: магазина вызова (в отличие от просто хранить строку в таблице и делается с ним).
Чтобы обновить статистику, используйте функцию анализа инструментов управления данными (отметьте их все). Он будет знать, как обращаться с дельта-таблицами (и любыми другими таблицами), которые необходимы.
источник
[Первое сообщение извинения: это должен быть комментарий, а не окончательный ответ.] Если у вас есть какие-либо версии редактирования, которые являются относительно старыми и не были опубликованы, их следует удалить, опубликовать или согласовать. Старая несогласованная версия сохраняет старое представление по умолчанию, что предотвращает сжатие дельта-записей, принадлежащих более новым версиям, в базовые таблицы. Может быть огромное количество этих несжатых дельта-записей, прикрепленных к старой версии, и это влияет на производительность, потому что все версии являются представлениями дельта и базовых таблиц. Производительность системы связана с количеством правок с момента последней сверки (или создания) каждой версии. Короче говоря; если есть какие-либо версии, которые вы не можете опубликовать, регулярно сверяйте их и сжимайте.
источник