2. Миграции

2.1. Переход с РЕД Базы Данных 3 на 5.0

  1. Обновите версию РЕД Базы Данных 3 до последней.

  2. Сделайте бэкап баз данных на РЕД Базе Данных 3:

    gbak -user sysdba -pas masterkey -b {host/path}<имя базы даных> {host/path}<имя backup>

  1. Если в firebird.conf в параметре UserManager использовался плагин Multifactor_Manager, то в новой версии его надо заменить на GostPassword_Manager.

  2. Перенести параметры конфигурации из файла fbjava.yaml в databases.conf.

  3. Если используются UDF - задать параметр конфигурации:

    UDFAccess = Restrict UDF

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

2.2. Проблемы совместимости РЕД Базы Данных 3 и 5

  1. Устаревание UDF функций

    При восстановлении базы данных с версии 3.0 на версию 5.0 может возникнуть ошибка, если в базе данных использовались устаревшие UDF функции:

    gbak: WARNING:function XXX is not defined
gbak: WARNING: module name or entrypoint could not be found

    Поддержка внешних UDF функций (реализованных в динамических библиотеках и определенных в базе данных с помощью функций оператора DECLARE FUNCTION) в версии 5.0 устарела. Теперь по умолчанию для параметра UdfAccess в firebird.conf задано значение NONE. UDF-библиотеки ib_udf и fbudf изъяты из дистрибутива. Конечно, вы можете реализовать свою собственную динамическую библиотеку (или использовать библиотеки из предыдущей версии РЕД Базы Данных), настроить конфигурацию и работать с устаревшими функциями. Но этого делать не рекомендуется — вам лучше переключиться на использование функций UDR или PSQL. Чтобы переход стал проще, в дистрибутив включен скрипт udf_replace.sql, выполняющий соответствующую замену устаревших функций. К этим функциям относятся:

    ADDDAY

    ADDDAY2

    ADDHOUR

    ADDMILLISECOND

    ADDMINUTE

    ADDMONTH

    ADDSECOND

    ADDWEEK

    ADDYEAR

    DIV

    DNULLIF

    DNVL

    DOW

    DPOWER

    GETEXACTTIMESTAMP

    GETEXACTTIMESTAMPUTC

    I64NULLIF

    I64NVL

    I64ROUND

    I64TRUNCATE

    INULLIF

    INVL

    ISLEAPYEAR

    LTRIM

    ROUND

    RTRIM

    SDOW

    SNULLIF

    SNVL

    SRIGHT

    STRING2BLOB

    STRLEN

    SUBSTR

    SUBSTRLEN

    TRUNCATE

    UDF_FRAC или FRAC

    Просто запустите скрипт:

    isql -user sysdba -pas masterkey -i udf_replace.sql <база данных>

    и UDF, распространяемые в ib_udf и fbudf, будут заменены соответствующими новыми функциями.

  2. Изменения в DDL и DML из-за поддержки часовых поясов

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

    • Синтаксис для объявления типов данных TIMESTAMP и TIME был расширен, чтобы включить аргументы, определяющие, должны ли столбец, домен, параметр или переменная быть определены с установкой часового пояса или без него:

      TIME [ {WITHOUT|WITH} TIME ZONE ]
TIMESTAMP [ {WITHOUT|WITH} TIME ZONE ]

      По умолчанию используется аргумент WITHOUT TIME ZONE.

    • В версии 5.0 переменные CURRENT_TIME и CURRENT_TIMESTAMP изменены: теперь они возвращают значения типа TIME WITH TIME ZONE и TIMESTAMP WITH TIME ZONE с часовым поясом, установленным часовым поясом сеанса. В предыдущих версиях CURRENT_TIME и CURRENT_TIMESTAMP возвращали соответствующие типы в соответствии с системными часами, то есть без какого-либо часового пояса.

      Переменные LOCALTIMESTAMP и LOCALTIME теперь заменяют прежние функциональные возможности CURRENT_TIMESTAMP и CURRENT_TIME соответственно.

  3. Сокращенное преобразование неявных литералов даты/времени не поддерживается

    Синтаксис сокращенного преобразования типов, используемый вместе с неявными литералами даты/времени, такой как, например:

    TIMESTAMP 'NOW'
DATE 'TODAY'
DATE 'YESTERDAY'

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

    • в хранимых процедурах и функциях вычисление этих выражений будет происходить во время компиляции, а не во время вызова процедуры или функции, сохраняя результат в BLR и извлекая это устаревшее значение во время выполнения;

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

    Если что-то вроде TIMESTAMP NOW использовалось в SQL запросах в коде приложения или в PSQL, возникнет проблема совместимости с Ред Базой Данных 5.0. Теперь движок будет выдавать ошибку.

    В тоже время сокращенное преобразование явных литералов, таких как DATE 2019.02.20 допустимо. Также преобразование CAST(NOW AS TIMESTAMP) продолжает работать как раньше.

  4. Стартовое значение последовательности

    До версии 5.0 последовательности (generator/sequence) создавались с текущим значением равным стартовому значению (или 0 по умолчанию).

    Следующим значением последовательности со стартовым значением 0 и приращением 1 было 1.

    В версии 5.0 последовательности создаются с текущим значением равным стартовому минус инкремент. И начальным значением по умолчанию является 1 (а не 0).

    То есть результат оператора NEXT VALUES FOR для последовательности со стартовым значением 100 и приращением 10 будет 100 (а не 110, как было раньше). Аналогично функция GEN_ID(SEQ, 1) возвратит 91 (а не 101, как было раньше).

  5. Совместимость с новыми типами данных

    Параметр DataTypeCompatibility задает уровень совместимости, определяющий, какие типы данных доступны клиентскому API. В настоящее время доступны два варианта: 3.0 и 2.5. Режим эмуляции 3.0 скрывает типы данных, появившиеся после версии 3.0, а именно DECIMAL и NUMERIC с точностью 19 и выше, DECFLOAT, TIME WITH TIME ZONE, TIMESTAMP WITH TIME ZONE. Соответствующие значения возвращаются через типы данных, поддерживаемые версией 3.0. Режим эмуляции 2.5 преобразует ещё и тип данных BOOLEAN. Этот параметр позволяет устаревшим клиентским приложениям работать с версией 5.0 без перекомпиляции для обработки новых типов данных.

  6. Параметры репликации

    Cледующие параметры репликации в РЕД Базе Данных 5 были переименованы. Для обеспечения совместимости можно использовать названия из версии 3. В РЕД Базе Данных 6 нельзя будет использовать старые названия.

    Таблица 2.1 Совместимость параметров репликации

    Название опции в 5.0

    Название опции в 3.0

    sync_replica

    replica_database

    journal_segment_size

    log_segment_size

    journal_segment_count

    log_segment_count

    journal_directory

    log_directory

    journal_file_prefix

    log_file_prefix

    journal_group_flush_delay

    log_group_flush_delay

    journal_archive_directory

    log_archive_directory

    journal_archive_command

    log_archive_command

    journal_archive_timeout

    log_archive_timeout

    journal_source_directory

    log_directory

    verbose_logging

    verbose

  7. Изменилось имя пользователя, от которого запускается сервер

    Предупреждение

    Сервер РЕД Базы Данных 5 работает от пользователя reddatabase.

2.3. Переход с РЕД Базы Данных 5 на 3

  1. Прекратите работы с базой данных и сделайте её копию.

  2. Запустите миграцию:

    rdbsvcmgr service_mgr -user SYSDBA -action_migrate -mig_version rdb3.0 -dbname <база данных>

  3. Сделайте резервную копию базы данных на версии 5 утилитой gbak от версии 3. Для этого скопируйте файлы РЕД Базы Данных 3 в каталог /opt/rdb_3.0. Затем выполните:

    export FIREBIRD=/opt/rdb_3.0
export LD_LIBRARY_PATH=/opt/rdb_3.0/lib
gbak -user sysdba -password masterkey -b -v -g 127.0.0.1:<база данных> <файл бэкапа> -y <путь к логу бэкапа> -ignore

  4. Сохраните копии конфигурационных файлов:

    cp /opt/RedDatabase/*.conf /home/firebird

  5. Удалите РЕД Базу Данных 5.

  6. Установите РЕД Базу Данных 3.

  7. Восстановите базу данных из резервной копии:

    gbak -user sysdba -password masterkey -c -v <файл бэкапа> <база данных 3.0> -y <путь к логу рестора>

    При этом могут возникнуть сообщения -bad debug info и информация об ошибках blr. Эти предупреждения нужно игнорировать.

  8. Выгрузите скрипты с несовместимыми объектами (/home/firebird/prefix_permanent.sql) и объектами, требующими перекомпиляции (/home/firebird/prefix_restore.sql):

    isql -user SYSDBA -password masterkey -ch <кодировка> <база данных 3.0> -extract -incompatible /home/firebird/prefix -MIGVER 30 -nodbtrig

    Каталог /home/firebird должен существовать. Если его нет, то создайте его предварительно.

  9. Необходимо исправить SQL, содержащийся в prefix_permanent.sql, чтобы он был совместим с версией 3.0. После исправления выполните скрипт:

    isql -user SYSDBA -password masterkey -ch <кодировка> -i /home/firebird/prefix_permantnt.sql <база данных 3.0> -nodbtrig

  10. Перекомпилируйте объекты:

    isql -user SYSDBA -password masterkey -ch <кодировка> -i /home/firebird/prefix_restore.sql <база данных 3.0> -nodbtrig

    При этом могут возникнуть сообщения bad debug info. Это предупреждения и они не влияют на результат.

  11. Восстановите параметры конфигурации РЕД Базы Данных 5. Необходимо для каждого файла конфигурации, сохранённого на шаге 4, перенести активные опции в соответствующий файл конфигурации версии 3. Если в РЕД Базе Данных 3 нет параметра, который присутствовал в версии 5, необходимо либо найти подходящий по смыслу (т.е. случай, когда изменилось имя параметра), либо не переносить его (такого параметра в версии 3 просто нет).

  12. Перезапустите сервер.