|
История одной миграции
Миграция баз данных возможна двумя способами: с помощью Migration Assistant (MA) и с помощью
Export-Import (EI). С помощью MA можно мигрировать только базы данных на одной платформе.
Но если Вы хотите мигрировать через
версию, скажем
свою 7.3 на версию 9i вам нужно убедиться, что
MA поддерживает такую комбинацию.
Оказывается, что если вы решили
мигрировать с помощью EI, то мигрировать с
помощью полного (full) export'а - import'a на версию 9.2
можно также только с версий:
- - Oracle7 : 7.3.4
- - Oracle8 : 8.0.6
- - Oracle8i: 8.1.7
- - Oracle9i: 9.0.1
Поэтому важнейший вопрос, который нужно
задать себе перед миграцией - на какую
версию я хочу мигрировать, и могу ли я это
делать немедленно, или необходимы доп. шаги.
Нужно учесть также, насколько долго Вы
сможете работать на новой версии. Скажем
поддержка 8.1.7 заканчивается в 2004 году.
Возможно будет продлена, но будет ли ?
Я же буду дальше рассказывать про
миграцию между платформами, в моем случае DEC
Alpha, версия Oracle 7.3.3 и Sun Solaris, версия 8.1.7. К
тому же, требовалось перенести БД не
полностью, а только выделенные данные. Единственный вариант для такой миграции
между платформами было использовать
Export-Import (EI).
Будем называть базу данных откуда мы
выгружаем данные исходной СУБД, базу данных
куда мы загружаем целевой.
Обязательно прочитайте статью
металинка, какой версией export'а нужно
выгружать, а какой версией загружать данные
для ваших версий. Я
выгружал данные export'ом версии 7, а загружал
Import'ом версии 8. Общая рекомендация такова:
Всегда используйте import от версии целевой
СУБД.
Перед миграцией
Итак, что необходимо знать перед
собственно миграцией данных.
- Объем данных. В моем случае это было 60 Gb.
Также нужно оценить свободное место на
диске исходной СУБД. Места на выгрузку
целиком, не было. Оставался вариант
производить выгрузку через сеть. Но сеть
была крайне не надежной, к тому же всего
лишь 10Mbit.
- Необходимо определить список схем,
которые подлежат миграции. Убедитесь,
что табличные пространства по умолчанию
у них существуют.
- Проверить исходную СУБД на наличие
невалидных (invalid) объектов. Попробовать
понять почему это произошло. Обратить
внимание разработчиков на этот факт.
- Так как идет миграция между версиями,
стоит проверить не используются ли в коде
исходной СУБД, ключевые слова,
появившиеся в целевой СУБД. В Oracle 8i
существует view v$reserved_words. Ее можно
перенести на исходный сервер и
выполнить сравнение.
- Давайте создадим список пользователей с
их паролями и табличными пространствами
по умолчанию. Он нам очень пригодится.
Сколько времени занимает подобный проект
?
Перед тестирование нужно представить себе
окружение в котором предстоит работать. На
это уйдет около дня. Далее, время миграции складывается из времени
экспорта времени переноса данных на
целевую СУБД + времени импорта на целевой БД
+ время передачи данных по сети + время сбора
статистики оптимизатора. Дальше
необходимо тестирования приложения после
переноса (это как правило несколько дней),
учет особенностей новой версии (зависит от
вашей подготовки).
Выгружаем данные
Теперь собственно о процессе export'а. Для
версии 7 существует замечательный документ
(Conventional and Direct Path Export),
описывающий какие параметры и как влияют
на производительность этого процесса.
Наиболее важные это buffer, recordlength, direct, compress
Второй момент - нужно помнить что на
некоторых платформах export не умеет
создавать файлы размером более 2gb. Поэтому в
версии 8i даже появились параметры ...Но я
рекомендую старый добрый способ с
использованием pipe.
cat $PIPEDIR/$OWNER.pipe | gzip -1 > $EXPDIR/$OWNER.dmp.gz &
exp $USERNAME/$PASSWORD file=$PIPEDIR/$OWNER.pipe OWNER=$OWNER
Посмотрите полный пример exp.sh. Синтакс его
такой:
exp.sh <имя схемы>
Что важно в этом примере для
производительности выгрузки. Балансировка
нагрузки по дискам. Чтобы читался export'ом
один диск, pipe располагался на другом, а gzip
писал на третий. Одновременно можно
запускать более одного exp.sh с разными
параметрами.
Ниже будет рассказано, что все же придется
еще сделать и полный export, без данных.
Загружаем данные
Так как мы мигрируем на новую версию,
конечно хотелось бы использовать все новые
возможности. Также нужно учесть
особенности новой архитектуры. Так что БД
лучше создать, перед импортом данных. DataBase
Assistance (dbassist) создает замечательные скрипты,
которые вполне можно поправить, как это
необходимо. Почему то по умолчанию, в версии
8.1.7 табличное пространство temp создается без
использования синтаксиса tempfile, а другие
табличные пространства dictionary managed, а не localy.
Init.ora в целом можно взять от исходной СУБД.
Если Ваше приложение использовало
механизм db links, вам необходимо также
перенести файл tnsnames.ora и, возможно, /etc/hosts
Как я писал выше, я переносил часть данных.
Поэтому выполнял export по одной схеме. В dmp файлах нет команд создания
пользователей. Поэтому лучше всего создать
пользователей, из списка который мы
приготовили чуть раньше.
Могут существовать
перекрестные права доступа, ограничения
ссылочной целостности, которые не
создадутся, если еще нет необходимой схемы
в новой БД. Если Вы хорошо знаете, как
устроено Ваше приложение, Вы можете
импортировать в правильном порядке. Но,
есть способ проще. Можно импортировать
схемы с данными (rows=Y) в произвольном порядке.
А позже, пропустить полный импорт исходной
СУБД, выполненный без данных (rows=N). Этот
последний импорт выполнит, все что не
получилось у импортов схем данных.
Вот синтаксис для полного импорта:
imp sys/q1 file=main_full.dmp log=main_full.log full=Y ignore=Y
А вот для отдельных схем. Так как у нас
получились на этапе экспорта файлы, сжатые
командой gzip нам нужно опять использовать
механизм pipe
gzip -d < $IMPDIR/$OWNER.dmp.gz > $PIPEDIR/$OWNER.pipe &
fromuser=$OWNER touser=$OWNER buffer=10485760 recordlength=131072 log=$IMPDIR/$OWNER.log ignore=Y rows=Y commit=Y
Полный синтаксис для Imp.sh
(этот файл пересоздает пользователя с
определенным паролем. Если переносишь
несколько раз, это может быть полезно.
Пароли не проблема, помните, у нас же есть
список пользователей и их паролей ).
Проверяем
Теперь надо откомпилировать объекты в
нашей БД. Проще всего воспользоваться
скриптом compile.sql
Вроде мы делали очень простые операции. В
логах наших export'ов нет критических ошибок.
Но давайте попробуем сравнить схемы данных
на нашей исходной и целевой БД. Вы можете
найти в интернете несколько программ.
которые выполняют сравнение схем на разных
БД, но они сравнивают по одной схеме. Если мы
переносили скажем 50 схем, это не вполне
удобно. Я попробовал написать очень простой
скрипт, для сравнения кол-ва валидных и
инвалидных объектов. Выполнил этот скрипт на
обоих базах, потом сравнил два текстовых
файла с помощью команды.
diff -bitw <file1> <file2>
Если вывод этой команды пустой - все
нормально. Если нет разбирайтесь. Я
столкнулся с такой ошибкой. По какой-то
причине, даже несмотря на наличие объектов (таблиц,
процедур) в файле dmp они ...не импортируются.
На metalink есть несколько открытых репортов на
эту тему. Предлагается или установить патч
7.3.4 или выполнять export из-под владельца схемы.
В результате я выбрал последний вариант.
Ну если все нормально, стоит собрать
статистику для оптимизатора. После
этого начинать тестировать приложений.
Огромная благодарность Алексею Козлову
который выполнил массу черновой работы в
этом проекте.
Ссылки:
Oracle
Utilities (Export/Import) Technical Notes
http://www.orafaq.com/faqiexp.htm
http://www.jlcomp.demon.co.uk/faq/bigexp.html
Вот совет
как оценить размер будущего файла export'а,
правда его для этого нужно сделать в /dev/null:
mknod exp.pipe p
dd if=/tmp/exp.pipe of=/dev/null bs=1024 &
exp file=pipe
Увидев в выводе dd кол-во записей умножаем
их на 1024.
|
