Мы готовы сказал о том, почему секционирование базы данных очень важно для производительности DLP-системы и как мы реализовали это в PostgreSQL. Эта статья будет посвящена Oracle. Специфика использования СУБД в DLP-решениях заключается в том, что объем данных растет очень быстро.
Их невозможно хранить в оперативном архиве, а длительное хранение – необходимость в компании численностью не менее 50 человек.
При этом оперативный архив заполняется настолько быстро, что информацию приходится передавать в долгосрочный архив раз в 2 недели и чаще.
Использование только встроенных инструментов СУБД требует знаний и опыта.
В этом основная трудность, и она, в общем-то, очевидна «на берегу».
Кроме того, возникают проблемы, которые не сразу очевидны.
Как вернуть из долговременного архива раздел с данными старой версии приложения и присоединить его к более свежей? Что делать, если у них разные форматы хранения данных? Что делать, если соединение раздела прервалось и он завис между долгосрочным и онлайн-архивом?
В целом решение этих вопросов сводится к двум основным техническим задачам: автоматизация управления разделами в СУБД 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
-
Романтика О Googlewave
19 Oct, 24 -
Электронных Книг От Microsoft Не Будет
19 Oct, 24 -
Видеонаблюдение На Raspberry Pi
19 Oct, 24