Как Управлять Разделами В Базе Данных Oracle, Не Сходя С Ума

Мы готовы сказал о том, почему секционирование базы данных очень важно для производительности DLP-системы и как мы реализовали это в PostgreSQL. Эта статья будет посвящена Oracle. Специфика использования СУБД в DLP-решениях заключается в том, что объем данных растет очень быстро.

Их невозможно хранить в оперативном архиве, а длительное хранение – необходимость в компании численностью не менее 50 человек.

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

Использование только встроенных инструментов СУБД требует знаний и опыта.

В этом основная трудность, и она, в общем-то, очевидна «на берегу».

Кроме того, возникают проблемы, которые не сразу очевидны.

Как вернуть из долговременного архива раздел с данными старой версии приложения и присоединить его к более свежей? Что делать, если у них разные форматы хранения данных? Что делать, если соединение раздела прервалось и он завис между долгосрочным и онлайн-архивом?

Как управлять разделами в базе данных Oracle, не сходя с ума

В целом решение этих вопросов сводится к двум основным техническим задачам: автоматизация управления разделами в СУБД Oracle (отключение и подключение) и система «отката» разделов в случае, если при подключении что-то пошло не так.



Что не так со встроенными механизмами Oracle DB

Опция «Разделение» помогает удалить данные на ленту и вернуть их из долговременного архива; с ее помощью можно разделить таблицу на части по какому-либо принципу, например, по диапазону дат. Помимо управляемости и доступности такое разделение также повышает производительность.

Каждый период хранится в отдельном табличном пространстве, что позволяет с помощью технологии переносимых табличных пространств быстро перемещать табличные пространства между различными базами данных отчетности и архивирования с разными версиями и платформами.

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

И тогда администратор вынужден создавать вокруг себя кучу инструментов управления.

А сам процесс отключения-подключения-передачи требует навыков администрирования базы данных.

Поэтому задача-минимум — автоматизировать этот процесс и сделать его доступным для администраторов приложений.

Мы разработали набор скриптов, с помощью которых можно управлять секционированными таблицами, получать о них любую информацию и т.д. Никаких знаний команд или опыта работы с СУБД не требуется.

Администратор приложения просто запускает скрипт или выбирает нужное действие в интерфейсе, указывает необходимый раздел, и все происходит само собой.



Совместимость версий (не)

Итак, мы автоматизировали отключение разделов и отправку их в долгосрочный архив.

А вот с долгосрочным архивом есть проблема: иногда его нужно вернуть.

Допустим, администратор перенес в него несколько разделов в старой версии.

Через год вышла новая версия, в которой в таблицы были добавлены новые поля, новые индексы, а в долгосрочный архив добавлен еще ряд разделов.

И тут чекист расследует некий инцидент, и ему нужно подтянуть данные двухлетней давности, т. е.

поднять раздел на несколько версий назад и как-то подключить его к базе данных.

Структура таблиц новой версии иногда отличается от исторической.

Для раздела архива требуется ряд проверок и изменений.

Проверка всегда начинается со сравнения текущей версии Солар Дозор и версии СУБД и подключенного раздела.

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

Использование текстовых индексов для поиска в Solar Dozor также вносит дополнительные сложности.

Имеются некоторые ошибки, связанные с EXCHANGE PARTITION для текстовых индексов, созданных в разных версиях СУБД или при использовании переносимого табличного пространства (повреждение метаданных индекса до версии 12).

Патчи не всегда доступны для необходимой версии или платформы.

Пересоздание индексов при подключении — процедура не быстрая и достаточно ресурсоемкая.

Пришлось встроить обходные пути в процедуры подключения разделов.

Структура DR$ таблиц текстовых индексов подключенного раздела «приравнивается» к текущей, а поле таблицы ctxsys.dr$index обновляется.

Также имеется защита от различных ошибок администратора.

Например, на уровне приложения запрещены любые действия с разделом, в который в данный момент загружаются данные и который имеет статус «текущий».



"Хьюстон у нас проблема.

"

В ходе внедрения этих механизмов мы столкнулись с еще одной проблемой, которая неожиданно часто возникает среди клиентов.

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

СУБД Oracle имеет DDL и DML. DML реализует механизм обеспечения целостности транзакций, который откатывает результаты в случае сбоя транзакции.

В DDL такого механизма нет, и любые действия с разделом — это дорога в один конец.

Мы разработали механизм, который проверяет выполнение всех действий по отключению и подключению раздела и исправляет возникающие проблемы.

При возникновении проблем механизм перезапускает работу с разделом с того момента, когда что-то пошло не так.

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

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

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

Если что-то пошло не так, после перезапуска процедуры производится проверка, на каком шаге остановилось завершение работы, и либо выполняется следующая команда, либо происходит откат — записанные операции отмены выполняются в обратном порядке.

ИДЕНТИФИКАТОР ЗАЯВЛЕНИЕ ОТМЕНИТЬ ПОЛОЖЕНИЕ ДЕЛ
4411 СОЗДАТЬ ТАБЛИЦУ ADDRESS2_P10001 TABLESPACE DOZOR1_INDEXES AS SELECT * FROM ADDRESS2 WHERE 1 = 2 УДАЛЕНИЕ ТАБЛИЦЫ АДРЕС2_P10001 ХОРОШО
4412 СОЗДАТЬ ИНДЕКС IX_ADDRESS2_MESSAGE_P10001 ПО АДРЕСУ 2_P10001 (СООБЩЕНИЕ) ТАБЛИЧНОЕ ПРОСТРАНСТВО DOZOR1_INDEXES НУЛЕВОЙ; ХОРОШО
4413 СОЗДАТЬ УНИКАЛЬНЫЙ ИНДЕКС IX_ADDRESS2_UNIQ2_P10001 ПО ADDRESS2_P10001 (ADDR_TYPE, VALUE, MESSAGE) TABLESPACE DOZOR1_INDEXES НУЛЕВОЙ; ХОРОШО
4414 ALTER TABLE ADDRESS2 EXCHANGE PARTITION p10001 С TABLE ADDRESS2_P10001 ВКЛЮЧАЯ ИНДЕКСЫ БЕЗ ПРОВЕРКИ ALTER TABLE ADDRESS2 EXCHANGE PARTITION p10001 С TABLE ADDRESS2_P10001 ВКЛЮЧАЯ ИНДЕКСЫ БЕЗ ПРОВЕРКИ ХОРОШО
В результате мы получаем либо исходное состояние базы данных, либо успешное завершение процедуры выключения.

Теги: #информационная безопасность #Хранение данных #Администрирование баз данных #oracle #База данных Oracle #oracle DB #dlp #dlp

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.