Trees in SQL

 Перевод статьи про древовидные структуры в SQL на английский:

• Trees in SQL. Part 1
• Trees in SQL. Part 2
  

Как приступить к разработке платформы Гедымин

Для разработки платформы необходим компьютер с операционной системой Windows не ниже Windows XP и 8 или 16 Гб ОЗУ. Мы рекомендуем больше памяти при использовании виртуальной машины.

Существует два варианта подготовки инструментария для компиляции. Первый -- установить Delphi 5 и Firebird 2.5 непосредственно на компьютер следуя этой инструкции.

Второй вариант -- это обратиться к специалистам нашей компании за готовой виртуальной машиной с предустановленной системой Delphi и сервером баз данных.

Существует два режима работы Гедымина с сервером базы данных. В режим клиент-сервер необходима клиентская библиотека (fbclient.dll или gds32.dll -- обязательно разрядностью 32 бита!) и запущенный сервер (на этом же компьютере или доступный по сети).

В режиме встроенного сервера необходима библиотека fbembed.dll которая, собственно, представляет собой весь сервер Firebird выполняющийся в адресном пространстве gedemin.exe.

В настоящее время Гедымин поддерживает серверы Firebird 2.5, Firebird 3 и Firebird 4. Для двух последних необходимо дополнительно настроить файл конфигурации firebird.conf. 

Некоторые базы данных могут использовать внешние функции из библиотеки GUDF.DLL. Ее следует скачать с нашего сайта и поместить в подкаталог UDF сервера.

Для запуска Гедымина в рабочем режиме потребуется файл базы данных. Это может быть т.н. эталон -- чистая база данных без загруженных прикладных решений. Свежий эталон всегда находится здесь. Либо, можно воспользоваться одной из установок прикладных решений и взять из нее файл базы данных уже с загруженными пространствами имен (так у нас называются файлы с исходным кодом прикладных решений).

Далее, переходим к получению исходного кода, который находится на github.com в приватном репозитории. Обратитесь к сотрудникам компании, чтобы они предоставили вам доступ к нему.

Мы работаем по такому алгоритму:

0. Настраиваем git. Прописываем свое имя пользователя и email командами:

git config --global user.name "FIRST_NAME LAST_NAME"

git config --global user.email "MY_NAME@example.com"

1. Создаем папку \Golden, переходим в нее и клонируем репозиторий себе на компьютер командой:

git clone https://github.com/GoldenSoftwareLtd/gedemin-private.git gedemin

Выполняем действия для подготовки исходников к компиляции, которые указаны в инструкции выше. Компилируем все библиотеки и сам Гедымин согласно инструкции.

2. Основная ветка -- master -- сразу идет в продакшн. В эту ветку мы не комитим изменения напрямую. Перед тем как делать какие-то изменения снимаем код с сервера и создаем новую ветку:

git pull

git checkout -b IssueXXXX

Команду выполняем в папке Gedemin. Имя ветки на ваш выбор.

3. Делаем изменения. Затем комитим их в свою ветку:

Важно! Перед комитом проверяем, что исходники компилируются в Delphi без ошибок.

git commit -a -m "Пишем комментарий"

Перед комитом можно просмотреть сделанные изменения командой:

git status -uno

Важно! Не следует включать в комит следующие файлы, даже если они были изменены:

• gedemin.res, и, вообще, все *.res файлы
• файлы экранных форм *.DFM, где только поменялись координаты экранных элементов при открытии формы в Delphi

Если такие файлы показывает git как измененные, следует вернуть их в исходное состояние. Например, в окне комита оболочки TortoiseGit выбрать такой файл в списке и из контекстного меню вызвать команду Revert.

4. Загружаем изменения в свою ветку в github:

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

git push --set-upstream origin <YOUR BRANCH NAME>

В последствии можно выполнять:

git push

5. Идем на сайт github.com и создаем Pull Request из вашей ветки в мастер. После того, как ведущий разработчик подтвердит ваши изменения, они попадут в мастер и пойдут в продакшн.

6. На своем компьютере переключаетесь на ветку мастер и снимаете последние изменения:

git checkout master

git pull

7. Подключив телеграм бот @gbuilderbot можно получать уведомления об автоматической компиляции проекта и сборке дистрибутивов.

С чего начать?

Мы планируем доработки и регистрируем ошибки и пожелания в списке Issues в этом репозитории.

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

Например, доработки вроде этой вообще не требует написания кода, а только правки экранных форм. 

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

How to find useless foreign keys in a database

With times, old databases tend to overgrow with unnecessary or just empty fields. Whilst regular fields are not much of a concern, those with foreign key constraints, especially in tables with millions of records, would needlessly inflate the database file and put performance penalty on every insert/update/delete operation, as appropriate index need to be updated.

For example, an index on a field that holds nothing more than NULL values over a table with 100 000 000 records has a size approximately of 600 MB.

The query below helps to spot fields with foreign keys, which contain no more than a given count of unique values (by default, the variable maxuniqvalues is set to 1 to find all fields which are empty or contain exactly one value). Additionally, the condition on minimal record count in a table in question could be set through variable minreccnt.

The result data set includes the following columns: name of the relation, number of records in the relation, name of the field, value (only the first value is shown), and a list of objects dependent on the field. The latter will help a lot if the field to be deleted later.

  EXECUTE BLOCK
  RETURNS(
    rn VARCHAR(31),
    reccnt INTEGER,
    fkfieldname VARCHAR(31),
    val INTEGER,
    dependent VARCHAR(8192)
  )
AS
  DECLARE VARIABLE minreccnt DOUBLE PRECISION = 1000000;
  DECLARE VARIABLE maxuniqvalues DOUBLE PRECISION = 1;
BEGIN
  FOR
    SELECT
      rc.rdb$relation_name,
      CAST((1 / idx.rdb$statistics) AS INTEGER),
      idxsfk.rdb$field_name,
      (SELECT
         LIST(TRIM(d.rdb$dependent_name))
         FROM rdb$dependencies d
         WHERE 
           d.rdb$depended_on_name = rc.rdb$relation_name
           AND 
           d.rdb$field_name = idxsfk.rdb$field_name)
    FROM
      rdb$relation_constraints rc
      JOIN rdb$indices idx
        ON idx.rdb$index_name = rc.rdb$index_name
      JOIN rdb$index_segments idxs
        ON idxs.rdb$index_name = idx.rdb$index_name
        AND idxs.rdb$field_position = 0
      JOIN rdb$relation_constraints rcfk
        ON rcfk.rdb$constraint_type = 'FOREIGN KEY'
        AND rcfk.rdb$relation_name = rc.rdb$relation_name
      JOIN rdb$indices idxfk
        ON idxfk.rdb$index_name = rcfk.rdb$index_name
      JOIN rdb$index_segments idxsfk
        ON idxsfk.rdb$index_name = idxfk.rdb$index_name
        AND idxsfk.rdb$field_position = 0
    WHERE
      rc.rdb$constraint_type = 'PRIMARY KEY'
      AND
      (idx.rdb$statistics > 0 
        AND idx.rdb$statistics < (1.0 / :minreccnt))
      AND
      idxfk.rdb$statistics >= (1.0 / :maxuniqvalues)
    ORDER BY
      idx.rdb$statistics ASC
    INTO
      :rn, :reccnt, :fkfieldname, :dependent
  DO BEGIN
    EXECUTE STATEMENT 
      'SELECT FIRST 1 ' || 
      :fkfieldname || 
      ' FROM ' || 
      :rn
      INTO :val;
    SUSPEND;
  END
END

Каждой программе по своей "проблеме 2000 года"

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

В Гедымине есть своя "проблема  2000 года", а точнее проблема 32-х битного идентификатора бизнес-объекта. Чтобы быть еще более точным, не самого идентификатора а генератора GD_G_UNIQUE, с помощью которого идентификаторы добываются.

Данный генератор стартует со значения 147 000 000 и увеличивается по мере запроса новых идентификаторов. Причем, для сокращения количества запросов к серверу, увеличиение идет с шагом в 100, а неиспользованный на момент завершения программы интервал сохраняется в системном реестре.

Так как у нас ИД объекта -- это знаковое 32-х битное целое, то всего доступно чуть более 2-х миллиардов идентификаторов (мы не учитываем первые 147 миллионов, которые выделены под системные объекты платформы).

Два миллиарда число большое. Скажем, если непрерывно получать по одному идентификатору в секунду, то такого диапазона хватит на 63 года. Однако сам генератор ничем не защищен от некорректного использования, уже не говоря про то, что его можно просто "подвинуть" вперед вручную на произвольную величину. Нам встречался код, где генератор использовался для упорядочивания записей в выборке. Естественно, каждое перестроение запроса приводило к пустому расходу сотен, если не тысяч значений генератора.

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

Что делать?

Теоретически есть два варианта решения проблемы. Первый -- это сдвинуть, утрамбовать все идентификаторы "вниз" на выявленные пустые пробелы. Затем изменить значение генератора в соответствии с максимальным ИД в базе.

Технически, для этого придется выполнить следующую последовательность шагов:

1. Сохранить все существующие ИД в некоторой структуре.
2. Построить таблицу соответствия старый ИД -- новый ИД.
3. Отключить все внешние и первичные ключи.
4. Обновить ВСЕ записи в базе данных, заменяя старые идентификаторы на новые.
5. После предыдущего шага желательно выполнить бэкап-восстановление БД для чистки мусора.
6. Восстановить все первичные и внешние ключи.

На базах размером свыше 100 Гб мы не представляем как можно выполнить указанную последовательность в доступное нам технологическое окно (обычно 8-10 часов).  И, если где-то в коде, используется привязка к ИД записи, вместо РУИД, то такой код перестанет работать. К тому же, надо будет как-то вычистить из реестров всех компьютеров сохраненные интервалы или одномоментно заменить все экзешники, скорректировав алгоритм кэширования.

Второй вариант:

1. Создать таблицу для доступных интервалов идентификаторов GD_AVAILABLE_ID.
2. При обращении к функции gdcBaseManager.GetNextID проверять не приблизились ли мы к опасной черте. 
3. Если нет, то работать по-старому -- через генератор. 
4. Если уже пора, то заполняем таблицу и по-мере необходимости берем очередной интервал из нее.

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

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

DATABASE TRIGGERS в Гедымине

Буквально на днях появится возможность создавать в Гедымине DATABASE TRIGGERS. Такие триггеры могут быть назначены на следующие события:

• CONNECT
• DISCONNECT 
• TRANSACTION START
• TRANSACTION COMMIT 
• TRANSACTION ROLLBACK

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

Окно работает на своей транзакции, которая по итогу или комитится -- кнопка Ок, или отменяется.

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

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

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

CREATE OR ALTER TRIGGER after_ins_update
  FOR bookings
  ACTIVE
  AFTER INSERT OR UPDATE
  POSITION 32000
AS BEGIN
  RDB$SET_CONTEXT('user_transaction', 'check_tr', 1);
END

Затем, если флаг выставлен, сделаем проверку корректности данных:

CREATE OR ALTER TRIGGER transaction_check
  ACTIVE
  ON TRANSACTION COMMIT
  POSITION 32000
AS BEGIN
  IF (RDB$GET_CONTEXT('user_transaction', 'check_tr') = 1) THEN
  BEGIN
     --   проверяем не пересекаются ли интервалы
     --   если пересекаются, то вызываем EXCEPTION
  END
END

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

Differences between Firebird and InterBase

InterBase was created in 1985: it was the first commercial multi-versioning database. In the end of 1999, Borland decided to close InterBase development and published its source codes under InterBase Public License. This code was copied (it is permitted by the license), and Firebird was born – from the version 1.0 Firebird is a production-ready database, based on previous decades of InterBase development.

Большой размер кэша в Firebird 3.0

Сам уже дважды прокололся, поэтому хочу предупредить всех. 2.5 мы используем в режиме Classic и размер кэша не велик. Обычно 2000 страниц. С 3.0 основная идея -- это гигантский кэш, соизмеримый с размером БД, и значительный буфер под сортировку в ОЗУ. Например, при размере памяти сервера 128 Гб мы рекомендуем кэш 64 Гб и 32 Гб под буфер сортировки.

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

В таком случае следует уменьшить буфер одной из баз данных с помощью утилиты командной строки:

gfix database_name -user SYSDBA -password sysdba_password -buffers 2000

Быстрая установка сервера Firebird 3

Здесь под "быстрая" мы имеем ввиду, что Firebird запускается в режиме максимальной совместимости с версией 2.5. Т.е. от нас не потребуется дополнительных усилий по настройке учетной записи SYSDBA и для существующих приложений не придется менять клиентские библиотеки.

Заходим сюда и скачиваем архив с новейшей версией сервера нужной нам разрядности.

Предположим, мы остановились на 32-х битной версии. Заходим в c:\Program Files и создаем там папку FB3.

Распаковываем содержимое скачаного архива в созданную папку.

Переходим в нее, находим и открываем на редактирование файл firebird.conf. Находим следующие параметры, убираем перед их именем символ комментария -- решетку и устанавливаем значения по списку ниже:

• AuthServer = Legacy_Auth
• AuthClient = Legacy_Auth
• UserManager = Legacy_UserManager
• WireCrypt = Disabled
• WireCompression = false

Если на данном компьютере уже установлен Firebird, например версии 2.5, то изменим номер порта, чтобы избежать конфликтов. Номер по-умолчанию 3050. Установим, например, 3054:

• RemoteServicePort = 3054

Сохраняем файл конфигурации.

В папку FB3\UDF подкладываем библиотеку GUDF.DLL, которую берем здесь (если устанавливается 64-х битная версия сервера, то библиотеку берем здесь).

Создаем учетную запись SYSDBA:

1. Остановим сервер, если он был уже запущен.
2. Откроем командную строку. Перейдем в папку сервера и выполним:
   isql -user sysdba employee
3. Выполним следующие команды:
   create user SYSDBA password 'masterkey';
   commit;
   quit;

Запуск сервера:

Открываем окно командной строки. Перемещаемся в папку FB3 и выполняем три команды:

1. instreg install
2. instsvc install -a -n fb3
3. instsvc start -n fb3

Теперь сервер работает и к нему можно подключаться. Если мы прописали порт 3054, как указано выше, то с этого же компьютера сетевое подключение будет выглядеть как localhost/3054.

Базы со старых версий сервера на тройку следует переносить через процедуру бэкап на старом сервере, затем восстановление на новом.

GDMNN: Задача #1

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

Цель:

• Унифицировать механизмы фиксации и учета движения, обобщив и распространив их не только на движение ТМЦ, но и на движение (изменение, трансформацию) любого объекта учета.
• Избавиться от дублирования данных и непрозрачных функций преобразования (поля документа => аналитические признаки в проводках).
• Любое поле документа может быть использовано в качестве аналитического признака при построении отчетов.
• Отойти от ограниченной структуры шапка-позиции. Для сложных документов предусмотреть наличие нескольких датасетов с произвольным уровнем вложенности. 
• Для сумовых данных, используемых с целью ускорения выборок (INV_BALANCE), предусмотреть неблокирующую схему обновления, чтобы отказаться от автокомита в складских документах (комита частично введенного документа). 
• Статус документа: черновик, отложенный, готовый.
• Уменьшить размер базы и, как следствие, увеличить скорость операций по изменению и выборке. 

Для новой структуры представить запрос на построение журнала ордера с использованием SQL window functions и другого функционала Firebird 3.

Задание на неделю #1. Firebird 3

На этой неделе произошло событие, которого мы с нетерпением ждали шесть долгих лет -- вышла третья версия сервера Firebird. В двух словах предыстория такова: Interbase, от которого в 2000-м году отпочковался Firebird, был задуман в те времена, когда многопроцессорные системы с десятками гигабайт оперативной памяти встречались разве что в фантастических рассказах. Когда же научно-технический прогресс догнал и перегнал самые смелые фантазии, именно внутренняя архитектура сервера стала основным тормозом. По сути, в многопользовательском сценарии у системного администратора было два выбора: или использовать оперативную память для кэширования данных, но тогда запросы из всех подключений будут выполняться только на одном процессоре/ядре (архитектура SuperServer), или задействовать все процессоры/ядра, но тогда не будет общего кэша и скорость будет зависеть от производительности дисковой подсистемы (архитектура Classic). Тот случай, когда хрен редьки не слаще.

Изменения в архитектуре SuperServer движка Firebird 3 теперь позволяют последнему выполнять запросы сетевых клиентов параллельно на разных процессорах/ядрах, при доступе к общему кэшу, что теоретически делает SuperServer выбором по умолчанию при развертывании системы на предприятии. Как оно получится на практике -- зависит от надежности тройки. В начале 2000-х мы перевели всех клиентов с SuperServer на Classic по двум причинам: падение процесса SuperServer означает обрыв всех коннектов и потерю данных во всех открытых транзакциях у сетевых пользователей; выполнение тяжелого запроса одним из клиентов практически парализует работу всех остальных.

У одного нашего клиента база данных имеет размер 50 Гб, количество одновременных подключений 50-60, на сервере 128 Гб оперативной памяти и 20 физических ядер. План: использовать SuperServer, установить кэш размером 50 Гб и выделить под буфер сортировки 32 Гб. Учитывая, что дисковая подсистема построена на RAID контроллере с 2 Гб энергонезависимой памяти, теоретически, это позволит вообще исключить прямое обращение к дискам. Т.е. производительность сервера базы данных будет определяться процессором, памятью и скоростью обмена с RAID контроллером.

Напомним, что именно производительность дисковой подсистемы всегда возглавляла список факторов, влияющих на общую производительность СУБД. Мы ожидаем ускорения выполнения запросов минимум на порядок. О достигнутых результатах напишем в этом блоге.

Практически все нововведения из третьей версии найдут применение в Гедымине:

• Передача НУЛЛ значений по сети битовой маской. Сейчас каждое поле с НУЛЛ значением занимает при передаче 4 байта + длина поля. Например, в таблице с бухгалтерскими проводками у нас десятки полей-аналитических признаков, которые могут быть не заполнены. Экономия может достигать нескольких сотен байт на каждую запись.
• Возможность увеличить TCP буфер до 32 Кб и применить компрессию данных при передаче. В интернете есть свидетельства о том, что скорость возрастает десятикратно при подключении по сетям с большой латентностью. Например, к серверу в удаленном офисе по VPN каналу.
• Шифрование файла базы данных. Теперь злоумышленник не сможет получить доступ к конфиденциальной информации просто переписав файл на сервер с чистой установкой Firebird и известным паролем к учетной записи SYSDBA.
• Window функции в SQL запросах позволяют объединять вместе данные и агрегатные значения по заданным группам этих данных. До Firebird 3 такую задачу можно было решить либо подзапросами (крайне медленно, так как подзапрос будет выполняться для каждой записи), либо выполнением в цикле отдельных запросов для каждой группы и объединением их результатов в единый набор данных с помощью EXECUTE BLOCK или STORED PROCEDURE, либо алгоритмической обработкой на клиенте (например, внутри Fast Report при построении отчета).
• “Linger” Database Closure for Superserver -- период времени, в течение которого сервер сохраняет в памяти все ресурсы, после закрытия последнего подключения к базе данных -- позволит ускорить загрузку пакета пространств имен, так как переподключение к базе данных выполняется после каждого ПИ, содержащего метаданные.
• DDL триггеры позволят отказаться от выполнения процедуры at_p_sync при старте системы для синхронизации информации о структуре базы данных с содержимым AT_ таблиц.
• Другие изменения и улучшения, на которых мы подробнее остановимся в следующих выпусках.

Исходный код Гедымина уже поправлен для совместимости с последней версией. После внутреннего тестирования мы опубликуем подробную инструкцию апгрейда для наших клиентов.

Официальный Firebird 3.0 Release Candidate 1

Официальная версия Firebird 3.0 Release Candidate 1 для Windows и Linux (а также исходники) доступна для скачивания на www.firebirdsql.org.

Бета-версия документации по языку Firebird 3.0 находится здесь. Полная версия документации ожидается вместе с релизом Firebird 3.0.

По кулуарным сведениям второй релиз-кандидат будет ориентировочно через месяц. А финальная версия планируется на январь-февраль 2016 г.

Обратите внимание!

Запуск Гедымина в режиме совместимости с Windows XP SP3 на Windows 10 замедляет работу программы в 2-4 раза. Чем больше операций с памятью, тем больше степень замедления.

Появилось подробное руководство по подбору и конфигурированию железа для сервера Firebird.

Утилита RAMMap позволяет узнать как именно использует оперативную память операционная система. Например, какая часть файла базы данных кэшируется для ускорения обработки. Task Manager показывает такую память как свободную, чем создает впечатление что много памяти Firebird как бы и не надо.

Японцы переизобрели велосипед и выпустили утилиту конвертации БД Firebird:

...на 7 лет позже нашего FDBConvert:

Выпущен Firebird 2.5.4

Исправление ошибок и два улучшения:

1. Возможность проверки целостности таблиц и индексов без отключения пользователей от БД.
2. Оптимизация использования памяти под временные BLOB.

Подробнее здесь.

Скачать файлы.

Firebird Tour 2015

В рамках тура однодневные семинары пройдут:

• 24 Апреля - Зелигенштадт, Германия
• 19 Мая – Прага, Чехия
• 5 Июня – Москва, Россия

Центральная тема семинара - оптимизация производительности SQL. Семинары проводятся IBSurgeon и IBPhoenix, при поддержке Firebird Developers Team.

Программа семинара, места проведения, расписание.

New SQL features in Firebird 3

New SQL Features in Firebird 3, by Vlad Khorsun from Mind The Firebird

Firebird 3.0 beta 1 is almost ready

Dmitry Yemanov recently announced (in fb-devel discussion list) that Beta 1 of Firebird 3 is expected to be released in the next week.

11º Firebird Developers Day in Brasil

Бразилия точно вторая в списке по популярности Firebird, после Беларуси ;) Традиционный, 11-й, ежегодный день разработчика на Firebird прошел 30 августа 2014 г. при полном аншлаге в городе Пирасикаба.

18 июля вышел релиз Firebird 2.5.3

Исправлены десятки ошибок с момента выхода 2.5.2. Внесены небольшие улучшения:

• New context variables have been added to the SYSTEM namespace to retrieve more information about the current connection and current transaction.

  The added variables: SYSTEM::CLIENT_PID and SYSTEM::CLIENT_PROCESS for the current connection, SYSTEM::LOCK_TIMEOUT and SYSTEM::READ_ONLY for the current transaction.

• Some limits have increased:

  The maximum number of connections on Windows for Superserver and Superclassic has been raised from 1024 to 2048 connections.

  The maximum number of input parameters for external functions (UDFs) has increased to 15.

• Error reporting improvements, including:

  More details are now reported for “object in use” errors.

  The relation name is now added to the text of validation constraint error messages, to help identify the error context.

  Error reporting for index and constraint violations has been extended to include the problematic key value.

• Physical backup (using ALTER DATABASE BEGIN/END BACKUP or the nBackup utility) was improved to speed up extension of the main database file when backup state changes from stalled to merge.

  Contention for the allocation table lock while a database is in the stalled physical backup state has been reduced.

  Faster file growth has been enabled on Linux systems that support fallocate().

• Attachments no longer block others when the allocation table is being read for the first time.
• Execution of a SET STATISTICS INDEX statement no longer blocks or slows down concurrent attachments.
• The scan for limbo transactions at the end of a sweep has been improved.
• Support for the UPDATE OR INSERT statement and the RETURNING clause have been implemented for Embedded SQL (ESQL).

Всем клиентам рекомендуется обновиться до последней версии.

100Gb Firebird database in production