Упорядочение, восстановление и частота фиксации

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

Заголовок файла может иметь, например, такой вид - HDR CUST L0AD,4. Цифра 4 указывает, что это четвертая операция загрузки и она не должна начинаться до завершения третьей загрузки. Пример таблицы, которая используется для управления загрузкой данных, содержится в табл. 8.1. Здесь каждой операции загрузки присвоен порядковый номер и имя. Кроме того, для каждой операции указаны полное имя внешнего файла, из которого бьши взяты данные, и ее статус. В этом примере также регистрируется позиция во входном файле, до которой дошла активная операция загрузки. Это число обновляется в каждой точке фиксации. Такой подход позволяет упростить процедуру восстановления в случае сбоя при загрузке большого объема данных. При перезапуске процесса загрузки программа может определить из этой таблицы достигнутую позицию, а затем просто перемотать ленту в эту точку файла и возобновить процесс. Однако использование файла управления загрузкой и описанного здесь механизма восстановления возможно лишь в случае, если вы напишете собственную ЗСЬ-программу загрузки. Возможно, стоит применить 3GL лишь для обеспечения контроля, чтобы затем возобновить процесс загрузки и не нарушить в результате ссылочную целостность.

Таблица 8.1. Пример таблицы управления загрузкой

Использование SQL*Loader

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

Сравнение SQL*Loader и 3GL

Мы уже рассматривали ряд вопросов, касающихся выбора инструментальных средств для приема данных, но еще не проводили непосредственное сравнение двух самых эффективных из них. Это:

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

ЗСЬ-программа, например, на Рго*С или Pro*COBOL, обеспечивающая чтение данных из среды передачи, а также их проверку, корректировку, вставку и обновление.

Лучщей характеристикой по производительности обладает первое средство, а опция прямой загрузки SQL*Loader - несомненно, самый быстрый способ вставки данных в Oracle-таблицу.

Программы на Рго*С, как правило, более трудоемки в плане создания и тестирования, чем, например, код на PL/SQL, но они почти наверняка работают в несколько раз быстрее PL/SQL с любыми объемами данных, если выполняются на той же платформе, что и экземпляр базы данных, и используют массивный интерфейс (array interface) Oracle.

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

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

Сильные и слабые стороны SQL*Loader

SQL*Loader - это зрелый и широко используемый продукт. Он поддерживает записи фиксированной и переменной длины и может обрабатывать смесь символьных (как правило, ASCH) и двоичных данных. Кроме того, он имеет внутренний генератор последовательности, генерирующий уникаль-нью идентификаторы строк. Учтите, что это не то же самое, что последовательность в Oracle?, поэтому после загрузки каждую последовательность, используемую приложением для назначения ключей таблице, нужно изменить так, чтобы она начиналась с максимального значения в таблице после завершения загрузки. SQL*Loader является идеальным средством для выполнения простой загрузки данных с проверкой целостности сущностей. Так, например, SQL*Loader отклоняет записи с отсутствующими значениями в столбцах NOT NULL и недопустимым форматом данных.

К основным недостаткам SQL*Loader следует отнести:

неспособность выполнять обновление;

неспособность выполнять трансформацию данных;

неспособность обеспечить ссылочную целостность; но так как Oracle? позволяет вводить ограничения FOREIGN KEY и UNIQUE на уровне базы данных, этот недостаток не является критичным.

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

Самое большое преимущество SQL*Loader состоит в способности этой программы выполнять прямую загрузку. В процессе прямой загрузки SQL*Loade записывает целые блоки прямо в базу данных, пропуская промежуточные этапы, такие как выполнение SQL и управление кэшами данных. Это нарушает правило подрыва функциональности, сформулированное Тедом Коддом для реляционных баз данных, но дает такой рост производительности, что никто не обращает на это никакого внимания!

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

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

Предупреждение

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