**NAME**
Ora2Pg — инструмент для преобразования схемы базы данных Oracle в PostgreSQL

**DESCRIPTION**
Ora2Pg – это бесплатный инструмент, используемый для переноса базы данных Oracle на совместимую схему PostgreSQL. Он подключается к вашей базе данных Oracle, автоматически сканирует её и извлекает структуру или данные, а затем генерирует SQL-скрипты, которые вы можете загрузить в свою базу данных PostgreSQL.

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

**FEATURES**
Ora2Pg состоит из скрипта Perl (ora2pg) и модуля Perl (Ora2Pg.pm). Единственное, что вам нужно изменить, — это файл конфигурации ora2pg.conf, установив DSN для базы данных Oracle и, возможно, имя схемы. После этого вам просто нужно установить тип экспорта, который вы хотите: TABLE с ограничениями, VIEW, MVIEW, TABLESPACE, SEQUENCE, INDEXES, TRIGGER, GRANT, FUNCTION, PROCEDURE, PACKAGE, PARTITION, TYPE, INSERT или COPY, FDW, QUERY, KETTLE, SYNONYM.

По умолчанию Ora2Pg экспортирует в файл, который можно загрузить в PostgreSQL с помощью клиента psql, но вы также можете импортировать непосредственно в базу данных PostgreSQL, указав её DSN в файле конфигурации. Со всеми параметрами конфигурации файла ora2pg.conf у вас есть полный контроль над тем, что должно быть экспортировано и как.

Включённые функции:
* экспорт полной схемы базы данных (таблицы, представления, последовательности, индексы), с уникальными, первичными, внешними ключами и проверочными ограничениями;
* экспорт грантов/привилегий для пользователей и групп;
* экспорт диапазонов/списков разделов и подразделов;
* экспорт таблицы по выбору (путем указания имён таблиц);
* экспорт схемы Oracle в схему PostgreSQL 8.4+;
* экспорт предопределённых функций, триггеров, процедур, пакетов и тел пакетов;
* экспорт полных данных или следующих за предложением WHERE;
* полная поддержка объекта Oracle BLOB как PG BYTEA;
* экспорт представлений Oracle как таблиц PG;
* экспорт пользовательских типов Oracle;
* предоставление некоторого базового автоматического преобразования кода PLSQL в PLPGSQL;
* работает на любой платформе;
* экспорт таблиц Oracle как внешних таблиц оболочки данных;
* экспорт материализованного представления;
* показ отчёта о содержимом базы данных Oracle;
* оценка стоимости миграции базы данных Oracle;
* оценка уровня сложности миграции базы данных Oracle;
* оценка стоимости миграции кода PL/SQL из файла;
* оценка стоимости запросов Oracle SQL, хранящихся в файле;
* генерация XML-файлов ktr для использования с Penthalo Data Integrator (Kettle);
* экспорт локатора Oracle и пространственных геометрий в PostGis;
* экспорт DBLINK как Oracle FDW;
* экспорт синонимов как представлений;
* экспорт DIRECTORY как внешней таблицы или каталога для расширения external_file;
* отправка списка SQL-команд через несколько подключений PostgreSQL;
* выполнение сравнения между базами данных Oracle и PostgreSQL для целей тестирования;
* миграция MySQL/MariaDB и Microsoft SQL Server.

Ora2Pg делает всё возможное, чтобы автоматически преобразовать вашу базу данных Oracle в PostgreSQL, но всё ещё требуется ручная работа. Код Oracle PL/SQL, сгенерированный для функций, процедур, пакетов и триггеров, должен быть проверен на соответствие синтаксису PostgreSQL. Вы найдёте некоторые полезные рекомендации по переносу кода Oracle PL/SQL в PostgreSQL PL/PGSQL в разделе «Преобразование из других баз данных в PostgreSQL», подраздел «Oracle» (http://wiki.postgresql.org/wiki/Main_Page).

См. http://ora2pg.darold.net/report.html для примера отчёта о миграции базы данных Oracle.

**INSTALLATION**
Все модули Perl всегда можно найти по адресу... **CPAN (http://search.cpan.org/)**

Просто введите полное имя модуля (например, DBD::Oracle) в поле поиска, и вы перейдёте на страницу для скачивания.

Релиз Ora2Pg доступен на SF.net (https://sourceforge.net/projects/ora2pg/).

В Windows вам следует установить Strawberry Perl (http://strawberryperl.com/) и соответствующие клиенты Oracle для операционных систем. Начиная с версии 5.32 этот дистрибутив Perl включает предварительно скомпилированные драйверы DBD::Oracle и DBD::Pg.

**Требования**

На системе должен быть установлен Oracle Instant Client или полная установка Oracle. Вы можете загрузить RPM из центра загрузки Oracle:

    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

или просто загрузите соответствующие ZIP-архивы из центра загрузки Oracle и установите их там, где хотите, например: /opt/oracle/instantclient_12_2/.

Вам также потребуется современный дистрибутив Perl (perl 5.10 и выше). Для подключения к базе данных и перехода к её миграции вам понадобится модуль Perl DBI версии > 1.614. Для переноса базы данных Oracle вам потребуются установленные модули Perl DBD::Oracle.

Чтобы установить DBD::Oracle и заставить его работать, вам необходимо установить клиентские библиотеки Oracle и определить переменную среды ORACLE_HOME.

Если вы планируете экспортировать базу данных MySQL, вам нужно установить модуль Perl DBD::MySQL, для которого требуются установленные клиентские библиотеки mysql.

Если вы планируете экспортировать базу данных SQL Server, вам потребуется установить модуль Perl DBD::ODBC, который требует установки пакета unixODBC.

В некоторых дистрибутивах Perl может потребоваться установить модуль Time::HiRes Perl.

Если ваш дистрибутив не включает эти модули Perl, вы можете установить их с помощью CPAN:

        perl -MCPAN -e 'install DBD::Oracle'
        perl -MCPAN -e 'install DBD::MySQL'
        perl -MCPAN -e 'install DBD::ODBC'
        perl -MCPAN -e 'install Time::HiRes'

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

**Необязательно**

По умолчанию Ora2Pg выполняет дамп экспорта в плоские файлы. Чтобы загрузить их в вашу базу данных PostgreSQL, вам нужен клиент PostgreSQL (psql). Если у вас его нет на хосте, на котором работает Ora2Pg, вы всегда можете перенести эти файлы на хост с установленным клиентом psql. Если вы предпочитаете загружать экспорт «на лету», требуется модуль Perl DBD::Pg.

Ora2Pg позволяет вам выгрузить весь вывод в сжатый файл gzip. Для этого вам необходим модуль Perl Compress::Zlib или программа bzip2, если вы предпочитаете использовать сжатие bzip2. Она должна быть доступна в вашем PATH.

Если ваш дистрибутив не включает эти модули Perl, вы можете установить их с помощью CPAN:

        perl -MCPAN -e 'install DBD::Pg'
        perl -MCPAN -e 'install Compress::Zlib'

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

**Инструкция для SQL Server**

Для SQL Server вам необходимо установить пакет unixodbc и драйвер Perl DBD::ODBC:

        sudo apt install unixodbc
        sudo apt install libdbd-odbc-perl

или

        sudo yum install unixodbc
        sudo yum install perl-DBD-ODBC
        sudo yum install perl-DBD-Pg

затем установите Microsoft ODBC Driver for SQL Server. Следуйте инструкциям относительно вашей операционной системы отсюда:

https://docs.microsoft.com/fr-fr/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-for-sql-server?view=sql-server-ver16

Как только это будет сделано, установите следующее в файле /etc/odbcinst.ini, настроив версию драйвера SQL Server ODBC:

[msodbcsql18]
Description=Microsoft ODBC Driver 18 for SQL Server
Driver=/opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.0.so.1.1
UsageCount=1 **Установка Ora2Pg**

Как и любой другой модуль Perl, Ora2Pg можно установить с помощью следующих команд:

    * tar xjf ora2pg-x.x.tar.bz2;
    * cd ora2pg-x.x/;
    * perl Makefile.PL;
    * make && make install.

Это установит Ora2Pg.pm в репозиторий сайта Perl, ora2pg в /usr/local/bin/ и ora2pg.conf в /etc/ora2pg/.

В ОС Windows(tm) вы можете использовать вместо этого:

    * perl Makefile.PL;
    * gmake && gmake install.

Это позволит установить скрипты и библиотеки в каталог установки сайта Perl и файл ora2pg.conf, а также все файлы документации в C:\ora2pg\.

Чтобы установить ora2pg в другом каталоге, отличном от каталога по умолчанию, просто используйте эту команду:

    * perl Makefile.PL PREFIX=<your_install_dir>;
    * make && make install;

затем установите PERL5LIB в путь к каталогу установки перед использованием Ora2Pg:

    * export PERL5LIB=<your_install_dir>;
    * ora2pg -c config/ora2pg.conf -t TABLE -b outdir/.

**Упаковка**

Если вы хотите создать бинарный пакет для предпочитаемого вами дистрибутива Linux, ознакомьтесь с каталогом packaging/ исходного архива tarball. Там есть всё необходимое для создания пакетов RPM, Slackware и Debian. См. файл README в этом каталоге.

**Установка DBD::Oracle**

Ora2Pg требуется модуль Perl DBD::Oracle для подключения к базе данных Oracle из Perl DBI. Чтобы получить DBD::Oracle, получите его из CPAN — репозитория модулей Perl.

После установки переменных среды ORACLE_HOME и LD_LIBRARY_PATH как пользователь root установите DBD::Oracle. Действуйте следующим образом:

    * 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'.

Если вы запускаете программу впервые, она задаст много вопросов; вы можете оставить значения по умолчанию, нажав клавишу ENTER, но вам нужно указать один подходящий зеркальный сайт для загрузки модулей CPAN. Установите через CPAN вручную, если вышеописанное не работает:

    * #perl -MCPAN -e shell;
    * cpan> get DBD::Oracle;
    * cpan> quit;
    * cd ~/.cpan/build/DBD-Oracle*;
    * export LD_LIBRARY_PATH=/usr/lib/oracle/11.2/client64/lib;
    * export ORACLE_HOME=/usr/lib/oracle/11.2/client64;
    * perl Makefile.PL;
    * make;
    * make install.

Для установки DBD::Oracle необходимо установить три пакета Oracle: instant-client, SDK и SQLplus, а также библиотеку libaio1.

Если вы используете Instant Client из ZIP-архивов, LD_LIBRARY_PATH и ORACLE_HOME будут одинаковыми и должны быть установлены в каталог, где вы установили файлы. Например: /opt/oracle/instantclient_12_2/.

**Конфигурация**

Конфигурацию Ora2Pg можно выполнить очень просто, выбрав базу данных Oracle для экспорта и тип экспорта. Это можно сделать за минуту.

Прочитав эту документацию, вы также сможете:

    * выбрать только определённые таблицы и/или столбцы для экспорта;
    * переименовать некоторые таблицы и/или столбцы во время экспорта;
    * выбирать данные для экспорта в соответствии с предложением WHERE для каждой таблицы;
    * приостанавливать ограничения базы данных во время загрузки данных;
    * сжимать экспортированные данные для экономии места на диске;
    * и многое другое.

Полный контроль над миграцией базы данных Oracle осуществляется через единственный файл конфигурации с именем ora2pg.conf. Формат этого файла состоит из имени директивы в верхнем регистре, за которым следует символ табуляции, и значения. Комментарии — это строки, начинающиеся с символа #.

Нет определённого порядка размещения директив конфигурации, они устанавливаются при их чтении в файле конфигурации.

Директивы конфигурации, которые принимают только одно значение, можно использовать несколько раз в файле конфигурации, но будет использоваться только последнее вхождение, найденное в файле. Для директив конфигурации... **Объект**
Можно использовать для импорта данных с помощью COPY и импортировать большие объекты вручную за второй проход. Это необходимо для BLOB > 1 ГБ. Дополнительную информацию см. в документации.

**--mview_as_table str:** список материализованных представлений, разделённых запятыми, для экспорта в виде обычной таблицы.

**--drop_if_exists:** перед созданием объекта удалить его, если он существует.

**--delete clause:** установить предложение DELETE, которое будет применяться к запросу Oracle перед импортом данных. Можно использовать несколько раз.

**--oracle_fdw_prefetch:** установить значение oracle_fdw prefetch. Большие значения обычно приводят к более быстрой передаче данных за счёт большего использования памяти в месте назначения.

Полную документацию см. на сайте https://ora2pg.darold.net/ или обратитесь к странице руководства с командой «man ora2pg».

Ora2Pg вернёт 0 в случае успеха, 1 при ошибке. Вернёт 2, когда дочерний процесс был прерван и вы получили предупреждающее сообщение: «ВНИМАНИЕ: во время экспорта данных произошла ошибка. Пожалуйста, проверьте, что произошло». В большинстве случаев это проблема OOM, сначала попробуйте уменьшить значение DATA_LIMIT.

Разработчики могут добавить свои собственные параметры в Perl-скрипт ora2pg, так как любой параметр конфигурации из ora2pg.conf можно передать строчными буквами новому экземпляру объекта Ora2Pg. См. код ora2pg о том, как добавить свой собственный параметр.

Обратите внимание, что производительность может быть улучшена путём обновления статистики по Oracle:

BEGIN
DBMS_STATS.GATHER_SCHEMA_STATS
DBMS_STATS.GATHER_DATABASE_STATS 
DBMS_STATS.GATHER_DICTIONARY_STATS
END;

Создайте шаблон миграции
Два параметра --project_base и --init_project при использовании указывают ora2pg создать шаблон проекта с рабочим деревом, файлом конфигурации и сценарием для экспорта всех объектов из базы данных Oracle. Вот пример использования команды:

ora2pg --project_base /app/migration/ --init_project test_project
Создание проекта test_project.
/app/migration/test_project/
        schema/
                dblinks/
                directories/
                functions/
                grants/
                mviews/
                packages/
                partitions/
                procedures/
                sequences/
                synonyms/
                tables/
                tablespaces/
                triggers/
                types/
                views/
        sources/
                functions/
                mviews/
                packages/
                partitions/
                procedures/
                triggers/
                types/
                views/
        data/
        config/
        reports/

Создание общего файла конфигурации
Создание сценария export_schema.sh для автоматизации всего экспорта.
Создание сценария import_all.sh для автоматизации всего импорта.

Он создаёт общий файл конфигурации, где вам просто нужно определить соединение с базой данных Oracle и сценарий оболочки под названием export_schema.sh. Каталог sources/ будет содержать код Oracle, а каталог schema/ — код, перенесённый в PostgreSQL. Отчёт будет содержать html-отчёты с оценкой стоимости миграции.

Если вы хотите использовать свой собственный файл конфигурации по умолчанию, используйте опцию -c, чтобы указать путь к этому файлу. Переименуйте его с суффиксом .dist, если вы хотите, чтобы ora2pg применил общие значения конфигурации, иначе файл конфигурации будет скопирован без изменений. Вы установили соединение с базой данных Oracle, вы можете выполнить скрипт export_schema.sh, который экспортирует все типы объектов из вашей базы данных Oracle и выводит файлы DDL в подкаталоги схемы. В конце экспорта будет дана команда для последующего экспорта данных после того, как импорт схемы будет выполнен и проверен.

Вы можете загрузить сгенерированные файлы DDL вручную или использовать второй скрипт import_all.sh для интерактивного импорта этих файлов. Если такой вид миграции вам не подходит, рекомендуется использовать эти скрипты.

**Подключение к базе данных Oracle**
Есть 5 директив конфигурации для управления доступом к базе данных Oracle.

* ORACLE_HOME
Используется для установки переменной среды ORACLE_HOME в библиотеки Oracle, необходимые модулю Perl DBD::Oracle.

* ORACLE_DSN
Эта директива используется для задания имени источника данных в форме стандартного DBI DSN. Например:
dbi:Oracle:host=oradb_host.myhost.com;sid=DB_SID;port=1521
или
dbi:Oracle:DB_SID
В версии 18c это может быть, например:
dbi:Oracle:host=192.168.1.29;service_name=pdb1;port=1521
Для второй нотации SID должен быть объявлен в хорошо известном файле $ORACLE_HOME/network/admin/tnsnames.ora или в пути, указанном для переменной среды TNS_ADMIN.

Для MySQL DSN будет выглядеть так:
dbi:mysql:host=192.168.1.10;database=sakila;port=3306
Часть «sid» заменяется на «database».

Для MS SQL Server это будет выглядеть следующим образом:
dbi:ODBC:driver=msodbcsql18;server=mydb.database.windows.net;database=testdb;TrustServerCertificate=yes

* ORACLE_USER и ORACLE_PWD
Эти две директивы используются для определения пользователя и пароля для подключения к базе данных Oracle. Обратите внимание, что если возможно, лучше войти в систему как суперпользователь Oracle, чтобы избежать проблем с грантами во время сканирования базы данных и убедиться, что ничего не пропущено.

Если вы не предоставите учётные данные с помощью ORACLE_PWD и у вас установлен модуль Perl Term::ReadKey, Ora2Pg запросит пароль в интерактивном режиме. Если ORACLE_USER не установлен, он также будет запрашиваться в интерактивном режиме.

Чтобы подключиться к локальному экземпляру ORACLE с подключением «as sysdba», необходимо установить ORACLE_USER в «/» и пустой пароль.

Чтобы установить соединение с использованием Oracle Secure External Password Store (SEPS), сначала настройте Oracle Wallet, а затем установите обе директивы ORACLE_USER и ORACLE_PWD в специальное значение «__SEPS__» (без кавычек, но с двойным подчёркиванием).

* USER_GRANTS
Установите эту директиву в 1, если вы подключаетесь к базе данных Oracle как простой пользователь и не имеете достаточных грантов для извлечения данных из таблиц DBA_. Это будет использовать таблицы ALL_.

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

* TRANSACTION
Эту директиву можно использовать, если вы хотите изменить уровень изоляции транзакции по умолчанию при экспорте данных. По умолчанию теперь устанавливается уровень сериализуемой транзакции для обеспечения согласованности данных. Допустимые значения для этой директивы:
readonly: 'SET TRANSACTION READ ONLY',
readwrite: 'SET TRANSACTION READ WRITE',
serializable: 'SET TRANSACTION ISOLATION LEVEL SERIALIZABLE'
committed: 'SET TRANSACTION ISOLATION LEVEL READ COMMITTED',

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

* INPUT_FILE
Эта директива не контролирует подключение к базе данных Oracle или не отключает использование любой базы данных Oracle путём принятия файла в качестве аргумента. Установите эту директиву для файла. **Перевод текста на русский язык:**

**PL/SQL Oracle код: функции, процедуры и полное тело пакета для предотвращения подключения Ora2Pg к базе данных Oracle**

Ora2Pg может быть использован с большинством типов экспорта: TABLE, TRIGGER, PROCEDURE, VIEW, FUNCTION или PACKAGE и т. д.

*ORA_INITIAL_COMMAND*
Эта директива может использоваться для отправки начальной команды в Oracle сразу после соединения. Например, чтобы разблокировать политику перед чтением объектов или установить некоторые параметры сеанса. Эта директива может быть использована несколько раз.

**Шифрование данных с сервером Oracle**
Если ваш конфигурационный файл клиента Oracle уже включает метод шифрования, то DBD:Oracle использует эти настройки для шифрования соединения при извлечении данных. Например, если вы настроили конфигурационный файл Oracle Client (sqlnet.ora или .sqlnet) со следующей информацией:

# Настроить шифрование соединений с Oracle
SQLNET.ENCRYPTION_CLIENT = required
SQLNET.ENCRYPTION_TYPES_CLIENT = (AES256, RC4_256)
SQLNET.CRYPTO_SEED = «должно быть 10–70 случайных символов»

Любой инструмент, использующий клиент Oracle для общения с базой данных, будет зашифрован, если вы установите шифрование сеанса, как указано выше.
Например, Perl DBI использует DBD-Oracle, который использует клиент Oracle для фактической обработки связи с базой данных. Если установка клиента Oracle, используемого Perl, настроена на запрос зашифрованных соединений, то ваше соединение Perl с базой данных Oracle также будет зашифровано.
Полные сведения доступны по ссылке: https://kb.berkeley.edu/jivekb/entry.jspa?externalID=1005

**Тестирование соединения**
После того как вы установили DSN базы данных Oracle, вы можете выполнить ora2pg, чтобы проверить, работает ли он:
ora2pg -t SHOW_VERSION -c config/ora2pg.conf
покажет версию сервера базы данных Oracle. Потратьте некоторое время на тестирование вашей установки, так как большинство проблем возникает здесь, остальные шаги настройки более технические.

**Устранение неполадок**
Если выходной файл .sql не экспортировал ничего, кроме заголовка и нижнего колонтитула транзакции Pg, есть две возможные причины.
Перл-скрипт ora2pg выдаёт ошибку ORA-XXX, что означает, что ваши DSN или информация для входа неверны, проверьте ошибку и ваши настройки и попробуйте снова. Перл-скрипт ничего не говорит, а выходной файл пуст: у пользователя нет разрешения на извлечение чего-либо из базы данных. Попробуйте подключиться к Oracle как суперпользователь или взгляните на директиву USER_GRANTS выше и на следующий раздел, особенно на директиву SCHEMA.

LOGFILE
По умолчанию все сообщения отправляются на стандартный вывод. Если вы укажете путь к файлу для этой директивы, весь вывод будет добавлен в этот файл.

**Схема Oracle для экспорта**
Экспорт базы данных Oracle может быть ограничен определённой схемой или пространством имён, это может быть обязательным после подключения пользователя базы данных.

SCHEMA
Эта директива используется для установки имени схемы во время экспорта. Например:
SCHEMA APPS
извлечёт объекты, связанные со схемой APPS.
Когда имя схемы не указано и EXPORT_SCHEMA включён, Ora2Pg экспортирует все объекты из всех схем экземпляра Oracle с их именами, предваряемыми именем схемы.

EXPORT_SCHEMA
По умолчанию схема Oracle не экспортируется в базу данных PostgreSQL, и все объекты создаются под стандартным пространством имён Pg. Если вы хотите также экспортировать эту схему и создать все объекты под этим пространством, установите директиву EXPORT_SCHEMA в 1. Это установит путь поиска схемы в верхней части файла экспорта SQL на имя схемы, установленное в директиве SCHEMA, с пространством имён pg_catalog по умолчанию. Если вы хотите изменить этот путь, используйте директиву PG_SCHEMA.

CREATE_SCHEMA
Включите/отключите порядок SQL CREATE SCHEMA в начале выходного файла. Он включается с помощью **База данных**

Можно установить директиву *FORCE_SECURITY_INVOKER* в значение 1 или установить для неё совершенно другое имя пользователя, задав значение этой директивы равным этому имени пользователя.

*FORCE_SECURITY_INVOKER*
Ora2Pg использует привилегии безопасности функций, установленные в Oracle, и они часто определяются как SECURITY DEFINER. Если вы хотите переопределить эти привилегии безопасности для всех функций и вместо этого использовать SECURITY DEFINER, включите эту директиву.

**USE_TABLESPACE**
При включении этой директивы Ora2Pg экспортирует все таблицы, индексы и ограничения с использованием имени табличного пространства, определённого в базе данных Oracle. Это работает только с табличными пространствами, которые не являются TEMP, USERS и SYSTEM.

**WITH_OID**
Активация этой директивы заставит Ora2Pg добавлять WITH (OIDS) при создании таблиц или представлений в виде таблиц. По умолчанию используется то же самое, что и в PostgreSQL, отключено.

**LOOK_FORWARD_FUNCTION**
Список схем для получения метаинформации о функциях/процедурах, используемых в текущем экспорте схемы. При замене вызова функции с параметрами OUT, если функция объявлена в другом пакете, переписать вызов функции невозможно, поскольку Ora2Pg знает только о функциях, объявленных в текущей схеме. Установив список схем через запятую в качестве значения этой директивы, Ora2Pg будет искать вперёд в этих пакетах все объявления функций/процедур/пакетов перед переходом к текущему экспорту схемы.

**NO_FUNCTION_METADATA**
Заставляет Ora2Pg не искать объявление функции. Обратите внимание, что это предотвратит перепись вызовов функций Ora2Pg, если это необходимо. Не включайте её, если поиск вперёд по функциям нарушает другой экспорт.

Тип экспорта
Действие экспорта выполняется после одной конфигурации директивы «TYPE», некоторые другие добавляют больше контроля над тем, что действительно должно быть экспортировано.

TYPE
Вот различные значения директивы TYPE, по умолчанию — TABLE:
— TABLE: Извлекает все таблицы с индексами, первичными ключами, уникальными ключами, внешними ключами и проверочными ограничениями.
— VIEW: Извлекаются только представления.
— GRANT: Извлекаются роли, преобразованные в группы Pg, пользователи и гранты на все объекты.
— SEQUENCE: Извлекается вся последовательность и их последняя позиция.
— TABLESPACE: Извлекаются пространства хранения для таблиц и индексов (Pg >= v8).
— TRIGGER: Извлекаются триггеры, определённые после действий.
— FUNCTION: Извлекаются функции.
— PROCEDURE: Извлекаются процедуры.
— PACKAGE: Извлекаются пакеты и тела пакетов.
— INSERT: Извлечение данных в виде инструкции INSERT.
— COPY: Извлечение данных в виде инструкции COPY.
— PARTITION: Извлечение диапазонов и списков разделов Oracle с подразделами.
— TYPE: Извлечение пользовательских типов Oracle.
— FDW: Экспорт таблиц Oracle в качестве внешней таблицы для FDW Oracle, MySQL и SQL Server.
— MVIEW: Экспорт материализованного представления.
— QUERY: Попытка автоматического преобразования запросов Oracle SQL.
— KETTLE: Генерация файлов шаблонов XML ktr для использования Kettle.
— DBLINK: Создание внешнего сервера данных Oracle для использования в качестве dblink.
— SYNONYM: Экспорт синонимов Oracle в виде представлений объектов других схем.
— DIRECTORY: Экспорт каталогов Oracle в виде объектов расширения external_file.
— LOAD: Отправка списка запросов по нескольким соединениям PostgreSQl.
— TEST: Выполнение сравнения между базой данных Oracle и PostgreSQL.
— TEST_COUNT: Выполнение подсчёта количества строк между таблицей Oracle и PostgreSQL.
— TEST_VIEW: Подсчёт количества строк, возвращаемых представлениями с обеих сторон.
— TEST_DATA: Проверка достоверности данных в строках с обеих сторон.
— SEQUENCE_VALUES: экспорт DDL для установки последних значений последовательностей. Таблица PostgreSQL.

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

* SHOW_REPORT: показать подробный отчёт о содержимом базы данных Oracle.

Вот пример отчёта: http://ora2pg.darold.net/report.html.

Также есть более продвинутый отчёт со стоимостью миграции. См. специальную главу об оценке стоимости миграции.

ESTIMATE_COST
Активирует оценку стоимости миграции. Должен использоваться только с типами экспорта SHOW_REPORT, FUNCTION, PROCEDURE, PACKAGE и QUERY. По умолчанию отключён. Вы можете использовать параметр командной строки --estimate_cost для активации этой функции. Обратите внимание, что включение этой директивы приведёт к активации PLSQL_PGSQL.

COST_UNIT_VALUE
Устанавливает значение в минутах единицы оценки стоимости миграции. По умолчанию — пять минут на единицу. Используйте параметр командной строки --cost_unit_value, чтобы изменить значение единицы.

DUMP_AS_HTML
По умолчанию при использовании SHOW_REPORT отчёт о миграции генерируется в виде простого текста. Включение этой директивы заставит ora2pg создать отчёт в формате HTML.

См. http://ora2pg.darold.net/report.html для примера отчёта.

HUMAN_DAYS_LIMIT
Используйте эту директиву, чтобы переопределить количество человеко-дней, после которого уровень оценки миграции должен переключиться с B на C. По умолчанию установлено значение 10 человеко-дней.

JOBS
Эта конфигурация добавляет поддержку многопроцессорности для COPY, FUNCTION и PROCEDURE типов экспорта. Значение — это количество процессов, которые будут использоваться. По умолчанию многопроцессорность отключена.

Эта директива используется для установки количества ядер, используемых для параллельного импорта данных в PostgreSQL. Во время экспорта FUNCTION или PROCEDURE каждая функция будет переведена в plpgsql с использованием нового процесса. Повышение производительности может быть очень важным, когда нужно преобразовать множество функций.

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

Не работает под операционной системой Windows, просто отключено.

ORACLE_COPIES
Эта конфигурация добавляет многопроцессорную поддержку для извлечения данных из Oracle. Значение — количество процессов, используемых для распараллеливания запроса SELECT. По умолчанию параллельный запрос отключён.

Параллелизм основан на разделении запроса в соответствии с количеством ядер, заданным в качестве значения ORACLE_COPIES:

SELECT * FROM MYTABLE WHERE ABS(MOD(COLUMN, ORACLE_COPIES)) = CUR_PROC

где COLUMN — технический ключ, такой как первичный или уникальный ключ, на основе которого будет происходить разделение, а CUR_PROC — текущий процесс, используемый запросом. Также можно принудительно указать имя столбца с помощью директивы DEFINED_PK.

Не работает под операционной системой Windows, просто отключено.

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

DEFINED_PK EMPLOYEES:employee_id

Параллельный запрос, который будет использоваться, если -J или ORACLE_COPIES установлен на 8:

SELECT * FROM EMPLOYEES WHERE ABS(MOD(employee_id, 8)) = N

где N — текущий разветвлённый процесс, начиная с 0.

PARALLEL_TABLES
Эта директива используется для определения количества таблиц, которые будут обрабатываться параллельно для извлечения данных. Ограничение — количество ядер на вашем компьютере. Ora2Pg откроет одно соединение с базой данных для каждой параллельной выборки таблицы. Эта директива, если она больше 1, сделает недействительной ORACLE_COPIES, но не JOBS, поэтому реальное количество процессов, которое будет использоваться, равно PARALLEL_TABLES * JOBS.

Обратите внимание, что эта директива при... **Установить верхний предел, который также автоматически включит директиву FILE_PER_TABLE при экспорте в файлы.**

Это используется для экспорта таблиц и представлений в отдельные файлы.

**Использовать PARALLEL_TABLES для параллелизма с действиями COPY, INSERT и TEST_DATA.** Это также полезно с TEST, TEST_COUNT и SHOW_TABLE, если используется --count_rows для реального подсчёта строк.

DEFAULT_PARALLELISM_DEGREE:

Можно заставить Ora2Pg использовать /*+ PARALLEL(tbname, degree) */ подсказку в каждом запросе, используемом для экспорта данных из Oracle, установив значение больше 1 для этой директивы. Значение 0 или 1 отключает использование параллельной подсказки. По умолчанию отключено.

FDW_SERVER:

Эта директива используется для установки имени внешнего сервера данных, которое используется в команде «CREATE SERVER name FOREIGN DATA WRAPPER <fdw_extension> ...». Это имя будет использоваться в командах SQL «CREATE FOREIGN TABLE...» и для импорта данных с использованием oracle_fdw. По умолчанию внешний сервер не определён. Это касается только типа экспорта FDW, COPY и INSERT. Для типа экспорта FDW по умолчанию используется orcl.

FDW_IMPORT_SCHEMA:

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

ORACLE_FDW_PREFETCH:

Поведение Ora2Pg по умолчанию — НЕ устанавливать опцию «prefetch» для oracle_fdw при использовании для COPY и INSERT. Эта директива позволяет установить prefetch. См. документацию oracle_fdw для текущего значения по умолчанию.

ORACLE_FDW_COPY_MODE:

При использовании Ora2Pg COPY с oracle_fdw можно использовать два разных режима: 1) «local», который использует psql на хосте, на котором запущен Ora2Pg, для двоичного потока «TO»; 2) «server», который использует PostgreSQL на стороне сервера для двоичного потока «TO». Оба режима используют psql для «FROM STDIN BINARY». Однако «local» запускает psql «FROM STDIN BINARY» на хосте, с которого запускается Ora2Pg, тогда как «server» запускает psql «FROM STDIN BINARY» на сервере PostgreSQL. Режим «local» должен работать в любой системе на основе PostgreSQL, включая управляемые предложения, которые, как ожидается, не поддерживают использование режима «server» из-за разрешений. По умолчанию используется режим «local», поскольку он совместим с большим количеством конфигураций.

ORACLE_FDW_COPY_FORMAT:

При использовании Ora2Pg COPY с oracle_fdw можно использовать либо двоичный, либо CSV формат данных. Двоичный обеспечивает лучшую производительность, однако требует точного соответствия типов данных между FDW и целевой таблицей. CSV обеспечивает большую гибкость в отношении соответствия типов данных: если типы данных FDW и целевые функционально совместимы, столбцы могут быть скопированы. По умолчанию используется двоичный формат.

DROP_FOREIGN_SCHEMA:

Ora2Pg по умолчанию удаляет временную схему ora2pg_fdw_import, используемую для импорта внешней схемы Oracle перед каждым новым импортом. Если вы хотите сохранить существующую схему из-за изменений или использования стороннего сервера, отключите эту директиву.

EXTERNAL_TO_FDW:

Эта директива, включённая по умолчанию, позволяет экспортировать внешние таблицы Oracle как таблицы file_fdw. Чтобы вообще не экспортировать эти таблицы, установите для директивы значение 0.

INTERNAL_DATE_MAX:

Внутренние метки времени извлекаются из пользовательского типа в следующем формате: 01-JAN-77 12.00.00.000000 AM. Невозможно узнать точный век, который следует использовать, поэтому по умолчанию любой год ниже 49 будет добавлен к 2000, а остальные — к 1900. Вы можете использовать эту директиву, чтобы изменить значение по умолчанию 49. Это актуально только в том случае, если у вас есть пользовательский тип с столбцом timestamp.

AUDIT_USER:

Установите список имён пользователей через запятую, которые должны использоваться. **Отфильтровать**

Запросы из таблицы DBA_AUDIT_TRAIL. По умолчанию эта таблица не сканируется, и запросы не ищутся. Этот параметр используется только с типами экспорта SHOW_REPORT и QUERY без входного файла для запросов. Обратите внимание, что запросы будут нормализованы перед выводом в отличие от случая, когда файл задаётся с помощью опции -i или директивы INPUT.

**FUNCTION_CHECK**

Отключите эту директиву, если вы хотите отключить check_function_bodies.

SET check_function_bodies = false;

Это отключает проверку строки тела функции во время CREATE FUNCTION. По умолчанию используется настройка postgresql.conf, которая включает её по умолчанию.

**ENABLE_BLOB_EXPORT**

Экспорт BLOB занимает время, в некоторых случаях вы можете захотеть экспортировать все данные, кроме столбцов BLOB. В этом случае отключите эту директиву, и столбцы BLOB не будут включены в экспорт данных. Убедитесь, что целевой столбец bytea не имеет ограничения NOT NULL.

**ENABLE_CLOB_EXPORT**

То же поведение, что и ENABLE_BLOB_EXPORT, но для CLOB.

**DATA_EXPORT_ORDER**

По умолчанию порядок экспорта данных будет осуществляться путём сортировки по имени таблицы. Если у вас есть огромные таблицы в конце алфавитного порядка, и вы используете многопроцессорность, может быть лучше установить порядок сортировки по размеру, чтобы несколько небольших таблиц могли быть обработаны до того, как закончатся самые большие таблицы. В этом случае установите эту директиву на размер. Возможные значения: имя и размер. Обратите внимание, что тип экспорта SHOW_TABLE и SHOW_COLUMN также будет использовать этот порядок сортировки, а не только тип экспорта COPY или INSERT. Если вы хотите задать собственный порядок экспорта, просто укажите имя файла в качестве значения, содержащего упорядоченный список таблиц для экспорта. Должен быть список одной таблицы на строку, в верхнем регистре для Oracle.

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

**ALLOW**
Эта директива позволяет вам установить список объектов, экспорт которых должен быть ограничен, исключая все остальные объекты того же типа экспорта. Значение представляет собой список имён объектов через пробел или запятую для экспорта. Вы можете включить допустимое регулярное выражение в список. Например:

ALLOW           EMPLOYEES SALE_.* COUNTRIES .*_GEOM_SEQ

будет экспортировать объекты с именем EMPLOYEES, COUNTRIES, все объекты, начинающиеся с 'SALE_' и все объекты с именем, оканчивающимся на '_GEOM_SEQ'. Объект зависит от типа экспорта. Обратите внимание, что регулярное выражение не работает с базой данных 8i, вместо этого вы должны использовать заполнитель %; Ora2Pg будет использовать оператор LIKE.

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

ora2pg -p -c ora2pg.conf -t TRIGGER -a 'TABLE[employees]'

ограничит экспорт триггеров теми, которые определены для таблицы employees. Если вы хотите извлечь все триггеры, кроме некоторых INSTEAD OF триггеров:

ora2pg -c ora2pg.conf -t TRIGGER -e 'VIEW[trg_view_.*]'

Или более сложная форма:

ora2pg -p -c ora2pg.conf -t TABLE -a 'TABLE[EMPLOYEES]' \
        -e 'INDEX[emp_.*];CKEY[emp_salary_min]'

Эта команда экспортирует определение таблицы сотрудников, но исключит все индексы, начинающиеся с emp_, и ограничение CHECK с именем emp_salary_min.
При экспорте раздела вы можете исключить некоторые таблицы разделов, используя

ora2pg -p -c ora2pg.conf -t PARTITION -e 'PARTITION[PART_199.* PART_198.*]'

Это исключит таблицы разделов за 1980–1999 годы из экспорта, но не основную таблицу разделов. Триггер также **Адаптировано для исключения этих таблиц**

С помощью GRANT export вы можете использовать эту расширенную форму, чтобы исключить некоторых пользователей из экспорта или ограничить экспорт только некоторыми другими:

    * ora2pg -p -c ora2pg.conf -t GRANT -a 'USER1 USER2'

или

    * ora2pg -p -c ora2pg.conf -t GRANT -a 'GRANT[USER1 USER2]'

ограничит экспорт грантов пользователям USER1 и USER2. Но если вы не хотите экспортировать гранты на некоторые функции для этих пользователей, например:

    * ora2pg -p -c ora2pg.conf -t GRANT -a 'USER1 USER2' -e 'FUNCTION[adm_.*];PROCEDURE[adm_.*]'

Расширенные фильтры могут потребовать некоторого изучения.

Oracle не позволяет использовать выражение опережающего просмотра, поэтому вы можете захотеть исключить некоторые объекты, соответствующие определённому вами регулярному выражению ALLOW. Например, если вы хотите экспортировать все таблицы, начинающиеся с E, но не те, которые начинаются с EXP, это невозможно сделать в одном выражении. Вот почему вы можете начать регулярное выражение с символа !, чтобы исключить объекты, соответствующие регулярному выражению, указанному сразу после него. Наш предыдущий пример можно записать следующим образом:

    * ALLOW   E.* !EXP.*

это будет переведено в:

     * REGEXP_LIKE(..., '^E.*$') AND NOT REGEXP_LIKE(..., '^EXP.*$')

в выражении поиска объекта.

**EXCLUDE**

Эта директива противоположна предыдущей, она позволяет вам определить разделенный пробелом или запятой список имён объектов для исключения из экспорта. Вы можете включить допустимые регулярные выражения в список. Например:

    * EXCLUDE         EMPLOYEES TMP_.* COUNTRIES

исключит объекты с именами EMPLOYEES, COUNTRIES и все таблицы, начинающиеся с 'tmp_'.

Например, вы можете запретить экспорт некоторых нежелательных функций с помощью этой директивы:

    * EXCLUDE         write_to_.* send_mail_.*

этот пример исключит все функции, процедуры или функции в пакете с именем, начинающимся с этих регулярных выражений. Обратите внимание, что регулярные выражения не будут работать с базой данных 8i, вместо этого вы должны использовать заполнитель %; Ora2Pg будет использовать оператор NOT LIKE.

См. выше (директиву «ALLOW») для расширенного синтаксиса.

**NO_EXCLUDED_TABLE**

По умолчанию Ora2Pg исключает из экспорта некоторые «мусорные» таблицы Oracle, которые никогда не должны быть частью экспорта. Такое поведение генерирует множество выражений REGEXP_LIKE, которые замедляют экспорт при просмотре таблиц. Чтобы отключить это поведение, включите эту директиву, вам придётся исключить или очистить ненужные таблицы позже самостоятельно. Регулярное выражение, используемое для исключения таблицы, определено в массиве @EXCLUDED_TABLES в lib/Ora2Pg.pm. Обратите внимание, что это поведение не зависит от конфигурации директивы EXCLUDE.

**VIEW_AS_TABLE**

Установите, какие представления экспортировать как таблицы. По умолчанию — ни одного. Значение должно быть списком имён представлений или регулярных выражений, разделённых пробелом или запятыми. Если имя объекта является представлением, а тип экспорта — TABLE, представление будет экспортировано как инструкция создания таблицы. Если тип экспорта COPY или INSERT, будут экспортированы соответствующие данные.

Подробнее см. в главе «Экспорт представлений в виде таблицы PostgreSQL».

**MVIEW_AS_TABLE**

Установите, какие материализованные представления экспортировать в виде таблиц. По умолчанию ни одного. Значение должно представлять собой список имён материализованных представлений или регулярных выражений, разделенных пробелами или запятыми. Если имя объекта — материализованное представление, а тип экспорта — TABLE, представление будет экспортироваться как инструкция создания таблицы. Если типом экспорта является COPY или INSERT, то будут экспортированы соответствующие данные.

**NO_VIEW_ORDERING**

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

**GRANT_OBJECT**

При экспорте грантов вы можете указать список через запятую... Объекты, для которых будет экспортироваться привилегия. По умолчанию экспорт осуществляется для всех объектов. Возможные значения: TABLE, VIEW, MATERIALIZED VIEW, SEQUENCE, PROCEDURE, FUNCTION, PACKAGE BODY, TYPE, SYNONYM, DIRECTORY. Одновременно можно использовать только один тип объекта. Например, установите значение TABLE, если вы хотите экспортировать привилегии только для таблиц. Вы можете использовать опцию -g для перезаписи этого параметра.

При использовании этой директивы экспорт пользователей запрещается, если не установлено значение USER. В этом случае экспортируются только определения пользователей.

WHERE
Эта директива позволяет вам указать предложение WHERE при дампинге содержимого таблиц. Значение строится следующим образом: TABLE_NAME[WHERE_CLAUSE], или если у вас есть только одно предложение where для каждой таблицы, просто поместите предложение where в качестве значения. Оба варианта также возможны. Вот несколько примеров:

# Глобальное предложение where, применяемое ко всем таблицам, включённым в экспорт
WHERE 1=1

# Применить предложение where только к таблице TABLE_NAME
WHERE TABLE_NAME[ID1='001']

# Применяет два разных предложения к таблицам TABLE_NAME и OTHER_TABLE и общее предложение where на DATE_CREATE ко всем остальным таблицам
WHERE TABLE_NAME[ID1='001' OR ID1='002] DATE_CREATE > '2001-01-01' OTHER_TABLE[NAME='test']

Любое предложение where, не включённое в предложение table name bracket, будет применяться ко всем экспортируемым таблицам, включая таблицы, определённые в предложении where. Эти предложения WHERE полезны, если вы хотите заархивировать некоторые данные или, наоборот, экспортировать только некоторые недавние данные.

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

WHERE ROWNUM < 1000

и для MySQL используйте следующее:

WHERE 1=1 LIMIT 1,1000

Это также может быть ограничено экспортом данных некоторых таблиц.

Параметр командной строки -W или --where переопределит эту директиву для глобальной части и для каждой таблицы, если имена таблиц совпадают.

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

LOG_ON_ERROR
Включите эту директиву, если вы хотите продолжить прямой импорт данных при ошибке. Когда Ora2Pg получит ошибку в операторе COPY или INSERT из PostgreSQL, он запишет оператор в файл с именем TABLENAME_error.log в выходном каталоге и продолжит обработку следующего блока данных. Таким образом, вы можете попытаться исправить оператор и вручную перезагрузить файл журнала ошибок. По умолчанию отключено: прервать импорт при ошибке.

REPLACE_QUERY
Иногда вы можете захотеть извлечь данные из таблицы Oracle, но вам нужен для этого специальный запрос. Не просто «SELECT * FROM table», как это делает Ora2Pg, а более сложный запрос. Эта директива позволяет перезаписать запрос, используемый Ora2Pg для извлечения данных. Формат — TABLENAME[SQL_QUERY]. Если у вас несколько таблиц для извлечения путём замены запроса Ora2Pg, вы можете определить несколько строк REPLACE_QUERY.

CONTROL OF FULL TEXT SEARCH EXPORT
Несколько директив могут использоваться для управления способом экспорта индексов полнотекстового поиска Ora2Pg. По умолчанию индексы CONTEXT будут экспортированы в индексы FTS PostgreSQL, но индексы CTXCAT будут экспортированы как индексы с использованием расширения pg_trgm.

CONTEXT_AS_TRGM
Заставляет Ora2Pg переводить индексы Oracle Text в индексы PostgreSQL с использованием расширения pg_trgm. По умолчанию переводятся индексы CONTEXT в индексы FTS и CTXCAT. **REFERENCE**

Как и ранее. Значение «duplicate» дублирует указанный столбец в секционированной таблице и применяет то же секционирование из указанной таблицы к секционированной. Если значение — число, таблица будет секционирована методом HASH с использованием значения в качестве модуля. Например, если вы установите значение 4, будет создано 4 раздела HASH.

**DISABLE_UNLOGGED**

По умолчанию Ora2Pg экспортирует таблицы Oracle с атрибутом NOLOGGING как таблицы UNLOGGED. Вы можете полностью отключить эту функцию, потому что потеряете все данные из неотмеченных таблиц в случае сбоя PostgreSQL. Установите значение 1, чтобы экспортировать все таблицы как обычные таблицы.

**DOUBLE_MAX_VARCHAR**

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

Oracle Spatial to PostGis

Ora2Pg полностью экспортирует пространственный объект из базы данных Oracle. Есть несколько конфигурационных директив, которые можно использовать для управления экспортом.

**AUTODETECT_SPATIAL_TYPE**

По умолчанию Ora2Pg ищет индексы, чтобы увидеть тип пространственного ограничения и измерения, определённые в Oracle. Эти ограничения передаются при создании индекса, например:

CREATE INDEX...INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS('sdo_indx_dims=2, layer_gtype=point');

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

Директива AUTODETECT_SPATIAL_TYPE позволяет Ora2Pg автоматически определять реальный пространственный тип и измерение, используемые в пространственном столбце, в противном случае используется неограниченный тип «геометрия». Включение этой функции заставит Ora2Pg сканировать выборку из 50 000 столбцов, чтобы посмотреть на используемый GTYPE. Вы можете увеличить или уменьшить размер выборки, установив желаемое количество строк для сканирования в значении AUTODETECT_SPATIAL_TYPE. Директива включена по умолчанию.

Например, в случае столбца с именем shape и определённого с типом Oracle SDO_GEOMETRY при отключённой директиве он будет преобразован следующим образом:
shape geometry(GEOMETRY) или shape geometry(GEOMETRYZ, 4326)

и если директива включена и столбец содержит только один тип геометрии, который использует одно измерение:
shape geometry(POLYGON, 4326) или shape geometry(POLYGONZ, 4326)

с двух- или трёхмерным полигоном.

**CONVERT_SRID**

Эта директива позволяет вам контролировать автоматическое преобразование SRID Oracle в стандартный EPSG. Если включено, Ora2Pg будет использовать функцию Oracle sdo_cs.map_oracle_srid_to_epsg() для преобразования всех SRID. Включено по умолчанию.

Если SDO_SRID, возвращённый Oracle, равен NULL, он будет заменён значением по умолчанию 8307, преобразованным в его значение EPSG: 4326 (см. DEFAULT_SRID).

Если значение больше 1, все SRID будут принудительно установлены на это значение, в этом случае DEFAULT_SRID не будет использоваться, когда Oracle возвращает нулевое значение, и значение будет принудительно установлено на CONVERT_SRID.

Обратите внимание, что также можно установить значение EPSG на стороне Oracle, когда sdo_cs.map_oracle_srid_to_epsg() возвращает NULL, если вы хотите принудительно установить значение:
system@db> UPDATE sdo_coord_ref_sys SET legacy_code=41014 WHERE srid = 27572;

**DEFAULT_SRID**

Используйте эту директиву, чтобы переопределить используемый по умолчанию EPSG SRID: 4326. Может быть перезаписано CONVERT_SRID (см. выше).

**GEOMETRY_EXTRACT_TYPE**

Эта директива может принимать три значения: WKT (по умолчанию), WKB и INTERNAL. Когда установлено значение WKT, Ora2Pg будет использовать SDO_UTIL.TO_WKTGEOMETRY() для извлечения геометрических данных. Когда установлено значение WKB, Ora2Pg будет использовать двоичный вывод с помощью... **SDO_UTIL.TO_WKBGEOMETRY()**

Если эти два типа извлечения вызываются на стороне Oracle, они работают медленно, и вы можете легко достичь Out Of Memory, когда у вас много строк. Также WKB не может экспортировать 3D-геометрию и некоторые геометрии, такие как CURVEPOLYGON. В этом случае вы можете использовать тип извлечения INTERNAL. Он будет использовать библиотеку Pure Perl для преобразования данных SDO_GEOMETRY в представление WKT, перевод выполняется на стороне Ora2Pg. Это работа в процессе, пожалуйста, проверьте ваши экспортированные геометрические данные перед использованием. Тип пространственного объекта по умолчанию — INTERNAL.

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

**ST_SRID_FUNCTION**
Функция Oracle для использования для извлечения srid из метаинформации ST_Geometry. По умолчанию: ST_SRID, например, для ArcSDE должно быть установлено значение sde.st_srid.

**ST_DIMENSION_FUNCTION**
Функция Oracle для использования для извлечения измерения из метаинформации ST_Geometry. По умолчанию: ST_DIMENSION, например, для ArcSDE должно быть установлено значение sde.st_dimention.

**ST_GEOMETRYTYPE_FUNCTION**
Функция Oracle для использования для извлечения типа геометрии из столбца ST_Geometry. По умолчанию: ST_GEOMETRYTYPE, например, для ArcSDE должно быть установлено значение sde.st_geometrytype.

**ST_ASBINARY_FUNCTION**
Функция Oracle, используемая для преобразования значения ST_Geometry в формат WKB. По умолчанию: ST_ASBINARY, например, для ArcSDE должно быть установлено значение sde.st_asbinary.

**ST_ASTEXT_FUNCTION**
Функция Oracle, используемая для преобразования значения ST_Geometry в формат WKT. По умолчанию: ST_ASTEXT, например, для ArcSDE должно быть установлено значение sde.st_astext.

Импорт PostgreSQL
По умолчанию преобразование в формат PostgreSQL записывается в файл «output.sql». Команда:
psql mydb < output.sql
импортирует содержимое файла output.sql в базу данных PostgreSQL mydb.

**DATA_LIMIT**
Когда вы выполняете INSERT/COPY экспорт Ora2Pg, действуйте порциями DATA_LIMIT кортежей для повышения скорости. Кортежи хранятся в памяти перед записью на диск, поэтому, если вы хотите ускорить работу и у вас достаточно системных ресурсов, вы можете увеличить этот предел до более высокого значения, например: 100 000 или 1 000 000. До версии 7.0 значение 0 означало отсутствие ограничения, так что все кортежи хранились в памяти перед сбросом на диск. В ветке 7.x это было удалено, и размер блока будет установлен по умолчанию: 10 000.

**BLOB_LIMIT**
Когда Ora2Pg обнаружит таблицу с некоторыми BLOB, он автоматически уменьшит значение этой директивы, разделив его на 10, пока его значение не станет ниже 1000. Вы можете контролировать это значение, установив BLOB_LIMIT. Экспорт BLOB использует много ресурсов, установка слишком высокого значения может привести к OOM.

**CLOB_AS_BLOB**
Примените то же поведение к CLOB, что и настройки BLOB_LIMIT. Это особенно полезно, если у вас есть большие данные CLOB. По умолчанию включено.

**OUTPUT**
Имя выходного файла Ora2Pg можно изменить с помощью этой директивы. Значение по умолчанию — output.sql. Если вы установите имя файла с расширением .gz или .bz2, вывод будет автоматически сжат. Для этого требуется, чтобы модуль Perl Compress::Zlib был установлен, если расширение имени файла — .gz, и чтобы системная команда bzip2 была установлена для расширения .bz2.

**OUTPUT_DIR**
Начиная с версии 7.0 вы можете определить базовый каталог, в который будет записан файл. Каталог должен существовать.

**BZIP2**
Эта директива позволяет вам указать полный путь к программе bzip2, если она не может быть найдена в переменной среды PATH.

**FILE_PER_CONSTRAINT**
Разрешить сохранение ограничений объектов в отдельном файле во время экспорта схемы. Файл будет называться CONSTRAINTS_OUTPUT, где OUTPUT — значение соответствующей директивы конфигурации. Вы можете использовать .gz. **Xor .bz2 расширение для включения сжатия.** По умолчанию все данные сохраняются в файле OUTPUT. Эта директива применима только к типу экспорта TABLE.

Ограничения можно быстро импортировать в PostgreSQL с помощью типа экспорта LOAD, чтобы распараллелить их создание через несколько подключений (-j или JOBS).

**FILE_PER_INDEX**
Разрешает сохранять индексы в отдельном файле во время экспорта схемы. Файл будет называться INDEXES_OUTPUT, где OUTPUT — значение соответствующей директивы конфигурации. Можно использовать расширение файла .gz xor .bz2 для включения сжатия. По умолчанию все данные сохраняются в файл OUTPUT. Эта директива применяется только к типам экспорта TABLE и TABLESPACE. В случае с типом экспорта TABLESPACE она используется для записи «ALTER INDEX...TABLESPACE...» в отдельный файл с именем TBSP_INDEXES_OUTPUT, который можно загрузить в конце миграции после создания индексов для перемещения индексов.

Индексы можно быстро импортировать в PostgreSQL, используя тип экспорта LOAD для распараллеливания их создания через несколько подключений (-j или JOBS).

**FILE_PER_FKEYS**
Позволяет сохранять объявление внешнего ключа в отдельном файле при экспорте схемы. По умолчанию внешние ключи экспортируются в основной выходной файл или в файл CONSTRAINT_output.sql. Если эта функция включена, внешние ключи будут экспортированы в файл с именем FKEYS_output.sql

**FILE_PER_TABLE**
Разрешает экспорт данных в один файл на таблицу/представление. Файлы будут называться как tablename_OUTPUT, где OUTPUT — это значение соответствующей директивы конфигурации. Вы по-прежнему можете использовать расширение .gz xor .bz2 в директиве OUTPUT для включения сжатия. Значение по умолчанию 0 сохранит все данные в одном файле, установите значение 1, чтобы включить эту функцию. Это применимо только во время типов экспорта INSERT или COPY.

**FILE_PER_FUNCTION**
Разрешает сохранение функций, процедур и триггеров в одном файле на объект. Файлы будут названы как objectname_OUTPUT. Где OUTPUT — это значение соответствующей директивы конфигурации. Вы всё ещё можете использовать расширение .gz xor .bz2 в директиве OUTPUT, чтобы включить сжатие. Значение по умолчанию 0 сохраняет всё в одном файле, установите значение 1, чтобы включить эту функцию. Это применимо только во время соответствующего типа экспорта, экспорт тела пакета имеет особое поведение.

Когда тип экспорта — PACKAGE и вы включили эту директиву, Ora2Pg создаст каталог для каждого пакета с именем в нижнем регистре имени пакета и создаст один файл для каждой функции/процедуры в этом каталоге. Если директива конфигурации не включена, она создаст один файл на пакет как packagename_OUTPUT, где OUTPUT — это значение соответствующей директивы.

**TRUNCATE_TABLE**
Если эта директива установлена в 1, перед загрузкой данных будет добавлена инструкция TRUNCATE TABLE. Это применимо только для типов экспорта INSERT или COPY.

При активации инструкция будет добавлена только в том случае, если нет глобального предложения DELETE или конкретного для текущей таблицы (см. ниже).

**DELETE**
Поддержка включения предложения DELETE FROM...WHERE перед импортом данных и выполнение удаления некоторых строк вместо усечения таблиц. Значение строится следующим образом: TABLE_NAME[DELETE_WHERE_CLAUSE], или если у вас есть только одно предложение where для всех таблиц, просто поместите предложение delete как единственное значение. Оба варианта также возможны. Вот несколько примеров:

* DELETE 1=1 # Применить ко всем таблицам и удалить все кортежи
* DELETE TABLE_TEST[ID1='001'] # Применить только к таблице TABLE_TEST
* DELETE TABLE_TEST[ID1='001' OR ID1='002] DATE_CREATE > '2001-01-01' TABLE_INFO[NAME='test']

Последнее применяет два разных предложения delete where к таблицам TABLE_TEST и TABLE_INFO и При использовании экспорта Ora2Pg:

* **generic delete where clause on DATE_CREATE** — применяется ко всем другим таблицам. Если TRUNCATE_TABLE включён, он будет применяться ко всем таблицам, не охваченным определением DELETE. Эти предложения DELETE могут быть полезны при регулярных «обновлениях».

    * **STOP_ON_ERROR** — установите этот параметр в 0, чтобы не включать вызов ON_ERROR_STOP ON во всех SQL-скриптах, генерируемых Ora2Pg. По умолчанию этот порядок всегда присутствует, поэтому сценарий немедленно прервётся при возникновении ошибки.

    * **COPY_FREEZE** — включите эту директиву, чтобы использовать COPY FREEZE вместо простого COPY для экспорта данных с уже замороженными строками. Это предназначено для повышения производительности при начальной загрузке данных. Строки будут заморожены, только если загружаемая таблица была создана или усечена в текущей подтранзакции. Это будет работать только при экспорте в файл и когда -J или ORACLE_COPIES не установлены или по умолчанию равны 1. Его можно использовать для прямого импорта в PostgreSQL при том же условии, но -j или JOBS также должны быть сброшены или по умолчанию равняться 1.

    * **CREATE_OR_REPLACE** — по умолчанию Ora2Pg использует CREATE OR REPLACE в функциях и представлениях DDL. Если вам не нужно переопределять существующие функции или представления, отключите эту конфигурацию, DDL не будет включать OR REPLACE.

    * **DROP_IF_EXISTS** — чтобы добавить DROP <OBJECT> IF EXISTS перед созданием объекта, включите эту директиву. Может быть полезно в итерационной работе. По умолчанию отключено.

    * **EXPORT_GTT** — PostgreSQL не поддерживает глобальные временные таблицы изначально, но вы можете использовать расширение pgtt для имитации этого поведения. Включите эту директиву для экспорта глобальной временной таблицы.

    * **PGTT_NOSUPERUSER** — по умолчанию расширение pgtt загружается с использованием привилегии суперпользователя. Включите его, если вы запускаете SQL-сценарии, используя пользователя без прав суперпользователя. Будет использоваться: LOAD '$libdir/plugins/pgtt'; вместо значения по умолчанию: LOAD 'pgtt'.

    * **NO_HEADER** — включение этой директивы предотвратит вывод заголовка Ora2Pg в выходные файлы. Будет записан только переведённый код.

    * **PSQL_RELATIVE_PATH** — по умолчанию Ora2Pg использует команду \i psql для выполнения сгенерированных SQL-файлов. Если вы хотите использовать относительный путь после файла выполнения скрипта, включение этой опции будет использовать \ir. См. справку psql для получения дополнительной информации.

    * **DATA_VALIDATION_ROWS** — количество строк, которые необходимо извлечь с обеих сторон для проверки данных. По умолчанию сравниваются первые 10 000 строк. Значение 0 означает сравнение всех строк.

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

    * **DATA_VALIDATION_ERROR** — прекратите проверку данных из таблицы после определённого количества ошибок сопоставления строк. По умолчанию проверка прекращается после 10 ошибок строк.

    * **TRANSFORM_VALUE** — используйте эту директиву, чтобы указать, какое преобразование следует применить к столбцу при экспорте данных. Значение должно быть списком через точку с запятой TABLE[COLUMN_NAME, <код замены в SELECT целевом списке>]. Например, чтобы заменить строку 'Oracle' на 'PostgreSQL' в столбце varchar2, используйте следующее.
        * TRANSFORM_VALUE ERROR_LOG_SAMPLE[DBMS_TYPE:regexp_replace("DBMS_TYPE",'Oracle','PostgreSQL')]

или чтобы заменить все Oracle char(0) в строке пробелом:
        * TRANSFORM_VALUE CLOB_TABLE[CHARDATA:translate("CHARDATA", chr(0), ' ')]

Выражение будет применено в SQL-выражении, используемом для извлечения данных из исходной базы данных. Если вы хотите выгрузить данные в файл и при этом включён параметр FILE_PER_TABLE, то вас предупредят, что Ora2Pg не будет экспортировать данные повторно, если файл уже существует. Это сделано для того, чтобы предотвратить повторную загрузку таблицы с огромным объёмом данных. Чтобы принудительно загрузить данные из этих таблиц, сначала необходимо удалить существующий выходной файл.

Если вы хотите импортировать данные «на лету» в базу данных PostgreSQL, у вас есть три директивы конфигурации для установки соединения с базой данных PostgreSQL. Это возможно только с типами экспорта COPY или INSERT, поскольку для схемы базы данных это не представляет реального интереса.

PG_DSN
Используйте эту директиву, чтобы установить пространство имён источника данных PostgreSQL с помощью модуля Perl DBD::Pg следующим образом:
dbi:Pg:dbname=pgdb;host=localhost;port=5432
подключится к базе данных 'pgdb' на локальном хосте через порт TCP 5432.
Обратите внимание, что эта директива используется только для экспорта данных, другой экспорт необходимо импортировать вручную с помощью psql или любого другого клиента PostgreSQL.
Чтобы использовать зашифрованное соединение SSL, необходимо добавить sslmode=require в строку подключения следующим образом:
dbi:Pg:dbname=pgdb;host=localhost;port=5432;sslmode=require

PG_USER и PG_PWD
Эти две директивы используются для установки имени пользователя и пароля для входа.
Если вы не предоставите учётные данные с PG_PWD и у вас установлен модуль Perl Term::ReadKey, Ora2Pg запросит пароль в интерактивном режиме. Если PG_USER не установлен, он также будет запрашиваться в интерактивном режиме.

SYNCHRONOUS_COMMIT
Указывает, будет ли фиксация транзакции ожидать записи WAL на диск перед тем, как команда вернёт клиенту указание на «успех». Это эквивалентно настройке синхронной фиксации в файле postgresql.conf. Это используется только тогда, когда вы загружаете данные непосредственно в PostgreSQL, по умолчанию отключено, чтобы отключить синхронную фиксацию для увеличения скорости записи данных. Некоторые модифицированные версии PostgreSQL, такие как greenplum, не имеют этой настройки, поэтому в этом наборе эта директива установлена на 1, ora2pg не будет пытаться изменить настройку.

PG_INITIAL_COMMAND
Эту директиву можно использовать для отправки начальной команды в PostgreSQL сразу после подключения. Например, для установки некоторых параметров сеанса. Эту директиву можно использовать несколько раз.

INSERT_ON_CONFLICT
Когда включено, это указывает Ora2Pg добавлять предложение ON CONFLICT DO NOTHING ко всем операторам INSERT, созданным для этого типа экспорта данных.

Контроль типа столбца
PG_NUMERIC_TYPE
Если установлено значение 1, замените переносимый числовой тип на внутренний тип PostgreSQL. Приблизительное преобразование типа данных Oracle NUMBER(p,s) в типы данных real и float PostgreSQL. Если у вас есть денежные поля или вы не хотите проблем с округлением дополнительных десятичных знаков, вам следует сохранить тот же числовой (p, s) тип данных PostgreSQL. Делайте это только в том случае, если вам нужна точность, потому что использование numeric(p,s) медленнее, чем использование real или double.

PG_INTEGER_TYPE
Если установлено значение 1, замените переносимый числовой тип внутренним типом PostgreSQL. Тип данных Oracle NUMBER (p) или NUMBER преобразуется в тип данных smallint, integer или bigint PostgreSQL в соответствии со значением точности. Если NUMBER без точности установлены на DEFAULT_NUMERIC (см. ниже).

DEFAULT_NUMERIC
NUMBER без точности преобразуются по умолчанию в bigint, только если PG_INTEGER_TYPE имеет значение true. Вы можете перезаписать это значение любым типом PG, например, integer или float.

DATA_TYPE
Если у вас возникли проблемы с преобразованием схемы типов данных, с помощью этой директивы вы можете полностью контролировать соответствие между типами Oracle и PostgreSQL, чтобы переопределить перевод типов данных, используемый в Ora2pg. Синтаксис представляет собой список, разделённый запятыми, «Тип данных Oracle: Тип данных PostgreSQL». Вот список по умолчанию. **Использовано:**

                DATA_TYPE       VARCHAR2:varchar,NVARCHAR2:varchar,NVARCHAR:varchar,NCHAR:char,DATE:timestamp(0),LONG:text,LONG RAW:bytea,CLOB:text,NCLOB:text,BLOB:bytea,BFILE:bytea,RAW(16):uuid,RAW(32):uuid,RAW:bytea,UROWID:oid,ROWID:oid,FLOAT:double precision,DEC:decimal,DECIMAL:decimal,DOUBLE PRECISION:double precision,INT:integer,INTEGER:integer,REAL:real,SMALLINT:smallint,BINARY_FLOAT:double precision,BINARY_DOUBLE:double precision,TIMESTAMP:timestamp,XMLTYPE:xml,BINARY_INTEGER:integer,PLS_INTEGER:integer,TIMESTAMP WITH TIME ZONE:timestamp with time zone,TIMESTAMP WITH LOCAL TIME ZONE:timestamp with time zone

        Директива и определение списка должны быть одной строкой.

        Обратите внимание, что при обнаружении столбцов RAW(16) и RAW(32) или если столбец RAW имеет значение по умолчанию «SYS_GUID()», Ora2Pg автоматически переводит тип столбца в uuid, что может быть правильным переводом в большинстве случаев. В этом случае данные будут автоматически перенесены как тип данных uuid PostgreSQL, предоставляемый расширением «uuid-ossp».

        Если вы хотите заменить тип с точностью и масштабом, вам нужно экранировать запятую обратной косой чертой. Например, если вы хотите заменить все NUMBER(*,0) на bigint вместо numeric(38), добавьте следующее:

               DATA_TYPE       NUMBER(*\,0):bigint

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

        Существует особый случай с BFILE, когда они преобразуются в тип TEXT, они будут содержать только полный путь к внешнему файлу. Если вы установите целевой тип BYTEA (по умолчанию), Ora2Pg экспортирует содержимое BFILE как bytea. Третий случай — когда вы устанавливаете целевой тип EFILE, в этом случае Ora2Pg будет экспортировать его как запись EFILE: (DIRECTORY, FILENAME). Используйте тип экспорта DIRECTORY для экспорта существующих каталогов, а также привилегий для этих каталогов.

        Нет доступной SQL-функции для получения пути к BFILE. Ora2Pg должен создать её, используя пакет DBMS_LOB.

                CREATE OR REPLACE FUNCTION ora2pg_get_bfilename( p_bfile IN BFILE )
                RETURN VARCHAR2
                AS
                    l_dir   VARCHAR2(4000);
                    l_fname VARCHAR2(4000);
                    l_path  VARCHAR2(4000);
                BEGIN
                    dbms_lob.FILEGETNAME( p_bfile, l_dir, l_fname );
                    SELECT directory_path INTO l_path FROM all_directories
                        WHERE directory_name = l_dir;
                    l_dir := rtrim(l_path,'/');
                    RETURN l_dir || '/' || l_fname;
                END;

        Эта функция создаётся только в том случае, если Ora2Pg находит таблицу со столбцом BFILE и целевой тип — TEXT. Функция удаляется в конце экспорта. Это касается обоих типов экспорта: COPY и INSERT.

        Не существует доступной SQL-функции для извлечения BFILE в виде записи EFILE, поэтому Ora2Pg должна создать её с помощью пакета DBMS_LOB.

                CREATE OR REPLACE FUNCTION ora2pg_get_efile( p_bfile IN BFILE )
                RETURN VARCHAR2
                AS
                    l_dir   VARCHAR2(4000);
                    l_fname VARCHAR2(4000);
                BEGIN
                    dbms_lob.FILEGETNAME( p_bfile, l_dir, l_fname );
                    RETURN '(' || l_dir || ',' || l_fnamei || ')';
                END;

        Эта функция создаётся только в том случае, если Ora2Pg находит таблицу со столбцом BFILE и целевой тип — EFILE. Функция удаляется в конце экспорта. Это касается обоих типов экспорта: COPY и INSERT.

        Чтобы установить целевой тип, используйте директиву конфигурации DATA_TYPE:

                DATA_TYPE       BFILE:EFILE

например.

Тип EFILE — это определяемый пользователем тип, созданный расширением PostgreSQL. Типы символов и чисел поддерживаются.

TO_NUMBER_CONVERSION
По умолчанию вызов функции TO_NUMBER в Oracle будет переведён как приведение к числовому типу. Например, TO_NUMBER('10.1234') преобразуется в вызов to_number('10.1234')::numeric в PostgreSQL. При желании можно привести вызов к целому числу или bigint, изменив значение директивы конфигурации. Если вам нужен более точный контроль над форматом, просто установите его в качестве значения, например: TO_NUMBER_CONVERSION 99999999999999999999.9999999999 преобразует код выше следующим образом: TO_NUMBER('10.1234', '99999999999999999999.9999999999'). Любое значение директивы, которое не является числовым, целым числом или bigint, будет восприниматься как маска формата. Если установлено значение none, преобразование не будет выполнено.

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

FORCE_IDENTITY_BIGINT
Обычно столбец идентификатора должен быть bigint для соответствия последовательности автоматического увеличения, поэтому Ora2Pg всегда принудительно устанавливает его как bigint. Если по какой-либо причине вы хотите, чтобы Ora2Pg учитывал DATA_TYPE, который вы установили для столбца идентификатора, отключите эту директиву.

TO_CHAR_NOTIMEZONE
Если вы хотите, чтобы Ora2Pg удалял любую информацию о часовом поясе из части формата функции TO_CHAR(), включите эту директиву. По умолчанию отключена.

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

SKIP
Для экспорта ТАБЛИЦЫ вы можете не захотеть экспортировать все ограничения схемы, директива конфигурации SKIP позволяет указать список ограничений через пробел, которые не должны быть экспортированы. Возможные значения:
— fkeys: отключить ограничения внешнего ключа;
— pkeys: отключить первичные ключи;
— ukeys: отключить уникальные ограничения столбцов;
— indexes: отключить все остальные типы индексов;
— checks: отключить проверочные ограничения.
Например:
SKIP индексы, проверки
удалит индексы и проверочные ограничения из экспорта.

PKEY_IN_CREATE
Включите эту директиву, если вы хотите добавить определение первичного ключа внутри оператора создания таблицы. Если она отключена (по умолчанию), определение первичного ключа будет добавлено оператором alter table. Включите её, если вы экспортируете в базу данных GreenPlum PostgreSQL.

KEEP_PKEY_NAMES
По умолчанию имена первичных и уникальных ключей в исходной базе данных Oracle игнорируются, а имена ключей автоматически генерируются в целевой базе данных PostgreSQL с использованием внутренних правил именования PostgreSQL по умолчанию. Если вы хотите сохранить имена первичных и уникальных ключей Oracle, установите этот параметр равным 1.

FKEY_ADD_UPDATE
Эта директива позволяет вам добавить опцию ON UPDATE CASCADE к внешнему ключу, когда определено ON DELETE CASCADE или всегда. Oracle не поддерживает эту функцию, вы должны использовать триггер для работы с ON UPDATE CASCADE. Поскольку PostgreSQL имеет эту функцию, вы можете выбрать способ добавления опции внешнего ключа. Есть три значения этой директивы: никогда, что означает, что внешние ключи будут объявлены точно так же, как в Oracle. Второе значение — delete, это означает, что опция ON UPDATE CASCADE будет добавлена только в том случае, если ON DELETE CASCADE уже определена для внешних ключей. Последнее значение, always, заставит все внешние ключи определяться с использованием опции обновления.

FKEY_DEFERRABLE
При экспорте таблиц Ora2Pg обычно экспортирует ограничения как есть, если они не подлежат отсрочке, они экспортируются как не подлежащие отсрочке. Однако ограничения, не подлежащие отсрочке, вероятно, вызовут проблемы при попытке импортировать данные в Pg. Опция FKEY_DEFERRABLE установлена... Для 1 все ограничения внешних ключей будут экспортированы как
откладываемые.

DEFER_FKEY
Кроме экспорта данных, когда для параметра DEFER_FKEY установлено значение 1, будет добавлена команда отложить все ограничения внешнего ключа во время экспорта данных, и импорт будет выполнен в одной транзакции. Это будет работать только в том случае, если внешние ключи были экспортированы как откладываемые и вы не используете прямой импорт в PostgreSQL (PG_DSN не определён). Ограничения будут проверены в конце транзакции.

Эту директиву также можно включить, если вы хотите принудительно создать все внешние ключи как откладываемые и изначально отложенные во время экспорта схемы (тип экспорта TABLE).

DROP_FKEY
Если отложить внешние ключи невозможно из-за объёма данных в одной транзакции, вы не экспортировали внешние ключи как откладываемые или вы используете прямой импорт в PostgreSQL, вы можете использовать директиву DROP_FKEY.

Она удалит все внешние ключи перед импортом всех данных и воссоздаст их в конце импорта.

DROP_INDEXES
Эта директива позволяет значительно повысить скорость импорта данных за счёт удаления всех индексов, которые не являются автоматическими индексами (индексы первичных ключей), и их воссоздания в конце импорта данных. Конечно, гораздо лучше не импортировать индексы и ограничения до того, как будут импортированы все данные.

DISABLE_TRIGGERS
Эта директива используется для отключения триггеров во всех таблицах в режимах экспорта COPY или INSERT. Доступные значения: USER (отключить только пользовательские триггеры) и ALL (включает системные триггеры RI). По умолчанию — 0: не добавлять операторы SQL для отключения триггера перед импортом данных.

Если вы хотите отключить триггеры во время миграции данных, установите значение USER, если вы подключены как не суперпользователь, и ALL, если вы подключены как суперпользователь PostgreSQL. Значение 1 равно USER.

DISABLE_SEQUENCE
Если установлено значение 1, это отключает изменение последовательностей во всех таблицах во время режима экспорта COPY или INSERT. Это используется для предотвращения обновления последовательности во время переноса данных. По умолчанию — 0, изменение последовательностей.

NOESCAPE
По умолчанию все данные, не относящиеся к типу даты или времени, экранируются. Если у вас возникли какие-либо проблемы с этим, вы можете установить значение 1 для отключения экранирования символов во время экспорта данных. Эта директива используется только во время экспорта COPY. См. STANDARD_CONFORMING_STRINGS для включения/отключения экранирования с операторами INSERT.

STANDARD_CONFORMING_STRINGS
Это определяет, обрабатывают ли обычные строковые литералы ('...') обратную косую черту буквально, как указано в стандарте SQL. Раньше по умолчанию было значение до Ora2Pg v8.5, поэтому все строки сначала экранировались, теперь это включено, в результате чего Ora2Pg использует синтаксис escape-строки (E'...'), если этот параметр не установлен в 0. Это точное поведение той же опции в PostgreSQL. Эта директива используется только при экспорте данных для создания операторов INSERT. См. NOESCAPE для включения/выключения экранирования в операторах COPY.

TRIM_TYPE
Если вы хотите преобразовать CHAR(n) из Oracle в varchar(n) или text в PostgreSQL с помощью директивы DATA_TYPE, вы можете захотеть выполнить некоторое усечение данных. По умолчанию Ora2Pg автоматически обнаружит это преобразование и удалит любые пробелы в обоих начальных и конечных позициях. Если вы просто хотите удалить начальный набор символов, установите значение LEADING. Если вы хотите удалить конечный символ, установите значение TRAILING. Значение по умолчанию — BOTH.

TRIM_CHAR
Символ по умолчанию для обрезки — пробел, используйте эту директиву, если вам нужно изменить символ, который будет удалён. Например, установите его на -, если у вас есть начальный - в поле char(n). Чтобы использовать пробел в качестве символа обрезки, прокомментируйте эту директиву; это значение по умолчанию. **PRESERVE_CASE**

Если вы хотите сохранить регистр имени объекта Oracle, установите для этой директивы значение 1. По умолчанию Ora2Pg преобразует все имена объектов Oracle в нижний регистр. Я не рекомендую включать эту опцию, если только вам не придётся всегда заключать имена объектов в двойные кавычки во всех ваших SQL-скриптах.

**ORA_RESERVED_WORDS**

Разрешает экранирование имени столбца с использованием зарезервированных слов Oracle. Значение представляет собой список зарезервированных слов через запятую. По умолчанию: audit, comment, references.

**USE_RESERVED_WORDS**

Включите эту директиву, если у вас есть имена таблиц или столбцов, которые являются зарезервированными словами для PostgreSQL. Ora2Pg заключит имя объекта в двойные кавычки.

**GEN_USER_PWD**

Установите для этой директивы значение 1, чтобы заменить стандартный пароль случайным паролем для всех извлечённых пользователей во время экспорта GRANT.

**PG_SUPPORTS_MVIEW**

Начиная с PostgreSQL 9.3, материализованные представления поддерживаются с помощью синтаксиса SQL «CREATE MATERIALIZED VIEW». Чтобы заставить Ora2Pg использовать встроенную поддержку PostgreSQL, необходимо включить эту конфигурацию — по умолчанию она включена. Если вы хотите использовать старый стиль с таблицей и набором функций, отключите её.

**PG_SUPPORTS_IFEXISTS**

Версии PostgreSQL ниже 9.x не поддерживают IF EXISTS в операторах DDL. Отключение директивы со значением 0 предотвратит добавление Ora2Pg этих ключевых слов во все сгенерированные операторы. Значение по умолчанию равно 1 (включено).

**PG_VERSION**

Задайте основной номер версии PostgreSQL целевой базы данных. Например, 9.6 или 13. По умолчанию используется текущая основная версия на момент нового выпуска. Эта настройка заменяет старые и устаревшие директивы конфигурации PG_SUPPORTS_*.

**PG_SUPPORTS_ROLE (Deprecated)**

Эта опция устарела начиная с версии Ora2Pg v7.3.
По умолчанию роли Oracle переводятся в группы PostgreSQL. Если у вас PostgreSQL 8.1 или более поздняя версия, рассмотрите возможность использования ROLES и установите для этой директивы значение 1 для экспорта ролей.

**PG_SUPPORTS_INOUT (Deprecated)**

Эта опция устарела начиная с версии Ora2Pg v7.3.
Если установлено значение 0, все параметры IN, OUT или INOUT не будут использоваться в сгенерированных объявлениях функций PostgreSQL (отключите его для версий баз данных PostgreSQL ниже 8.1). Теперь включено по умолчанию.

**PG_SUPPORTS_DEFAULT**

Эта директива включает или отключает использование значения параметра по умолчанию в экспорте функций. До PostgreSQL 8.4 такая стоимость по умолчанию не поддерживалась, теперь эта функция включена по умолчанию.

**PG_SUPPORTS_WHEN (Deprecated)**

Добавьте поддержку предложения WHEN в триггерах, поскольку PostgreSQL версии 9.0 теперь поддерживает его. Эта директива включена по умолчанию, установите значение 0 для отключения этой функции.

**PG_SUPPORTS_INSTEADOF (Deprecated)**

Добавьте поддержку использования INSTEAD OF в триггерах (используется с PG >= 9.1), если эта директива отключена, триггеры INSTEAD OF будут переписаны как правила Pg.

**PG_SUPPORTS_CHECKOPTION**

При включении экспортируйте представления с CHECK OPTION. Отключите, если у вас версия PostgreSQL до 9.4. Значение по умолчанию: 1, включено.

**PG_SUPPORTS_IFEXISTS**

Если отключено, не экспортируйте объекты с операторами IF EXISTS. Включено по умолчанию.

**PG_SUPPORTS_PARTITION**

В версиях PostgreSQL до 10.0 нет встроенной поддержки секционирования. Включите эту директиву, если вы хотите использовать декларативное секционирование. Включено по умолчанию.

**PG_SUPPORTS_SUBSTR**

Некоторые версии PostgreSQL, такие как Redshift, не поддерживают substr() и должны быть заменены вызовом substring(). В этом случае отключите его.

**PG_SUPPORTS_NAMED_OPERATOR**

Отключите эту директиву, если используете PG < 9.5, оператор PL/SQL, используемый в именованном параметре =>, будет заменён собственным оператором PostgreSQL := Включено по умолчанию.

**PG_SUPPORTS_IDENTITY**

Включите эту директиву, если у вас PostgreSQL >= 10, чтобы использовать столбцы IDENTITY вместо **Кодировка в Perl**

Выполняется через вызов прагмы Perl:

    use open ':utf8';

Можно переопределить эту кодировку с помощью директивы BINMODE. Например, можно установить её в :locale для использования вашей локали или iso-8859-7. Это соответственно будет использовать:

     use open ':locale';
     use open ':encoding(iso-8859-7)';

Если вы изменили NLS_LANG в кодировке, отличной от UTF8, возможно, вам потребуется установить эту директиву. Подробнее см. на сайте http://perldoc.perl.org/5.14.2/open.html. В большинстве случаев оставляйте эту директиву закомментированной.

**CLIENT_ENCODING**
По умолчанию кодировка клиента PostgreSQL автоматически устанавливается в UTF8 во избежание проблем с кодировкой. Если вы изменили значение NLS_LANG, возможно, придётся изменить кодировку клиента PostgreSQL.

Вы можете ознакомиться с поддерживаемыми наборами символов PostgreSQL здесь: http://www.postgresql.org/docs/9.0/static/multibyte.html

**FORCE_PLSQL_ENCODING**
Чтобы принудительно использовать кодировку utf8 для экспортируемого кода PL/SQL, включите эту директиву. Может быть полезно в некоторых редких случаях.

**Преобразование PLSQL в PLPGSQL**
Автоматическое преобразование кода из Oracle PLSQL в PostgreSQL PLPGSQL находится в разработке в Ora2Pg, и, конечно, всегда будет требоваться ручная работа. Код Perl, используемый для автоматического преобразования, хранится в специальном модуле Perl под названием Ora2Pg/PLSQL.pm. Вы можете свободно изменять/добавлять свой собственный код и отправлять мне патчи. Основная работа ведётся над функциями, процедурами, пакетами и заголовками и параметрами пакетов.

**PLSQL_PGSQL**
Включите/отключите преобразование PLSQL в PLPGSQL. Включено по умолчанию.

**NULL_EQUAL_EMPTY**
Ora2Pg может заменить все условия проверкой NULL с помощью вызова функции coalesce(), чтобы имитировать поведение Oracle, где пустые строки считаются равными NULL.

(field1 IS NULL) заменяется на (coalesce(field1::text, '') = '')
(field2 IS NOT NULL) заменяется на (field2 IS NOT NULL AND field2::text <> '')

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

**EMPTY_LOB_NULL**
Принудительно empty_clob() и empty_blob() будут экспортироваться как NULL вместо пустой строки для первого и '\x' для второго. Если NULL разрешён в вашем столбце, это может повысить скорость экспорта данных, если у вас много пустых lob. По умолчанию данные сохраняются точно так же, как в Oracle.

**PACKAGE_AS_SCHEMA**
Если вы не хотите экспортировать пакет как схему, а как простые функции, вы также можете захотеть заменить все вызовы package_name.function_name(). Если вы отключите директиву PACKAGE_AS_SCHEMA, Ora2Pg заменит все вызовы package_name.function_name() на package_name_function_name(). По умолчанию используется схема для эмуляции пакета.

Замена будет производиться во всех видах DDL или кода, который анализируется конвертером PLSQL в PLPGSQL. PLSQL_PGSQL должен быть включён или -p использоваться в командной строке.

**REWRITE_OUTER_JOIN**
Включите эту директиву, если переписывание собственного синтаксиса Oracle (+) OUTER JOIN нарушено. Это заставит Ora2Pg не переписывать такой код, по умолчанию он пытается переписать простую форму правого внешнего соединения на данный момент.

**UUID_FUNCTION**
По умолчанию Ora2Pg преобразует вызов функции SYS_GUID() Oracle с вызовом uuid_generate_v4 из расширения uuid-ossp. Вы можете переопределить его, чтобы использовать функцию gen_random_uuid из расширения pgcrypto, изменив имя функции. По умолчанию — uuid_generate_v4.

Обратите внимание, что когда столбцы RAW(16) и RAW(32) найдены или когда столбец RAW имеет «SYS_GUID()» в качестве значения по умолчанию, Ora2Pg автоматически переведёт тип столбца в uuid, что может привести к... **Быть правильным переводом в большинстве случаев.** В этом случае данные будут автоматически перенесены как тип данных PostgreSQL uuid, предоставленный расширением «uuid-ossp».

FUNCTION_STABLE
По умолчанию функции Oracle помечаются как STABLE, поскольку они не могут изменять данные, если только они не используются в PL/SQL с присвоением переменной или в качестве условного выражения. Вы можете заставить Ora2Pg создавать эти функции как VOLATILE, отключив эту директиву конфигурации.

COMMENT_COMMIT_ROLLBACK
По умолчанию вызовы COMMIT/ROLLBACK остаются нетронутыми Ora2Pg, чтобы заставить пользователя проверить логику функции. Как только это будет исправлено в исходном коде Oracle или вы захотите прокомментировать эти вызовы, включите следующую директиву.

COMMENT_SAVEPOINT
Обычно можно увидеть вызов SAVEPOINT внутри процедуры PL/SQL вместе с ROLLBACK TO savepoint_name. Когда COMMENT_COMMIT_ROLLBACK включён, вы также можете захотеть закомментировать вызовы SAVEPOINT, в этом случае включите его.

STRING_CONSTANT_REGEXP
Ora2Pg заменяет все строковые константы во время перевода pl/sql на plpgsql, строковые константы — это весь текст, заключённый в одинарные кавычки. Если у вас есть какой-либо строковый заполнитель, используемый в динамическом вызове запросов, вы можете установить список регулярных выражений для временной замены, чтобы не нарушить работу парсера. Например:

    STRING_CONSTANT_REGEXP <placeholder value=".*">

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

ALTERNATIVE_QUOTING_REGEXP
Чтобы поддерживать альтернативный механизм цитирования ('Q' или 'q') для строковых литералов, установите регулярное выражение с текстом захвата, который будет использоваться для извлечения текстовой части. Например, с переменной, объявленной как

c_sample VARCHAR2(100 CHAR) := q'{This doesn't work.}';

регулярное выражение для использования должно быть:

ALTERNATIVE_QUOTING_REGEXP q'{(.*)}'

ora2pg будет использовать $$ разделитель, с примером результат будет:

c_sample varchar(100) := $$This doesn't work.$$;

Значение этой директивы конфигурации может быть списком регулярных выражений, разделённых точкой с запятой. Часть значения (между скобками) является обязательной в каждом регулярном выражении, если вы хотите восстановить строковую константу.

USE_ORAFCE
Если вы хотите использовать функции, определённые в библиотеке Orafce, и запретить Ora2Pg переводить вызовы этих функций, включите эту директиву. Библиотеку Orafce можно найти здесь:
https://github.com/orafce/orafce

По умолчанию Ora2pg переписывает функции add_month(), add_year(), date_trunc() и to_char(), но вы можете предпочесть использовать версию этих функций orafce, которая не требует какого-либо преобразования кода.

AUTONOMOUS_TRANSACTION
Включите перевод автономных транзакций в функцию-оболочку с использованием dblink или расширения pg_background. Если вы не хотите использовать этот перевод и просто хотите, чтобы функция экспортировалась как обычная без вызова прагмы, отключите эту директиву.

**Материализованное представление**
Материализованные представления экспортируются как моментальный снимок «Моментальные снимки материализованных представлений», поскольку PostgreSQL поддерживает только полное обновление.

Если вы хотите импортировать материализованные представления в PostgreSQL до версии 9.3, вам необходимо установить директиву конфигурации PG_SUPPORTS_MVIEW равной 0. В этом случае Ora2Pg будет экспортировать все материализованные представления, как описано в этом документе:
http://tech.jonathangardner.net/wiki/PostgreSQL/Materialized_Views.

При экспорте материализованного представления Ora2Pg сначала добавляет код SQL для создания таблицы «materialized_views»:

CREATE TABLE materialized_views (
mview_name text NOT NULL PRIMARY KEY,
view_name text NOT NULL,
iname text,
last_refresh TIMESTAMP WITH TIME ZONE
);

Все материализованные представления будут иметь запись в этой таблице. Затем он добавляет код plpgsql для создания дерева. **Функции:**

* create_materialized_view(text, text, text) используется для создания материализованного представления;

* drop_materialized_view(text) используется для удаления материализованного представления; 

* refresh_full_materialized_view(text) используется для обновления представления.

**Затем добавляется SQL-код для создания представления и материализованного представления:**

    CREATE VIEW mviewname_mview AS
    SELECT ... FROM ...;

    SELECT create_materialized_view('mviewname','mviewname_mview', измените на имя столбца, который будет использоваться для индекса);

Первый аргумент — это имя материализованного представления, второй — имя представления, на котором основано материализованное представление, а третий — имя столбца, по которому должен быть построен индекс (чаще всего это первичный ключ). Этот столбец не определяется автоматически, поэтому его необходимо заменить.

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

    refresh_full_materialized_view('mviewname');

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

Другие директивы конфигурации:

DEBUG
Установите значение 1, чтобы включить подробный вывод.

IMPORT
Можно определить общие директивы конфигурации Ora2Pg в одном файле, который можно импортировать в другие файлы конфигурации с помощью директивы IMPORT следующим образом:

        IMPORT  commonfile.conf

будет импортировать все директивы конфигурации, определённые в commonfile.conf, в текущий файл конфигурации.

Экспорт представлений как таблиц PostgreSQL
Можно экспортировать любое представление Oracle в виде таблицы PostgreSQL, просто установив параметр конфигурации TYPE равным TABLE, чтобы получить соответствующее выражение CREATE TABLE. Или используйте тип COPY или INSERT для экспорта соответствующих данных. Чтобы разрешить это, вы должны указать свои представления в параметре конфигурации VIEW_AS_TABLE.

Например, со следующим представлением:

    CREATE OR REPLACE VIEW product_prices (category_id, product_count, low_price, high_price) AS
    SELECT  category_id, COUNT(*) as product_count,
        MIN(list_price) as low_price,
        MAX(list_price) as high_price
     FROM   product_information
    GROUP BY category_id;

Установка VIEW_AS_TABLE в product_prices и использование типа экспорта TABLE заставит Ora2Pg определить типы возвращаемых столбцов и сгенерировать оператор CREATE TABLE:

    CREATE TABLE product_prices (
            category_id bigint,
            product_count integer,
            low_price numeric,
            high_price numeric
    );

Данные будут загружены в соответствии с типом экспорта COPY или INSERT и объявлением представления.

Вы можете использовать директивы ALLOW и EXCLUDE в дополнение к фильтрации других объектов для экспорта.

Экспорт в виде файлов преобразования XML Kettle
Тип экспорта KETTLE полезен, если вы хотите использовать Penthalo Data Integrator (Kettle) для импорта данных в PostgreSQL. При таком типе экспорта Ora2Pg будет генерировать один файл преобразования Kettle (.ktr) на таблицу и добавлять строку для ручного выполнения преобразования в файле output.sql. Например:

ora2pg -c ora2pg.conf -t KETTLE -j 12 -a MYTABLE -o load_mydata.sh

сгенерирует один файл с именем 'HR.MYTABLE.ktr' и добавит строку в выходной файл (load_mydata.sh):

#!/bin/sh

KETTLE_TEMPLATE_PATH='.'

JAVAMAXMEM=4096 ./pan.sh -file $KETTLE_TEMPLATE_PATH/HR.MYTABLE.ktr -level Detailed

Опция -j 12 создаст шаблон с 12 процессами для вставки данных. **Миграция с Oracle на PostgreSQL: оценка стоимости и анализ данных**

PostgreSQL. Можно также указать количество параллельных запросов, используемых для извлечения данных из Oracle, с помощью параметра командной строки -J:

    ora2pg -c ora2pg.conf -t KETTLE -J 4 -j 12 -a EMPLOYEES -o load_mydata.sh

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

    DEFINED_PK      EMPLOYEES:employee_id

заставит использовать 4 копии соединения Oracle и определит SQL-запрос следующим образом в файле преобразования XML Kettle:

    <sql>SELECT * FROM HR.EMPLOYEES WHERE ABS(MOD(employee_id,${Internal.Step.Unique.Count}))=${Internal.Step.Unique.Number}</sql>

Тип экспорта KETTLE требует определения DSN для Oracle и PostgreSQL. Вы также можете активировать директиву TRUNCATE_TABLE, чтобы принудительно обрезать таблицу перед импортом данных.

Тип экспорта KETTLE — оригинальная работа Марка Кузена.

Оценка стоимости миграции

Оценить стоимость процесса миграции с Oracle на PostgreSQL непросто. Чтобы получить хорошую оценку этой стоимости, Ora2Pg проверит все объекты базы данных, все функции и хранимые процедуры, чтобы определить, есть ли ещё какие-либо объекты и код PL/SQL, которые не могут быть автоматически преобразованы Ora2Pg.

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

Чтобы активировать режим «анализ и отчёт», необходимо использовать тип экспорта SHOW_REPORT, как в следующей команде:

    ora2pg -t SHOW_REPORT

Вот пример отчёта, полученного с помощью этой команды:

    --------------------------------------
    Ora2Pg: Oracle Database Content Report
    --------------------------------------
    Версия Oracle Database 10g Enterprise Edition Release 10.2.0.1.0
    Схема  HR
    Размер  880,00 МБ

    --------------------------------------
    Объект  Количество  Недействительные комментарии
    --------------------------------------
    CLUSTER   2 0 Кластеры не поддерживаются и не будут экспортированы.
    FUNCTION  40  0 Общий размер кода функции: 81992.
    INDEX     435 0 232 индекса(ов) связаны с экспортом, остальные автоматически генерируются и будут делать это в PostgreSQL. 1 растровый индекс(ы). 230 b-tree индекс(ов). 1 обратный b-tree индекс(ов)
                                            Обратите внимание, что растровые индексы(ы) будут экспортироваться как b-tree индексы(ы), если таковые имеются. Кластерные, доменные, растровые и IOT индексы вообще не будут экспортироваться. Обратные индексы тоже не экспортируются, вы можете использовать триграммный индекс (см. pg_trgm) или индекс на основе функции reverse() и поиск. Вы также можете использовать операторы 'varchar_pattern_ops', 'text_pattern_ops' или 'bpchar_pattern_ops' в своих индексах для улучшения поиска с оператором LIKE соответственно в столбцах varchar, text или char.
    MATERIALIZED VIEW 1 0 Все материализованные представления будут экспортироваться в виде моментальных снимков, они обновляются только при полном обновлении.
    PACKAGE BODY  2 1 Общий размер пакета кода: 20700.
    PROCEDURE 7 0 Общий размер процедурного кода: 19198.
    SEQUENCE  160 0 Последовательности полностью поддерживаются, но все вызовы sequence_name.NEXTVAL или sequence_name.CURRVAL будут преобразованы в NEXTVAL('sequence_name') или CURRVAL('sequence_name').
    TABLE     265 0 1 внешняя таблица(ы) будет экспортирована как стандартная таблица. См. EXTERNAL_TO_FDW **configuration**

Директива для экспорта в качестве file_fdw внешних таблиц или использования COPY в вашем коде, если вы просто хотите загрузить данные из внешних файлов. 2 двоичных столбца. 4 неизвестных типа.

**TABLE PARTITION**
8 0 Разделы экспортируются с использованием наследования таблиц и проверочного ограничения. 1 раздел HASH. 
2 раздела LIST. 6 разделов RANGE. Обратите внимание, что разделы Hash не поддерживаются.

**TRIGGER**
30 0 Общий размер кода триггера: 21677.

**TYPE**
7 1 5 типов связаны с экспортом, другие не поддерживаются. 2 вложенных таблицы. 2 объектных типа. 1 подтип. 1 тип Boby. 1 унаследованный тип. 1 Varrays. Обратите внимание, что унаследованные типы и подтипы преобразуются в таблицы, наследование типов не поддерживается.

**TYPE BODY**
0 3 Экспорт типа с методом-членом не поддерживается, они не будут экспортированы.

**VIEW**
7 0 Представления полностью поддерживаются, но если у вас есть обновляемые представления, вам нужно будет использовать триггеры INSTEAD OF.

**DATABASE LINK**
1 0 Баз данных ссылки не будут экспортироваться. Вы можете попробовать модуль dblink perl contrib или использовать функции SQL/MED PostgreSQL с различными расширениями Foreign Data Wrapper (FDW).

Примечание: Недействительный код не будет экспортирован, если не активирована директива конфигурации EXPORT_INVALID.

После анализа базы данных Ora2Pg, благодаря своей способности преобразовывать код SQL и PL/SQL из синтаксиса Oracle в PostgreSQL, может пойти дальше, оценивая сложность кода и рассчитывая время, необходимое для выполнения полной миграции базы данных.

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

--estimate_cost

Эту функцию можно использовать только с типами экспорта SHOW_REPORT, FUNCTION, PROCEDURE, PACKAGE и QUERY.

ora2pg -t SHOW_REPORT --estimate_cost

Сгенерированный отчёт такой же, как и выше, но с новым столбцом «Оценочная стоимость»:

--------------------------------------
Ora2Pg: Отчёт о содержимом базы данных Oracle
--------------------------------------
Версия Oracle Database 10g Express Edition Release 10.2.0.1.0
Схема HR
Размер 890,00 МБ

--------------------------------------
Объект  Количество  Недействительная Оценочная стоимость  Комментарии
--------------------------------------
DATABASE LINK  3 0 9 Базы данных ссылки будут экспортированы как расширения Foreign Data Wrapper (FDW) SQL/MED PostgreSQL, используя oracle_fdw.
FUNCTION  2 0 7 Общий размер кода функции: 369 байт. HIGH_SALARY: 2, VALIDATE_SSN: 3.
INDEX 21  0 11 11 индексов связаны с экспортом, остальные автоматически генерируются и будут делать это в PostgreSQL. 11 b-tree индексов. Обратите внимание, что растровые индексы будут экспортироваться как b-tree индексы, если таковые имеются. Кластерные, доменные, растровые и IOT индексы вообще не экспортируются. Обратные индексы также не экспортируются, вы можете использовать индекс на основе триграмм (см. pg_trgm) или индекс на основе функции reverse() и поиск. Вы также можете использовать операторы 'varchar_pattern_ops', 'text_pattern_ops' или 'bpchar_pattern_ops' в своих индексах для улучшения поиска с помощью оператора LIKE соответственно в столбцах varchar, text или char.
JOB 0 0 0 Задания не экспортируются. Вы можете настроить внешние задания cron с ними.
MATERIALIZED VIEW 1 0 3
Все материализованные представления будут экспортированы как моментальные снимки материализованных представлений, они обновляются только при полном обновлении.

PACKAGE BODY  0 2 54
Общий размер кода пакета: 2487 байт. Количество процедур и функций, найденных внутри этих пакетов: 7. two_proc.get_table: 10, emp_mgmt.create_dept: 4, emp_mgmt.hire: 13, emp_mgmt.increase_comm: 4, emp_mgmt.increase_sal: 4, emp_mgmt.remove_dept: 3, emp_mgmt.remove_emp: 2.

PROCEDURE 4 0 39
Общий размер процедурного кода: 2436 байт. TEST_COMMENTAIRE: 2, SECURE_DML: 3, PHD_GET_TABLE: 24, ADD_JOB_HISTORY: 6.

SEQUENCE  3 0 0
Последовательности полностью поддерживаются, но все вызовы sequence_name.NEXTVAL или sequence_name.CURRVAL будут преобразованы в NEXTVAL('sequence_name') или CURRVAL('sequence_name').

SYNONYM   3 0 4
Синонимы будут экспортироваться как представления. Синонимы не существуют в PostgreSQL, но общий обходной путь — использовать представления или установить путь поиска PostgreSQL в сеансе для доступа к объекту вне текущей схемы.
user1.emp_details_view_v — это псевдоним hr.emp_details_view.
user1.emp_table — это псевдоним hr.employees@other_server.
user1.offices — это псевдоним hr.locations.

TABLE 17  0 8.5 1
Одна внешняя таблица будет экспортирована как стандартная таблица. См. директиву конфигурации EXTERNAL_TO_FDW для экспорта в качестве внешних таблиц file_fdw или используйте COPY в своём коде, если вы просто хотите загрузить данные из внешних файлов. 2 двоичных столбца. 4 неизвестных типа.

TRIGGER 1 1 4
Общий объём кода триггера: 123 байта. UPDATE_JOB_HISTORY: 2.

TYPE  7 1 5
5 типов затронуты экспортом, остальные не поддерживаются. 2 вложенных таблицы. 2 объектных типа. 1 подтип. 1 тип тела. 1 наследуемый тип. 1 Varrays. Обратите внимание, что наследуемые типы и подтипы преобразуются в таблицы, наследование типов не поддерживается.

TYPE BODY 0 3 30
Экспорт типов с методами-членами не поддерживается, они не будут экспортированы.

VIEW  1 1 1
Представления полностью поддерживаются, но если у вас есть обновляемые представления, вам нужно будет использовать триггеры INSTEAD OF.

--------------------------------------
Всего 65  8 162.5
162,5 единицы стоимости миграции означают примерно 2 человеко-дня.

Последняя строка показывает общую предполагаемую стоимость миграции в человеко-днях, следуя количеству единиц миграции, оценённых для каждого объекта. Эта единица миграции представляет около пяти минут для эксперта по PostgreSQL. Если это ваша первая миграция, вы можете получить более высокую оценку с помощью директивы конфигурации COST_UNIT_VALUE или параметра командной строки --cost_unit_value:
ora2pg -t SHOW_REPORT  --estimate_cost --cost_unit_value 10

Ora2Pg также может дать вам оценку уровня сложности миграции, вот пример:
Уровень миграции: B-5
Уровни миграции:
A — Миграция, которая может быть запущена автоматически
B — Миграция с переписыванием кода и стоимостью в человеко-дни до 5 дней
C — Миграция с переписыванием кода и стоимостью в человеко-дни свыше 5 дней
Технические уровни:
1 = тривиальный: нет хранимых функций и нет триггеров
2 = простой: нет хранимых функций, но с триггерами, без ручного переписывания
3 = простой: хранимые функции и/или триггеры, без ручного переписывания
4 = ручной: нет хранимых функций, но с триггерами или представлениями с **Переписывание кода**

5 = сложно: хранимые функции и/или триггеры с переписыванием кода.

Эта оценка состоит из буквы A или B, чтобы указать, требуется ли ручное переписывание при миграции или нет. И числа от 1 до 5, чтобы дать вам уровень технической сложности. У вас есть дополнительная опция —human_days_limit, чтобы указать количество человеко-дней, где уровень миграции должен быть установлен на C, что указывает на то, что требуется огромный объём работы и полное управление проектом с поддержкой миграции. По умолчанию это 10 человеко-дней. Вы можете использовать директиву конфигурации HUMAN_DAYS_LIMIT, чтобы навсегда изменить это значение по умолчанию.

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

**Глобальная оценка миграции Oracle и MySQL**

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

Использование: ora2pg_scanner -l CSVFILE [-o OUTDIR]

-b | --binpath DIR: полный путь к каталогу, в котором находится двоичный файл ora2pg. Может быть полезен только в ОС Windows.
-c | --config FILE: установить пользовательский файл конфигурации, иначе ora2pg будет использовать значение по умолчанию: /etc/ora2pg/ora2pg.conf.
-l | --list FILE: CSV-файл, содержащий список баз данных для сканирования со всей необходимой информацией. Первая строка файла может содержать следующий заголовок, описывающий формат, который необходимо использовать:
«type», «schema/database», «dsn», «user», «password»

-o | --outdir DIR: (необязательно) по умолчанию все отчёты будут выгружены в каталог с именем «output», он будет создан автоматически. Если вы хотите изменить имя этого каталога, укажите его во втором аргументе.
-t | --test: просто попробуйте все подключения, получив необходимое имя схемы или базы данных. Полезно для проверки вашего CSV-файла списка.
-u | --unit MIN: глобально переопределить стоимость единицы миграции в минутах. Значение по умолчанию берётся из ora2pg.conf (по умолчанию 5 минут).

Вот полный пример CSV-файла со списком баз данных:

«type», «schema/database», «dsn», «user», «password»
«MYSQL», «sakila», «dbi:mysql:host=192.168.1.10;database=sakila;port=3306», «root», «secret»
«ORACLE», «HR», «dbi:Oracle:host=192.168.1.10;sid=XE;port=1521», «system», «manager»
«MSSQL», «HR», «dbi:ODBC:driver=msodbcsql18;server=srv.database.windows.net;database=testdb», «system», «manager»

Разделитель полей CSV должен быть запятой.

Обратите внимание, что если вы хотите сканировать все схемы из экземпляра Oracle, вам просто нужно оставить поле схемы пустым, Ora2Pg автоматически обнаружит все доступные схемы и создаст отчёт для каждой из них. Конечно, вам нужно использовать соединение с пользователем с достаточными привилегиями, чтобы иметь возможность сканировать все схемы. Например:

«ORACLE»,, «dbi:Oracle:host=192.168.1.10;sid=XE;port=1521», «system», «manager»
«MSSQL»,, «dbi:ODBC:driver=msodbcsql18;server=srv.database.windows.net;database=testdb», «usrname», «passwd»

создаст отчёт для всех схем в экземпляре XE. Обратите внимание, что в этом случае директива SCHEMA в ora2pg.conf не должна быть установлена.

Он создаст CSV-файл с результатами оценки, по одной строке на схему или базу данных и подробный HTML-отчёт для каждой отсканированной базы данных.

Совет: используйте опцию -t | —test перед тем, как протестировать все ваши соединения в вашем CSV-файле.

Для пользователей Windows вы должны использовать параметр командной строки -b, чтобы установить каталог, в котором находится ora2pg_scanner, иначе вызовы команды ora2pg завершатся ошибкой.

В деталях оценки миграции информация о функциях Ora2Pg всегда включает по умолчанию 2 единицы миграции для TEST и 1 единицу для SIZE на каждые 1000. Синтаксис в стандарт SQL CASE statement. Вы можете найти некоторую информацию об этом в презентации, представленной на PgConf.RU:

    http://ora2pg.darold.net/slides/ora2pg_the_hard_way.pdf

Тестирование миграции

Действие с типом TEST позволяет проверить, что все объекты из базы данных Oracle были созданы под PostgreSQL. Конечно, PG_DSN должен быть установлен, чтобы иметь возможность проверять сторону PostgreSQL.

Обратите внимание, что эта функция учитывает ограничение имени схемы, если определены EXPORT_SCHEMA и SCHEMA или PG_SCHEMA. Если установлен только EXPORT_SCHEMA, сканируются все схемы из Oracle и PostgreSQL. Вы можете отфильтровать одну схему, используя SCHEMA и/или PG_SCHEMA, но вы не можете фильтровать по списку схем. Чтобы протестировать список схем, вам придётся повторить вызовы Ora2Pg, каждый раз указывая одну схему.

Например, команда:

        ora2pg -t TEST -c config/ora2pg.conf > migration_diff.txt

создаст файл, содержащий отчёт обо всех объектах и количестве строк с обеих сторон, Oracle и PostgreSQL, с разделом ошибок, дающим подробную информацию о различиях для каждого типа объекта. Вот пример результата:

        [TEST INDEXES COUNT]
        ORACLEDB:DEPARTMENTS:2
        POSTGRES:departments:1
        ORACLEDB:EMPLOYEES:6
        POSTGRES:employees:6

        [ERRORS INDEXES COUNT]
        Таблица departments не имеет такого же количества индексов в Oracle (2) и в PostgreSQL (1).

        [TEST UNIQUE CONSTRAINTS COUNT]
        ORACLEDB:DEPARTMENTS:1
        POSTGRES:departments:1
        ORACLEDB:EMPLOYEES:1
        POSTGRES:employees:1

        [ERRORS UNIQUE CONSTRAINTS COUNT]
        ОК, Oracle и PostgreSQL имеют одинаковое количество уникальных ограничений.

        [TEST PRIMARY KEYS COUNT]
        ORACLEDB:DEPARTMENTS:1
        POSTGRES:departments:1
        ORACLEDB:EMPLOYEES:1
        POSTGRES:employees:1

        [ERRORS PRIMARY KEYS COUNT]
        OK, Oracle и PostgreSQL имеют одинаковое количество первичных ключей.

        [TEST CHECK CONSTRAINTS COUNT]
        ORACLEDB:DEPARTMENTS:1
        POSTGRES:departments:1
        ORACLEDB:EMPLOYEES:1
        POSTGRES:employees:1

        [ERRORS CHECK CONSTRAINTS COUNT]
        OK, Oracle и PostgreSQL имеют одинаковое количество проверочных ограничений.

        [TEST NOT NULL CONSTRAINTS COUNT]
        ORACLEDB:DEPARTMENTS:1
        POSTGRES:departments:1
        ORACLEDB:EMPLOYEES:1
        POSTGRES:employees:1

        [ERRORS NOT NULL CONSTRAINTS COUNT]
        OK, Oracle и PostgreSQL имеют одинаковое количество ограничений not null.

        [TEST COLUMN DEFAULT VALUE COUNT]
        ORACLEDB:DEPARTMENTS:1
        POSTGRES:departments:1
        ORACLEDB:EMPLOYEES:1
        POSTGRES:employees:1

        [ERRORS COLUMN DEFAULT VALUE COUNT]
        OK, Oracle и PostgreSQL имеют одинаковое количество значений столбцов по умолчанию.

        [TEST IDENTITY COLUMN COUNT]
        ORACLEDB:DEPARTMENTS:1
        POSTGRES:departments:1
        ORACLEDB:EMPLOYEES:0
        POSTGRES:employees:0

        [ERRORS IDENTITY COLUMN COUNT]
        OK, Oracle и PostgreSQL имеют одинаковое количество столбцов идентификаторов.

        [TEST FOREIGN KEYS COUNT]
        ORACLEDB:DEPARTMENTS:0
        POSTGRES:departments:0
        ORACLEDB:EMPLOYEES:1
        POSTGRES:employees:1

        [ERRORS FOREIGN KEYS COUNT]
        OK, Oracle и PostgreSQL имеют одинаковое количество внешних ключей.

        [TEST TABLE COUNT]
        ORACLEDB:TABLE:2
        POSTGRES:TABLE:2

        [ERRORS TABLE COUNT]
        OK, Oracle и PostgreSQL имеют одинаковое количество TABLE.

        [TEST TABLE TRIGGERS COUNT]
        ORACLEDB:DEPARTMENTS:0
        POSTGRES:departments:0
        ORACLEDB:EMPLOYEES:1
        POSTGRES:employees:1

        [ERRORS TABLE TRIGGERS COUNT]
        OK, Oracle и PostgreSQL имеют одинаковое количество триггеров таблицы. Таблица триггеров.

            [TEST TRIGGER COUNT]
            ORACLEDB:TRIGGER:2
            POSTGRES:TRIGGER:2
            [ERRORS TRIGGER COUNT]
            ОК, Oracle и PostgreSQL имеют одинаковое количество TRIGGER.

            [TEST VIEW COUNT]
            ORACLEDB:VIEW:1
            POSTGRES:VIEW:1
            [ERRORS VIEW COUNT]
            ОК, Oracle и PostgreSQL имеют одинаковое количество VIEW.

            [TEST MVIEW COUNT]
            ORACLEDB:MVIEW:0
            POSTGRES:MVIEW:0
            [ERRORS MVIEW COUNT]
            ОК, Oracle и PostgreSQL имеют одинаковое количество MVIEW.

            [TEST SEQUENCE COUNT]
            ORACLEDB:SEQUENCE:1
            POSTGRES:SEQUENCE:0
            [ERRORS SEQUENCE COUNT]
            Последовательность имеет разное количество в Oracle (1) и в PostgreSQL (0).

            [TEST TYPE COUNT]
            ORACLEDB:TYPE:1
            POSTGRES:TYPE:0
            [ERRORS TYPE COUNT]
            Тип имеет разное количество в Oracle (1) и в PostgreSQL (0).

            [TEST FDW COUNT]
            ORACLEDB:FDW:0
            POSTGRES:FDW:0
            [ERRORS FDW COUNT]
            ОК, Oracle и PostgreSQL имеют одинаковое количество FDW.

            [TEST FUNCTION COUNT]
            ORACLEDB:FUNCTION:3
            POSTGRES:FUNCTION:3
            [ERRORS FUNCTION COUNT]
            ОК, Oracle и PostgreSQL имеют одинаковое количество функций.

            [TEST SEQUENCE VALUES]
            ORACLEDB:EMPLOYEES_NUM_SEQ:1285
            POSTGRES:employees_num_seq:1285
            [ERRORS SEQUENCE VALUES COUNT]
            ОК, Oracle и PostgreSQL имеют одинаковые значения для последовательностей.

            [TEST ROWS COUNT]
            ORACLEDB:DEPARTMENTS:27
            POSTGRES:departments:27
            ORACLEDB:EMPLOYEES:854
            POSTGRES:employees:854
            [ERRORS ROWS COUNT]
            ОК, Oracle и PostgreSQL имеют одинаковое количество строк.

  Проверка данных
    Проверка данных заключается в сравнении данных, полученных из внешней таблицы, указывающей на исходную таблицу Oracle, и локальной таблицы PostgreSQL, полученной в результате экспорта данных.

    Для выполнения проверки данных можно использовать прямое подключение, как и любое другое действие Ora2Pg, но вы также можете использовать расширение oracle_fdw, mysql_fdw или tds_fdw при условии, что установлены директивы конфигурации FDW_SERVER и PG_DSN.

    По умолчанию Ora2Pg извлекает 10 000 первых строк с обеих сторон, вы можете изменить это значение с помощью директивы DATA_VALIDATION_ROWS. Когда она установлена на ноль, будут сравниваться все строки таблиц.

    Проверка данных требует, чтобы таблица имела первичный ключ или уникальный индекс, а столбцы ключа не были LOB. Строки будут отсортированы с использованием этого уникального ключа. Из-за различий в поведении сортировки между Oracle и PostgreSQL, если сопоставление столбцов уникального ключа в PostgreSQL не равно 'C', порядок сортировки может отличаться от Oracle. В этом случае проверка данных завершится неудачно.

    Проверку данных необходимо выполнить до внесения каких-либо изменений в данные.

    Ora2Pg прекратит сравнение двух таблиц после достижения DATA_VALIDATION_ROWS или обнаружения 10 ошибок, результат будет записан в файл с именем «data_validation.log», который по умолчанию записывается в текущий каталог. Количество ошибок перед остановкой сравнения строк можно контролировать с помощью директивы конфигурации DATA_VALIDATION_ERROR. Все строки с ошибками выводятся в выходной файл для вашего анализа.

    Можно распараллелить проверку данных с помощью опции -P или соответствующей директивы конфигурации PARALLEL_TABLES в ora2pg.conf.

  Использование номера изменения системы (SCN)
    Ora2Pg может экспортировать данные на определённый SCN. Вы можете установить его в командной строке с помощью параметра -S или --scn. Можно указать конкретный SCN или, если вы хотите использовать текущий SCN при первом подключении, установите значение «current». В последнем случае пользователь соединения имеет роль «SELECT ANY DICTIONARY» или «SELECT_CATALOG_ROLE», текущий SCN просматривается в представлении v$database. **Извлечение данных с использованием SCN**

ora2pg -c ora2pg.conf -t COPY --scn 16605281

Это добавляет следующее предложение в запрос, используемый для извлечения данных:

AS OF SCN 16605281.

Также можно использовать опцию --scn для использования возможности Oracle flashback, указав выражение timestamp вместо SCN. Например:

ora2pg -c ora2pg.conf -t COPY --scn "TO_TIMESTAMP('2021-12-01 00:00:00', 'YYYY-MM-DD HH:MI:SS')"

Это добавит следующее предложение в запрос, используемый для извлечения данных:

AS OF TIMESTAMP TO_TIMESTAMP('2021-12-01 00:00:00', 'YYYY-MM-DD HH:MI:SS')

или, например, чтобы извлечь данные только за вчерашний день:

ora2pg -c ora2pg.conf -t COPY --scn "SYSDATE - 1"

**Захват изменённых данных (CDC)**

Ora2Pg не имеет такой функции, которая позволяет импортировать данные и применять изменения только после первого импорта. Но вы можете использовать опцию --cdc_ready для экспорта данных с регистрацией SCN на момент экспорта таблицы. Все SCN для таблиц записываются в файл с именем TABLES_SCN.log по умолчанию, его можно изменить с помощью опции -C | --cdc_file.

Эти SCN, зарегистрированные для каждой таблицы во время экспорта COPY или INSERT, можно использовать с инструментом CDC. Формат файла — имя таблицы: SCN в каждой строке.

**Импорт BLOB как больших объектов**

По умолчанию Ora2Pg импортирует Oracle BLOB как bytea, целевой столбец создаётся с использованием типа данных bytea. Если вы хотите использовать большой объект вместо bytea, просто добавьте опцию --blob_to_lo в команду ora2pg. Это создаст целевой столбец как тип данных Oid и сохранит BLOB в качестве большого объекта с использованием функции lo_from_bytea(). Возвращаемый функцией Oid вставляется в целевой столбец вместо bytea. Из-за использования функции эту опцию можно использовать только с действиями SHOW_COLUMN, TABLE и INSERT. Действие COPY не разрешено.

Если вы хотите использовать COPY или у вас есть огромный размер BLOB (> 1 ГБ), который нельзя импортировать с помощью lo_from_bytea(), вы можете добавить опцию --lo_import в команду ora2pg. Это позволит импортировать данные в два этапа.

1) Экспорт данных с использованием COPY или INSERT установит целевой столбец Oid для BLOB со значением 0 и сохранит значение BLOB в специальный файл. Также будет создан сценарий оболочки для импорта файлов BLOB в базу данных с помощью команды psql \lo_import и для обновления столбца таблицы Oid до возвращённого большого объекта Oid. Сценарий называется lo_import-TABLENAME.sh.

2) Выполните все сценарии lo_import-TABLENAME.sh после установки переменных среды PGDATABASE и, возможно, PGHOST, PGPORT, PGUSER и т. д., если они не соответствуют значениям по умолчанию для libpq.

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

Ограничение: таблица должна иметь первичный ключ, он используется для установки предложения WHERE для обновления столбца Oid после импорта большого объекта. Импорт BLOB с использованием этого второго метода (--lo_import) очень медленный, поэтому его следует использовать для строк, где BLOB > 1 ГБ. Для всех остальных строк используйте опцию --blob_to_lo. Чтобы отфильтровать строки, вы можете использовать директиву конфигурации WHERE в ora2pg.conf.

*Примечание: данный перевод может содержать неточности.* Данная программа распространяется в надежде на то, что она будет полезна,
но БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ; даже без подразумеваемой гарантии
КОММЕРЧЕСКОЙ ПРИГОДНОСТИ или ПРИГОДНОСТИ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ.  Подробнее см.
в Стандартной общественной лицензии GNU.

Вы должны были получить копию Стандартной общественной лицензии
GNU вместе с этой программой. Если нет, смотрите <http://www.gnu.org/licenses/>.

БЛАГОДАРНОСТЬ
Я должен поблагодарить всех замечательных участников, см. журнал изменений для всех благодарностей.