Вопрос о файле .delta

[TAV]

Здравствуйте, уважаемые коллеги!

Настроил на сервере у себя инкрементный бекап, посредством замечательного скрипта http://borisnote.wordpress.com/2009/01/ ... -firebird/

Дак вот, все работает как часы, но создается файл с расширением [имя_БД].delta, и не исчезает (должен ли он исчезать?).
Собственно вопрос вот в чем, что это за файл, он там должен быть? Никак на работу БД инкрементный бекап не влияет?
И еще вопрос: возможен ли запуск двух задач бекапа в одно время, то есть пока не закончился бекап одной БД запускать бекап другой БД на том же сервере?

[kdv]

Дак вот, все работает как часы, но создается файл с расширением [имя_БД].delta, и не исчезает (должен ли он исчезать?). \
Собственно вопрос вот в чем, что это за файл, он там должен быть?

Встречный вопрос - а Вы прочитали исходную ссылку, которую рекомендовал автор поста?
http://www.firebirdsql.org/devel/doc/ma ... ew-ru.html

для начала, как бы, неплохо ознакомиться с технологией. Когда создается файл нбэкапа любого уровня сервер блокирует базу от изменений, в это время изменения идут только в дельту. По окончании создания файла нбэкапа (или окончания блокирования БД) дельта заливается в базу.
Если дельта не удаляется после скрипта, значит или скрипт что-то делает не так, или по какой-то причине база не разблокируется.

Я настоятельно рекомендую прочитать оригинальную документацию по nbackup, указанную выше, и поэкспериментировать самостоятельно с изготовлением резервных копий таким образом ВРУЧНУЮ. Чтобы было понятно, что, зачем, и как работает.

кроме этого, в зависимости от версии FB, на Classic отсутствие commit в некоторых процессах может приводить к этому самому "зависанию" файла дельты.

возможен ли запуск двух задач бекапа в одно время, то есть пока не закончился бекап одной БД запускать бекап другой БД на том же сервере?

а за каким, простите за прямоту? и Вы про какой бэкап - про бэкап или нбэкап? Если про нбэкап, то ответ очевиден, он изложен выше.

[hvlad]

.delta должен сам исчезать после того, как изменения из дельты слиты в основную БД.
Иногда это не происходит (ошибки сервера, скорее всего исправлены в тек. версии).
Ничего страшного, но ни в коем случае нельзя удалять дельту руками.

С помощью gstat -h нужно посмотреть состояние физ. бекапа. Если БД в состоянии физ. бекапа, то gstat это покажет.

Далее нужно выполнить nbackup -N для окончания физ. бекапа. Это действие сольёт изменения из дельты в БД и удалит дельту.
Но прежде я бы рекомендовал остановить сервер и скопировать БД и дельту.

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

Бекапить разные БД одновременно можно без проблем.

[hvlad]

в зависимости от версии FB, на Classic отсутствие commit в некоторых процессах может приводить к этому самому "зависанию" файла дельты.

Не в коммитах там было дело.

[TAV]

Версия сервера к сожалению 2.1.2 Super

С помощью gstat -h нужно посмотреть состояние физ. бекапа. Если БД в состоянии физ. бекапа, то gstat это покажет.

Код: Выделить всё

Database header page information:
        Flags                   0
        Checksum                12345
        Generation              524814
        Page size               8192
        ODS version             11.1
        Oldest transaction      463180
        Oldest active           463181
        Oldest snapshot         463181
        Next transaction        483513
        Bumped transaction      1
        Sequence number         0
        Next attachment ID      41253
        Implementation ID       16
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        3
        Creation date           Jan 8, 2010 19:15:05
        Attributes              force write

    Variable header data:
        Database backup GUID:   {94C934FA-6640-4CF7-CBA6-C643344BBCA8}
        Sweep interval:         0
        *END*

Я правильно понимаю с БД все в порядке?
Сейчас чтобы слить Дельту, нужно отключить всех пользователей и выполнить nbackup -N.
Без отключения пользователей можно выполнить данную команду?

[kdv]

Версия сервера к сожалению 2.1.2 Super

на суперсервере залипания дельты маловероятны, как мне кажется. А вот смысла использовать 2.1.2 не вижу, т.к. обновление на 2.1.3 можно сделать в течение нескольких секунд.

Сейчас чтобы слить Дельту, нужно отключить всех пользователей и выполнить nbackup -N.

как минимум, попробовать стоит.

Без отключения пользователей можно выполнить данную команду?

разумеется.

[TAV]

Извините, версия не Super, а Classic
Если классик то видимо проблема все таки в зависших транзакциях при старте нбекапа?
nbackup -N написала вот чего:

Код: Выделить всё

[
PROBLEM ON "end backup".
unsuccessful metadata update
-Database is not in the physical backup mode
SQLCODE:-607
]
Failure: Database error

Дельта так и висит и на первой и на второй БД. Причем изменения уже идут в БД давно.

[hvlad]

Остановить сервер. Убедиться что нет коннектов и процессов fb_inet_server.
Убрать дельту (перенести в другое место).
Попробовать коннект к БД.

Обновиться до 2.1.3 !

Ещё раз - тр-ции не при чём.

[TAV]

Остановить сервер. Убедиться что нет коннектов и процессов fb_inet_server.

Нет такой возможности. Отключить физически Ethernet или ждать когда уйдут коннекты?
Получается что дельта - это что сейчас повисшие данные? Так как дата и время у нее уже не меняется, последнее изменение к примеру так:
нбекап был в 12:00 - изменения дельты в 12:05 - и все дальше никаких изменений нет. А БД тем не менее работает и дальше.

Ещё раз - тр-ции не при чём.

А что тогда при чем?

[kdv]

изменения дельты в 12:05 - и все дальше никаких изменений нет. А БД тем не менее работает и дальше.

посмотри даты последней модификации файлов БД и дельты. если под виндами - обязательно только через свойства по правой кнопке в проводнике (иначе может показать не то).

По идее, если дельта новее базы, то нбэкап продолжается. Если дельта старее базы, то не понятно, как она осталась. Попробуй советы Влада, но ни в коем случае файлы дельты не удаляй безвозвратно, пока не разберешься.

[TAV]

Да я так и говорю дата дельты старее БД, то есть на момент бекапа пять минут прошло и все дельта не менялась

Дельта:
Создан: 12 февраля 2010 г., 9:00:00 (вот это время интересно! то есть файл с 9:00 не удалялся - нбекап запускался каждый час)
Изменен: 12 февраля 2010 г., 12:05:17
БД:
Изменен: 12 февраля 2010 г., 16:13:52

Попробовать коннект к БД.

Что это даст? Коннект идет и так. И gstat -h говорит, что те в режиме физ бекапа. Инкрементный бекап задания я остановил сразу, сейчас они не стартуют. Ошибок пока нет (по крайней мере никто не жаловался). БД в работе. Пока не могу обновить версию сервера.

Может быть так что в дельте какие то ошибочные данные остались? как это выяснить? У нее довольно маленький размер: примерно 500 кБ (размер БД 2 гБ)

[hvlad]

Остановить сервер. Убедиться что нет коннектов и процессов fb_inet_server.

Нет такой возможности. Отключить физически Ethernet или ждать когда уйдут коннекты?

Для надёжности - лучше сделать так, как я написал.

Получается что дельта - это что сейчас повисшие данные? Так как дата и время у нее уже не меняется, последнее изменение к примеру так:
нбекап был в 12:00 - изменения дельты в 12:05 - и все дальше никаких изменений нет. А БД тем не менее работает и дальше.

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

Ещё раз - тр-ции не при чём.

А что тогда при чем?

Долго объяснять. Вот это, например.
Оно в 2.1.3 или 2.1.4 тоже должно быть исправлено, не помню точно в где

[TAV]

В общем ситуация развивалась следующим образом:

Без отключения пользователей делал бекап полный GBAK посредством IBEXPERT - процесс повис (примерное время создания нормального бекапа 4-6 минут) я его принудительно снял.
Дождался отключения (отключил принудительно) пользователей. Перегрузил сервер (службу FB) попробовал снова сделать бекап - стопорится на одной из таблиц (пытался два раза, в том числе на другом компьютере и даже версии сервера 2.1.3). Дропнул эту таблицу (благо она не очень важная) - бекап прошел. Перепроверил все данные - вроде все чисто.
Тем не менее странное поведение gbak очень непонятно, раньше такого не наблюдалось (до использования nbackup).
Сервер естественно обновил до 2.1.3.

Вопрос: есть ли какая то хорошая утилита по автоматизации процесса бекапа (gbak и nbackup) или начинать писать ее самому? Интересует гибкий процесс, то есть делаем бекап, архивируем его, копируем на другой сервер, все это обернуто в свой планировщик.

[hvlad]

gbak и nbackup никак не связаны.
RTFM gbak -g

[kdv]

Без отключения пользователей делал бекап полный GBAK посредством IBEXPERT

поздравляю. как у нас еще неистребима вера в GUI.

процесс повис я его принудительно снял.

какой процесс ? IBExpert умеет только через Services API, то есть командовать серверу, чтобы он делал бэкап. Снял процесс сервера или IBExpert?

Дропнул эту таблицу (благо она не очень важная) - бекап прошел. Перепроверил все данные - вроде все чисто.

OMG. про версии и сборку мусора, очевидно, не в курсе.

есть ли какая то хорошая утилита по автоматизации процесса бекапа

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

Интересует гибкий процесс, то есть делаем бекап, архивируем его, копируем на другой сервер, все это обернуто в свой планировщик.

под виндами - cmd+at, под линуксом cron, хоть обпишись.

Но сначала - www.ibase.ru/devinfo/gbak.htm , статьи про сборку мусора, и т.д.

[TAV]

поздравляю. как у нас еще неистребима вера в GUI.

Ув. КДВ и при чем тут вера в гуи? Всегда делаю бекап средствами IBEXPERT(он запускает gbak с определенными параметрами вот и все) и завис не он а серверный процесс, естественно его я и снял (Вы со всеми как с блондинкой разговариваете?)

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

К таким результатам привела ошибка в оф-й утилите NBACKUP, а никак не написание каких либо батников либо JS-скриптов. Скачайте вышеприведенный скрипт и посмотрите, он не делает ничего кроме вызова той самой утилиты.

[TAV]

gbak и nbackup никак не связаны.
RTFM gbak -g

Всмысле не связаны? Я и не говорю что они связаны. Я говорю о написании утилиты, которая позволит их запускать в автоматическом режиме раздельно.

[kdv]

Всегда делаю бекап средствами IBEXPERT(он запускает gbak с определенными параметрами вот и все) и завис не он а серверный процесс, естественно его я и снял (Вы со всеми как с блондинкой разговариваете?)

Я о том, что Вы не можете АВТОМАТИЗИРОВАТЬ резервное копирование при помощи IBExpert. И если Вы не умеете делать резервное копирование иными способами, то как собираетесь писать утилиту? Которые, кстати, уже написаны в достаточном количестве, или организуется упомянутыми мной способами (gbak + cmd + AT).

Еще один косвенный вывод, который делается из "бэкапа только через IBExpert" - что у Вас нет базы, находящейся в "промышленной эксплуатации".

К таким результатам привела ошибка в оф-й утилите NBACKUP, а никак не написание каких либо батников либо JS-скриптов. Скачайте вышеприведенный скрипт и посмотрите, он не делает ничего кроме вызова той самой утилиты.

я в курсе, и смотреть этот скрипт никакой нужды нет.

[TAV]

И если Вы не умеете делать резервное копирование иными способами, то как собираетесь писать утилиту? Которые, кстати, уже написаны в достаточном количестве, или организуется упомянутыми мной способами (gbak + cmd + AT).

Поверьте умею.

Я о том, что Вы не можете АВТОМАТИЗИРОВАТЬ резервное копирование при помощи IBExpert.

Даже и не помышлял об этом.

Еще один косвенный вывод, который делается из "бэкапа только через IBExpert" - что у Вас нет базы, находящейся в "промышленной эксплуатации".

Поясните? По-вашему нельзя делать бекап посредством IBEXPERT, если БД в "промышленной эксплуатации"? (кстати она в той самой эксплуатации)

[kdv]

Поясните? По-вашему нельзя делать бекап посредством IBEXPERT, если БД в "промышленной эксплуатации"? (кстати она в той самой эксплуатации)

да можно, но я ведь уже сказал, что автоматизировать бэкап в IBExpert нельзя. А если данные дороги, и база находится в промышленной эксплуатации, то ей нужно делать бэкап регулярно. То есть, Вы конечно можете тыкать мышью в IBE каждое утро или вечер, но если Вы вдруг на работу не придете, то бэкап сделан не будет, правильно?
Кроме того, попытались сделать бэкап, а он "завис", взяли и вырубили сервер. Нормальная такая "промышленная эксплуатация", да?

Если Вы про все в курсе, то мне непонятно, почему приходится объяснять элементарные вещи.