Oracle. Программирование

1 ... 135 136 137 [ 138 ] 139 140 141 ... 469

Импорт и экспорт 443

клиента, с которого запускается IMP, и клиента, с которого выполняется ЕХР;

клиента, с которого запускается IMP, и базы данных, в которую выполняется им-

порт.

Если в любой паре наборы символов различаются, данные могут оказаться поврежденными. Рассмотрим весьма тривиальный (но типичный) пример:

ops$tkyte@DEV816> create table t (с varchar2(1)); Table created.

ops$tkyte@DEV816> insert into t values (chr(235)); 1 row created.

ops$tkyte@DEV816> select dump(c) from t; DUMP(C)

Typ=l Len=l: 235

ops$tkyte@DEV816> commit; Commit complete.

Пока все хорошо. Теперь займемся экспортом:

Connected to: Oracle8i Enterprise Edition Release 8.1.6.2.0 - Production

With the Partitioning option

JServer Release 8.1.6.2.0 - Production

Export done in US7ASCII character set and US7ASCII NCHAR character set server uses WE8ISO8859P1 character set (possible charset conversion)

About to export specified tables via Conventional Path . . .

. exporting table T 1 rows

exported

Export terminated successfully without warnings.

Это сообщение (possible charset conversion) должно насторожить! Мы только что взяли 8-битовые данные и экспортировали их в 7-битовый набор символов. Теперь давайте попытаемся импортировать эти данные обратно:

Connected to: Oracle8i Enterprise Edition Release 8.1.6.2.0 - Production

With the Partitioning option

JServer Release 8.1.6.2.0 - Production

Глава 8

Export file created by EXPORT:V08.01.06 via conventional path import done in US7ASCII character set and US7ASCII NCHAR character set import server uses WE8ISO8859P1 character set (possible charset conversion) . importing OPS$TKYTEs objects into OPS$TKYTE

. . importing table T 1 rows

imported

Import terminated successfully without warnings. ops$tkyte@DEV816> select dump(c) from t; DUMP(C)

Typ=l Len=l: 235

Typ=l Len=l: 101

Функция DUMP показывает, что данные, взятые из таблицы и снова в нее помещенные, различаются. Это станет понятнее, если представить числа в двоичном виде:

235 а десятичной системе = 11101011 в двоичной 101 в десятичной системе = 01100101 в двоичной

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

Если выдается упомянутое выше сообщение, остановитесь и подумайте о последствиях. В моем случае решение простое. В ОС UNIX или NT достаточно установить значение переменной среды NLS LANG так, чтобы оно соответствовало базе данных:

$ echo $NLS LANG AMERICAN AMERICA.WE8ISO8859P1

Теперь ни ЕХР, ни IMP не будет преобразовывать набор символов. Кроме того, эти утилиты будут заметно быстрее работать. В ОС Windows NT/2000 значение NLSLANG можно также задать в реестре.

Таблицы, расположенные в нескольких табличных пространствах

Первоначально операторы CREATE TABLE б]ли сравнительно простыми. С годами они все более усложнялись. Синтаксическая диаграмма для простого оператора CREATE TABLE сейчас занимает восемь страниц. Одно из новейших свойств таблиц - возможность разместить их по частям в нескольких табличных пространствах. Например, таблица со столбцом типа CLOB будет иметь сегмент таблицы, сегмент индекса CLOB и сегмент данных CLOB. Можно явно задать местонахождение таблицы и местонахождение данных столбца типа CLOB. Таблица, организованная по индексу, может иметь сегмент индекса и дополнительный сегмент. Фрагментированные таблицы могут состоять из множества фрагментов, каждый из которых располагается в отдельном табличном пространстве.

Это создает определенные трудности для утилит экспорта и импорта. Если попытка импорта объекта завершится неудачно из-за отсутствия табличного пространства или ис-

Импорт и экспорт 445

черпания квоты в этом табличном пространстве, утилита IMP автоматически так изменит SQL-операторы, чтобы объект создавался в стандартном табличном пространстве пользователя. Утилита IMP не будет этого делать для объектов, расположенных в нескольких табличных пространствах, даже если все табличные пространства, заданные в команде CREATE, совпадают. Следующий пример это демонстрирует, а затем я опишу, как обойти проблему.

Начнем со схемы, имеющей объекты в нескольких табличных пространствах, и одну простую таблицу, расположенную в одном пространстве:

tkyte@TKYTE816> create tablespace exp test

2 datafile c:\oracle\oradata\tJcyte816\exp test.dbf

3 size 1m

4 extent management local

5 uniform size 64k

Tablespace created.

tkyte@TKYTE816> alter user tkyte default tablespace exp test

2 / User altered.

tkyte@TKYTE816> create table tl

2 (x int primary key, у varchar2 (25))

3 organization index

4 overflow tablespace exp test

5 / Table created.

tkyte@TKYTE816> create table t2

2 (x int, у clob)

3 / Table created.

tkyte@TKYTE816> create table t3

2 (x int ,

3 a int default to char(sysdate,d)

5 PARTITION BY RANGE (a)

7 PARTITION part l VALUES LESS THAN(2) ,

8 PARTITION part 2 VALUES LESS THAN(3),

9 PARTITION part 3 VALUES LESS THAN(4),

10 PARTITION part 4 VALUES LESS THAN(5),

11 PARTITION part 5 VALUES LESS THAN(6),

12 PARTITION part 6 VALUES LESS THAN(7) ,

13 PARTITION part 7 VALUES LESS THAN(8)

14 )

15 / Table created.

tkyte@TKYTE816> create table t4 (x int)

2 / Table created.

1 ... 135 136 137 [ 138 ] 139 140 141 ... 469