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

Нелегко оценить стоимость процесса миграции из Oracle в Postgres Pro. Чтобы достаточно хорошо произвести такую оценку, ora2pgpro анализирует все объекты в БД, все функции и хранимые процедуры, чтобы определить, есть ли объекты и код PL/SQL, которые невозможно преобразовать автоматически.

Для анализа БД Oracle в ora2pgpro есть специальный режим анализа, который позволяет сгенерировать отчёт о содержимом БД и возможности его экспорта.

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

ora2pgpro -t SHOW_REPORT

Пример отчёта, генерируемого командой:

--------------------------------------
Ora2Pg: Oracle Database Content Report
--------------------------------------
Version Oracle Database 10g Enterprise Edition Release 10.2.0.1.0
Schema  HR
Size  880.00 MB

--------------------------------------
Object  Number  Invalid Comments
--------------------------------------
CLUSTER   2 0 Clusters are not supported and will not be exported.
FUNCTION  40  0 Total size of function code: 81992.
INDEX     435 0 232 index(es) are concerned by the export, others are automatically generated and will
                                do so on PostgreSQL. 1 bitmap index(es). 230 b-tree index(es). 1 reversed b-tree index(es)
                                Note that bitmap index(es) will be exported as b-tree index(es) if any. Cluster, domain,
                                bitmap join and IOT indexes will not be exported at all. Reverse indexes are not exported
                                too, you may use a trigram-based index (see pg_trgm) or a reverse() function based index
                                and search. You may also use 'varchar_pattern_ops', 'text_pattern_ops' or 'bpchar_pattern_ops'
                                operators in your indexes to improve search with the LIKE operator respectively into
                                varchar, text or char columns.
MATERIALIZED VIEW 1 0 All materialized view will be exported as snapshot materialized views, they
                                are only updated when fully refreshed.
PACKAGE BODY  2 1 Total size of package code: 20700.
PROCEDURE 7 0 Total size of procedure code: 19198.
SEQUENCE  160 0 Sequences are fully supported, but all call to sequence_name.NEXTVAL or sequence_name.CURRVAL
                                will be transformed into NEXTVAL('sequence_name') or CURRVAL('sequence_name').
TABLE     265 0 1 external table(s) will be exported as standard table. See EXTERNAL_TO_FDW configuration
                                directive to export as file_fdw foreign tables or use COPY in your code if you just
                                want to load data from external files. 2 binary columns. 4 unknown types.
TABLE PARTITION 8 0 Partitions are exported using table inheritance and check constraint. 1 HASH partitions.
                                2 LIST partitions. 6 RANGE partitions. Note that Hash partitions are not supported.
TRIGGER   30  0 Total size of trigger code: 21677.
TYPE      7 1 5 type(s) are concerned by the export, others are not supported. 2 Nested Tables.
                                2 Object type. 1 Subtype. 1 Type Boby. 1 Type inherited. 1 Varrays. Note that Type
                                inherited and Subtype are converted as table, type inheritance is not supported.
TYPE BODY 0 3 Export of type with member method are not supported, they will not be exported.
VIEW      7 0 Views are fully supported, but if you have updatable views you will need to use
                                INSTEAD OF triggers.
DATABASE LINK 1 0 Database links will not be exported. You may try the dblink perl contrib module or use
                                the SQL/MED PostgreSQL features with the different Foreign Data Wrapper (FDW) extensions.

Note: Invalid code will not be exported unless the EXPORT_INVALID configuration directive is activated.

Поскольку утилита ora2pgpro может преобразовывать код SQL и PL/SQL из синтаксиса Oracle в Postgres Pro, она может оценивать трудности в коде и время, необходимое для выполнения полной миграции БД.

Для оценки стоимости миграции в человеко-днях, ora2pgpro предоставляет директиву ESTIMATE_COST, которую также можно включить в командной строке: --estimate_cost.

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

ora2pgpro -t SHOW_REPORT  --estimate_cost

Сгенерированный отчёт выглядит так же, как в предыдущем примере, но добавляется столбец Estimated cost (Предполагаемая стоимость) следующим образом:

--------------------------------------
Ora2Pg: Oracle Database Content Report
--------------------------------------
Version Oracle Database 10g Express Edition Release 10.2.0.1.0
Schema  HR
Size  890.00 MB

--------------------------------------
Object  Number  Invalid Estimated cost  Comments
--------------------------------------
DATABASE LINK  3 0 9 Database links will be exported as SQL/MED PostgreSQL's Foreign Data Wrapper (FDW) extensions
                                using oracle_fdw.
FUNCTION  2 0 7 Total size of function code: 369 bytes. HIGH_SALARY: 2, VALIDATE_SSN: 3.
INDEX 21  0 11  11 index(es) are concerned by the export, others are automatically generated and will do so
                                on PostgreSQL. 11 b-tree index(es). Note that bitmap index(es) will be exported as b-tree
                                index(es) if any. Cluster, domain, bitmap join and IOT indexes will not be exported at all.
                                Reverse indexes are not exported too, you may use a trigram-based index (see pg_trgm) or a
                                reverse() function based index and search. You may also use 'varchar_pattern_ops', 'text_pattern_ops'
                                or 'bpchar_pattern_ops' operators in your indexes to improve search with the LIKE operator
                                respectively into varchar, text or char columns.
JOB 0 0 0 Job are not exported. You may set external cron job with them.
MATERIALIZED VIEW 1 0 3 All materialized view will be exported as snapshot materialized views, they
                                        are only updated when fully refreshed.
PACKAGE BODY  0 2 54  Total size of package code: 2487 bytes. Number of procedures and functions found
                                        inside those packages: 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  Total size of procedure code: 2436 bytes. TEST_COMMENTAIRE: 2, SECURE_DML: 3,
                                        PHD_GET_TABLE: 24, ADD_JOB_HISTORY: 6.
SEQUENCE  3 0 0 Sequences are fully supported, but all call to sequence_name.NEXTVAL or sequence_name.CURRVAL
                                        will be transformed into NEXTVAL('sequence_name') or CURRVAL('sequence_name').
SYNONYM   3 0 4 SYNONYMs will be exported as views. SYNONYMs do not exists with PostgreSQL but a common workaround
                                        is to use views or set the PostgreSQL search_path in your session to access
                                        object outside the current schema.
                                        user1.emp_details_view_v is an alias to hr.emp_details_view.
                                        user1.emp_table is an alias to hr.employees@other_server.
                                        user1.offices is an alias to hr.locations.
TABLE 17  0 8.5 1 external table(s) will be exported as standard table. See EXTERNAL_TO_FDW configuration
                                directive to export as file_fdw foreign tables or use COPY in your code if you just want to
                                load data from external files. 2 binary columns. 4 unknown types.
TRIGGER 1 1 4 Total size of trigger code: 123 bytes. UPDATE_JOB_HISTORY: 2.
TYPE  7 1 5 5 type(s) are concerned by the export, others are not supported. 2 Nested Tables. 2 Object type.
                                1 Subtype. 1 Type Boby. 1 Type inherited. 1 Varrays. Note that Type inherited and Subtype are
                                converted as table, type inheritance is not supported.
TYPE BODY 0 3 30  Export of type with member method are not supported, they will not be exported.
VIEW  1 1 1 Views are fully supported, but if you have updatable views you will need to use INSTEAD OF triggers.
--------------------------------------
Total 65  8 162.5 162.5 cost migration units means approximatively 2 man day(s).

Последняя строка показывает предполагаемое количество человеко-дней на миграцию кода с блоками миграции для каждого объекта. Блок миграции составляет 5 минут, что соответствует скорости миграции, выполняемой специалистом Postgres Pro. Для первой миграции можно увеличить это значение в директиве COST_UNIT_VALUE или передав параметр --cost_unit_value в командной строке:

ora2pgpro -t SHOW_REPORT  --estimate_cost --cost_unit_value 10

ora2pgpro может выдавать оценку уровня сложности миграции, например Migration level: B-5.

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

Выдаваемый уровень оценки содержит букву (A и B), показывающую необходимость ручной замены кода, и цифру от 1 до 5, определяющую уровень технической сложности. Кроме того, предоставляется параметр --human_days_limit, в котором можно задать предел человеко-дней, по достижении которого уровень миграции меняется на C, чтобы показать необходимость проведения длительных работ и управления проектом миграции с поддержкой. Значение по умолчанию — 10 человеко-дней. Чтобы изменить это значение на постоянной основе, используйте директиву HUMAN_DAYS_LIMIT.

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