На самом деле, еще 9 часов заняла загрузка данных в PostgreSQL, но обо всем по порядку.
Ничто не предвещало грозы — у Заказчика упал сервер и всего-то предполагалось поднять Оракл ;-)


Что я и сделал.


Но ВНЕЗАПНО оказалось, что по договору нужна миграция а дедлайн через 3 дня и все заверте...


Тут стоит упомянуть, что с Постгрес до этого был более чем незнаком, а о процессе миграции знал лишь по публикациям на Хабре.


Я сразу предупредил все стороны, что гарантий своевременности — никаких, но все-же, "МЫ ПРИНИМАЕМ БОЙ!"



Мне была предоставлена виртуалка с Centos 8 и всем, что нужновыходом в интернет и безграничной поддержкой администратора серверов.


Времени на размышления не было, поэтому сразу была загружена последняя(23.0) версия ora2pg.


Действовать решил тоже по инструкции с этого же сайта, но что-то пошло не так:


perl -MCPAN -e 'install DBD::Oracle'
/usr/bin/ld: cannot find -lnsl
collect2: error: ld returned 1 exit status


Советы Гугла не помогли, а часы продолжали неумолимо тикать...


Ничего не оставалось делать, как пойти проторенным путем
Там автор мигрировал с 12-го Оракла софтом Ora2Pg v21.1 в тринадцатый PostgreSQL.


Я лишь немного поменял вводные — CentOS Linux release 7.9 и двенадцатый Постгрес.


Начало было довольно банальным и прошло без проблем(все имена и IP -вымышленные):
192.168.0.8 — Oracle sever
192.168.0.14 — new PostgreSQL server
client — dbname Оракла и имя базы данных Постгреса


Все манипуляции выполняются на последнем:


rpm -ivh oracle-instantclient12.2-basic-12.2.0.1.0-1.x86_64.rpm
rpm -ivh oracle-instantclient12.2-devel-12.2.0.1.0-1.x86_64.rpm
rpm -ivh oracle-instantclient12.2-jdbc-12.2.0.1.0-1.x86_64.rpm
rpm -ivh oracle-instantclient12.2-sqlplus-12.2.0.1.0-1.x86_64.rpm

yum install -y wget

wget https://yum.oracle.com/RPM-GPG-KEY-oracle-ol7 -O /etc/pki/rpm-gpg/RPM-GPG-KEY-oracle

yum install -y perl perl-CPAN perl-DBI perl-Time-HiRes perl-YAML perl-local-lib make gcc

yum install -y perl-App-cpanminus

cpanm CPAN::Config
cpanm CPAN::FirstTime

export LD_LIBRARY_PATH=/usr/lib/oracle/12.2/client64/lib
export ORACLE_HOME=/usr/lib/oracle/12.2/client64

perl -MCPAN -e 'install DBD::Oracle'

tar zxf ora2pg-21.1.tar.gz && cd ora2pg-21.1 && perl Makefile.PL && make && make install

Но мы-же помним, о 500Гигах, а учитывая, что на дисках Винды dbf-файлы занимали вдвое больше, то 3ТБ, были смонтированы в /postgres


Соответственно, нужно сообщить об этом инструменту ora2pg:


ora2pg --project_base /postgres/ora2pg --init_project client WORKDIR /postgres/ora2pg


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


COPY ora2pg.conf /postgres/ora2pg/client/config/

cd /postgres/ora2pg/client

Редактируем файл конфигурации — vi ora2pg.conf меняем следующие строки:


ORACLE_HOME     /usr/lib/oracle/12.2/client64

# Set Oracle database connection (datasource, user, password)
ORACLE_DSN      dbi:Oracle:host=192.168.0.8;sid=client;port=1521
ORACLE_USER     system
ORACLE_PWD      systempwd

# Set this to 1 if you connect as simple user 
USER_GRANTS     0

# Export Oracle schema to PostgreSQL schema
EXPORT_SCHEMA   1

# Oracle schema/owner to use
SCHEMA

Теперь самое время проверить соединение с БД Оракл, устанавливаем переменные окружения:


export LD_LIBRARY_PATH=/usr/lib/oracle/12.2/client64/lib
export ORACLE_HOME=/usr/lib/oracle/12.2/client64

И запускаем проверку:


cd /postgres/ora2pg/client
ora2pg -t SHOW_VERSION -c config/ora2pg.conf

Oracle Database 12c Enterprise Edition Release 12.2.0.1.0


Ок, соединение — успешное, можно еще просмотреть список всех таблиц БД:


ora2pg -t SHOW_TABLE -c config/ora2pg.conf


И самое интересное — можно оценить оценить трудозатраты (время миграции):


ora2pg -t SHOW_REPORT --estimate_cost -c config/ora2pg.conf export_schema.sh


В выводе было много текста и среди ниих такая строка :


cost migration units means approximatively 11 man-day(s)


Нет, на это я пойтить не могу!



И даже строки Migration level: C-5
C — Migration with code rewrite and a human-days cost above 5 days
5 = difficult: stored functions and/or triggers with code rewriting

оптимизма не внушали


Если Вас ничего не смущает в полученных цифрах, то можно смело запускать выгрузку данных:


ora2pg -t INSERT -o data.sql -b ./data -c ./config/ora2pg.conf


В результате получаются командные файлы в виде create table — insert для psql


Тестовая выгрузка показала удурчающе низкую скорость создания этих самых инсертов — около 5ГБ/час.


Что-ж читаем опции командной строки, что нам предлагает ora2pg, и оказывается что ВНЕЗАПНО можно параллелить чтение/запись, о чем я у других авторов гайдов по миграции не читал.


Тут как раз в пору заряжать шестиствольный пулеметмногопоточную выгрузку:

ОК, расширяем количество ядер нашей виртуалки с 4 до 16 и после ряда экспериментов выходим на оптимальное соотношение параметров:


nohup ora2pg -j 2 -J 12 -t INSERT -o data.sql -b ./data -c ./config/ora2pg.conf


Тут Оракл вычитывается в 12 потоков, запись идет в два, еще два процесса занимает ora2pg.


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


У Вас может быть все по другому — экспериметнируйте!


Каково-же было мое удивление, когда выгрузка по сети закончилась за 5 часов!


Это при том, что локальный бэкап Оракла датапампом идет все 6.


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


Но согласитесь, загрузка CPU, достигающая порой 90% — хоть и косвенный, но показатель оптимальности параметров.


Теперь самое время установить PostgreSQL, если Вы не сделали это ранее, 12 версия была пожеланием разработчиков:


yum install dnf 

dnf module list postgresql

https://www.postgresql.org/

# Install the repository RPM:
yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm

# Install PostgreSQL:
yum install -y postgresql12-server

Инициализируем БД и добавляем в автостарт:


/usr/pgsql-12/bin/postgresql-12-setup initdb
systemctl enable postgresql-12
systemctl start postgresql-12

Но не все так просто — мы-же помним про пол-Тера информации, это у Джонни-мнемоника адресация выше 320ГБ вызывает OOM



Для того, чтобы избежать сией участи нам нужно немного подправить конфиг, указав на "большой" диск:


vi /var/lib/pgsql/12/data/postgresql.conf

data_directory = '/postgres/pgsql'

Теперь копируем всю структуру в новое место и перезапускаем серверный процесс:


cp /var/lib/pgsql/12/data/* /postgres/pgsql

chown -R postgres /postgres/pgsql

chmod -R 750 /postgres/pgsql

systemctl restart postgresql-12

Но это еще не все — нужно назаначить пароль пользователю БД и создать саму базу:


psql -c "alter user postgres with password 'clientpostgres'" 

vi /var/lib/pgsql/12/data/postgresql.conf

set Listen address to your server IP address or “*” for all interfaces.

vi /var/lib/pgsql/12/data/pg_hba.conf

# Accept from anywhere
host all all 0.0.0.0/0 md5

restart:

systemctl restart postgresql-12

psql -U postgres -h 192.168.0.14 -p 5432 postgres

CREATE DATABASE client;

Момент истины(загрузки данных) стремительно приближался, точно так же, как и дедлайн



Я уже всеми фибрами души чувствовал степень авантюрности своего начинания, но как говорится — глаза-боятся а руки — делают!


Многие советуют запускать скрипт загрузки:


postgres/ora2pg/client/import_all.sh -d client -o postgres -U postgres


Но он ну очень интерактивный и задает много вопросов — в стиле — пересоздавать-ли БД, какие компоненты (таблицы, индексы и т.д. ) загружать.


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


А потому, путем чтения мануала и ряда ошибок я таки запустил автозагрузку данных без вопросов со стороны скрипта


nohup /postgres/ora2pg/client/import_all.sh -d client -o postgres -U postgres -a -y -I -P 8


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


Да, тут тоже фишка в параллельной загрузке 8 таблиц, иначе не знаю, насколько растянулся-бы 9-часовой процесс.


И еще, если придется догружать другие обьекты — то уже без опций -a, -y, -I и ноухапа, с ответом на кучу вопросов.


Собственно, на этом все, и как-бы сказал(а) программист(ка) из "Путешественников":



"… Пожалуйста!, — ведь я спасла Ваши задницы!"


Комментарии (7)


  1. DMGarikk
    28.12.2021 11:10
    +13

    миграция в 3 дня с оракла в постри да еще без привлечения dba по постгри, а у заказчика там забавные грибы
    вангую в течении недели перед новым годом срочную миграцию обратно на оракл


  1. CrushBy
    28.12.2021 16:51
    +3

    А после установки PostgreSQL и перед загрузкой, Вы ему хоть настройки памяти поменяли ? А fsync, full_page_writes и прочее не выключали ? Может и размеры wal не меняли, и checkpoint'ы каждые 20 секунд шли ?

    Если нет, то зря. Все могло быть значительно быстрее (хотя какие-то параметры возможно скрипт меняет, но я сомневаюсь). Кроме того, интересно посмотреть сам скрипт. Если там сначала создается схема с индексами, а потом INSERT, то тоже все будет гораздо печальнее, чем наоборот.


    1. gerasimenkoao Автор
      28.12.2021 22:01

      "Ведь если б было у меня времени хотя бы час —Я бы дворников позвал бы с мётлами, а тут"

      c. Владимир Высоцкий

      Согласно законам жанра,

      исполнителю стирают память(отключают VPN) после выполнения задания, как в фильме Paycheck ;-)

      Но к счастью, на клочке туалетной бумаги остался хвост лога:

      ALTER TABLE
      ALTER TABLE
      ALTER TABLE
      COMMIT
      Would you like to import indexes from ./schema/tables/INDEXES_table.sql?

      Это позволяет судить о том, что создатели утилиты ora2pg - не самые глупые люди.

      Да, память я в настройках добавлял, остальное - нет.

      Но не стоит забывать жесткий тайминг в котором все происходило.

      Сейчас база в руках специалистов по PostgreSQL, которые на момент миграции были в отпуске (или не хотели принимать ответственность).

      Там уже все хорошо - и pgAdmin, и настройки, и бэкапы.

      Но исполнителей как говорится - не будят, или победителей не судят - как-то так ;-)


      1. vodopad
        28.12.2021 22:38
        +1

        Очень странная у вас организация и очень странный заказчик, однако.


        1. gerasimenkoao Автор
          28.12.2021 23:15

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

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

          С другой стороны, возможно было не совсем полное понимание степени и глубины проблематики, ведь установить СУБД можно по "щелчку пальцев", создать 8-теровый стендбай за 5 часов.

          А то, что скажем 100-гиговую базу Oracle 9i из Винды в Линукс на 18с можно апгрейдить/переносить обычным export-import двое суток, видимо не учли.

          Не говоря уже о миграции между различными типами БД.

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


  1. FlashHaos
    28.12.2021 23:05
    +2

    Какая-то дичь. Нагрузочное тестирование информационной системы перед сменой СУБД и операционкой системы тоже не проводили, наудачу поехали?


    1. gerasimenkoao Автор
      29.12.2021 09:55

      Единственная "дикая" миграция до этого у меня была при переходе с FoxPro.

      Так я познакомился с Oracle.

      Может нынешний случай - это знак?

      Хотя темы миграции на PostgreSQL появлялись в поле моено зрения последние лет 5.

      Не думалось только, что знакомство с процессом произойдет таким образом