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

Question

Советы / предложения, необходимые для небольшого дизайна приложения.

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

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

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

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

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

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

Спасибо.

Answer 1

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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