научите про gfix...
Модераторы: kdv, Alexey Kovyazin
научите про gfix...
FB 1.5.3
Выполняю такой вот батничек на базе, к которой есть несколько подключений:
gbak -b -g host:d:\base.fdb d:\base.fbk --архивируем
gfix -sh -force 2 host:d:\base.fdb --останавливаем
gbak -r -p 4096 d:\base.fbk host:d:\base.fdb --ресторим
если не вдаваться в дискуссию о вреде рестора на рабочую базу, возникает такая вот проблема:
скрипт отрабатывает нормально, но ресторить не даёт - говорит, что database in use...
А чем тогда gfix занимается? Да и реально в оставшихся коннектах работать невозможно - они говорят, то lost connection.
Так непонятно кто же врёт и как тогда надо правильно организовывать останов базы для рестора?
Выполняю такой вот батничек на базе, к которой есть несколько подключений:
gbak -b -g host:d:\base.fdb d:\base.fbk --архивируем
gfix -sh -force 2 host:d:\base.fdb --останавливаем
gbak -r -p 4096 d:\base.fbk host:d:\base.fdb --ресторим
если не вдаваться в дискуссию о вреде рестора на рабочую базу, возникает такая вот проблема:
скрипт отрабатывает нормально, но ресторить не даёт - говорит, что database in use...
А чем тогда gfix занимается? Да и реально в оставшихся коннектах работать невозможно - они говорят, то lost connection.
Так непонятно кто же врёт и как тогда надо правильно организовывать останов базы для рестора?
Re: научите про gfix...
Это только кажется. Что останавливаем. Во-первых, бага там, зафтксированная в тракере - форс работает правильно только с параметром 0.sydenis писал(а):FB 1.5.3
Выполняю такой вот батничек на базе, к которой есть несколько подключений:
gbak -b -g host:d:\base.fdb d:\base.fbk --архивируем
gfix -sh -force 2 host:d:\base.fdb --останавливаем
LOL вообще-то.sydenis писал(а): gbak -r -p 4096 d:\base.fbk host:d:\base.fdb --ресторим
если не вдаваться в дискуссию о вреде рестора на рабочую базу,
А gfix занимается установкой флага в хидере. И фсё. Соединения никуда не деваются, но сделать ничего кроме как завершиться не имеют права. В теории.sydenis писал(а): возникает такая вот проблема:
скрипт отрабатывает нормально, но ресторить не даёт - говорит, что database in use...
А чем тогда gfix занимается?
Врёш. Они говорят что датабазе шутдовн.sydenis писал(а): Да и реально в оставшихся коннектах работать невозможно - они говорят, то lost connection.
Кто врёт, мы уже разобрались а про дальше ты же просил не вдаваться.sydenis писал(а): Так непонятно кто же врёт и как тогда надо правильно организовывать останов базы для рестора?
в общем, в третьем пункте надо ресторить в БД с другим именем.
потом останавливать сервер ib/fb (net stop или instsvc stop), потом переименовывать оригинальную БД, переименовывать ресторенную БД в оригинал, и стартовать сервер (net start или instsvc start).
т.к.
а) когда сервер остановлен, пользователям некуда ломиться, и они не подсоединятся при ресторе (включая SYSDBA)
б) если вдруг приспичит перейти на линукс, то даже при 1-м коннекте сервера к БД удаление БД реально файл не удаляет, т.е. этот коннект останется на "удаленном файле".
потом останавливать сервер ib/fb (net stop или instsvc stop), потом переименовывать оригинальную БД, переименовывать ресторенную БД в оригинал, и стартовать сервер (net start или instsvc start).
т.к.
а) когда сервер остановлен, пользователям некуда ломиться, и они не подсоединятся при ресторе (включая SYSDBA)
б) если вдруг приспичит перейти на линукс, то даже при 1-м коннекте сервера к БД удаление БД реально файл не удаляет, т.е. этот коннект останется на "удаленном файле".
коль уж всё-таки начали это обсуждать, то...
конечно опасности моего рестора очевидны, но как ни извращайся ошибка может возникнуть на любом этапе - ресторь ты на живую базу или манипулируй с остановами и переименованиями imho...
в любом случае приходится как-то надо анализировать поток ошибок и надеяться на удачу.
100% защищённого варианта автоматического бэкапа я не встречал.
конечно опасности моего рестора очевидны, но как ни извращайся ошибка может возникнуть на любом этапе - ресторь ты на живую базу или манипулируй с остановами и переименованиями imho...
в любом случае приходится как-то надо анализировать поток ошибок и надеяться на удачу.
100% защищённого варианта автоматического бэкапа я не встречал.
Парень, ты ходишь по краю кратера. Неверное движение - и тебя "жарит" начальник и твои сотрудники, так как ты остаешься без актуальной базы (потеряешь данные с момента последнего бэкапа). Если же ресторить в другой файл - в случае ошибки база будет жить. Максимум - потеряешь один (или несколько) бэкапов, что в принципе не страшно. Такое бывает, но редко (например, свободное место закончилось либо что-то другое). Далее. А если бэкап не сработает и gbk'шником останется предыдущий бэкап? Тогда твоя рабочая база будет замещена старой копией. Что тоже популярности тебе не прибавит.sydenis писал(а):конечно опасности моего рестора очевидны, но как ни извращайся ошибка может возникнуть на любом этапе - ресторь ты на живую базу или манипулируй с остановами и переименованиями imho...
И не встретишь. Все равно надо проверять. Да и зачем тебе каждый день разбекапленная база? Раз в неделю/две недели/месяц обычно достаточно.sydenis писал(а):в любом случае приходится как-то надо анализировать поток ошибок и надеяться на удачу.
100% защищённого варианта автоматического бэкапа я не встречал.
дык я ровно про то же самое и говорю...
несколько строчек скрипта, которые приведены вначале треда - просто выжимка из более сложной конструкции и нужны тока, чтоб мне спросить о том как работает gfix
реальный скрипт позволяет воссоздать базу на любое состояние в течении последних 2х недель (такой срок нужен по специфике),
он ресторит в другой файл, а вывод gbak сливается в файл, в котором потом ищется error и тока потом...
в общем там ещё до хрена чего делается, но всё это лишь извращения на тему, о которой я писал выше - при "удачном" стечении обстоятельств могут не спасти никакие шаманские пляски с переименованиями.
несколько строчек скрипта, которые приведены вначале треда - просто выжимка из более сложной конструкции и нужны тока, чтоб мне спросить о том как работает gfix
реальный скрипт позволяет воссоздать базу на любое состояние в течении последних 2х недель (такой срок нужен по специфике),
он ресторит в другой файл, а вывод gbak сливается в файл, в котором потом ищется error и тока потом...
в общем там ещё до хрена чего делается, но всё это лишь извращения на тему, о которой я писал выше - при "удачном" стечении обстоятельств могут не спасти никакие шаманские пляски с переименованиями.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
вопрос не в бровь, а в глаз )
это ты меня, Василий Иванович, крепко поправил
Рестор я по слабости человеческой делаю
Когда нет уверенности, что полностью контролируешь все процессы в БД (мусор, свип, индексы и т.п.), то проще отресторится...
а заодно (если крик не поднялся) знаешь, что весь твой бэкап - рабочий
Но любые другие мнения на эту тему - всегда welcome
это ты меня, Василий Иванович, крепко поправил
Рестор я по слабости человеческой делаю
Когда нет уверенности, что полностью контролируешь все процессы в БД (мусор, свип, индексы и т.п.), то проще отресторится...
а заодно (если крик не поднялся) знаешь, что весь твой бэкап - рабочий
Но любые другие мнения на эту тему - всегда welcome
При чем тут уверенность в процессах... Отресторивать каждый бэкап - это в принципе нормально (у самого так). А вот заменять рабочую базу свежеотресторенным бэкапом каждый день - имхо, это уже слишком.
Кстати, вспомнил, на работе юзается батничек, в котором есть обработка ошибок при бэкапе и архивации. Завтра запостю, если интересует.
Кстати, вспомнил, на работе юзается батничек, в котором есть обработка ошибок при бэкапе и архивации. Завтра запостю, если интересует.
А вот и обещанный bat-файл:
Код: Выделить всё
@ECHO OFF
REM Имя учетной записи
SET FB_USERNAME=SYSDBA
REM Пароль учетной записи
SET FB_PASSWORD=masterkey
REM Путь к базе данных на сервере
SET DATABASE_PATH=G:\Abonent\
REM Имя файла БД (без расширения)
SET DATABASE_NAME=Abonent
REM Путь для хранения архива резервной копии БД
SET BACKUP_PATH=G:\ABONENT\BACKUP\
REM Путь к утилите gbak.exe
SET GBAK=c:\progra~1\firebird\bin\gbak.exe
REM Путь к архиватору
SET WINRAR=c:\progra~1\winrar\winrar.exe
REM Если уже есть бэкап базы, удаляем его
IF EXIST %BACKUPPATH%%DATABASENAME%.GBK DEL %BACKUPPATH%%DATABASENAME%.GBK
REM Если уже есть распакованная база, удаляем ее
IF EXIST %BACKUPPATH%%DATABASENAME%.GDB DEL %BACKUPPATH%%DATABASENAME%.GDB
REM Создание резервной копии БД
%GBAK% -b -v -user %FB_USERNAME% -password %FB_PASSWORD% "%DATABASE_PATH%%DATABASE_NAME%.GDB" "%BACKUP_PATH%%DATABASE_NAME%.GBK"
IF ERRORLEVEL == 1 GOTO GBAK_ERROR
REM Выполнение архивирования созданной резервной копии БД
REM Переход в саму папку, чтобы в архиве не было вложенных папок
G:
cd Abonent\backup\
%WINRAR% a -agYYYY-MM-DD z:\kms_ *.*
IF ERRORLEVEL == 1 GOTO ARC_ERROR
NET SEND 127.0.0.1 Archive "Abonent" created.
GOTO END
:GBAK_ERROR
NET SEND 127.0.0.1 Error Firebird.
GOTO END
:ARC_ERROR
NET SEND 127.0.0.1 Error WinRAR.
GOTO END
:END
EXIT
Хорошая штука, правда кое-что делаю иначе, но это дело вкуса...
Но вот, насчёт проверки на ресторабельность бакупа тут, имхо, слабовато:
IF ERRORLEVEL == 1 GOTO GBAK_ERROR
И это единственная проверка?
Дык у меня сколько раз было бэкапится нормально, а рестор не идёт - например у тебя там где-нть поле есть с кондишеном, а в нём одно значение, оставшееся от каких-то давних тестов и не проходящее по кондишену... или просто файл бэкапа на бэд сектор записался...
Но вот, насчёт проверки на ресторабельность бакупа тут, имхо, слабовато:
IF ERRORLEVEL == 1 GOTO GBAK_ERROR
И это единственная проверка?
Дык у меня сколько раз было бэкапится нормально, а рестор не идёт - например у тебя там где-нть поле есть с кондишеном, а в нём одно значение, оставшееся от каких-то давних тестов и не проходящее по кондишену... или просто файл бэкапа на бэд сектор записался...
Здесь нет проверок на ресторабельность бэкапа . Только проверка на то, что *.gbk создался нормально. Просто у меня бэкап и рестор базы разнесены во времени. То есть сначала делается этим батником (немного измененным) бэкап с архивом, а через несколько часов запускается уже другой батник с рестором, в котором стоит аналогичная проверка на ErrorLevel. Конечно, ничего не мешает делать все это в одном батнике.sydenis писал(а): Но вот, насчёт проверки на ресторабельность бакупа тут, имхо, слабовато:
IF ERRORLEVEL == 1 GOTO GBAK_ERROR
И это единственная проверка?