Izyaправильно я понимаю, что ....?
1) проект burp дает статическая библиотка, которая используется gbak?
2) Основную работу в burp выполняю ф-ии BACKUP_backup и RESTORE_restore, работают они на уровне логических записей. Соответственно, восстанавливая через gbak мы имеем перестроенную структуру записей, например записи меняют свой RecordNumber.
3) поэтому gbak умный, много чего может, но тормоз

4) А nackup наоборот тупой, но быстрый и очень простой, потому что тупо пишет целые страницы из файла БД в файл бекапа . Соответственно логическая структура записей остается совершенно нетронутой.
в целом, правильно. gbak это обычное клиентское приложение, работающее с базой через API. Поэтому ничего знать про физическую структуру базы оно не может в принципе.

Izyaчастности меня RecordNumber интересует, в т.ч. 1) время его неизменной жизни, 2) моменты, когда он может меняться
RecordNumber это внутреннее название RDB$DBKEY. На физическом уровне он неизменен до тех пор, пока жива хоть одна версия записи. Т.е. никакой update/delete не меняет номер записи. Но как только запись была удалена, транзакция закоммичена, не осталось заинтересованных других транзакций и сборка мусора физически удалила эту запись, то номер записи (по сути это слот на странице) может быть использован хранения для другой записи. Поэтому на прикладном уровне считается, что номер записи стабилен на время выполнения транзакции, прочитавшей запись (ибо она заинтересована и не дает убрать мусор). Можно сколь угодно увеличивать этот интервал, заблокировав сборку мусора (снапшот-транзакцией), со всеми вытекающими.

IzyaЯ думал, что RecordNumber показывает где она физически в страницах лежит.
он показывает, где физически на страницах лежит самая свежая версия в цепочке

IzyaИ если мы добавляем поле в таблицу с ALTER TABLE, то последующий UPDATE записи в этой таблице может привести к ее переносу в файле, что означает, что ее RecordNumber меняется
будет создана новая версия записи, старая будет перемещена, новая займет ее место (с тем же RecordNumber, т.е. он не меняется)

Izyaи это видно даже на логическом уровне (например VIO_modify(tdbb, orgRpb, newRpb, transaction) после выполнения в newRpb содержит rpb_number с новым RecordNumber'ом
не может такого быть

IzyaНу видна она в какой-то транзакции с новым RecordNumber
не надо выдумывать то, чего нет

IzyaА между транзакциями RecordNumber меняться может? В каких случаях( кроме восстановления через gbak)? Хотя бы приблизительно.
я уже написал в предыдущем ответе. У существующей записи (ее цепочки версий) никогда, пока ее не удалят и не соберется мусор. После этого тот же номер будет заюзан под другую запись. Иными словами, нельзя "запомнить" RecordNumber и через пару транзакций надеяться, что там находится все та же запись. Разве что из таблицы гарантированно ничего не удаляется.

уточню немного - в некоторых местах ядра rpb_number может указывать и на конкретную версию, но это просто особенность реализации и она никогда не выходит наружу. Например, внутри того же VIO_modify() есть record_param temp, который представляет собой перемещенную старую версию записи, у него rpb_number действительно изменится и будет указывать на новое место. Но он нигде далее не используется и в org/new rpb не попадает, новая версия ссылается на старую только через rpb_b_page / rpb_b_line (которые по сути и есть rpb_number, только в виде прямой адресации). Но снаружи невозможно обратиться к конкретной версии по ее физическому адресу, только по "публичному" rpb_number (адресу самой свежей версии).

IzyaЕсли мы добавили ALTER TABLE к таблице 100 новых полей и в UPDATE записали в эти поля значения - как запись может лежать в том же месте, не мешая соседним записям?
на том же месте будет лежать кусок новой записи, а избыток уйдет в другое место. Это называется фрагментацией.

IzyaТо есть получается, что RecordNumber теоретически можно использовать, что бы обращаться к конкретной записи "всю свою жизнь", т.е. от момента её INSERT до момента её DELETE
да, при условии что ты можешь контролировать эти моменты. Иначе DELETE-GC-INSERT и на том же месте лежит совсем другая запись.