Добрый день. Не пускает в базу.
выдает ошибку
-internal Firebird consystency chek (Duplicated item in allocation table detected)
-internal Firebird consystency chek (Can't actualize alloc table)

Есть сам файл и дельта.

Firebird 2.5.7.27050

gfix -shut -force 0
выдает
internal Firebird consystency chek (Duplicated item in allocation table detected)
-internal Firebird consystency chek (Can't actualize alloc table)

gstat -h

Database header page information:
Flags 0
Checksum 12345
Generation 19133937
Page size 4096
ODS version 11.2
Oldest transaction 11015121
Oldest active 11015122
Oldest snapshot 11015122
Next transaction 19122770
Bumped transaction 1
Sequence number 0
Next attachment ID 65318
Implementation ID 26
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Apr 13, 2018 6:19:45
Attributes force write, backup lock

Variable header data:
Database backup GUID: {0B85EBA6-9ABA-405E-B7A7-C1234088241A}
Sweep interval: 20000
*END*

Есть копия file_0_.nbk, file_1_.nbk, file_2_.nbk.
Дельта создалась после file_2_.nbk.

Что можно сделать ?

Basil A. Sidorov,
nbackup -L и nbackup -N
выдают

PROBLEM ON "attach database".
-internal Firebird consistency check (Duplicated item in allocation table detected)
-internal Firebird consistency check (Can't actualize alloc table)
SQLCODE:-902

Failure: Database error

В какой то момент, во время nbackup что то произошло.
Резервное копирование перестало выполняться, но никто не проконтролировал.
Файл дельты рос, копирование не делалось.
В один прекрасный момент решили запустить проверку базы на ошибки.

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

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

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

В конечном итоге базу восстанови.

Но к этому времени уже взяли последний бекап, 4-х месячной давности, и набили все руками.

hvladrem16достигли максимальный размер файла дельты 4 гб (во всяком случае в логах была такая ошибка).Сохранилось сообщение ?


SRV1 (Server) Mon Oct 15 00:04:06 2018
I/O error during "WriteFile" operation for file "C:\BASE\TEMP.FDB"
Error while trying to write to file
Недостаточно места на диске.

SRV1 (Server) Mon Oct 15 18:50:47 2018
I/O error during "ReadFile" operation for file "C:\BASE\base1_2018.FDB.delta"
Error while trying to read from file
Достигнут конец файла.

hvlad
rem16После того как на дисковом массиве закончилась перестройка и проверка дисков, которая длилась пару недель, еще раз забрали сохраненные туда файлы и уже на на них gfix и gback вернули базу к жизни.Т.е. сообщения "Duplicated item in allocation table detected" на этих файлах не было ?
Каким боком тут gbak ? Может nbackup ?

"Duplicated item in allocation table detected" - не было.

Каким боком тут gbak ? Может nbackup ? - сделали gfix -v -full, только после этого прошла успешно команда nbackup -N, затем бекап и восстановление с использованием gbak и после этого gfix показал что нет ошибок.

Симонов Денис, да макс размер дельты не причем, я ошибся.
просто так совпало что место на диске кончилось когда дельта была 4 Г с хвостиком и сразу виноватого нашел.