Вопрос о файле .delta
Модераторы: kdv, Alexey Kovyazin
Re: Вопрос о файле .delta
TAV, Вы не кипятитесь, просто смотрите что пишете - Ваш текст провоцирует на соответствующие вопросы и ответы. То "Всегда делаю бекап средствами IBEXPERT", то нужна программа автоматизации, но "знаю про gbak + cmd +at", "бэкап стопорится на таблице" и так далее.
Если мои "догадки" не верны, то я рад, что мы не будем Вас ждать с запросом на ремонт БД или восстановление битого бэкапа.
p.s. впрочем, желание программы автоматизации бэкапа вполне понятно. На сайте есть кое-что, но оно в большинстве устаревшее.
Если мои "догадки" не верны, то я рад, что мы не будем Вас ждать с запросом на ремонт БД или восстановление битого бэкапа.
p.s. впрочем, желание программы автоматизации бэкапа вполне понятно. На сайте есть кое-что, но оно в большинстве устаревшее.
Re: Вопрос о файле .delta
Не понятно что так активно решили обсудить дельту?)
У меня тоже часто этот файл остается. Но все работает ведь.
Скрипт работает просто:
Генирится автоматом батник для рестора.
Пошагово:
Все команды выполняемые с nback там можно посмотреть.
Можно конечно все сделать и через bat, но по моему у любой языка (даже JScript) гораздо гибче и возможностей больше.
Чем не промышленное решение?
У меня тоже часто этот файл остается. Но все работает ведь.
Скрипт работает просто:
- В начале дня создается 0-й бэкап.
- Каждый час создается бэкап 1-го уровня
- Бэкапы за предыдущие дни архивируются
Генирится автоматом батник для рестора.
Пошагово:
- Смотрим в реестре когда был нулевой бэкап.
- Если дата не текущая то будем делать нулевой.
- Если бэкап нулевой или есть .delta то запускаем nbackup -N
- Делаем бэкап
- Если бэкап прошел нормально и он 0-й то записываем об этом в реестре
- Создаем bat файл для рестора
- Архивируем старые бэкапы через rar
- Удаляем старые бэкапы
Все команды выполняемые с nback там можно посмотреть.
Можно конечно все сделать и через bat, но по моему у любой языка (даже JScript) гораздо гибче и возможностей больше.
Чем не промышленное решение?
Re: Вопрос о файле .delta
это пример. обычно 0 и 1 уровней маловато, чаще используют до 2 и до 3.Чем не промышленное решение?
Потому что для баз, где nbackup имеет смысл (думаю, не меньше 5 гиг), делать нбэкап 0 уровня каждый день - не напасешься архивов.
Наиболее распространенная схема - месяц, неделя, день, час. Т.е. 4 уровня.
Впрочем, это все на усмотрение конкретного администратора.
Против скрипта ничего не имею, абсолютно, это один из способов автоматизации.
Re: Вопрос о файле .delta
Все наверное зависит от того для чего нужен инкрементный бэкап.kdv писал(а):это пример. обычно 0 и 1 уровней маловато, чаще используют до 2 и до 3.Чем не промышленное решение?
Потому что для баз, где nbackup имеет смысл (думаю, не меньше 5 гиг), делать нбэкап 0 уровня каждый день - не напасешься архивов.
Наиболее распространенная схема - месяц, неделя, день, час. Т.е. 4 уровня.
Впрочем, это все на усмотрение конкретного администратора.
Против скрипта ничего не имею, абсолютно, это один из способов автоматизации.
У нас обычный бэкап делается каждую ночь. Через обычный батник и пакуется 7z.
Каждую ночь из филиалов тенется wget на сервер холдинга.
Если бы инкрементный тянули - замучилась бы от объемов и возможных проблем.
Re: Вопрос о файле .delta
Про все в курсе, только на первом курсеkdv писал(а):Если Вы про все в курсе, то мне непонятно, почему приходится объяснять элементарные вещи.
Я не кипячусь - это вы провоцируете на кипячение, ну да ладно. "всегда делаю бекап IBEXPERT" - я его также делаю и через батник (настроено копирование БД на сервер реплики).kdv писал(а):TAV, Вы не кипятитесь, просто смотрите что пишете - Ваш текст провоцирует на соответствующие вопросы и ответы. То "Всегда делаю бекап средствами IBEXPERT", то нужна программа автоматизации, но "знаю про gbak + cmd +at", "бэкап стопорится на таблице" и так далее.
Если мои "догадки" не верны, то я рад, что мы не будем Вас ждать с запросом на ремонт БД или восстановление битого бэкапа.
Обошлось все. Дело было скорее всего в слишком большом количестве повисших транзакций пишущих (25000) как раз по той самой таблице на которой "стопорился" потом бекап. Виноват сам - каюсь черт возьми. В приложении, в читающей транзакции было гнусное слово write.
Обсудить решил я "дельту", потому что не должна она оставаться, и вообще БД которая при создании бекапа подвешивается в какое то не понятное состояние - настораживает. Как выяснилось ошибки в версии 2.1.2 могли приводить к такой ситуации + наличие большого количества повисших транзакций пишущих.BorisMor писал(а):Не понятно что так активно решили обсудить дельту?)
У меня тоже часто этот файл остается. Но все работает ведь.
По поводу скрипта никаких проблем и вопросов нет - все понятно, как он работает. Не плохо было бы иметь возможность создания бекапов уровня 2,3. Но это легко можно модифицировать.
А взяться за разработку утилиты по автоматизации процесса бекапа, думаю все же стоит.kdv писал(а):p.s. впрочем, желание программы автоматизации бэкапа вполне понятно. На сайте есть кое-что, но оно в большинстве устаревшее.
Re: Вопрос о файле .delta
у нас она уже есть - FBDataGuard. nbackup там пока нет, но любые проблемы с дельтой уже отслеживаются.А взяться за разработку утилиты по автоматизации процесса бекапа, думаю все же стоит.
Если речь была про самостоятельную тулзу - дерзайте.
Re: Вопрос о файле .delta
Я уже говорил, что не в тр-циях дело.TAV писал(а):Обошлось все. Дело было скорее всего в слишком большом количестве повисших транзакций пишущих (25000)
Чтобы не настораживало - учи матчасть.TAV писал(а):БД которая при создании бекапа подвешивается в какое то не понятное состояние - настораживает.
Упёртость... (censored)TAV писал(а):Как выяснилось ошибки в версии 2.1.2 могли приводить к такой ситуации + наличие большого количества повисших транзакций пишущих.
Re: Вопрос о файле .delta
Но тем не менее Вы так и не сказали конкретно в чем же.hvlad писал(а):Я уже говорил, что не в тр-циях дело.
Re: Вопрос о файле .delta
по-моему тутНо тем не менее Вы так и не сказали конкретно в чем же.
http://tracker.firebirdsql.org/browse/CORE-2539
достаточно ясно все написано. Влад приводил эту ссылку.
Re: Вопрос о файле .delta
ОК. Давайте разберем ситуацию бага, которая там описана:kdv писал(а):по-моему тутНо тем не менее Вы так и не сказали конкретно в чем же.
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 файл открытым. Это не критично, но при следующая попытка резервного копирования не удастся из-за уже существующего файла дельты.
получается, что в 2.1.3 баг остался.Fix Version/s: 2.5 Beta 2
Re: Вопрос о файле .delta
Не нужно фантазировать о том, в чем не понимаешь. Не нужно публично показывать своё невежество.TAV писал(а):В моем случае процессы не признавали факт слияния, так как при чтении данных запускали транзакции на редактирование, а сервер не знал что они не редактируются, а читаются, ждал, а когда же они закончат редактироваться, а этого не происходило.
Я уже писал, что в 2.1.х это было портировано. Опять упираемся ? Зачем ?TAV писал(а):получается, что в 2.1.3 баг остался.Fix Version/s: 2.5 Beta 2
Re: Вопрос о файле .delta
Если я что-то не так написал, скажите что не так и как правильно.hvlad писал(а):Не нужно фантазировать о том, в чем не понимаешь. Не нужно публично показывать своё невежество.
Публично показывать невежество иногда очень даже нужно. Че ж вы такие тут все серьезные аж жуть..
Re: Вопрос о файле .delta
скорректировал перевод, рекомендую внимательно прочитать.
"не признавали факт слияния, так как при чтении данных запускали транзакции на редактирование"
то есть, как и сказал Влад, это чистые фантазии.
Это я предположил в самом начале, что "не Commit" может привести к подобному. Но я оказался неправ (подвел склероз).
То есть, открытые, не открытые транзакции - совершенно пофиг. Просто процессу классика достаточно "ничего не делать", чтобы удерживать дельту. Пользователь ушел на обед, коннект остался висеть без "активности", вот тебе и результат.
Впрочем, и в твоем переводе все тоже было ясно - если соединение все еще активно после nbackup, но НИЧЕГО НЕ ДЕЛАЕТ, то дельта будет удерживаться. Где тут про активные транзакции или еще что-либо? Причем, причина удержания дельты указана однозначная, вместо этого ты продолжаешь настаивать, что причиной являлосьЭто известная проблема. В вашем случае, процесс резервного копирования завершен успешно, но дельта файл не удален. В Classic дельта удаляется как только заканчивается перенос данных (из дельты в базу) и все рабочие процессы уведомлены об этом. Последнее происходит, когда они обращаются к любой странице в буферном кэше. Но если какое-либо соединение не выполняет никаких действий после завершения nbackup, то оно будет держать Delta файл открытым. Это не критично, но следующая попытка nbackup не удастся из-за уже существующего файла дельты.
"не признавали факт слияния, так как при чтении данных запускали транзакции на редактирование"
то есть, как и сказал Влад, это чистые фантазии.
Это я предположил в самом начале, что "не Commit" может привести к подобному. Но я оказался неправ (подвел склероз).
То есть, открытые, не открытые транзакции - совершенно пофиг. Просто процессу классика достаточно "ничего не делать", чтобы удерживать дельту. Пользователь ушел на обед, коннект остался висеть без "активности", вот тебе и результат.
Re: Вопрос о файле .delta
именно это (неактивная дельта) - вроде бы не былоhvlad писал(а):Я уже писал, что в 2.1.х это было портировано
Re: Вопрос о файле .delta
Проверил код - не было, увы.dimitr писал(а):именно это (неактивная дельта) - вроде бы не былоhvlad писал(а):Я уже писал, что в 2.1.х это было портировано
Re: Вопрос о файле .delta
Вот... Фикс будет для 2.1.3? или сразу ждать 2.5?hvlad писал(а):Проверил код - не было, увы.
Re: Вопрос о файле .delta
2.1.3 уже давно вышел.TAV писал(а):Вот... Фикс будет для 2.1.3? или сразу ждать 2.5?hvlad писал(а):Проверил код - не было, увы.
Если получится (что не есть факт), то можно ожидать в 2.1.4
2.5.0 выйдет раньше