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

[kdv]

TAV, Вы не кипятитесь, просто смотрите что пишете - Ваш текст провоцирует на соответствующие вопросы и ответы. То "Всегда делаю бекап средствами IBEXPERT", то нужна программа автоматизации, но "знаю про gbak + cmd +at", "бэкап стопорится на таблице" и так далее.

Если мои "догадки" не верны, то я рад, что мы не будем Вас ждать с запросом на ремонт БД или восстановление битого бэкапа.

p.s. впрочем, желание программы автоматизации бэкапа вполне понятно. На сайте есть кое-что, но оно в большинстве устаревшее.

[BorisMor]

Не понятно что так активно решили обсудить дельту?)
У меня тоже часто этот файл остается. Но все работает ведь.

Скрипт работает просто:

• В начале дня создается 0-й бэкап.
• Каждый час создается бэкап 1-го уровня
• Бэкапы за предыдущие дни архивируются

Все просто и ясно. Можно поднять бэкап за любой час дня очень быстро.
Генирится автоматом батник для рестора.

Пошагово:

1. Смотрим в реестре когда был нулевой бэкап.
2. Если дата не текущая то будем делать нулевой.
3. Если бэкап нулевой или есть .delta то запускаем nbackup -N
4. Делаем бэкап
5. Если бэкап прошел нормально и он 0-й то записываем об этом в реестре
6. Создаем bat файл для рестора
7. Архивируем старые бэкапы через rar
8. Удаляем старые бэкапы

Работа скрипта логируется в *.log
Все команды выполняемые с nback там можно посмотреть.
Можно конечно все сделать и через bat, но по моему у любой языка (даже JScript) гораздо гибче и возможностей больше.
Чем не промышленное решение?

[kdv]

Чем не промышленное решение?

это пример. обычно 0 и 1 уровней маловато, чаще используют до 2 и до 3.
Потому что для баз, где nbackup имеет смысл (думаю, не меньше 5 гиг), делать нбэкап 0 уровня каждый день - не напасешься архивов.
Наиболее распространенная схема - месяц, неделя, день, час. Т.е. 4 уровня.
Впрочем, это все на усмотрение конкретного администратора.

Против скрипта ничего не имею, абсолютно, это один из способов автоматизации.

[BorisMor]

Чем не промышленное решение?

это пример. обычно 0 и 1 уровней маловато, чаще используют до 2 и до 3.
Потому что для баз, где nbackup имеет смысл (думаю, не меньше 5 гиг), делать нбэкап 0 уровня каждый день - не напасешься архивов.
Наиболее распространенная схема - месяц, неделя, день, час. Т.е. 4 уровня.
Впрочем, это все на усмотрение конкретного администратора.

Против скрипта ничего не имею, абсолютно, это один из способов автоматизации.

Все наверное зависит от того для чего нужен инкрементный бэкап.
У нас обычный бэкап делается каждую ночь. Через обычный батник и пакуется 7z.
Каждую ночь из филиалов тенется wget на сервер холдинга.
Если бы инкрементный тянули - замучилась бы от объемов и возможных проблем.

[TAV]

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

Про все в курсе, только на первом курсе

TAV, Вы не кипятитесь, просто смотрите что пишете - Ваш текст провоцирует на соответствующие вопросы и ответы. То "Всегда делаю бекап средствами IBEXPERT", то нужна программа автоматизации, но "знаю про gbak + cmd +at", "бэкап стопорится на таблице" и так далее.

Если мои "догадки" не верны, то я рад, что мы не будем Вас ждать с запросом на ремонт БД или восстановление битого бэкапа.

Я не кипячусь - это вы провоцируете на кипячение, ну да ладно. "всегда делаю бекап IBEXPERT" - я его также делаю и через батник (настроено копирование БД на сервер реплики).
Обошлось все. Дело было скорее всего в слишком большом количестве повисших транзакций пишущих (25000) как раз по той самой таблице на которой "стопорился" потом бекап. Виноват сам - каюсь черт возьми. В приложении, в читающей транзакции было гнусное слово write.

Не понятно что так активно решили обсудить дельту?)
У меня тоже часто этот файл остается. Но все работает ведь.

Обсудить решил я "дельту", потому что не должна она оставаться, и вообще БД которая при создании бекапа подвешивается в какое то не понятное состояние - настораживает. Как выяснилось ошибки в версии 2.1.2 могли приводить к такой ситуации + наличие большого количества повисших транзакций пишущих.
По поводу скрипта никаких проблем и вопросов нет - все понятно, как он работает. Не плохо было бы иметь возможность создания бекапов уровня 2,3. Но это легко можно модифицировать.

p.s. впрочем, желание программы автоматизации бэкапа вполне понятно. На сайте есть кое-что, но оно в большинстве устаревшее.

А взяться за разработку утилиты по автоматизации процесса бекапа, думаю все же стоит.

[kdv]

А взяться за разработку утилиты по автоматизации процесса бекапа, думаю все же стоит.

у нас она уже есть - FBDataGuard. nbackup там пока нет, но любые проблемы с дельтой уже отслеживаются.
Если речь была про самостоятельную тулзу - дерзайте.

[hvlad]

Обошлось все. Дело было скорее всего в слишком большом количестве повисших транзакций пишущих (25000)

Я уже говорил, что не в тр-циях дело.

БД которая при создании бекапа подвешивается в какое то не понятное состояние - настораживает.

Чтобы не настораживало - учи матчасть.

Как выяснилось ошибки в версии 2.1.2 могли приводить к такой ситуации + наличие большого количества повисших транзакций пишущих.

Упёртость... (censored)

[TAV]

Я уже говорил, что не в тр-циях дело.

Но тем не менее Вы так и не сказали конкретно в чем же.

[kdv]

Но тем не менее Вы так и не сказали конкретно в чем же.

по-моему тут
http://tracker.firebirdsql.org/browse/CORE-2539
достаточно ясно все написано. Влад приводил эту ссылку.

[TAV]

Но тем не менее Вы так и не сказали конкретно в чем же.

по-моему тут
http://tracker.firebirdsql.org/browse/CORE-2539
достаточно ясно все написано. Влад приводил эту ссылку.

ОК. Давайте разберем ситуацию бага, которая там описана:
А ситуация там примерно такая же как у меня. Только

The DML are using the default isolation level, nl. concurrency write

в моем случае было очень много из-за Большого количества долгих (пишущих транзакций) повторюсь еще раз, может это и Упертость .

Dmitry Yemanov added a comment - 05/Jul/09 01:28 PM
It's a known issue. In your cases, the backup process is finished successfully, but the delta file is not deleted. In Classic, the delta is removed as soon as merge had finished and all the worker processes had acknowledged this fact. The latter happens when they access any page in the buffer cache. But if any user connection was idle after the backup has ended, then the appropriate worker process will keep the delta file open. It's not fatal per se, but the next backup attempt will fail due to the already existing delta file.
This issue is expected to be fixed in v2.5. You might want to validate it there.

Примерный перевод:

Это известная проблема. В вашем случае, процесс резервного копирования завершен успешно, но дельта файл не удаляется. В классическом, дельта снимается, как только заканчивается слияние данных и все рабочие процессы признали этот факт (были закрыты). Последнее происходит, когда они получат доступ к любой странице в буферном кэше. Но если любой пользователь соединение которого простаивало после резервного копирования отсоединился, то соответствующий рабочий процесс будет держать Delta файл открытым. Это не критично, но при следующая попытка резервного копирования не удастся из-за уже существующего файла дельты.

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

Fix Version/s: 2.5 Beta 2

получается, что в 2.1.3 баг остался.

[hvlad]

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

Не нужно фантазировать о том, в чем не понимаешь. Не нужно публично показывать своё невежество.

Fix Version/s: 2.5 Beta 2

получается, что в 2.1.3 баг остался.

Я уже писал, что в 2.1.х это было портировано. Опять упираемся ? Зачем ?

[TAV]

Не нужно фантазировать о том, в чем не понимаешь. Не нужно публично показывать своё невежество.

Если я что-то не так написал, скажите что не так и как правильно.
Публично показывать невежество иногда очень даже нужно. Че ж вы такие тут все серьезные аж жуть..

[kdv]

скорректировал перевод, рекомендую внимательно прочитать.

Это известная проблема. В вашем случае, процесс резервного копирования завершен успешно, но дельта файл не удален. В Classic дельта удаляется как только заканчивается перенос данных (из дельты в базу) и все рабочие процессы уведомлены об этом. Последнее происходит, когда они обращаются к любой странице в буферном кэше. Но если какое-либо соединение не выполняет никаких действий после завершения nbackup, то оно будет держать Delta файл открытым. Это не критично, но следующая попытка nbackup не удастся из-за уже существующего файла дельты.

Впрочем, и в твоем переводе все тоже было ясно - если соединение все еще активно после nbackup, но НИЧЕГО НЕ ДЕЛАЕТ, то дельта будет удерживаться. Где тут про активные транзакции или еще что-либо? Причем, причина удержания дельты указана однозначная, вместо этого ты продолжаешь настаивать, что причиной являлось
"не признавали факт слияния, так как при чтении данных запускали транзакции на редактирование"

то есть, как и сказал Влад, это чистые фантазии.
Это я предположил в самом начале, что "не Commit" может привести к подобному. Но я оказался неправ (подвел склероз).
То есть, открытые, не открытые транзакции - совершенно пофиг. Просто процессу классика достаточно "ничего не делать", чтобы удерживать дельту. Пользователь ушел на обед, коннект остался висеть без "активности", вот тебе и результат.

[dimitr]

Я уже писал, что в 2.1.х это было портировано

именно это (неактивная дельта) - вроде бы не было

[hvlad]

Я уже писал, что в 2.1.х это было портировано

именно это (неактивная дельта) - вроде бы не было

Проверил код - не было, увы.

[TAV]

Проверил код - не было, увы.

Вот... Фикс будет для 2.1.3? или сразу ждать 2.5?

[hvlad]

Проверил код - не было, увы.

Вот... Фикс будет для 2.1.3? или сразу ждать 2.5?

2.1.3 уже давно вышел.
Если получится (что не есть факт), то можно ожидать в 2.1.4
2.5.0 выйдет раньше