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

Question

У нас есть база данных аудита (oracle), которая содержит информацию о мониторинге всех операций, выполняемых службами (около 100), развернутых на серверах приложений. Как вы можете себе представить, база данных аудита действительно огромна из-за большого количества запросов, которые обслуживают службы. И единственная транзакция записи, которая происходит в этой базе данных, это сервисы, записывающие информацию аудита в режиме реального времени.

Поскольку база данных аудита начала расти (более миллиона записей в день), запрос необходимых данных (например, select all errors occurred with service A for requests between start date and end date) быстро стал почти невозможным.

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

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

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

Answer 1

Возможно, вы захотите разобраться в разбиении вашей базовой таблицы.

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

Затем вы можете просто поменять "старые" разделы (используя ALTER TABLE the_table EXCHANGE partition) из одной таблицы в другую. Нужно всего несколько секунд, чтобы «переместить» раздел. Фактическая производительность будет зависеть от определенных индексов (локальных, глобальных).

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

Answer 2

Легкий путь.

1. удалить старые записи, частично лучшие с оператором FORALL
2. копирование данных частично лучшее с FORALL
3. добавить разбиение по дням недели

II Очереди

1. удалить старые записи, частично лучшие с оператором FORALL
2. заполнить audit_archives триггером при аудите, в триггере использовать очередь, чтобы избежать длинных dml