Самые быстрые, самые надежные и самые маленькие LOB-ы

Источник: oracle
Джонатан Генник

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

Oracle  Database  11g  прилагает  большие  усилия  для решения  проблемы  адресации  неструктурированных данных,  разработав  совершенно  новую  инфраструктуру хранения  данных,  которые  в  настоящее  время  часто остаются в файловых системах. Эта новая инфраструктура называется Oracle SecureFiles, которая полностью заменяет предыдущую  инфраструктуру  больших  объектов  Oracle (LOB)  (которая  теперь  называется  BasicFiles).  Каждая грань Oracle  SecureFiles  LOB-архитектуры,  от  дискового формата  до  сетевого  протокола  и  до  алгоритмов  redo  и undo, были пересмотрены и реализованы заново с целью:

  • Повышения производительности
  • Повышения надежности
  • Уменьшения использования диска

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

Эта статья описывает, как установить и сконфигурировать Oracle  SecureFiles  и  как  применить  демонстрационный контент  в  подобной  системе  управления  цифровыми активами. Конфигурирование экземпляра Oracle После установки Database 11g и перед использованием Or-acle SecureFiles, проверьте установленное значение нового в Oracle Database 11g параметра инициализации db_secure-file. Его значение по умолчаниюdb_securefile = permittedЭто  значение  соответствует  BasicFiles,  а  не  Secure-Files.  Оно  означает  способ  хранения  по  умолчанию  для любых  новых  создаваемых  LOB-столбцов,  и  в  то  же время  дает  возможность  явно  указать  SecureFiles  там, где  это необходимо.  (BasicFiles  -  это LOB-архитектура  в предыдущих  версиях базы данных). Остальные  значения параметра задают различные способы предопределенного использования  того  или  иного  типа  памяти.  Например,  можно  установить  db_securefile  =  force,  чтобы  все  LOB-ы  создавались  как  SecureFiles,  даже  когда  создающий пользователь явно указывает иное. Следует понимать, какое значение db_securefile действует в вашей базе данных.

Создание табличных пространств

Любое  табличное  пространство,  которое  планируется использовать  для  Oracle  SecureFiles,  должно  быть сконфигурировано  с  параметрами  автоматического управления  сегментами  (automatic  segment  space  man-agement  -  ASSM).  Для  этого  важно  указать  SEGMENT SPACE MANAGEMENT AUTO при создании табличного пространства  для  LOB.  Следующая  команда  создает табличное пространство ARTICLE_LOBS для этой статьи:

CREATE TABLESPACE
article_lobs
DATAFILE "H:\APP\JONATHAN\ORADATA\ORCL\AR-
TICLE_LOBS.DBF"
SIZE 5M
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO;

Если  вы  повторяете  действия,  описываемые  в примере  этой  статьи,  то  выдайте  пользователю необходимую  квоту  на  табличное  пространство  AR-TICLE_LOBS.  Также  нужно  правильно  указать путь  к  соответствующему  файлу  в  вашей  системе. Настройки шифрования Oracle  SecureFiles  дополнительно  обеспечивает прозрачное  (transparent)  шифрование  LOB-данных. Прозрачное шифрование  данных  защищает  LOB-данные  от  неавторизованных  пользователей,  которые  могут каким-либо  способом  получить  доступ  к  файлу  данных. Это  шифрование  совершенно  незаметно  конечному пользователю и приложениям.Если  вы  планируете  использовать шифрование  для  Oracle SecureFiles, необходимо  создать кошелек прозрачного шифрования  данных  (transparent  data  encryption  wallet)  для  хранения  ключа  шифрования.  Сначала  создайте директорию,  в  которой  будет  находиться  кошелек. 

Эту директорию  можно  разместить  в  $ORACLE_HOME. Например: mkdir H:\app\Jonathan\product\11.1.0\db_1\wallet  Затем  добавьте  в  файл  sqlnet.ora  параметр  EN-CRYPTION_WALLET_LOCATION.  Файл  sql-net.ora  расположен  в  $ORACLE_HOME/net-work/admin.  Следующий  пример  устанавливает соответствие  с  только  что  созданной  директорией: ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY= H:\app\Jonathan\product\11.1.0\db_1\wallet))) Убедитесь, что ENCRYPTION_WALLET_LOCATION в sql-net.ora - это одна длинная строка. И ещё, если вы следуете нашему  примеру,  то  необходимо  назначить  директорию кошелька на какую-нибудь в собственной системе.

Наконец, установите ключ шифрования: ALTER SYSTEM SET ENCRYPTION KEY AUTHENTICATED BY "My secret key"; При  такой настройке Oracle Database  будет  генерировать ключ  шифрования,  и  размещать  его  в  кошелеке.  Затем кошелек защищается паролем "My secret key". Создание SecureFile LOB Создание  Oracle  защищенных  LOB-файлов  (Secure-Files  LOB)  может  быть  простым  настолько,  насколько просто  указание  STORE AS  SECUREFILE  в  выражении  для  хранения  LOB  в  предложении  CREATE  TABLE или  ALTER  TABLE.  (Убедитесь,  что  ваши  SecureFiles LOB  связаны  с  ASSM-поддерживающими  табличными пространствами).  Листинг  1  создает  таблицу  article_draft_redef  с  единственным  SecureFiles  LOB-столбцом, названным  article_content.  Данные  для  этого  LOB привязаны  к  табличному  пространству  ARTICLE_LOBS (созданному  ранее  в  этой  статье).  Каждая  строка  в  этой таблице  характеризует  журнальную  статью  на  заданной стадии цикла ее обработки, т.е. написания/редактирования/резензирования.

Листинг 1: Создание Oracle SecureFiles LOB

CREATE TABLE article_draft_redef (
 article_id NUMBER,
 article_stage VARCHAR(10),
 article_content BLOB,
 CONSTRAINT article_stage_check_b
 CHECK (article_stage IN (
 "1st Draft", "Edit Pass", "2nd Draft",
 "Copyedit", "Review", "Final")),
 CONSTRAINT article_draft_pk_b
 PRIMARY KEY (article_id)
)
LOB (article_content) STORE AS SECUREFILE
 article_content (
 TABLESPACE article_lobs
 RETENTION MIN 3600
 KEEP_DUPLICATES NOCOMPRESS DECRYPT
 CACHE READS);

Листинг  1  показывает  некоторые  опции,  возможные  при создании нового LOB. RETENTION MIN 3600 означает, что по крайней мере 1 час  (60 минут  x  60  секунд/минуту  =  3,600)  undo-данные будут  сохраняться  для  LOB-столбца.  Эта  возможность указания  минимального  времени  хранения  полезно  для запуска  базы  данных  в  режиме  flashback.  Значение  по умолчанию  RETENTION  AUTO  означает,  что  undo-данные  будут  храниться  только  в  том  случае,  если  есть свободный  объем  undo  для  удовлетворения  целостности запросов на чтение, пока транзакция находится в работе.

Вы также можете указать максимальный объем хранения в байтах или вообще ничего не хранить. Посмотрите Oracle  SQL  Reference,  чтобы  узнать  подробнее  синтаксис. KEEP_DUPLICATES,  NOCOMPRESS  и  DE-CRYPT  явно  отключают  устранение  дублей,  сжатие и  шифрование.  Я  вернусь  к  этим  опциям  позже  в  этой статье.  В  реальной  жизни  вам,  скорее  всего,  захочется оставить включенной одну или несколько из этих опций. CACHE READS  указывает LOB-данным  разместиться  в кэше (buffer cache) на время операции чтения, но не на время операции записи.

Этим вы увеличите производительность чтения за счет потенциального уплотнения других данных кэша.  NOCACHE  отменяет  поведение  по  умолчанию  и означает никогда не помещать LOB-данные в кэш. На  Листинге  1  создается  таблица  article_draft_redef  для миграции таблицы с устаревшими BasicFiles в новый метод хранения  SecureFiles.  Чтобы  проследить  за  процессом миграции,  скачайте  файл  o57securefiles.zip,  распакуйте его  и  следуйте  инструкциям  в  readme.txt  для  создания исходной таблицы с названием article_draft, которая будет мигрировать.  Логическая  структура  столбца  article_draft точно такая же, как и в article_draft_redef. Таблица  article_draft  содержит  существующие  LOB-данные,  хранимые  как  BasicFiles. 

Я  предполагаю,  что эти  данные  используются  запущенным  приложением,  а их надо мигрировать из BasicFiles в SecureFiles. Таблица article_draft_redef  со  столбцом  SecureFiles  LOB  является целевой для таблицы article_draft. Планирование миграцииТак как Oracle SecureFiles представляет совершенно новый  способ  записи  LOB-данных  в  базу  данных,  есть  только один способ миграции LOB-данных из BasicFiles в Secure-Files - полностью переписать данные путем пересоздания или  переопределения  таблиц,  содержащих  столбцы  Ba-sicFiles.  Если  есть  возможность  получить  данные  в режиме offline, то можнопросто извлечь данные из старой таблицы и вставить в новую. Начните с примерно с такого предложения:

INSERT INTO article_draft_redef
 SELECT article_id,
  article_stage,
  article_content
 FROM article_draft;

После INSERT выполните DROP и RENAME, чтобы новая таблица смогла заменить старую:

DROP TABLE article_draft;
RENAME article_draft_redef
TO article_draft;

Хотя на  самом деле не обязательно использовать данные в режиме offline. Вместо  этого обсудим переопределение таблиц в режиме online, что можно применять, начиная с Oracle9i Database Release 1. Листинг 2 показывает PL/SQL-блок, который мигрирует таблицу article_draft в структуру, заданную  таблицей  article_draft_redef.  Определение таблицы в режиме online сделать очень легко, и это делает миграцию  прозрачной  для  пользователей  и  приложений, так  как  мигрируемая  таблица  все  это  время  остается
доступной.

Листиг 2: Миграция через переопределение в режиме online.

DECLARE
 error_counter PLS_INTEGER;
BEGIN
 --Начало процесса переопределения
 DBMS_REDEFINITION.START_REDEF_TABLE (
 "gennick", "article_draft", "article_draft_redef ",
 "article_id, article_stage, article_content");
 --Окончание процесса переопределения
 DBMS_REDEFINITION.FINISH_REDEF_TABLE (
 "gennick", "article_draft", "article_draft_redef ");
END;

Если LOB-таблица секционирована, есть еще один способ миграции  -  это  обмен  секциями.  Указать  параметры хранения LOB можно для секции, задав опцию миграции от  BasicFiles  к  SecureFiles  для  каждой  секции  отдельно. (В  статье Аруп Нанда  (Arup Nanda)  "Partition Decisions" (http://www.oracle.com/technology/oramag/oracle/07-sep/o57partition.html)  находится  пример,  как  делается  обмен секциями.)

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

Имейте  в  виду,  что  каждый  обмен  "старой"  секции производится при  том,  что  обмениваемая  секция  должна быть  переведена  в  автономный  режим  (briefly  taken  of-fline).  Наконец,  необходимо  оценить  различные  методы и  выбрать  тот  метод,  который  лучше  всего  сработает  в конкретной ситуации.

Подтверждение миграции

Следует  удостовериться  в  статусе  SecureFiles  заданного LOB-столбца проверкой подтипа сегмента с этим столбцом. Например, следующее предложение подтверждает, что ar-ticle_content теперь SecureFiles LOB:SELECT segment_subtypeFROM user_segmentsWHERE segment_name="ARTICLE_CONTENT"; Ожидаемый  результат  -  это  SECUREFILE,  который означает хранение в виде SecureFiles. Если результат будет ASSM, хранение все еще производится в виде BasicFiles.

Устранение дублей

После миграции на Oracle SecureFiles вы можете включить режим  устранения  дублей,  то  есть  опции  Oracle  Secure-Files, позволяющей  серверу базы данных хранить  только одну копию данного LOB в данном столбце в одной и той же  секции.  Два  и  более  пользователя  могут  независимо хранить одинаковые данные в LOB-столбце - например, двойное хранение одного и того же варианта статьи - а база  данных  отслеживает  эти  дубли,  храня  только  одну копию  данных.  Режим  устранения  дублей  прозрачен. Пользователи  убеждены,  что  они  имеют  каждый  свою собственную копию данных и даже думают, что по-другому быть не может.

Листинг 3: Проверкаместа, занимаемого LOB

DECLARE
 seg_blocks NUMBER;
 seg_bytes NUMBER;
 used_blocks NUMBER;
 used_bytes NUMBER;

 expired_blocks NUMBER;
 expired_bytes NUMBER;
 unexpired_blocks NUMBER;
 unexpired_bytes NUMBER;
BEGIN
 DBMS_SPACE.SPACE_USAGE (
 "GENNICK", "ARTICLE_CONTENT", "LOB"
 , seg_blocks, seg_bytes, used_blocks, used_bytes
 , expired_blocks, expired_bytes, unexpired_blocks, unex-
pired_bytes);
 DBMS_OUTPUT.PUT_LINE ("Bytes used = " // to_
char(used_bytes));
END;

В процессе реальной миграции устранение дублей лучше проводить  во  время,  а  не  после  этого  процесса.  Хотя при  демонстрации  приятно  увидеть  как  действительно производится  удаление  дубликатов.  Выполните  код Листинга 3, чтобы увидеть, сколько байтов занимает LOB-сегмент.  (Убедитесь,  что  первый  параметр  процедуры ссылается на корректное название схемы в вашей системе). В моей системе результат следующий:  Bytes used = 450560. Чтобы устранить дубли в столбце article_content таблицы article_draft,  выполните  следующее  предложение ALTER
TABLE:

 ALTER TABLE article_draft
 MODIFY LOB(article_content)
 (DEDUPLICATE LOB);

Существующие  LOB-ы  в  столбце  article_content  будут просканированы,  все  дубли  будут  найдены  и  удалены. Все новые LOB-значения, записываемые в столбец, будут проверяться  на  наличие  уже  существующего  такого  же значения для предотвращения новых дублей.Теперь  выполните  код  Листинга  3  снова  и  посмотрите на  результат  устранения  дублей.  Количество  байтов, используемых  сегментом,  должно  уменьшиться.  В  моей системе я увидел следующее, уменьшенное значение:Bytes used = 376832 [Разность - это] число байтов, занимаемых LOB-сегментом, было  освобождено,  так  как  документ  #6  является    дубль статьи, сохраненной в другой строке. Благодаря устранению дублей,  эта  статья  не  хранится  дважды. 

Вместо  этого, сохраняется  указатель  на  LOB  в  другой  строке.  Когда вы  считываете  содержимое  LOB  для  документа  #6,  этот указатель "прозрачно"трансформируется.Определение  дублей  основано  на  контрольной  сумме, вычисляемой  по  криптографическому  хэш-алгоритму SHA1. Когдавы записываете новый LOB в LOB-сегмент, контрольная сумма вычисляется по первым n байтам этого нового LOB-а. Если контрольная сумма не соответствует ни одному  существующему  LOB  в  сегменте,  новый LOB  записывается  в  базу  данных.  Контрольные  суммы сохраняются  для  каждого LOB  для  устранения дублей  в будущем.

Когда  контрольная  сумма  нового  LOB-а  соответствует существующей  контрольной  сумме,  есть  большая вероятность,  что  эти  два  LOB-а  идентичны.  Экземпляр базы  данных  начинает  побайтовое  сравнение  входящих LOB-данных  с  возможным  дубликатом,  который  уже сохранен.  Этот  возможный  дубликат  назовем  основным LOB.  Процесс  сравнения  считывает  основной  LOB, но  не  записывает  новых  данных  до  тех  пор,  пока  LOB-данные  продолжают  соответствовать.  Если  сравнение LOB-ов  показало  идентичность,  записывается  только указатель на  основной LOB. Если  сравнение неуспешно, данные  основного LOB  до  этой  точки  используются  для формирования  первой  части  нового  LOB,  и  оставшиеся входящие данные нового LOB записываются на диск.

Сжатие

В  режиме  сжатия  данные  в  LOB-е  кодируются  для уменьшения объема, требуемого для его хранения. Сжатие прозрачно и уменьшает количество памяти, необходимое для  LOB-данных,  позволяя  сэкономить  каждый  доллар от организационных затрат на дисковую систему. Сжатие требует дополнительных мощностей CPU, так как сжатие выполняется  перед  вставкой  в  LOB-столбец.  Например, изображения, такие как PNG-файлы и JPEG-файлы, часто сжимаются  как  часть  применяемой  схемы  шифрования.

Дальнейшее сжатие файлов изображений может привести к  потере  производительности  CPU.  Однако  текстовые данные,  такие  как  XML  и  текстовые  документы, целесообразно сжимать, расходуя CPU, так как экономия дискового пространства в этом случае более существенна.Чтобы  включить  сжатие  для  демонстрационного LOB-столбца  типа  SecureFiles,  выполните  следующее предложение ALTER TABLE:

ALTER TABLE article_draft
 MODIFY LOB(article_content)
 (COMPRESS HIGH);

Это  предложение  активирует  высокоуровневое  сжатие данных столбца. Можно указать MEDIUM для отмены части этого сжатия для уменьшения затрат CPU. Варианта сжатия LOW нет, однако это ключевое слово зарезервировано для будущих реализаций. Из кода Листинга 3 видно, что теперь задействовано еще меньше места для LOB-сегмента. Я получил  следующий результат:Bytes used = 90112. Помните,  что  сжатие  имеет  множество  преимуществ. Требования  к  дисковому  пространству  меньше. Меньше данных  требуется  перемещать  вперед-назад,  тем  самым увеличивается  производительность.  Генерация  redo уменьшается. Меньше  используется  извлечений  и  кэша, оставляя больше места в кэше для других объектов.

Шифрование

Наконец  мы  добрались  до  прозрачного  шифрования данных.  Зашифрованные  LOB-данные  защищены, даже  когда  файлы  данных  или  файлы  резервных  копий попадают в "грязные" руки. Зашифрованные LOB-данные защищены, даже когда они передаются по сети.Чтобы  зашифровать  LOB-ы  в  Oracle  SecureFiles,  можно выбрать  один  из  четырех  алгоритмов  шифрования: 3DES168,  AES128,  AES192  и  AES256.  Например,  для выбора  шифрования  по  AES256,  которое  представляет собой  256-битный  алгоритм,  выполните  следующее предложение ALTER TABLE:

ALTER TABLE article_draft
 MODIFY LOB(article_content)
 (ENCRYPT USING "AES256");

Помните, что шифрование данных защищает ваши данные от недоброжелателей, которые могут случайно заполучить файл  данных  или  часть  резервной  копии.  Также  нужно управлять доступом к объектам базы данных внутри вашей базы данных, так как только авторизованные пользователи базы  данных  имеют  доступ  для  выполнения  запроса  по LOB-данным, которые вы защитили.

Заключение

Oracle SecureFiles предлагает три отличные возможности, которые  можно  использовать  сразу  же  без  выполнения каких-либо  изменений  в  ваших  приложениях, использующих LOB:

  • Устранение дублей
  • Сжатие
  • Шифрование

Предварительное тестирование показывает существенное повышение производительности, благодаря использованию Oracle  SecureFiles.  Внутреннее  тестирование  Oracle  показывает  от  200  до  900  процентов  повышения производительности по  записи в  зависимости от размера LOB  и  места,  в  котором  будет  повторно  использоваться существующий  сегмент.  Те  клиенты,  которые  раньше всех  начали  использовать  эти  возможности,  заявили о  повышении  производительности  от  300  до  700 процентов  по  основным  функциям  приложения. Так как Oracle SecureFiles легко обратно-совместимы с BasicFiles, даже до момента использования тех же названий типов  данных,  можно  начать  применять  что-нибудь из  того,  что  предложил  Oracle  SecureFiles,  сразу  же  с момента перехода на Oracle Database 11g. Вам необходимо переписать LOB-данные в базу данных, и вы можете делать это  в  то  время, как данные находятся  в режиме online, и изменение  совершенно  прозрачно  как  по  отношению  к пользователям, так и по отношению к приложениям.

Oracle  SecureFiles  -  это  подарок.  Взгляните  на  него. Получите  сразу  же  улучшение  производительности, сэкономите  денег  на  дисковое  пространство,  и  защитите ваши данные от того, кто может вам навредить.


Страница сайта http://test.interface.ru
Оригинал находится по адресу http://test.interface.ru/home.asp?artId=21100