Я использую Oracle для синхронизации событий между двумя узлами моего сервера приложений (не говоря уже о том, почему / если это лучший способ / и т. Д.).
Для этого я использую таблицу «событий», в которую один узел («активный») записывает новые события, а другой узел («пассивный») читает.Таблица выглядит следующим образом:
Event UUID (UUID) ||Идентификатор события (длинный) ||Данные события (несколько столбцов разных типов)
Идентификатор события - это постоянно увеличивающееся число (контролируемое приложением, а не последовательность), которое обозначает ревизию, в которой будет находиться внутренняя модель после применения данных события.Событие UUID имеет уникальное ограничение.У меня есть один индекс для идентификатора события, чтобы облегчить выбор SQL - «Выбрать ..., где Event_ID> XXX order by Event_ID», где XXX - внутренний номер ревизии пассивного узла.Время от времени я усекаю таблицу (используя «хранилище многократного использования усечения»).
[На самом деле, я использую три такие таблицы в порядке круговой проверки, чтобы всегда можно было обрезать ту, которую я собираюсь записать в мойпассивный узел может успеть «догнать»].
После нескольких часов вставки и усечения, где все в порядке, я начинаю получать много «шума» из базы данных, и время отклика резко падает.Это может продолжаться в течение часа или двух (или даже дольше), затем внезапно останавливается и время отклика возвращается к своему нормальному уровню.Отчеты AWR указывают на оператор усечения и немного на операторы вставки.Я подозреваю, что что-то происходит с DBWR - но я не могу точно определить.Обратите внимание, что это снижение производительности происходит даже тогда, когда вторичный узел (тот, на котором выполняются операторы «SELECT») выключен - так что это просто вставка / усечение.Примечание 2. Эта проблема НЕ воспроизводится на MSSQL.
Вопрос : почему это происходит?Что я могу сделать, чтобы остановить это?Существуют ли альтернативы этому дизайну (чем ближе альтернатива текущему дизайну, тем лучше).
Обновление 1: я мог бы ввести в заблуждение название.Это не единственная массовая вставка, а небольшая вставка, поскольку события генерируются на сервере приложений.
Обновление 2: сравнение AWR выборки из первого периода (хорошо) и второго периода (плохо)в http://pastehtml.com/view/1eirn20.html
Обновление 3: новая разность AWR в http://pastehtml.com/view/1eirn20.html
Обновление 4: Решено .Видимо, это было хранилище (спасибо ik_zelf!).Просто покажу - абстракции на самом деле не абстрактны.В конце это намагниченная прядильная плита.