Файл бази даних пошкоджен

[Charg]

[upd]решение ниже в комментариях

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

| Показать

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

Подскажите что с этим можно сделать?

[priup]

Администрування / резервне копиювання / Ctrl+N
А вот если резервную копию не создать ни какого формата ( .ZBF или .ZBK ) - тода жесть.......

[Charg]

Администрування / резервне копиювання / Ctrl+N

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

[priup]

Администрування / резервне копиювання / Ctrl+N

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

Да! Работать в МЕДОКе в это время не получится..............

[Charg]

Ок спасибо, попробую вечерком.
Так же нагуглил таких советов, буду пробовать на копии.

| Показать

If Firebird database is corrupted, please follow these steps to fix it:

Stop Firebird server. Don't use corrupted database - it leads to further corruption. Also, do not copy Firebird database when Firebird server is running - it leads to corrupted copy and, sometimes, to corrupted original database.
Make a copy of Firebird database. Always keep original copy of corrupted Firebird database for possible future use.
Start Firebird server and run the following commands:
gfix.exe -v -full -user SYSDBA -pass masterkey path_to_your_database
gfix.exe -mend -user SYSDBA -pass masterkey path_to_your_database
gbak -b -v -user SYSDBA -pass masterkey path_to_your_database path_to_backup

Try to run them all, even if gfix shows errors.

If backup completed successfully, restore database:
gbak -c -v -user SYSDBA -pass masterkey path_to_backup path_to_database

[ZuluSpirit]

Крім варіанту з резервними копіями, бо відновлення з формату .ZBK на великій базі може тривати не години, а дні, можете пошукати інструкцію створення резервної копії і її відновлення у БД засобами IBExpert, якщо не страшно. Там трішки зручніше, якщо консоль лякає.
Теоретично, це мало б бути аналогічно формату .ZBF, але не перевіряв, тому це не точно.

[Charg]

В общем оказалось совершенно ничего страшного, эти "ошибки" на самом деле не ошибки.
Ссылки на почитать что примерно происходит - раз, два, три

Решилось так (всё это я, естественно, сперва протестировал на копии виртуалки сервера прежде чем ковырять живой сервер):

1. остановил службу медка, потом службу firebird, сделал копию файла C:\programdata\medoc\medocsrv\db\zvit.fdb в ту же папку с именем zvit_copy.fdb. Далее все манипуляции я буду проводить с zvit_copy.fdb

2. далее удаляем (или переименовываем) файл C:\program files\medoc\medocsrv\firebird_m\firebird.log

3. проверяем базу на ошибки (тут и далее - всё в командной запущенной строке от администратора, логин\пароль в примерах я использую стандартный для firebird, разумеется подставляете свой, как и пути к базам):

Код: Виділити все

C:\program files\medoc\medocsrv\firebird_m\gfix.exe -v -full -user SYSDBA -pass masterkey "C:\programdata\medoc\medocsrv\db\zvitcopy.fdb"

в логе firebird.log (который теперь содержит только свежие актуальные данные) можно посмотреть наличие ошибок (error) и предупреждений (warning). Предупреждения пока что игнорируем, ошибки вида Index # is corrupt тоже игнорируем. Других ошибок у меня не было, поэтому если они есть у кого-то еще - я не уверен помогут ли дальнейшие шаги, сами гуглите

4. далее я "пофиксил" pointer page warnings с помощью такой команды.
Ремарка - фактически команда удаляет из БД затронутые записи, но судя по гуглу - восстановить их всё равно уже нельзя. Какие конкретно данные затронуты - можно посмотреть в том же логе firebird.log, в моем случае данные были не критичны.

Код: Виділити все

C:\program files\medoc\medocsrv\firebird_m\gfix.exe -mend -full -user SYSDBA -pass masterkey "C:\programdata\medoc\medocsrv\db\zvitcopy.fdb"

5. далее чтобы избавиться от ошибок индексов И прочих варнингов (во всяком случае тех что у меня были) - нужно сделать бэкап\рестор средствами firebird. Делается так:
Бэкап (ключ -b):

Код: Виділити все

C:\program files\medoc\medocsrv\firebird_m\gbak.exe -b -v -user SYSDBA -pass masterkey "C:\programdata\medoc\medocsrv\db\zvitcopy.fdb" "C:\programdata\medoc\medocsrv\db\zvitcopy_backup.fbk"

Вряд ли это критично, но мануалы обращали внимание на то что бэкап имеет расширение fbk а база fdb, соответственно нужно следить за этим
Рестор (ключ -c):

Код: Виділити все

C:\program files\medoc\medocsrv\firebird_m\gbak.exe -c -v -user SYSDBA -pass masterkey "C:\programdata\medoc\medocsrv\db\zvitcopy_backup.fbk" "C:\programdata\medoc\medocsrv\db\zvitcopy_restored.fdb"

Когда всё закончилось успешно - для очистки совести можно снова запустить валидацию предварительно переименовав firebird.log чтобы получить только свежие данные

Код: Виділити все

C:\program files\medoc\medocsrv\firebird_m\gfix.exe -v -full -user SYSDBA -pass masterkey "C:\programdata\medoc\medocsrv\db\zvitcopy_restored.fdb"

Если в итоге ошибок\варнингов нет (у меня стало именно так) - переименовываем старую бд zvit.fdb в zvit_old.fdb а новую восстановленную zvitcopy_restored.fdb в zvit.fdb, zvit_copy.fdb можно удалить т.к. это был промежуточный вариант "на всякий случай", запускаем службы (сначала firebird, потом медок) и готово.

По времени на моей 19гб базе валидация заняла минуты 3, -mend еще минут 5, бэкап и рестор по минут 10-15 каждый. Это всё, правда, проводилось на неплохом кластере VMware, на дохлом компе с жестким диском думаю будет прилично дольше.

[Забби]

По времени на моей 19гб базе валидация заняла минуты 3, -mend еще минут 5, бэкап и рестор по минут 10-15 каждый. Это всё, правда, проводилось на неплохом кластере VMware, на дохлом компе с жестким диском думаю будет прилично дольше.

А в Медку бекап/рестор такої бази займе тиждень)

[ibsurgeon]

Добрый день,

бэкап-рестор все равно лучше сделать после починки.
Насчет целого дня это преувеличение - 15Гб zvit за час бэкап-рестор прошел на не самом быстром amd 2700 на ssd samsung 850 pro.

С уважением,
Алексей

[Tima37]

Добрый день.
Подскажите, уважаемые.
Файл или папку, на диске С:, КУДА при создании резервной копии свапируется(копируется) база данных, которая при благоприятных обстоятельствах, потом появляется в указанном месте, в формате ZBF.
Предприятие: MedocSRV - база 17 гб находится на диске D:\. Сюда же на диск D:\ делаются резервные копии. D:\ - 56 гб свободного места.
На диске С:\ - 8гб.
При попытке сделать резервную копию Medoc дошел до 35%, сожрал все пространство и исчез.
На диске с:\ 700 Мб.
Перезагрузка ни чего не дала. Windows 10, SSD 240 Gb, 8 Gb ОЗУ.
Проверил Users, ProgramData, Profram Files\,Windows/TEMP - нет таких объемов - 7 Gb,
Где или в чем лежит недоделанная резервная копия???

[Yevhenii_Rish]

Добрый день.
Подскажите, уважаемые.
Файл или папку, на диске С:, КУДА при создании резервной копии свапируется(копируется) база данных, которая при благоприятных обстоятельствах, потом появляется в указанном месте, в формате ZBF.
Предприятие: MedocSRV - база 17 гб находится на диске D:\. Сюда же на диск D:\ делаются резервные копии. D:\ - 56 гб свободного места.
На диске С:\ - 8гб.
При попытке сделать резервную копию Medoc дошел до 35%, сожрал все пространство и исчез.
На диске с:\ 700 Мб.
Перезагрузка ни чего не дала. Windows 10, SSD 240 Gb, 8 Gb ОЗУ.
Проверил Users, ProgramData, Profram Files\,Windows/TEMP - нет таких объемов - 7 Gb,
Где или в чем лежит недоделанная резервная копия???

Добрый день. В данном случае необходимо настроить переменны среды, так как по умолчанию используется именно диск :С

[Tima37]

Добрый день.
Подскажите, уважаемые.
Файл или папку, на диске С:, КУДА при создании резервной копии свапируется(копируется) база данных, которая при благоприятных На диске

Добрый день. В данном случае необходимо настроить переменны среды, так как по умолчанию используется именно диск :С

Для настройки создания новых резервных копий - переменные среды - это уже понятно.
Меня сейчас интересует вот это:
Было - С:\ - 8гб.
При попытке сделать резервную копию Medoc сожрал все пространство и процесс исчез.
На диске стало С:\ - 700 Мб.
Где или в чем лежит недоделанная резервная копия, чтобы ее грохнуть и освободить место на диске С:\???

[Tima37]

Уважаемый, Евгений.
Меня интересует следующее.
Есть логи Медок.
В этих логах нет ни действия, ни пути по созданию временного каталога или файла с резервной копией.
Серверная часть стоит на D:\, а при создании резервной копии, исчезает пространство на диске С:\.
Ведь пока процесс создания резервной копии не закончен, размер резервной копии - 0 кб. Если процесс не закончен, система не сообщает, что нет места на диске С:\, с предложением откатить назад, а просто процесс исчезает, но занятое пространство в 6-8 Гб не возобновляется. Где лежит этот временный файл?

[Yevhenii_Rish]

Уважаемый, Евгений.
Меня интересует следующее.
Есть логи Медок.
В этих логах нет ни действия, ни пути по созданию временного каталога или файла с резервной копией.
Серверная часть стоит на D:\, а при создании резервной копии, исчезает пространство на диске С:\.
Ведь пока процесс создания резервной копии не закончен, размер резервной копии - 0 кб. Если процесс не закончен, система не сообщает, что нет места на диске С:\, с предложением откатить назад, а просто процесс исчезает, но занятое пространство в 6-8 Гб не возобновляется. Где лежит этот временный файл?

Должно писать в Users/.../AppData. Если есть возможность удаленного доступа - напишите в ЛС, просмотрим.

[Tima37]

Нашел решение проблемы.
В Users......../APPDATA/ нашел логи.
В одном из логов нашел текст - "Buh:9996\C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\".
Там в файлах с расширением tmp и хранилась эта не законченная резервная копия.
Убил и на диске сразу появилось место.