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