1 ноября 2000 г.

Доклад на XII конференции ROUG

Валерий Юринский,
ORACLE Certified Professional
("ТалгаP", г.Москва)

Сервер Oracle8i предоставляет новую возможность быстрого обмена большими объемами информации между базами данных Oracle – перемещаемые табличные пространства (transportable tablespaces). Некоторым аспектам практического применения этой возможности посвящена эта статья.

Как всегда возникают вопросы:

Вот лишь некоторые ответы. Перемещаемые табличные пространства обеспечивают:

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

Существует ряд условий ограничивающих применение описываемой возможности.

1) "Донором" может быть только Oracle8i Enterprise Edition. "Приёмником" – любой вариант сервера Oracle8i: Enterprise/Standard/Personal Edition.

Проверить поддерживает ли ваша система создание набора перемещаемых табличных пространств можно выполнив запрос:

SELECT * FROM v$option

WHERE UPPER(parameter) =
'EXPORT TRANSPORTABLE TABLESPACES'

/

Все в порядке, если в результате будет получено:

PARAMETER VALUE

-------------------------------- -----

Export transportable tablespaces TRUE

2) Можно перемещать табличные пространства только между такими базами данных Oracle8i, которые:

Удовлетворение первых трех требований можно проверить, выполнив в исходной и целевой БД (результаты должны быть идентичны) запрос:

SELECT name, value FROM v$parameter

WHERE name IN ('db_block_size','compatible')

UNION ALL

SELECT parameter, value FROM nls_database_parameters

WHERE parameter LIKE '%CHARACTERSET'

/

NAME VALUE

--------------------- ------------

db_block_size 4096

compatible 8.1.0

NLS_CHARACTERSET CL8MSWIN1251

NLS_NCHAR_CHARACTERSET CL8MSWIN1251

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

4) Не поддерживается транспортировка:

Предположим, что нам нужно перенести данные таблицы EMP, созданной следующим образом:

DROP TABLE emp

/

DROP TABLE dept

/

CREATE TABLE dept (

deptno NUMBER(2)

, dname VARCHAR2(14) CONSTRAINT dept#N#dname NOT NULL

, loc VARCHAR2(13) CONSTRAINT dept#N#loc NOT NULL

, CONSTRAINT dept#p PRIMARY KEY(deptno)

USING INDEX TABLESPACE indx

)

/

GRANT SELECT, INSERT, UPDATE, DELETE ON
dept TO emp_manager

/

CREATE TABLE emp (

empno NUMBER(4)

, ename VARCHAR2(10) CONSTRAINT emp#N#ename NOT NULL

, job VARCHAR2(9) CONSTRAINT emp#N#job NOT NULL

, mgr NUMBER(4)

, hiredate DATE CONSTRAINT emp#N#hiredate NOT NULL

, sal NUMBER(7,2) CONSTRAINT emp#N#sal NOT NULL

, comm NUMBER(7,2)

, deptno NUMBER(2) CONSTRAINT emp#N#deptno NOT NULL

, CONSTRAINT emp#p PRIMARY KEY (empno)

USING INDEX TABLESPACE indx

, CONSTRAINT emp#r#dept FOREIGN KEY (deptno)

REFERENCES dept(deptno)

, CONSTRAINT emp#r#emp FOREIGN KEY (mgr)

REFERENCES emp(empno)

)

/

GRANT SELECT, INSERT, UPDATE, DELETE
ON emp TO emp_manager

/

CREATE TRIGGER emp#BIU#R

BEFORE INSERT OR UPDATE ON EMP FOR EACH ROW

BEGIN

:NEW.ename := UPPER(:NEW.ename);

END;

/

Самодостаточный (self-contained) набор табличных пространств – это совокупность табличных пространств, объекты которых не ссылаются на какие-либо объекты, не содержащиеся в данном наборе. В качестве примеров нарушений самодостаточности можно привести случаи, когда:

Для проверки самодостаточности удобно использовать процедуру TRANSPORT_SET_CHECK из пакета SYS.DBMS_TTS (общего синонима нет). Пользователю должна быть предоставлена роль EXECUTE_CATALOG_ROLE (изначально такая роль предоставлена SYS).

BEGIN

sys.dbms_tts.transport_set_check (

-- Список табличных пространств

ts_list => 'USER_DATA'

-- Учитывать ссылочные ограничения

, incl_constraints => TRUE);

END;

/

Результаты ее работы записываются во временную таблицу и их можно посмотреть через системное представление SYS.TRANSPORT_SET_VIOLATIONS (общего синонима также нет):

SELECT * FROM sys.transport_set_violations

/

VIOLATIONS

---------------------------------

[1] Constraint EMP#N#ENAME between table SCOTT.DEPT
in tablespace USERS and table SCOTT.EMP
in tablespace USER_DATA

[2] Constraint EMP#N#JOB between table SCOTT.DEPT
in tablespace USERS and table SCOTT.EMP
in tablespace USER_DATA

[3] Constraint EMP#N#HIREDATE between table SCOTT.DEPT
in tablespace USERS and table SCOTT.EMP
in tablespace USER_DATA

[4] Constraint EMP#N#SAL between table SCOTT.DEPT
in tablespace USERS and table SCOTT.EMP
in tablespace USER_DATA

[5] Constraint EMP#N#DEPTNO between table SCOTT.DEPT
in tablespace USERS and table SCOTT.EMP
in tablespace USER_DATA

[6] Constraint EMP#P between table SCOTT.DEPT
in tablespace USERS and table SCOTT.EMP
in tablespace USER_DATA

[7] Constraint EMP#R#DEPT between table SCOTT.DEPT
in tablespace

USERS and table SCOTT.EMP
in tablespace USER_DATA

[8] Constraint EMP#R#EMP between table SCOTT.DEPT
in tablespace USERS and table SCOTT.EMP
in tablespace USER_DATA

Выявленные нарушения 1-5 и 8 вызывают некоторое недоумение, поскольку связаны с ограничениями типа NOT NULL таблицы EMP, ее первичным ключом и ссылкой самой на себя, что вроде бы никак не связанно с табличными пространствами, отличными USER_DATA (может быть это оттого, что сведения о них хранятся в словаре данных? J).

Если вы получите сообщение вида:

Master table SCOTT.EMP in tablespace USER_DATA
not allowed in transportable set

ищите снапшот, использующий указанную таблицу.

Диагностика подобная:

Partitioned table SCOTT.ORDER_DETAILS is partially
contained in the transportable set

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

Нарушение 7 напоминает о том, что EMP имеет ссылку на таблицу DEPT, поэтому добавим в список табличное пространство USERS, в котором создана DEPT:

BEGIN

sys.dbms_tts.transport_set_check (

ts_list => 'USER_DATA, USERS',

incl_constraints => TRUE);

END;

/

Выборка из SYS.TRANSPORT_SET_VIOLATIONS не возвращает строк, то есть все в порядке. Однако, если вы хотите перенести и индексы (возможно не все), то для выявления таблиц, имеющих индексы, расположенные в табличных пространствах, не входящих в набор, подлежащий транспортировке выполните:

SELECT table_name, tablespace_name FROM dba_indexes

WHERE table_name IN

(SELECT table_name FROM dba_tables

WHERE tablespace_name IN ('USER_DATA','USERS'))

MINUS

SELECT table_name, tablespace_name FROM dba_tables

WHERE tablespace_name NOT IN ('USER_DATA','USERS')

/

Для данного примера в результате получим:

TABLE_NAME TABLESPACE_NAME

---------- ---------------

EMP INDX

DEPT INDX

Внимание! Для секционированных (partitioned) таблиц и индексов, а также для индекс-таблиц (index organized tables), запрос следует модифицировать с учетом соответствующих представлений словаря данных!

На этом этапе будет также уместным определить:

SELECT tablespace_name, file_name

FROM dba_data_files

WHERE tablespace_name IN ('USER_DATA','USERS', 'INDX')

ORDER BY tablespace_name, file_name

/

TABLESPACE_NAME FILE_NAME

--------------- -----------------------------------

INDX D:ORACLE81ORADATAVSUIMBINDX01.ORA

USERS D:ORACLE81ORADATAVSUIMBUSERS01.ORA

USER_DATA D:ORACLE81ORADATAVSUIMBUSER_DATA_01.ORA

SELECT owner, segment_type, COUNT(*) AS cnt

FROM dba_segments

WHERE tablespace_name IN ('USER_DATA','USERS', 'INDX')

GROUP BY owner, segment_type

/

OWNER SEGMENT_TYPE CNT

----- ------------ -------

SCOTT INDEX 2

SCOTT TABLE 2

SYSTEM TABLE 1

TOAD INDEX 4

TOAD TABLE 3

SELECT DISTINCT P.owner AS table_owner

, P.grantee

, DECODE(U.type#, 0, 'ROLE', 1, 'USER') as grantee_type

FROM dba_tab_privs P, sys.user$ U

WHERE (P.owner, P.table_name) IN

(SELECT owner, segment_name

FROM dba_segments

WHERE tablespace_name IN ('USER_DATA','USERS', 'INDX'))

AND P.grantee = U.name

/

TABLE_OWNER GRANTEE GRANTEE_TYPE

----------- ------------ ------------

SCOTT EMP_MANAGER ROLE

SYSTEM PUBLIC ROLE

TOAD PUBLIC ROLE

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

SELECT DISTINCT owner AS trigger_owner

, table_owner

FROM dba_triggers

WHERE (table_owner, table_name) IN

(SELECT owner, segment_name

FROM dba_segments

WHERE tablespace_name IN ('USER_DATA','USERS', 'INDX'))

AND owner <> table_owner

/

что может в результате дать, например:

TRIGGER_OWNER TABLE_OWNER

------------- -----------

FILER SCOTT

1. Сначала следует перевести табличные пространства набора в состояние ТОЛЬКО ЧТЕНИЕ (READ ONLY):

ALTER TABLESPACE user_data READ ONLY;

ALTER TABLESPACE users READ ONLY;

ALTER TABLESPACE indx READ ONLY;

2. Затем с помощью утилиты EXP экспортируются метаданные словаря. Например:

EXP TRANSPORT_TABLESPACE=Y
TABLESPACES=(USERS, USER_DATA, INDX) TRIGGERS=Y
CONSTRAINTS=Y GRANTS=Y FILE=exp_tts log=exp_tts

Параметры:

При запросе имени, согласно документации, следует подключаться к базе данных как SYSDBA:

Username: SYS@VSUIMB AS SYSDBA

Password:

Впрочем, USERID=SYS@VSUIMB AS SYSDBA, как и все прочие параметры можно задать в отдельном файле параметров, указав его при вызове утилиты (EXP PARFILE=file_name.par). Кроме того, натурные испытания показали, что на данном этапе подключаться как SYSDBA вовсе не обязательно – достаточно роли DBA.

3. Сделать копии файлов данных в другое место на той же вычислительной установке или на транспортируемый носитель или на машину, где расположена целевая БД.

4. Не забудьте перевести табличные пространства назад в состояние ЧТЕНИЕ-ЗАПИСЬ (Если это необходимо для продолжения нормальной работы пользователей исходной БД):

ALTER TABLESPACE user_data READ WRITE;

ALTER TABLESPACE users READ WRITE;

ALTER TABLESPACE indx READ WRITE;

Этот шаг предельно прост.

Переносим копии файлов данных и файл, полученный утилитой экспорта, в место, доступное целевой базе данных. Это можно сделать любым доступным способом: утилитой ОС, по FTP, публикацией на неперезаписываемом носителе и т.п.

Содержимое файла экспорта метаданных можно посмотреть с помощью команды:

IMP TRANSPORT_TABLESPACE=Y FILE=exp_tts log=list_tts
indexfile=list_tts show=Y

В фрагменте полученного файла list_tts.sql, содержащем информацию о таблице DEPT обнаруживаем неописанные в документации служебные метапараметры SEG_FILE, SEG_BLOCK и OBJNO_REUSE:

REM CREATE TABLE "SCOTT"."DEPT" ("DEPTNO" NUMBER(2, 0),

REM "DNAME" VARCHAR2(14) CONSTRAINT "DEPT#N#DNAME"

REM NOT NULL ENABLE, "LOC" VARCHAR2(13)

REM CONSTRAINT "DEPT#N#LOC" NOT NULL ENABLE)

REM PCTFREE 10 PCTUSED 40 INITRANS 1

REM MAXTRANS 255 LOGGING

REM STORAGE(SEG_FILE 3 SEG_BLOCK 2992 OBJNO_REUSE 14780

REM INITIAL 53248 NEXT 53248 MINEXTENTS 1

REM MAXEXTENTS 2147483645

REM PCTINCREASE 1 FREELISTS 1 FREELIST GROUPS 1

REM BUFFER_POOL DEFAULT) TABLESPACE "USERS" ;

Перед тем, как приступить собственно к подключению (plug-in) может потребоваться создание:

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

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

IMP PARFILE=imp_tts.par

Файл imp_tts.par:

USERID=SYS@SVORA AS SYSDBA

TRANSPORT_TABLESPACE=Y

DATAFILES=('G:ORACLE816ORADATASVORAPLUGINDX01.ORA',

'G:ORACLE816ORADATASVORAPLUGUSERS01.ORA',

'G:ORACLE816ORADATASVORAPLUGUSER_DATA_01.ORA')

TABLESPACES=(USERS,USER_DATA,INDX)

TTS_OWNERS=(SCOTT,SYSTEM,TOAD)

FROMUSER=(SCOTT,SYSTEM,TOAD)

TOUSER=(TIGER,MANAGER,PANDORA)

FILE=exp_tts.dmp

LOG=imp_tts.log

Здесь:

Транспортируемые табличные пространства предоставляют разработчикам возможность получить копию части данных производственной системы, тождественных не только по содержанию, но и по физическим характеристикам (фрагментация). Однако для этого в дополнение к перечисленному выше потребуется выполнить некоторые дополнительные действия. Дело в том, что при транспортировке метаданных не экспортируются представления (view), процедуры, функции, пакеты и др. Поэтому их нужно переносить отдельно. Для этого удобнее всего воспользоваться всё тем же экспортом-импортом. Допустим, что все интересующие нас объекты принадлежат схеме SCOTT. Тогда команда экспорта в из исходной БД могла бы выглядеть так:

EXP SCOTT/TIGER@VSUIMB FILE=scott_proc log=scott_proc ROWS=N

Воссоздадим недостающие объекты в целевой базе данных, воспользовавшись при импорте в схему TIGER командой:

IMP TIGER/KING@SVORA FILE=scott_proc log=scott_proc_IMP IGNORE=Y

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

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

Такие дела.