Мимопроходящий,

ib xe7

gbak -?
-VA(LIDATE) validate data

причем, когда я писал в статью, проверял, и правда -va ВКЛЮЧАЛО валидацию, без нее ничего не валидировалось.
Надо будет перепроверить.

_Vasilisk_gbak.exe" -archive_recover
што??? Это восстановление базы из "архива", который делается через -archive_database, причем это ДАМП, а не "бэкап".
Почему оно не ругается на комбинацию -archive_recover -r - я не знаю. Но по смыслу это перпендикулярные опции.

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

_Vasilisk_,

ну проверил бы без -va. Это как сделали в ИБ 7, так я и написал. Может обратно переделали, хотя справка по гбак у ИБ хе7 утверждает что -va это именно включение проверки.

_Vasilisk_А откуда оно могло появиться?
у обычных индексов - кто-то взял и выключил.
у pk-fk-unique - маловероятно, разве что через системные таблицы (и то там волшебное значение 3 надо указывать для деактивации)

Ты вот спрашиваешь, и х.з. что тебе отвечать. Потому что, например, при ресторе все индексы создаются в конце рестора.
У ИБ видимо осталось (было и в ФБ, но в 2.1 уже нет), что если хоть какой-то индекс активировать обломилось, то дальше все остальные индексы тоже остаются неактивными. И тут всё зависит только от порядка таблиц, как они бэкапились.

Собственно. Сделал эксперимент. Взял employee.gdb. Вырубил rdb$primary1, добавил в country запись с дубликатом ПК, сделал бэкап.
Делаю рестор
gbak -c e.gbk e1.gdb -v
Thu Jul 23 17:09:02 2020: gbak: creating indexes
gbak: ERROR: connection lost to database
Thu Jul 23 17:09:12 2020: gbak: Exiting before completion due to errors
gbak: ERROR: connection lost to database

Упало! Упал гбак, ИБ при этом не упал.

Пускаю рестор с -va.
gbak -c e.gbk e1.gdb -v -va
На самом старте какие-то дикие тормоза.
Thu Jul 23 17:13:23 2020: gbak: creating indexes
Thu Jul 23 17:13:33 2020: gbak: cannot commit index RDB$FOREIGN3
gbak: ERROR: connection lost to database
gbak: ERROR: connection lost to database
Thu Jul 23 17:13:33 2020: gbak: Exiting before completion due to errors
gbak: ERROR: connection lost to database
gbak: ERROR: connection lost to database

Уже лучше. Явно видно что -va действительно ВКЛЮЧАЕТ валидацию. Смотрим внутрь баз.

Открываем базу от первого рестора.
I/O error for file "D:\IB2017\BIN\E11.GDB".
Error while trying to read from file.
Достигнут конец файла. .

Т.е. база тю-тю.

Открываем базу рестора с -va
Unsuccessful execution caused by a system error that precludes
successful execution of subsequent statements.
database file appears corrupt ().
wrong page type.
page 509 is of wrong type (expected 5, found 0).

И вторая тоже того, повреждена в процессе рестора (очешуеть можно!).
Тем не менее она открылась, а вот ibe системные таблицы не кажет. В rdb$indices неактивны вообще ВСЕ индексы, включая по системным таблицам. ПК-ФК на юзерские таблицы тоже неактивны все (значение 3)

Чё-то какой-то пугающий эксперимент.

p.s. кстати, что мне в голову впёрлась хе7, если у тебя 2017. Проверял на ней, версия 13.3.0.328, последняя (update 3).

hvlad,

кароч, у ИБ при ресторе коммит всех индексов идет в одной транзакции. Отсюда всё что есть - деактивировано нахрен :-)

Мимопроходящийа если с ключом -o[ne_at_time] ?
теперь это ключ -on[e_at_a_time]
потому что если написать
D:\IB2017\bin>gbak -c e.gbk e1.gdb -v -va -o
gbak: ERROR: ods version parameter missing
Thu Jul 23 18:58:04 2020: gbak: Exiting before completion due to errors

на букву О там дохрена чего
-ODS(_VERSION) restore to specific major ODS version number
-O(NE_AT_A_TIME) restore one table at a time
-OL(D_DESCRIPTIONS) save old style metadata descriptions
-OV(ERWRITE_DUMP) overwrite dump file

криворукие, что с них взять.

Впрочем, что с -on, что без, результат один (я ничего другого и не ожидал, т.к. -o это "не туда").