«Технологии баз данных (СУБД Oracle)» (стр. 4 )

Обычно в В*-дереве имеется однозначное соответствие между записью индекса и строкой - запись индекса указывает на строку. В индексе на основе битовых карт (BITMAP) запись использует битовую карту для ссылки на большое количество строк одновременно. Такие индексы подходят для данных с небольшим количеством различных значений, которые обычно только читаются. Столбец, имеющий всего три значения - Y, N и NULL, - в таблице с миллионом строк очень хорошо подходит для создания индекса на основе битовых карт. Индексы на основе битовых карт не нужно использовать в базе данных класса ООТ (оперативной обработки транзакций) из-за возможных проблем с одновременным доступом.

Пример создания индекса на основе битовых карт:

CREATE BITMAP INDEX ind_bit ON employees (commission_pct) ;

Индексы по функции

Эти индексы на основе В*-дерева или битовых карт хранят вычисленный результат применения функции к столбцу или столбцам строки, а не сами данные строки. Это можно использовать для ускорения выполнения запросов вида:

SELECT * FROM t WHERE ФУНКЦИЯ (столбец) = некоторое значение,

поскольку значение ФУНКЦИЯ (столбец) уже вычислено и хранится в индексе.

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

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

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

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

Чтобы использовать индексы по функциям, необходима предварительная настройка. В отличие от описанных ранее индексов на основе В*-дерева и битовых карт, перед созданием и использованием индексов по функциям необходимо выполнить определенные действия. Чтобы обеспечить возможность их создания, надо задать ряд параметров в файле init. ora или на уровне сеанса. Кроме того, необходимы соответствующие привилегии. Для использования индексов по функциям необходимо сделать следующее.

• Чтобы создать индексы по функциям для таблиц в собственной схеме, необходима системная привилегия QUERY REWRITE.

• Чтобы создать индексы по функциям для таблиц в других схемах, необходима системная привилегия GLOBAL QUERY REWRITE.

• Использовать оптимизатор, основанный на стоимости. Индексы по функциям доступны только стоимостному оптимизатору, и никогда не будут использоваться оптимизатором на основе правил.

• Чтобы оптимизатор использовал индексы по функциям, необходимо установить следующие параметры на уровне сеанса или системы:

QUERY_REWRITE_ENABLED=TRUE

QUERY_REWRITE_INTEGRITY=TRUSTED

Необходимо установить эти параметры либо на уровне сеанса с помощью оператора ALTER SESSION, либо на уровне системы в файле параметров инициализации init. ora. Смысл установки параметра QUERY_REWRITE_ENABLED - разрешить оптимизатору переписывать запрос так, чтобы можно было использовать индекс по функции. Смысл установки параметра QUERY_REWRITE_INTEGRITY - сообщить оптимизатору, что можно "доверять" указанному программистом признаку предопределенности результатов выполнения кода (deterministic). Если результаты выполнения кода не предопределены (другими словами, возвращает разные результаты при одних и тех же входных данных), полученные по индексу строки могут оказаться некорректными. Предопределенность должен обеспечить разработчик.

Пример создания индекса в таблице employees по функции UPPER для столбца last_name:

CREATE INDEX emp_func ON employees (UPPER (last_name))

Таблицы, организованные по индексу

Таблицы, организованные по индексу (index organized tables - IOT), - это таблицы, хранящиеся в структуре индекса. Стандартная таблица организована случайным образом (данные попадают в любое свободное место). В таблице же, организованной по индексу, хранимые данные отсортированы по первичному ключу. С точки зрения приложений, таблицы, организованные по индексу, ничем не отличаются: к ним применяются такие же SQL-операторы, как и для доступа к обычной таблице. Они особенно полезны для информационно-поисковых (information retrieval - IR) систем, хранения пространственных данных и приложений оперативного анализа информации (OLAP). При использовании стандартной таблицы необходимо управлять дисковым пространством, как для таблицы, так и индекса по первичному ключу. При использовании таблицы, организованной по индексу, дополнительное пространство для поддержки индекса по первичному ключу не требуется, поскольку индекс - это данные, а данные - это индекс. Проблема в том, что индекс - сложная структура данных, поддержка и управление которой требуют выполнения множества действий.

Пример создания простейшей индекс-организованной таблицы:

CREATE TABLE t1

(x INT PRIMARY KEY,

у VARCHAR2(25),

z DATE

)

ORGANIZATION INDEX;

Представления

Представления (view) – это определяемый вид выбираемых данных из одной или нескольких таблиц и других представлений. Их можно рассматривать как хранимые запросы. Представления в действительности не содержат данные, они выбирают их из таблиц, на которых они основываются. Эти таблицы называют базовыми таблицами представления. Данные из представлений запрашиваются так же, как и из таблиц. С некоторыми ограничениями можно выполнять изменение, вставку и удаление данных из представления. Все операции с представлениями в действительности выполняются с базовыми таблицами. С помощью представлений можно создать дополнительный уровень безопасности, ограничив доступ только к предопределенному набору строк и столбцов таблицы. Представления могут основываться на сложных запросах, упрощая доступ к данным пользователям и из приложений.

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

Простое представление (simple view) – это представление, которое:

-  выбирает данные только из одной таблицы;

-  не содержит функций и групп данных,

-  позволяет выполнять операции DML через представление.

Сложное представление – это представление, которое:

-  выбирает данные из нескольких таблиц,

-  содержит функции ли группы данных,

-  не всегда позволяет выполнять операции DML через представление.

Для изменения определения представления не создавая его заново (без удаления представления и повторного и повторного предоставления объектных привилегий) можно использовать параметр OR REPLACE.

Пример создания представления:

CREATE OR REPLACE VIEW emp_view

AS SELECT employee_id, last_name, salary FROM employees WHERE department_id=80;

Вывести структуру представления можно с помощью команды SQL*Plus:

DESCRIBE emp_view

Именами столбцов в представлении можно управлять путем включения псевдонимов (алиасов) столбцов в подзапрос или указывать их псевдонимы в предложении CREATE VIEW после имени представления и перед ключевым словом SELECT подзапроса. Количество указанных псевдонимов должно соответствовать количеству столбцов или выражений в подзапросе, как в примере:

CREATE OR REPLACE VIEW emp_view (id_number, name, ann_salary)

AS SELECT employee_id, last_name, salary*12 FROM employees WHERE department_id=80;

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

C момента создания представления его имя и определение хранятся в словаре данных USER_VIEWS. Текст команды SELECT, составляющей представление, хранится в столбце с типом данных LONG.

Пример создания сложного представления:

CREATE OR REPLACE sum_view (name, minsal, maxsal, avgsal)

AS SELECT d. department_name, MIN (e. salary), MAX (e. salary), AVG (e. salary)

FROM employees e, departments d

WHERE e. department_id = d. department_id

GROUP BY d. department_id;

Опция READ ONLY запрещает операции DML с представлениями. В следующем примере представление модифицируется так, чтобы все операции DML с ним были запрещены:

CREATE OR REPLACE VIEW emp_view

AS SELECT employee_id, last_name, salary FROM employees WHERE department_id=80

READ ONLY;

Триггера

Триггера – это хранимые в базе данных объекты, которые срабатывают автоматически, когда что-то происходит. База данных Oracle позволяет обрабатывать с помощью триггеров многие события. Например, вставку в таблицу, подсоединение пользователя к базе данных, кем-то предпринимаемую попытку удаления таблицы или изменения параметров аудита. Триггера могут вызывать другие процедуры и функции. Администраторы базы данных используют триггера для аудита по значениям данных, для проверки сложных ограничений и для автоматизации многих других задач. Существует много различных событий, которые могут быть использованы для создания триггеров. Большинство триггеров срабатывает перед или после события. Триггера DML могут быть созданы для событий, возникающих один раз на уровне команды(INSERT, UPDATE, DELETE) или же для событий, возникающих при изменении каждой строки таблицы.

Табличные триггера

Триггеры, определенные для таблиц, называются табличными триггерами (table triggers). Синтаксис создания триггера имеет следующей вид:

CREATE OR REPLACE TRIGGER имя_триггера момент_срабатывания триггерное_событие

ON имя_таблицы

[WHEN триггерное_ограничение]

[FOR EACH ROW]

[тело_триггера]

END имя_триггера';

Момент срабатывания определяет, когда будет срабатывать триггер: до (BEFORE) или после (AFTER) наступления триггерного события (выполнения запускающего оператора). Если указано значение BEFORE, триггер выполняется до каких-либо проверок ограничений на строки, затрагиваемые триггерным событием. Никакие строки не блокируются. Триггер этого типа называется, соответственно, BEFORE-триггером (BEFORE trigger).

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

Триггерное событие может принимать значения INSERT, UPDATE'или DELETE.

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

Набор ключевых слов FOR EACH ROW указывает на необходимость выполнить тело триггера для каждой строки, затрагиваемой запускающим оператором. Такие триггеры называются строчными (row triggers).

Если опция FOR EACH ROW отсутствует, то при наступлении триггерного события триггер выполняется только один раз. В этом случае он называется операторным триггером (statement trigger), поскольку выполняется только один раз для каждого запускающего оператора.

Тело триггера - представляет собой обычный базовый блок PL/SQL.

Различные триггерные события можно комбинировать с помощью оператора OR. Например:

DELETE OR INSERT остальные_операторы

В случае использования UPDATE можно указать список столбцов:

UPDATE ОF столбец_1, столбец_2,...

При использовании опции FOR EACH ROW для триггерного события UPDATE в операторах PL/SQL обращение к новой и старой строкам выполняется с помощью слов "NEW" и "OLD", предваренных двоеточием. Так, :OLD. имя_столбца даст значение, которое столбец имел до обновления. Однако в триггерном ограничении имена "OLD" и "NEW" используются без двоеточий.

В теле триггера можно использовать предикаты INSERTING, UPDATING, DELETING которые возвращают TRUE или FALSE в зависимости от команды DML, которую обрабатывает триггер.

IF INSERTING THEN

:new. hire_date = SYSDATE;

END IF;

В теле триггера на UPDATE можно уточнить, какой столбец был изменен в текущем операторе:

IF UPDATING ('SALARY') THEN ...

Если в таблице несколько разнотипных триггеров, то порядок их выполнения таков:

1. Все операторные BEFORE триггера.

2. Все строчные BEFORE триггера.

3. Все строчные AFTER триггера.

4. Все операторные AFTER триггера.

При создании триггеров необходимо учитывать следующее:

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

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

• В триггере, запускаемом оператором UPDATE, можно обращаться к старым и новым значениям столбцов. Это касается как BEFORE, так и AFTER триггеров.

• В триггере, запускаемом оператором DELETE, имеет смысл обращаться только к старым значениям столбцов. Поскольку удаленная строка перестает существовать, новым значением всегда будет NULL. Однако значения :NEW нельзя модифицировать. Если вы попытаетесь это сделать, будет выдано сообщение об ошибке ORA-4084.

• В теле триггера не рекомендуется использовать операторы ROLLBACK, COMMIT и SAVEPOINT.

• При возникновении необрабатываемых исключений производится откат всех изменений, включая те, которые были выполнены запускающим оператором.

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

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

Пример операторного триггера для фиксации удалений из таблицы employees

Создание таблицы для записи логов.

CREATE TABLE emp_log

(

date_changed DATE,

changed_by VARCHAR2(30),

comment VARCHAR2(30)

);

CREATE OR REPLACE TRIGGER stat_emp

AFTER DELETE

ON employees

BEGIN

INSERT INTO emp_log

VALUES (SYSDATE, USER, ‘Удаление из таблицы employees’);

END;

Пример строчного триггера для фиксации изменений поля salary таблицы employees:

Создание таблицы для записи логов.

CREATE TABLE salary_log

(

id NUMBER,

old_salary NUMBER(9,2),

new_salary NUMBER(9,2),

date_changed DATE,

changed_by VARCHAR2(30)

);

CREATE OR REPLACE TRIGGER row_emp

AFTER UPDATE OF salary

ON employees

FOR EACH ROW

BEGIN

INSERT INTO pay_change_log

VALUES (:old. employee_id, :old. salary, :new. salary, SYSDATE, USER );

END;

Пример строчного триггера для фиксации изменений поля salary таблицы employees с использованием триггерного ограничения:

CREATE OR REPLACE TRIGGER row_emp

AFTER UPDATE OF salary

ON employees

FOR EACH ROW

WHEN (new. department_id = 50)

BEGIN

INSERT INTO pay_change_log

VALUES ( :old. employee_id, :old. salary, :new. salary, SYSDATE, USER );

END;

Данный триггер будет срабатывать только для department_id = 50.

Триггер INSTEAD OF

Триггер INSTEAD OF (вместо) используется для представлений (view).

Пример использования триггера INSTEAD OF:

- Создаем представление по таблице employees:

CREATE VIEW name_view (id, name) AS

SELECT id, last_name || ',' || first_name

FROM employees

ORDER BY 1

- При попытке вставить запись в представление выдается ошибка:

INSERT INTO name_view

VALUES (emp_seq. nextval, 'Иванов, Петр')

- Определяем на представление триггер типа INSTEAD:

CREATE OR REPLACE TRIGGER name_trig

INSTEAD OF INSERT ON name_view

FOR EACH ROW

DECLARE

last VARCHAR2(25);

first VARCHAR2(15);

comma_pos NUMBER;

BEGIN

comma_pos := INSTR(:new. name, ',');

last := SUBSTR(:new. name, 1, comma_pos - 1);

first := SUBSTR(:new. name, comma_pos + 1);

INSERT INTO employees (employee_id, last_name, first_name)

VALUES (:new. id, last, first);

END;

- Вновь пытаемся вставить запись:

INSERT INTO name_view

VALUES (person_id_seq. nextval, 'Иванов, Петр');

Команда INSERT выполнилась успешно. Запись вставилась в таблицу employees.

Ограничения триггеров INSTEAD OF:

·  Используются только для представлений (не таблиц)

·  Переменные :OLD и :NEW можно использовать только для чтения (read-only).

·  Нельзя использовать опцию UPDATE [OF columns]

Системные триггера

Системные триггера на базу данных или схему определяются для следующих событий:

- команды DDL,

- старт базы данных (STARTUP) и останов базы данных (SHUTDOWN),

- ошибки сервера (SERVERERROR), начала сеанса пользователя (LOGON) и окончание сеанса пользователя (LOGOFF).

Синтаксис для определения системного триггера:

CREATE OR REPLACE TRIGGER triggername

{BEFORE | AFTER} {event(s)}

ON {SCHEMA | DATABASE}

…

Для создания системных триггеров необходима системная привилегия ADMINISTER DATABASE TRIGGER.

Пример системного триггера на команды DDL CREATE и ALTER:

CREATE OR REPLACE TRIGGER ddl_trig

BEFORE CREATE OR ALTER

ON SCHEMA

BEGIN

INSERT INTO ddl_log

VALUES (ORA_DICT_OBJ_OWNER, ORA_DICT_OBJ_NAME, ORA_DICT_OBJ_TYPE, ORA_LOGIN_USER, SYSDATE);

END;

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

- При обработке события CREATE:

ora_sysevent

ora_login_user

ora_instance_num

ora_database_name

ora_dict_obj_name

ora_dict_obj_owner

ora_dict_obj_type

ora_is_creating_nested_table

- При обработке события ALTER:

ora_sysevent

ora_login_user

ora_instance_num

ora_database_name

ora_dict_obj_type

ora_dict_obj_name

ora_dict_obj_owner

ora_des_encrypted_password

ora_is_alter_column

ora_is_drop_column

- При обработке события DROP:

ora_sysevent

ora_login_user

ora_instance_num

ora_database_name

ora_dict_obj_type

ora_dict_obj_name

ora_dict_obj_owner

- При обработке события GRANT:

ora_sysevent

ora_login_user

ora_instance_num

ora_database_name

ora_dict_obj_name

ora_dict_obj_type

ora_dict_obj_owner

ora_grantee

ora_with_grant_option

ora_privileges

- При обработке любой команды DDL:

ora_sysevent

ora_login_user

ora_instance_num

ora_database_name

ora_dict_obj_name

ora_dict_obj_type

ora_dict_obj_owner

- При обработке события RENAME:.

ora_sysevent

ora_login_user

ora_instance_num

ora_database_name

ora_dict_obj_name

ora_dict_obj_owner

ora_dict_obj_type

- При обработке событий AFTER LOGON и BEFORE LOGOFF:

ora_login_user

ora_instance_num

ora_database_name

Синонимы

Синоним (synonym) позволяет ссылаться на объект Oracle по имени, которое отличается от его настоящего имени. Синонимы можно определять для таблиц, представлений, последовательностей, функций, процедур и пакетов. Если вы часто ссылаетесь на таблицу с длинным именем, то по достоинству оцените возможность использования короткого имени без переименования таблицы и изменения кода, который на нее ссылается. Удобство синонимов проявляется и в том, что они могут облегчить доступ к вашим данным для других людей. Таблицы организуются по идентификатору пользователя Oracle, который их создает, поэтому если другой пользователь захочет обращаться к таблице, созданной вами, то в общем случае ему придется помещать перед именем таблицы ваше имя пользователя, как показано ниже:

SELECT * FROM ваше_имя_пользователя. имя_вашей_таблицы;

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

Команда создания синонима имеет следующий синтаксис:

CREATE [PUPLIC] SYNONYM имя_синонима FOR имя объекта

PUBLIC создает синоним, доступный всем пользователям базы данных.

Пример создания синонима:

CREATE PUPLIC SYNONYM emp FOR hr. employees;

Теперь все пользователи базы данных могут обращаться к таблице employees из схемы hr по имени emp.

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

Последовательности

Последовательности (sequence) – это объект базы данных, который может быть использован многими пользователями для генерации уникальных целых чисел. Обычно последовательности используются для генерации значений главного ключа. Генерация последовательности с приращением (или уменьшением) осуществляется внутренней программой Oracle. Этот объект базы данных может сэкономить время, так как замещает код, который потребовался бы для обеспечения уникальности чисел в прикладной программе. Числа последовательности хранятся и генерируются независимо от таблиц. Следовательно, одна и та же последовательность может одновременно использоваться для нескольких таблиц.

Пример создания последовательности emp_seq для использования в качестве главного ключа таблицы employees:

CREATE OR REPLACE emp_seq

INCREMENT BY 10

START WITH 120

MAXVALUE

MINVALUE 10

NOCACHE

NOCYCLE;

Последовательность начинается с 120, шаг 10, кэширование и циклическая генерация значений запрещены. Максимальное значение данной последовательности.- (может содержать до 28 цифр для возрастающей последовательности).

Установка Unlimited в качестве MINVALUE для убывающей последовательности соответствует -10 в 26 степени.

Обратиться к значениям последовательности можно с помощью псевдостолбцов NEXTVAL и CURRVAL. Псевдостолбец NEXTVAL используется для выборки следующего свободного числа последовательности. В результате выполнения emp_seq. NEXTVAL генерируется новое число, а текущее число помещается в CURRVAL. Псевдостолбец CURRVAL используется для ссылки на числов последовательности, только что сгенерированное текущим пользователем. Прежде, чем ссылаться на CURRVAL, необходимо использовать NEXTVAL для генерации числа в текущем сеансе пользователя. Псевдостолбцы NEXTVAL и CURRVAL могут использоваться в следующих командах и предложениях:

- Список SELECT команды SELECT, не являющейся частью подзапроса.

- Список SELECT подзапроса в команде INSERT.

- Предложение VALUES команды INSERT.

- Предложение SET команды UPDATE.

Псевдостолбцы NEXTVAL и CURRVAL не могут использоваться в следующих командах и предложениях:

- Список SELECT представления.

- Команда SELECT с ключевым словом DISTINCT.

- Команда SELECT с предложениями GROUP BY, HAVING или ORDER BY.

- Подзапрос в команде SELECT, DELETE или UPDATE.

- Выражение DEFAULT в команде CREATE TABLE или ALTER TABLE.

Примеры использования последовательности:

INSERT INTO employees (employee_id, last_name, department_id)

VALUES (emp_seq. NEXTVAL, ‘Иванов’, 50);

SELECT emp_seq. NEXTVAL FROM dual;

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

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

Импорт, экспорт и загрузка данных

Утилиты IMP и EXP

Утилиты командной строки IMP (для импорта) и EXP (для экспорта) используются для извлечения таблиц, схем или всей базы данных из одного экземпляра Oracle для дальнейшего импортирования в другой экземпляр или схему. Утилита ЕХР создает двоичный файл специфического формата, который также называют файлом дампа (и часто сокращенно ссылаются на него как на DMP). На выполнение утилиты запускаются из командной строки.

Вызов справки по утилитам EXP и IMP из командной строки:

EXP HELP =Y

IMP HELP=Y

Пример простейшего экспорта одной таблицы из схемы scott в файл c:/EXP/emp. dmp с записью файла журналирования = c:/EXP/emp. log:

EXP USERID=scott/*****@***TABLES=emp FILE=c:/EXP/emp. dmp LOG= c:/EXP/emp. log

Некоторые параметры утилиты Exp:

BUFFER (по умолчанию – зависит от ОС) - Этот параметр задает размер буфера извлечения, используемого утилитой ЕХР. Если поделить значение параметра BUFFER на максимальный размер строки в этой таблице, можно определить, сколько строк за раз будет извлекать из таблицы утилита ЕХР. Чем больше размер буфера, тем выше производительность. Некоторые таблицы, в частности, содержащие столбцы типа LONG или большие двоичные объекты, считываются по одной строке, независимо от размера буфера. Нужно только проверить, достаточен ли размер буфера для размещения самого большого столбца.

COMPRESS (по умолчанию = Y) - Этот параметр не задает сжатие экспортированных данных. Он управляет генерацией конструкции STORAGE для экспортируемых объектов. Если оставить значение Y, конструкция хранения будет задавать для объектов начальный экстент, размер которого равен суммарному размеру их текущих экстентов. Т. е. утилита ЕХР будет генерировать оператор CREATE и с его помощью попытаться поместить весь объект в одном экстенте.

ROWS - Указывает утилите ЕХР, следует экспортировать ли строки данных таблиц или только структуру.

FILESIZE - Если имеет положительное значение, файл DMP, создаваемый утилитой экспорта, устанавливается в максимальный размер. Используется при экспорте более двух гигабайт данных.

QUERY - Позволяет связывать конструкцию WHERE с экспортируемыми таблицами. Конструкция WHERE будет применяться к строкам в ходе экспорта на уровне таблиц, при этом будут экспортироваться только строки, удовлетворяющие конструкции WHERE. Это позволяет экспортировать "срез" таблицы.

FULL (по умолчанию = N) - Если имеет значение Y, экспортируется вся база данных. При этом выбираются все пользователи, определения табличных пространств, системные привилегии и остальное содержимое базы данных.

OWNER - Позволяет задать список схем для экспорта.

TABLES - Позволяет задать список экспортируемых таблиц.

PARFILE - Задает имя файла параметров, содержащего пары parameter_name = values. Может использоваться как альтернативный вариант заданию всех параметров в командной строке. Чаще всего используется для задания длинных списков экспортируемых таблиц или параметра QUERY.

CONSISTENT (по умолчанию =N) - Указывает, должно ли экспортирование выполняться в транзакции только для чтения. Это гарантирует согласованность различных таблиц. Транзакция только для чтения (или с уровнем изолированности SERIALIZABLE) распространяет согласованность по чтению до уровня транзакции. Если экспортируются таблицы, связанные декларативным требованием целостности ссылок (Rl - Referential Integrity) или вложенные таблицы и в дальнейшем планируется импортировать их вместе, рекомендуется использовать параметр consistent = Y. Это особенно важно, если велика вероятность изменения таблиц при экспортировании.

TRANSPORT_ TABLESPACE (по умолчанию = N) - Указывает, будет ли утилита ЕХР использоваться для экспортирования метаданных набора переносимых табличных пространств.

TABLESPACES (по умолчанию = N) - Используется совместно с параметром TRANSPORT_TABLESPACE, чтобы задать список табличных пространств для переноса.

Пример простейшего импорта данных из файла c:/EXP/emp. dmp с записью файла журналирования = c:/EXP/emp_i. log в схему scott:

EXP USERID=scott/*****@***FILE=c:/EXP/emp. dmp LOG= c:/EXP/emp. log

Некоторые параметры утилиты Imp:

SHOW (по умолчанию = N) - Если установлено значение Y, утилита импорта покажет свои потенциальные действия, не выполняя импортирование реально. Если задан параметр SHOW = Y, объекты не создаются и данные не добавляются.

IGNORE (по умолчанию = N) - Если установлено значение Y, IMP будет игнорировать большинство ошибок создания объектов. Пригодится, если объекты уже созданы в базе данных и IMP используется только для наполнения таблиц данными.

INDEXFILE - Если этот параметр задан, IMP будет сбрасывать все операторы CREATE INDEX и множество других операторов в указанный файл индексов (с комментариями в начальных строках, начинающихся с REM). Другие объекты из файла DMP не обрабатываются, создается только файл индексов.

FROMUSER - С помощью этого параметра задают список пользователей, объекты которых надо импортировать из файла DMP. Можно использовать для восстановления одной схемы из файла экспорта всей базы данных.

TOUSER - Если этот параметр указан, объекты пользователя, задаваемого параметром FROMUSER, импортируются в пользовательскую схему, имя которой является значением параметра TOUSER. Это позволяет "клонировать" пользовательскую схему.

COMMIT (по умолчанию = N) - Указывает, должна ли утилита IMP фиксировать изменения после каждой множественной вставки. Количество вставляемых строк определяется параметром BUFFER. Обычно утилита IMP выполняет COMMIT после полной загрузки таблицы. Поскольку операторы вставки генерируют минимальный объем данных отката, при частом фиксировании замедляется вставка и увеличивается объем информации, записываемой в журналы повторного выполнения. Кроме того, продолжить работу IMP с места сбоя нельзя, поэтому я рекомендуется оставлять для параметра значение N.

TTS_OWNERS - При использовании вместе с параметром TRANSPORTABLE_TABLESPACES задает список владельцев объектов в переносимом табличном пространстве.

Утилиты Data Pump

Утилита Data Pump выполняется на стороне сервера, а не на клиенте. Поэтому доступ к dump-файлам, файлам журналов операций и SQL файлам осуществляется через пути к директориям на стороне сервера. Утилита Data Pump требует, чтобы пути к директориям задавались с помощью объектов DIRECTORY. Такие объекты хранят путь к каталогу в файловой системе. Для создания объекта DIRECTORY используется команда

CREATE DIRECTORY. Объект DIRECTORY определяет псевдоним (алиас) каталога файловой системы сервера. Чтобы создать этот объект, необходимо иметь системную привилегию CREATE ANY DIRECTORY. Пользователю, создающему объект DIRECTORY, автоматически предоставляются объектные привилегии READ и WRITE на этот объект, которые он может передать другим пользователям и ролям.

Пример создания объекта DIRECTORY:

CREATE DIRECTORY dmpdir AS ‘c:/Pump/kurs’;

Oracle не проверяет, действительно ли существует каталог в файловой системе.

Описание объекта DIRECTORY можно вывести из представления DBA_ DIRECTORY.

Утилита Data Pump Export предоставляет возможность высокоскоростного переноса данных их одной базы данных в другую. Например, можно экспортировать данные из одной базы данных, а затем утилитой Data Pump Import загрузить их в другую базу данных. Утилиты Data Pump можно вызвать из Enterprise Manager или из командной строки.

Вызов справки по утилитам Data Pump из командной строки:

EXPDP HELP=Y

IMPDP HELP=Y

Пример выгрузки всех объектов из схемы scott в файл scott. dmp, который будет находиться в каталоге, определенном объектом DIRECTORY=dmpdir:

EXPDP scott/*****@***DUMPFILE=scott. dmp DIRECTORY=dmpdir SCHEMAS=scott

Пример загрузки данных из файла в схему scott:

IMPDP scott/*****@***DIRECTORY=dmpdir DUMPFILE=scott. dmp

Кроме экспорта схемы (SCHEMAS) можно выгружать всю базу данных (FULL=y),отдельные таблицы (TABLES= список таблиц).

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

SQL*Loader

Инструментальное средство SQL*Loader (SQLLDR) - высокопроизводительное средство массовой загрузки данных в СУБД Oracle. Это очень полезное средство, позволяющее поместить в базу данных Oracle данные из текстовых файлов множества различных форматов. Утилиту SQLLDR можно использовать для потрясающе быстрой загрузки огромных объемов данных. Она имеет два режима работы:

• Обычная загрузка. В этом режиме SQLLDR для загрузки данных будет автоматически вставлять строки с помощью SQL-операторов.

• Непосредственная загрузка. В этом режиме SQL не используется. Блоки данных в базе формируются непосредственно.

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

При вызове SQLLDR из командной строки без параметров выдается справочная информация:

SQLLDR

Назначение некоторых параметров:

BAD - имя файла, который будет содержать отвергнутые записи по окончании загрузки. Если не указать его имя явно, оно будет создано автоматически по имени управляющего (CONTROL) файла использованного для загрузки. Например, если в качестве управляющего использован файл foo. ctl, файл BAD по умолчанию получит имя foo. bad; именно в этот файл и будет помещать отвергнутые записи утилита SQLLDR (если файл существует, он будет перезаписан).

BINDSIZE - размер (в байтах) буфера, используемого утилитой SQLLDR для вставки данных при обычной загрузке. При непосредственной загрузке этот параметр не используется. Размер буфера используется для определения размера массива, с помощью которого SQLLDR будет вставлять данные.

CONTROL - имя управляющего (CONTROL) файла, описывающего формат данных и способ их загрузки в таблицу. Управляющий файл необходимо указывать при каждом вызове SQLLDR.

DATA - имя файла, из которого надо считывать данные.

DIRECT - допустимы значения True (непосредственная загрузка) и False (обычная загрузка), причем по умолчанию используется False. Таким образом, по умолчанию утилита SQLLDR выполняет обычную загрузку.

DISCARD - имя файла, куда помещаются пропущенные записи, которые не должны загружаться. Утилиту SQLLDR можно использовать для фильтрования загружаемых записей - она позволяет загружать только записи, удовлетворяющие указанным критериям.