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

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

Варианты архивации

В зависимости от конкретных данных и конкретной среды архивация может означать разные действия. Это может быть:

полное уничтожение данных (изъятие или удаление их без сохранения копий);

исключение возможности немедленного доступа к данным с сохранением их на внешнем носителе, с которого их можно (по крайней мере, теоретически) восстановить;

исключение возможности доступа к данным из промышленных систем с сохранением возможности доступа из информационно-управляющих систем (ИУС) и информационных систем руководителей (ИСР), например из хранилища данных или OLAP-сервиса;

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

Полное уничтожение данных

Вы можете сказать, что полное уничтожение данных - совершенно неприемлемый вариант. Действительно, стоимость сэкономленной ленты Можно считать единственным вознаграждением, которое можно когда-нибудь за это получить. Однако ни вы, ни мы не хотим очутиться в положении. Когда придется признать, что мы сознательно выбросили несколько сот гигабайт корпоративных данных. Тем не менее, во многих приложениях, особенно в ИСР и хранилищах данных, стоимость хранения данных иногда перевешивает выгоды от возможности доступа к ним как к справочным данным. В таких случаях данные вежливо теряют.

Вот как может звучать одно из типичных требований, предъявляемых к ИСР:

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

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

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

В версиях до 7.3 с таким представлением сопряжены определенные сложности, особенно если попытаться выполнить операцию соединения с ним. Может понадобиться ряд других представлений, в которых соединение используется в каждом запросе. Работая с версией 7.0, мы наблюдали случаи, когда единственным приемлемо работающим был метод, который заключался в индивидуальной выдаче запросов и выполнении объединения результатов внутри приложения. В версии 7.3 запросы, использующие этот метод (который называется ручным секционированием), оптимизируются очень хорошо при условии соблюдения ряда ограничивающих условий. По сути, эти ограничения сводятся к тому, что определения отдельных таблиц должны быть идентичны во всем, кроме имен и параметров хранения.

Если мы создадим такую структуру, удалить (заархивировать) данные будет легко. Для этого необходимо сделать следующее;

1. Создать новую таблицу (CALLS 97Q2).

2. Пересоздать представление, исютючив ссылку на CALLS 95Q1 и добавив ссылку на CALLS 97Q2.

3. Исключить таблицу CALLS 95Q1.

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

Кроме того, этот подход очень удобен при загрузке данных из операционных систем. Подробнее он описан в главе 13.

Отключение данных

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

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

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

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

Безусловно, мы - не единственные в мире, у кого до сих пор есть данные на 5-дюймовых дискетах (при том, что ни у одного из нас на домашних ПК нет дисководов для этих дискет). Кроме того, в надежных хранилищах, разбросанных по всему свету, находятся сотни копий баз данных Oracle версии 5.