Кроссплатформенная миграция Oracle с ограниченным временем простоя

На протяжении работы с абсолютно любой СУБД может наступить момент, когда ресурс используемого аппаратного обеспечения станет камнем преткновения в дальней успешной работе базы данных. Причин может быть несколько: устаревание, проблемы с поддержкой, нехватка ресурсов, ограниченность в расширении. И исход у такой проблемы может быть только один – миграция oracle на новое оборудование.

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

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

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

Но что же делать если требования таковы: миграция 10T+, до 2ух часов простоя, миграция oracle на другую платформу с другим порядком байт (endian)? Необходимо учесть тот факт, что исходная система должна быть скопирована, сконвертирована и перемещена на целевой сервер. Процесс копирования такой системы занимает уже несколько часов, не говоря уже о конвертации и распределении по массивам нового сервера. К тому же необходимо учесть консистентность системы и полную синхронизацию, что подразумевает достаточно большое время простоя системы.

В первую очередь хочется обратить внимание на следующие методы: RMAN Duplicate или Standby. Но по условиям оба не проходят, так как системы источника и целевой базы разные. Все остальные методы, будь то DataPump или стандартная миграция табличных пространств, все это занимает слишком много времени, а именно времени простоя системы.

Но один метод заслуживает своего отдельного описания, а именно “Миграция табличных пространств с использованием технологии инкрементальных резервирований”. Достаточно обширное название, но и сам метод не так прост.

Его логика заключается в следующем:

  • Делается копия требуемых табличных пространств прямым копированием через RMAN в формате бекапа as copy;
  • Полученные файлы данных конвертируются посредством той же утилиты RMAN для использования на целевой системе (по нашим первичным условиям мы взяли что системы имеют отличия в порядке хранения байт);
  • Сконвертированные файлы раскладываются на свое места уже на целевой системе;
  • Далее выполняется инкрементальный бекап, с условием начальной точки взятия бекапа на момент начала исходного копирования файлов данных из исходной базы данных;
  • Полученный бекап мы также конвертируем, приводя к формату новой системы, а дальше применяем его, накатывая на разложенные файлы на целевой системе (все файлы, как данных, так и бекапа, будут относиться логически к одной и той же базе данных).

В результате мы получаем файлы, последняя точка данных в которых сопоставима со временем окончания упомянутой резервной копии. В данном плане наибольшее количество времени потребуется для первичной копии данных, но операция эта производится без остановки системы и, с правильным подходом, никак не повлияет на общую работоспособность системы. Инкрементальная копия также берется во время стационарной работы системы, что не требует остановки источника. Упомянутый инкрементальный бекап может занять какое-то время, вполне возможно достаточно продолжительное, ибо выполняться он будет после того как первичная копия будет выполнена, сконвертирована и размещена на целевой системе, соответственно разница данных, сохраненных в нем может доходить до 15-20 часов на системе в 15-20T. Но размерность его будет гораздо меньше, нежели первичная копия, соответственно общие операции по перемещения и конвертации займут меньше времени.

А что дальше? Дальше снова выполняется инкрементальная копия, уже от момента окончания предыдущего бекапа. Такая же конвертация, такая же накатка и уже меньше потраченного времени на работу. Повторяя такой процесс несколько раз можно добиться эффекта, что очередной инкрементальный бекам будет включать в себя измененные данные за последние 20-30 минут. Соответственно небольшой размер и достаточно большая скорость накатывания.

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

Останется только выполнить экспорт/импорта табличных пространств штатными командами DataPump и в результате данные будут копированы. Но процедура миграции табличных пространств не перенесет все данные, а точнее будет потеряно часть объектов, которые физически не отображены в исходных табличных пространствах. Подробно о пропущенных объектах можно будет прочесть здесь:

What Objects Are Exported With Transportable Tablespaces (TTS) and the Original Export Utility (Doc ID 883153.1)

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

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

— Первым делом до начала миграции баз данных oracle необходимо провести создание пользователей в системе, и некоторых дополнительных сущностей, таких как DB_LINKS, ROLES, PROFILES, GRANTS. По существу, такие объекты на протяжении жизни базы данных меняются достаточно нечасто, если только не рассматривать GRANTS. Так что первым шагом будет миграция этих объектов.

impdp userid='" /as sysdba"' \
network_lin=MIGRATION_LINK \
include=ROLE,PROFILE \
full=y

impdp userid='" /as sysdba"' \
network_lin=MIGRATION_LINK \
include=USER \
REMAP_TABLESPACE=... \
full=y

impdp userid='" /as sysdba"' \
network_lin=MIGRATION_LINK \
include=GRANT,JOB \
full=y

impdp userid='" /as sysdba"' \
network_lin=MIGRATION_LINK \
include=DB_LINK \
full=y

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

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

— Чтобы восстановить «справедливость» необходимо выполнить дополнительный шаг – миграцию метаданных. Для пояснения, если сослаться на документ 883153.1, то будут пропущены такие объекты как пользовательские отображения, сиквенсы, часть синонимов и тому подобное. Все это можно перенести посредством миграции метаданных.

vi export.par
~~~
DIRECTORY=META_MIGRATION
DUMPFILE=export_metadata_%U.dmp
CONTENT=METADATA_ONLY
full=y
~~~
expdp userid='" /as sysdba"' parfile=export.par

vi import.par
~~~
FULL=Y
CONTENT=METADATA_ONLY
DUMPFILE=export_metadata_%U.dmp
DIRECTORY=META_MIGRATION
~~~
impdp userid='" /as sysdba"' parfile=import.par

Все – система будет считаться мигрированной. Несомненно, необходимо сделать множество проверок, несколько тестов. Каждая система имеет свои особенности, и это необходимо учитывать.

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

Миграция oracle 11g — Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 1389592.1)

Метод также применим для баз данных версий 12c. Каждый шаг подробно расписан и достаточно прост в выполнении. А для примера могу сказать одно, база данных в 20Т посредством такого метода была мигрирована с окном простоя в 5ч, что абсолютно невозможно, используя другие методы миграции баз данных oracle и это не предел.

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*