Преодоление «синхронизации файлов журнала» по дизайну?

Question

Рекомендации или рекомендации, необходимые для разработки приложения.

У меня есть приложение, которое использует 2 таблицы, один представляет собой промежуточную таблицу, которую многие отдельные процессы пишут, как только «группа» процессов завершается, другое задание выполняется вместе с объединением результатов вместе в финальную таблицу, затем удаляет эту «группу» из промежуточной таблицы.

Проблема, с которой я столкнулась, заключается в том, что когда эта промежуточная таблица очищается, генерируется много повторений, и я вижу, что в базе данных ждет много «синхронизации файлов журнала». Это общая база данных со многими другими приложениями, и это вызывает некоторые проблемы.

При применении агрегата строки сокращаются до примерно 1 строки в итоговой таблице для каждых 20 строк в промежуточной таблице.

Я думаю о том, чтобы обойти это, вместо того, чтобы иметь одну «промежуточную» таблицу, я создам таблицу для каждой «группы». После этого эта таблица может быть просто удалена, что должно привести к значительно меньшему количеству повторов.

У меня только SE, поэтому секционированные таблицы не являются опцией. Кроме того, более быстрые диски для повтора, вероятно, также не являются опцией в краткосрочной перспективе.

Это плохая идея? Какие-нибудь лучшие решения?

Спасибо.

Answer 1

Загрузка каждой группы в отдельную таблицу звучит как прекрасный план для уменьшения повтора. Вы можете обрезать таблицу отдельных групп после каждой агрегации.

Другой вариант (но, я думаю, скорее всего, хуже) заключается в создании новой промежуточной таблицы с группами, которые не были агрегированы, а затем отбросить оригинал и переименовать новую таблицу для замены промежуточной таблицы.

Answer 2

Можно ли решить проблему, выполнив логический процесс (например, установить столбец DELETE_FLAG в таблице на «Y»), а затем выполнить ночной процесс, который обрезает таблицу (потенциально записывая какие- удаленные строки в отдельную таблицу перед усечением, а затем скопировать их после того, как таблица усечена)?

Вы уверены, что источник синхронизации файла журнала ожидает, что ваши диски не могут идти в ногу с вводом/выводом? Конечно, это возможно, но есть и другие возможные причины чрезмерного ожидания синхронизации файлов журнала, включая чрезмерные коммиты. В блоге Pythian есть отличная статья о tuning log file sync events.

Answer 3

Я предпочитаю предложение Юстина («логическое удаление»), но другой вариант рассмотрения может быть секционированной таблицей, если у вас есть лицензия EE. Процесс агрегации может удалить раздел, а не удалять строки.

Answer 4

Наиболее частой причиной чрезмерной синхронизации файлов журнала является слишком частая фиксация, которая часто преднамеренно кодируется в попытке уменьшить нагрузку на систему из-за блокировки. Вы должны совершать транзакции только после завершения бизнес-транзакции.