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

Перенос данных в другое приложение

Перенос данных в другое приложение, возможно, покажется, легкой задачей, но ведь и в хранилище данных также может когда-нибудь не хватить места и в результате придется вернуться к одному из двух предыдущих вариантов. В крупной организации эта проблема может свалиться на кого-нибудь другого! А если серьезно, то перенос данных из действующих систем в ИУС или ИСР - вполне допустимая форма архивации с точки зрения администратора действующей системы.

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

Перенос данных в неияменяелюе пространство в этом же приложении

Этот вариант вообще не является архивацией как таковой, если только в процессе переноса данные некоторым образом не реструктурируются. Тем не менее, это ценный метод уменьщения объема данных, подлежащих регулярному резервному копированию, так как табличное пространство только для чтения нужно копировать только один раз (сразу же после ALTER TABLES РАСЕ...READ ONLY).

Как архивировать?

Какое рещение самое лучщее? Вот наща рекомендация: создавать одну архивную копию данных на магнитном носителе в форме, для использования которой требуется минимальный объем программного обеспечения. И для структурированных, и для текстовых данных это означает извлечение данных в текстовом формате, т.е. представление архива в виде отчета, включающего все содержимое каждой записи. Необходимо побеспокоится о том, чтобы этот формат был хорощо описан (т.е. названия полей были информативными). Для создания архива в формате такого типа потребуется гораздо больще времени, чем для получения копии базы данных или экспортированного файла (с помощью утилиты ЕХР), а для загрузки его на какой-нибудь пока не существующей платформе могут понадобиться значительные усилия разработчиков. Однако этим вы хотя бы оставляете себе (или своим преемникам) надежду на успех.

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

Предположим, вы архивируете таблицу (OLD X), а затем восстанавливаете ее в другую таблицу (NEW X). Если приведенный ниже запрос выполняется без ошибки и возвращает нуль, то это означает, что подпрограммы архивации и восстановления работают нормально.

(SELECT * FROM new x

MINUS SELECT * FROM old x

UNION ALL (SELECT * FROM old x

MINUS SELECT * FROM new x

Если таблица содержит много строк, то, несмотря на элегантность этого запроса, для его выполнения понадобится очень много времени и пространства для сортировки. Однако он работает значительно быстрее, чем реализация при помощи языка третьего поколения или PL/SQL.

Примечание

Набор операций над множествами из этого примера - это еще один образец полезного кода, который невозможно использовать, если таблица содержит столбцы типа LONG или LONG RAW.

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

Когда архивировать?

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

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

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

Если данные содержат метки времени, показывающие, когда они в Последний раз изменялись, то можно по ним найти данные, которые не

изменялись, скажем, три года. К сожалению, мы не сможем определить, когда к этим данным последний раз обращались с запросом.

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

Куда архивировать - в файл или в таблицу?

Хорощий вопрос! Достоинства и недостатки обоих методов очевидны. Использование файлов освобождает драгоценное пространство базы данных (и место на дисках, если файл, в свою очередь, архивируется на ленту). Если извлечь данные из архива будет трудно, мы, вероятно, сможем воспользоваться щлюзом, чтобы запросить их с помощью SQL, хотя вряд ли найдется шлюз, позволяющий читать данные прямо с ленты или получить доступ к последовательным файлам, находящимся в формате отчета.

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

Если вы передумали, то можно ли вернуть архивные данные обратно?

Еще один хороший вопрос! Если вы проектируете модули для архивации данных, то, конечно, можно создать модули и для воскрешения этих данных. Одна из множества опасностей, которых следует остерегаться в этом случае, связана с уникальными ключами. Может случиться, что к моменту возвращения данных появилась еще одна запись с тем же ключом.

Один из способов избежать дублирования ключей - оставить после архивации остовную часть строки. Мы знакомы с этим подходом, но он нам не нравится. При таком способе приходится оставлять данные во всех обязательных столбцах, и строка все равно занимает место. Более того, даже если все запросы к таблице содержат условие, например ARCHIVED = N, при их выполнении, скорее всего, будут обрабатываться все остаточные строки.

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