Предлагаемый в Oracle механизм переносимых табличных пространств (transportable tablespaces) представляет собой простой способ для эффективного перемещения между базами данных больших объемов данных за счет переноса файлов данных из одной базы в другую. Вместо того чтобы воссоздавать объекты, он позволяет перемещать большие объекты безо всяких усилий лишь за часть того времени, которое потребовалось бы потратить на их воссоздание в базе данных вручную. В Oracle настоятельно рекомендуют применять его везде, где только можно, так как он однозначно превосходит все остальные методы для перемещения данных между базами.
Процесс переноса табличных пространств подразумевает копирование всех файлов данных и импорт всей содержащейся в словаре данных информации о табличных пространствах из исходной базы данных в целевую. Из этого следует, что утилиты Data Pump Export и Import, которые описывались в предыдущих разделах, играют в механизме переносимых табличных пространств весьма существенную роль. Вдобавок может выполняться перенос табличных пространств индексов, которые имеют отношение к таблицам, что делает весь процесс переноса данных чрезвычайно быстрым. Вся операция будет занимать лишь немного больше того времени, которое бы потребовалось на выполнение копирования принадлежащих табличному пространству файлов данных в новое место через FTP, службу удаленного копирования или другой метод, например, утилиту копирования на ленту.
Сферы применения переносимых табличных пространств
Механизм transportable tablespaces (переносимых табличных пространств) в основном применяется в контексте хранилища данных, но может также использоваться и в контексте базы данных любого другого вида. Ниже перечислены некоторые наиболее важные сферы его применения.
- Перемещение данных из исходной базы (обычно базы данных OLTP) в хранилище данных (Data Warehouse).
- Перемещение данных из вспомогательной (промежуточной) базы в хранилище данных.
- Перемещение данных из хранилища в киоск данных (data mart).
- Восстановление содержимого табличного пространства на определенный момент в прошлом (Point-In-Time Recovery — PITR).
- Архивирование ретроспективных данных.
Перенос табличного пространства
Основные шаги, которые потребуется выполнить для переноса табличного пространства между двумя базами данных, перечислены ниже.
- Выбор табличного пространства, подлежащего транспортировке (и проверка того, чтобы не было никаких зависимостей с объектами в других табличных пространствах).
- Генерация набора переносимых табличных пространств.
- Выполнение импорта табличного пространства. Это подразумевает копирование файлов данных на целевой сервер и импорт связанных метаданных в целевую базу данных.
Давайте теперь рассмотрим каждый из этих шагов более подробно. Обратите внимание на то, что переносимое табличное пространство не должно существовать в целевой базе данных.
Выбор табличных пространств, подлежащих переносу
Главным условием, которое нужно соблюдать при переносе табличных пространств, является то, что набор выбираемых табличных пространств должен быть самодостаточным. Например, при наличии у таблиц в табличных пространствах каких-нибудь индексов, они должны обязательно содержаться в одном из табличных пространств переносимого набора. Ограничения ссылочной целостности, имеющиеся у объектов внутри переносимого табличного пространства, ни в коем случае не должны содержать ссылок на объекты, находящиеся за пределами этого табличного пространства.
Потребуется соблюдать и несколько других условий при импортировании табличных пространств, содержащих секционированные (partitioned) таблицы (узнать более подробно о которых можно в предлагаемом Oracle руководстве для администратора баз данных). Одним из способов удостовериться в том, что набор табличных пространств удовлетворяет условию самодостаточности, является применение пакета DBMS_TTS:
SQL> EXECUTE sys.dbms_tts.transport_set_check('sales01,sales02',true);
PL/SQL procedure successfully completed.
SQL>
Для выполнения процедуры TRANSPORT_SET_CHECK необходимы привилегии EXECUTE_CATALOG_ROLE. В этом примере процедура TRANSPORT_SET_CHECK не вернула никаких ошибок и тем самым показала, что оба табличных пространства — sales01 и sales02 — являются самодостаточными и, следовательно, кандидатами на перенос. Дополнительно удостовериться в этом можно, выполнив запрос к таблице transport_set_violations, в которой перечисляются все частично самодостаточные таблицы в табличном пространстве и все ссылки между объектами, которые относятся к другим табличным пространствам:
SQL> SELECT * FROM sys.transport_set_violations no rows selected SQL>
На заметку! Вместо того чтобы выполнять процедуру TRANSPORT_SET_CHECK, можно воспользоваться параметром TRANSPORT_FULL_CHECK во время экспорта и импорта Data Pump для указания того, что данный набор табличных пространств не имеет никаких зависимостей. Однако во время импорта в случае применения параметра TRANSPORT_FULL_CHECK потребуется также использовать и параметр NETWORK_LINK.
Генерация набора переносимых табличных пространств
Прежде чем транспортировать табличные пространства в целевую базу данных, нужно обязательно сгенерировать так называемый набор переносимых табличных пространств. В его состав входят все файлы данных из подлежащих переносу табличных пространств плюс экспортный файл дампа, содержащий всю информацию о структуре этих пространств из словаря данных.
Первое, что понадобится сделать перед тем, как переносить табличное пространство имен — это перевести его в режим только для чтения. При наличии активных транзакций, осуществляющих изменение таблиц, переносить табличное пространство нельзя. При желании экспортировать очень большую таблицу или часть какой-то большой таблицы, лучше создать новое табличное пространство и поместить в него новую таблицу с теми данными, которые представляют интерес, а затем уже спокойно переносить это табличное пространство в другую базу данных.
SQL> ALTER TABLESPACE sales01 READ ONLY; Tablespace altered. SQL> ALTER TABLESPACE sales02 READ ONLY; Tablespace altered. SQL>
На заметку! Переносить табличное пространство можно и без его предварительного перевода в режим только для чтения, но выполнение этого действия гарантирует, что тогда в этом табличном пространстве точно не будет выполняться никаких активных транзакций во время процесса его переноса.
После перевода обоих переносимых табличных пространств (sales01 и sales02) в режим только для чтения останется сделать только две вещи, чтобы сгенерировать набор переносимых табличных пространств: во-первых — использовать утилиту Data Pump Export, чтобы экспортировать для них обоих метаданные из словаря данных, а, во-вторых — физически скопировать все их файлы данных и экспортный файл дампа в такой каталог, к которому сможет получать доступ целевая база данных. Далее эти шаги рассматриваются более подробно.
Экспорт словарной информации (метаданных) для табличных пространств
Первый шаг в процессе создания набора переносимых табличных пространств предусматривает экспорт метаданных, описывающих объекты, из которых состоят такие табличные пространства. В этом отношении у механизма переносимых табличных пространств есть одно интересное свойство: каким бы большим не было табличное пространство, данный шаг выполняется очень быстро, потому что экспортируется только словарная информация об объектах (метаданные), а не сами содержащиеся в их строках данные. Еще есть возможность использовать параметр TTS_FULL_CHECK=Y, в случае чего утилита Data Pump Export будет проверять экспортируемые табличные пространства на предмет самодостаточности. В рассматриваемом примере, однако, соблюдение этого условия уже было проверено на предыдущем шаге, поэтому прибегать к использованию данного параметра нет никакой необходимости. В листинге ниже показано, как можно выполнить экспорт метаданных для табличных пространств sales01 и sales02.
[finance] $ expdp oe/oe DIRECTORY=dpump_dir1 DUMPFILE=sales.dmp
TRANSPORT_TABLESPACES=sales01,sales02 INCLUDE=triggers,constraint,grant
Import: Release 11.1.0.6.0 - Production on Tuesday, 25 March, 2008 12:23:07
Copyright (c) 2003, 2007, Oracle. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 –
Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting "oe"."SYS_EXPORT_TRANSPORTABLE_01": oe/********
transport_tablespaces=sales01,sales02
include=triggers,constraint,grant directory=dpump_dir1 dumpfile=sales.dmp
Processing object type TRANSPORTABLE_EXPORT/TYPE/GRANT/OBJECT_GRANT
Master table "OE"."SYS_EXPORT_TRANSPORTABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for OE.SYS_EXPORT_TRANSPORTABLE_01 is:
/u01/app/oracle/dba/sales.dmp
Job "OE"."SYS_EXPORT_TRANSPORTABLE_01" successfully completed at 14:36
Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript. [/u01/app/oracle]
[finance] $
Совет. Не нужно специфицировать параметр USERID при использовании параметра TRANSPORT_TABLESPACE. Тогда утилита Data Pump Export будет отображать приглашение ввести имя пользователя. Подключаться для выполнения операции TRANSPORT_TABLESPACE лучше с использованием строки connect SYS/password as SYSDBA.
Обратите внимание на то, что операция экспорта в этом примере не предполагает экспорта никаких строк из таблиц, которые входят в состав подлежащих переносу табличных пространств. В ней указывается только то, какие табличные пространства планируется сделать частью набора переносимых табличных пространств. В экспортный файл дампа экспортируются одни лишь метаданные (определения таблиц и индексов). В результате этот файл дампа — sales.dmp — получится очень маленьким, поскольку будет содержать только определения таблиц, описания столбцов и прочую информацию подобного рода, которая поможет идентифицировать объекты в табличном пространстве при выполнении их экспорта в целевую базу данных.
Копирование экспортного файла дампа и файлов данных табличных пространств в целевую базу данных
Следующим шагом в процессе создания набора переносимых табличных пространств является выполнение физического копирования всех файлов данных, которые присутствуют в подлежащих переносу табличных пространствах, и экспортного файла дампа, где содержатся метаданные об этих табличных пространствах, в целевую базу данных. Прежде чем приступать к импорту экспортного файла дампа в целевую базу данных, нужно проверять, совпадает ли размер блоков табличного пространства со стандартным размером блоков целевого табличного пространства. Если не совпадает, тогда в целевой базе данных внутри файла init.ora должен обязательно быть указан нестандартный размер блоков, совпадающий с размером блоков того табличного пространства, которое требуется экспортировать.
После этого можно приступать к копированию экспортного файла дампа (каковым в рассматриваемом примере является файл sales.dmp) в целевую базу данных с применением FTP, удаленного копирования (либо просто копирования, если речь идет о Windows) или других средств. Также требуется выполнить копирование и всех файлов данных, которые входят в состав переносимых табличных пространств (каковыми в данном примере являются табличные пространства sales01 и sales02), в место, откуда их можно будет импортировать в целевую базу данных.
Выполнение импорта табличных пространств
Далее останется лишь запустить (в целевой базе данных) утилиту Data Pump Import, чтобы подключить табличные пространства и импортировать информацию о них в словарь данных целевой базы данных. Поскольку в экспортном файле дампа никаких фактических данных не содержится, импортировать придется только метаданные об объектах. Целевая база данных просто использует файлы данных, скопированные из исходной базы данных, в качестве файлов данных для перенесенных табличных пространств. Все это в конечном итоге приведет к подключению табличных пространств к целевой базе данных.
В листинге ниже показано, как выглядит процесс импорта метаданных в целевую базу данных из файла дампа.
C:\>impdp system/sammyy1 dumpfile=sales.dmp TRANSPORT_DATAFILES='sales01_01.dbf', \ 'sales02_01.dbf' directory=dpump_dir1 Import: Release 11.1.0.6.0 - Production on Tuesday, 25 March, 2008 12:23:07 Copyright (c) 2003, 2007, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 – Production Master table "SYSTEM"."SYS_IMPORT_TRANSPORTABLE_01" successfully loaded/unloaded Starting "SYSTEM"."SYS_IMPORT_TRANSPORTABLE_01": system/******** dumpfile=sales.dmp TRANSPORT_DATAFILES='sales01_01.dbf', 'sales02_01.dbf' directory=dpump_dir1 Processing object type TRANSPORTABLE_EXPORT/TYPE/GRANT/OBJECT_GRANT . . . C:\>
Здесь видно, что операция импорта переносимых табличных пространств состоит из двух частей. Сначала утилита Data Pump Import извлекает метаданные переносимых табличных пространств из экспортного файла дампа. После этого она извлекает из файла дампа в целевую базу данных определения различных объектов (таблиц и индексов). Никакие строки фактических данных на этом этапе в базу данных не импортируются. Эти данные уже содержатся в файлах данных табличных пространств, а пространства уже были подключены к целевой базе данных. В журнале импорта будут присутствовать сведения о том, какие таблицы импортировались в целевую базу данных, но в отличие от обычного процесса импорта, информации о количестве импортированных строк там не будет.
Рассмотренный пример хорошо показывает, что механизм переносимых табличных пространств является очень мощным, поскольку позволяет перемещать между базами данных целые табличные пространства просто за счет копирования файлов данных и экспортирования словарной информации из одной базы данных в другую. По сравнению с любыми альтернативами, он является гораздо более быстрым и гораздо более эффективным средством для переноса очень больших объектов данных.
Совет. Переносить табличное пространство в базу данных можно как с таким же, так и с более высоким уровнем совместимости. Кроме того, исходная и целевая базы данных могут даже находиться на разных платформах.
Перенос табличных пространств между платформами с разным порядком следования байтов
Механизм переносимых табличных пространств работает независимо от того, на какой платформе находится исходная и целевая база данных, т.е. табличные пространства можно переносить, например, с платформы Windows, на платформу UNIX и наоборот. Однако существует одно требование, которое нужно обязательно удовлетворять: при выполнении переноса табличных пространств между платформами порядки следования байтов в файлах данных исходной и целевой базы данных должны обязательно совпадать.
На заметку! Порядок следования байтов бывает прямым (little endian) и обратным (big endian). Если он выглядит одинаково в исходной и целевой базе данных, для выполнения переноса табличных пространств хватает тех шагов, которые описывались до этого. Если же порядки разные, тогда перед или после переноса файлов данных на целевой сервер потребуется также дополнительно выполнить преобразование порядка следования байтов в исходных файлах данных.
Определение того, какой порядок следования байтов используется на платформе
Для выяснения того, совпадает ли исходный порядок следования байтов с целевым, необходимо соединить уже хорошо известное представление V$DATABASE с новым представлением V$TRANSPORTABLE_PLATFORM. Например, следующий запрос показывает, что на платформе Linux используется прямой порядок следования байтов:
SQL> SELECT t.endian_format 2 FROM v$transportable_platform t, v$database d 4* WHERE t.platform_name = d.platform_name; ENDIAN_FORMAT --------------------- Little SQL>
Выполнение этого же запроса на втором сервере (целевом или исходном) позволит увидеть, какой формат используется там. Если порядки следования байтов одинаковы на исходной и целевой платформе, выполнять перенос можно с помощью стандартного подхода, который описывался в предыдущем разделе. Если же они разные, тогда нужно дополнительно выполнить соответствующее преобразование табличных пространств либо в исходной, либо в целевой базе данных. Ниже перечислены необходимые шаги.
- Удостовериться в том, что табличные пространства являются самодостаточными.
- Перевести табличные пространства в режим только для чтения.
- Экспортировать метаданные с помощью утилиты Data Pump Export.
- Преобразовать файлы данных для согласования порядка следования байтов.
- Копировать файлы на целевую систему.
- Импортировать метаданные с помощью утилиты Data Pump Import.
Давайте посмотрим, что именно подразумевается под каждым из этих шагов.
Проверка самодостаточности табличных пространств и превращение их в доступные только для чтения
Все таблицы, которые требуется перенести, должны находиться в своих собственных отдельных табличных пространствах. Для проверки того, являются ли эти табличные пространства самодостаточными, служит процедура TRANSPORT_SET_CHECK, которая доступна в поставляемом вместе с Oracle пакете DBMS_TTS. Начиная с версии Oracle Database 10g Release 2, для проверки, не содержат ли табличные пространства зависимых объектов, можно применять во время экспорта параметр TRANSPORT_FULL_CHECK. Например, установка для этого параметра значения Y (TRANSPORT_FULL_CHECK=Y) гарантирует, что в экспортируемых табличных пространствах не будет содержаться никаких таблиц без индексов и никаких индексов без родительских таблиц.
Далее нужно сделать переносимые табличные пространства доступными только для чтения. После выполнения экспорта метаданных на следующем шаге их можно снова делать доступными также и для записи.
Экспорт метаданных с помощью утилиты Data Pump Export
Экспорт метаданных, описывающих входящие в состав табличных пространств объекты, осуществляется применением параметра TRANSPORTABLE_TABLESPACES.
Преобразование файлов данных для согласования порядка следования байтов
Если платформы совместимы, но порядки следования байтов у них разные, необходимо выполнить преобразование файлов данных. Это преобразование можно проводить как перед, так и после процесса переноса. Выполнять его перед переносом табличных пространств можно с помощью команды CONVERT TABLESPACE, которая предлагается в утилите RMAN (Recovery Manager — Диспетчер восстановления), как показано в листинге ниже.
RMAN> CONVERT TABLESPACE finance_tbs01 2> TO PLATFORM 'HP-UX (64-bit)' 3> FORMAT '/temp/%U'; Starting backup at 09-MAY-08 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile conversion input datafile fno=00011 name=C:\ORACLE\TEST02.DBF converted datafile=C:\TEMP\DATA_D-FINANCE_I-2343065311_TS-TODAY_FNO-11_05FLAUM6 channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:17 Finished backup at 09-MAY-08 RMAN> exit Recovery Manager complete.
Приведенный пример показывает, как использовать параметр FORMAT для указания Oracle, в какой формат следует преобразовывать файл и в какой каталог его помещать. Имя файлу, однако, в таком случае, как видно, присваивает Oracle. При желании иметь возможность самостоятельно указать, как должно выглядеть имя файла данных, нужно выполнить преобразование с использованием конструкции DB_FILE_NAME_CONVERT.
В листинге ниже показан пример выполнения команды CONVERT TABLESPACE с использованием конструкции DB_FILE_NAME_CONVERT.
RMAN> CONVERT TABLESPACE test 2> TO PLATFORM 'HP-UX (64-bit)' 3> DB_FILE_NAME_CONVERT = 'c:\oracle\test.dbf','c:\temp\test.dbf'; Starting backup at 10-MAY-08 using target database controlfile instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=151 devtype=DISK channel ORA_DISK_1: starting datafile conversion input datafile fno=00011 name=C:\ORACLE\TEST.DBF converted datafile=C:\TEMP\TEST.DBF channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:16 Finished backup at 10-MAY-08 RMAN>
Конструкция DB_FILE_NAME_CONVERT автоматически выполняет следующие функции.
- Берет исходное имя файла и преобразует в то, которое было задано.
- Помещает преобразованный файл в указанное место.
Обратите внимание на то, что команда DB_FILE_NAME_CONVERT применяется при выполнении преобразования файлов прямо в исходной системе, перед их переносом.
Копирование файлов в целевую систему
На этом этапе требуется скопировать как преобразованный файл данных, который является частью табличного пространства (каковым в данном примере является finance_tbs01), так и файл дампа, который был создан с помощью утилиты expdp (каковой в предыдущем примере переноса табличных пространств назывался sales.dmp) на целевой сервер, где расположена целевая база данных.
Если было решено сначала выполнить перенос табличных пространств (файлов данных, из которых они состоят), тогда на этом этапе нужно выполнить преобразование файлов данных на целевой платформе, прежде чем пытаться импортировать метаданные в табличное пространство. Ниже приведен пример, показывающий, как можно взять файл данных, принадлежащий платформе с операционной системой HP-UX, и преобразовать его в формат платформы Windows:
RMAN> CONVERT DATAFILE 'c:\audit_d01_01.dbf' 2> TO PLATFORM 'Microsoft Windows IA (32-bit)' 3> FROM platform='HP-UX (64-bit)' 4> FORMAT '\u01\oradata\finance\export';
Как и при выполнении преобразования в исходной системе, которое демонстрировалось в предыдущем примере, при преобразовании файлов данных в целевой системе тоже можно использовать конструкцию DB_FILE_NAME_CONVERT. Оператор для преобразования файла данных тогда должен иметь такой формат:
CONVERT DATAFILE . . . FROM PLATFORM . . . DB_FILE_NAME_CONVERT . . .
Ниже приведен пример, демонстрирующий применение конструкции DB_FILE_NAME_CONVERT.
RMAN> CONVERT DATAFILE 2> '/hq/finance/work/tru/tbs_31.f', 3> '/hq/finance/work/tru/tbs_32.f', 4> '/hq/finance/work/tru/tbs_41.f' 5> TO PLATFORM="Solaris[tm] OE (32-bit)" 6> FROM PLATFORM="HP TRu64 UNIX" 7> DB_FILE_NAME_CONVERT= 8> "/hq/finance/work/tru/", "/hq/finance/dbs/tru" 9> PARALLELISM=5;
Совет. По умолчанию Oracle размещает преобразованные файлы в области пакетного восстановления без изменения их имен.
Импорт метаданных с помощью утилиты Data Pump
После переноса преобразованных файлов в целевую систему (или сначала переноса, а затем преобразования файлов данных) остается только импортировать метаданные в целевую базу данных с помощью утилиты Data Pump Import:
$ impdp system/password DUMPFILE=sales.dmp DIRECTORY=dpump_dir TRANSPORT_DATAFILES=/salesdb/sales_101.dbf, /salesdb/sales_201.dbf
Нетрудно заметить, что табличные пространства просто подключаются, а утилита Data Pump Import позволяет интегрировать их файлы данных и метаданные (находящиеся в файле test.dmp).
Ранее в наших блогах уже рассказывалось, что утилиты Data Pump Export и Data Pump Import представляют большую ценность для администратора баз данных и помогают решать множество разнообразных задач. Механизм переносимых табличных пространств является очень полезным, особенно при работе с крупными таблицами. Вместо того чтобы выполнять трудоемкие и длительные операции экспорта и импорта, он позволяет просто копировать нужные поля данных на уровне операционной системы, а затем выполнять экспорт и импорт только описывающих их метаданных.
Любому администратору баз данных неоднократно придется работать с замечательным набором инструментов, предлагаемых в составе технологии Data Pump. Не будет преувеличением сказать, что во многих базах данных утилиты Data Pump будут входить в число самых часто используемых инструментов среди всех доступных средств администрирования баз данных.
