|
nbackup
|
|||
---|---|---|---|
#18+
Добрый день! nbackup выполняется длительное время. Можно ли его срубить? К чему это может привести? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.06.2017, 18:05 |
|
nbackup
|
|||
---|---|---|---|
#18+
H.e.l.p, что значит "очень долго"? Сколько гиг база? классик, суперклассик, суперсервер, версия ФБ? какой размер дельты? если срубить, база останется в состоянии, когда изменения будут продолжать идти в дельту, а не в базу. Базу надо будет разлочивать нбэкапом. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.06.2017, 18:33 |
|
nbackup
|
|||
---|---|---|---|
#18+
H.e.l.pДобрый день! nbackup выполняется длительное время. Можно ли его срубить? К чему это может привести?nbackup сам по себе практически ничего не делает. Вся реальная работа выполняется движком. "Срубать" его не имеет никакого смысла, разве что он выдал ошибку и повис (никогда такого не видел) Что показывает gstat -h <database> ? Версии 2.5 - не бывает, какая на самом деле версия ? Как долго nbackup работает обычно ? Есть ли свободное место на диске с БД, с бекапом ? Насколько нагружены диски с БД, с бекапом ? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.06.2017, 19:05 |
|
nbackup
|
|||
---|---|---|---|
#18+
hvlad, я бы еще посмотрел mon$transaction на длинную транзакцию, или поискал повисший процесс классика, ну и fb_lock_print. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.06.2017, 19:24 |
|
nbackup
|
|||
---|---|---|---|
#18+
hvladnbackup сам по себе практически ничего не делает он всего-навсего копирует 180 гигов :-) Если ТС вдруг передумал и не хочет ждать бекапа до завтра, пусть прибивает nbackup и делает unlock базе. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.06.2017, 19:35 |
|
nbackup
|
|||
---|---|---|---|
#18+
dimitrон всего-навсего копирует 180 гигов :-)Ну да, я имел в виду - никак не меняет БД :) А насчёт копировать 180ГБ - мы не знаем, какого уровня бекап выполняется, так шта... :) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.06.2017, 19:43 |
|
nbackup
|
|||
---|---|---|---|
#18+
hvladмы не знаем, какого уровня бекап выполняется на 2.5 делать nbackup такой базе достаточно тоскливо, т.к. независимо от уровня 2.5 будет всегда читать все 180 гиг. Однако, если скорость чтения базы составит хотя бы вшивые 50мб/сек, то на чтение 180 гиг потребуется ровно 1 час. Интересно, сколько nbackup на этой базе длился раньше, если вообще запускался? Что-то автор не горит желанием получить помощь, выдавая скудные ответы. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.06.2017, 20:57 |
|
nbackup
|
|||
---|---|---|---|
#18+
Никогда не делался ранее, запустили первый раз. Места полно. Чего решили снять - упала общая производительность - процесс,что обычно выполнялся до 10 минут, стал выполняться 4 часа. Решили БД закрыть на доступ пользователям, что бы таки дождаться завершения. Через 1 час 30 мин он закончил свою работу. Итог 11 часов на 180G. (Версия WI-V6.3.2.26540) Мониторинг загрузки показал по процессорному времени - 85% (4 ядра), память норм и диски норм (со слов админов). Нарезали еще 4 ядра - до 8, вроде все норм. Database header page information: Flags 0 Checksum 12345 Generation 3261543 Page size 16384 ODS version 11.2 Oldest transaction 1772753 Oldest active 1772754 Oldest snapshot 1755528 Next transaction 1830465 Bumped transaction 1 Sequence number 0 Next attachment ID 1431038 Implementation ID 16 Shadow count 0 Page buffers 1024 Next header page 0 Database dialect 1 Creation date Jun 1, 2017 4:54:43 Attributes force write Variable header data: Database backup GUID: {37EBE769-BD2C-46B0-4C8D-9F021A51F0BD} Sweep interval: 0 *END* Спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
06.06.2017, 22:49 |
|
nbackup
|
|||
---|---|---|---|
#18+
H.e.l.p, то есть, 2.5.2.26540 - ох, ёжик... а что за диски? и куда делали nbackup? H.e.l.pOldest active 1772754 Next transaction 1830465 если next поделить на 4 дня, получается где-то 19 тысяч транзакций в час. Значит, oldest active отстает часа на три примерно. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.06.2017, 23:40 |
|
nbackup
|
|||
---|---|---|---|
#18+
H.e.l.pЧего решили снять - упала общая производительность - процесс,что обычно выполнялся до 10 минут, стал выполняться 4 часа. Я так и не понял чего хотели добиться с помощью nbackup . Он с самой базой вообще ничего не делает (кроме того что на время своей работы переводит ее в другой режим и все изменения пишутся не в базу). Может вы хотели ее "перебэкапить"? Но nbackup тут не помощник совершенно, сама его идея - восстановить базу как было, буквально, со всеми ее ошибками и неоптимальностями. Перебэкап делается с помощью gbak . Сначала бэкап, который читает всю базу на момент старта бэкапа и сохраняет полученные данные в файл. В котором отсутствуют тела индексов, только информация о них. В итоге файл такого бэкапа получается в среднем раза в 2 меньше исходной базы. А потом из него восстанавливают базу, ресторят. И это процесс длительный. И бывают случаи когда такая оптимизация приводит не к ускорению работы а наоборот к замедлению, т.к. таблицы восстанавливаются по очереди и данные по ним лежат вместе, в то время как при работе данные заливаются в разные таблицы и расположены кучнее скорее по времени внесения данных в базу а не по принадлежности к таблицам. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 04:13 |
|
nbackup
|
|||
---|---|---|---|
#18+
kdvhvladмы не знаем, какого уровня бекап выполняется на 2.5 делать nbackup такой базе достаточно тоскливо, т.к. независимо от уровня 2.5 будет всегда читать все 180 гиг. Однако, если скорость чтения базы составит хотя бы вшивые 50мб/сек, то на чтение 180 гиг потребуется ровно 1 час. Интересно, сколько nbackup на этой базе длился раньше, если вообще запускался? Что-то автор не горит желанием получить помощь, выдавая скудные ответы. Что ты знаешь о тоске? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 05:41 |
|
nbackup
|
|||
---|---|---|---|
#18+
fraksЯ так и не понял gbak делается 6 часов в одну сторону, 6 в другую. Хотели, по возможности, ускорить процесс получения резервной копии. kdvто есть, 2.5.2.26540 - ох, ёжик... Сорри, WI-V6.3.2.26540 Стойка HUS150, делали на резервный сервер (его диски там же) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 09:09 |
|
nbackup
|
|||
---|---|---|---|
#18+
H.e.l.pfraksЯ так и не понял gbak делается 6 часов в одну сторону, 6 в другую. В смысле в одну и в другую, backup/restore? Тогда странно, бэкап всегда меньше по времени чем рестор. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 09:40 |
|
nbackup
|
|||
---|---|---|---|
#18+
H.e.l.pfraksЯ так и не понял gbak делается 6 часов в одну сторону, 6 в другую. Хотели, по возможности, ускорить процесс получения резервной копии. 1. Не верю что время рестора равно времени бэкапа, разве что в случае если это разные тачки. Или в базе вообще нет индексов. У меня рестор всегда дольше, и на моих базах соотношение времени примерно такое - бэкап минут 10-15, рестор минут 40-60. 2. И таки я опять не понял задачу: 2.1 сократить время снятия бэкапа с базы во время работы или 2.2 сократить время получения рабочей базы из резервной копии, если она вдруг понадобится. Если стоит задача ускорить по варианту вариант 2.2 - то да, для этого нужно использовать nbackup и выбрать оптимальную для вашего случая стратегию уровней бэкапов. Но тут есть тонкость. На сколько я в курсе - nbackup у сервера 2.X при создании бэкапа любого уровня должен прочитать все страницы базы. И для бэкапа первого уровня что nbackup что gbak затратит примерно сравнимое время. А вот в 3.X это дело значительно оптимизировали, и читаются только те страницы которые поменялись, что должно значительно сократить время и нагрузку при создании бэкапов не первого уровня. И, на всякий случай. Использование nbackup не отменяет необходимости создавать обычные бэкапы через gbak, а так же периодически проверять их восстановимость (проходит ли из них рестор). ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 10:13 |
|
nbackup
|
|||
---|---|---|---|
#18+
fraksИ, на всякий случай. Использование nbackup не отменяет необходимости создавать обычные бэкапы через gbak, а так же периодически проверять их восстановимость (проходит ли из них рестор). nbackup - это страничный бэкап, ты его сможешь сделать даже если база повреждена. Последствия такого рестора плачевны и сулят обращение в ibase. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 10:34 |
|
nbackup
|
|||
---|---|---|---|
#18+
Gallemar, Это я понимаю. Но если будет схема 1 раз в неделю полный, 2 каждый день, 3 каждый час - можно восстановиться максимально к точке сбоя БД (зная время сбоя)? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 10:40 |
|
nbackup
|
|||
---|---|---|---|
#18+
H.e.l.pGallemar, Это я понимаю. Но если будет схема 1 раз в неделю полный, 2 каждый день, 3 каждый час - можно восстановиться максимально к точке сбоя БД (зная время сбоя)? Вообще да, но потом такую бд надо всё равно проверять и опционально лечить/ресторить. Вы каждый день бэкап/рестор делаете? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 10:44 |
|
nbackup
|
|||
---|---|---|---|
#18+
H.e.l.pЭто я понимаю. Но если будет схема 1 раз в неделю полный, 2 каждый день, 3 каждый час - можно восстановиться максимально к точке сбоя БД (зная время сбоя)? Такая схема позволит восстановить базу на состояние до часа к последнему моменту. За прошлую неделю с точностью до часа уже не получится восстановить. Сбой не обязательно случился прямо сейчас, он мог произойти давно, просто сейчас наконец-то все окончательно сломалось. Кстати, для ускорения восстановления можно ежедневно превентивно накатывать бэкап второго уровня на бэкап первого, и иметь на утро базу на которую останется накатить только часовой бэкап третьего уровня. Но кажется до тебя не удалось донести смысл различий gbak и nbackup. gbak воссоздает базу в правильном виде, при этом выявляются или исправляются ошибки, даже те которые еще может быть не вылезли в продакшене, если к данным не обращались. nbackup просто воссоздает набор страниц на какой-то момент. Что там на этих страницах - ему пофиг. Может статься что случилась некая ошибка которая поломала базу но заметили это не сразу. И наличие инкрементальных бэкапов может не помочь если корни ошибки заложены например 2 месяца назад. Из этой ветки у меня создалось впечатление что вы: - никогда не делали бэкапов, полагаясь может быть на RAID или еще что - решили сделать бэкап, начав с nbackup - зачем при этом использовать еще и gbak вам непонятно Возможно я ошибаюсь в понимании ситуации. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 10:59 |
|
nbackup
|
|||
---|---|---|---|
#18+
Раз уж идет такая пьянка, то может смотреть в сторону репликации? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 11:04 |
|
nbackup
|
|||
---|---|---|---|
#18+
Несколько ссылок по теме: http://www.ibase.ru/admin/ http://www.ibase.ru/vldb/ http://www.ibase.ru/backupspeed/ http://www.ibase.ru/restorespeed/ http://www.ibase.ru/gbak/ https://www.firebirdsql.org/manual/ru/nbackup-ru.html ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 11:15 |
|
nbackup
|
|||
---|---|---|---|
#18+
fraksНесколько ссылок по теме: https://www.firebirdsql.org/manual/ru/nbackup-ru.html Кстати,вот что вспомнил относительно nbackup. У меня он шел очень медленно, из-за отсутствия ключа -D, в русской доке об этом нет упоминания https://www.firebirdsql.org/manual/nbackup-functions-params.html Попробуй с этим ключом. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 11:21 |
|
nbackup
|
|||
---|---|---|---|
#18+
fraksВозможно я ошибаюсь в понимании ситуации. Ошибаешься. Вопрос был не в этом. На что повлияет, если срезать выполнение nbackup. Ответ я уже получил. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 11:23 |
|
nbackup
|
|||
---|---|---|---|
#18+
H.e.l.pfraksВозможно я ошибаюсь в понимании ситуации. Ошибаешься. Вопрос был не в этом. На что повлияет, если срезать выполнение nbackup. Ответ я уже получил. Попробуй оценить надежность nbackup. Если время простоя критично лучше смотреть в сторону реплики. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 11:28 |
|
|
start [/forum/topic.php?fid=40&fpage=44&tid=1561543]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
65ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
72ms |
get tp. blocked users: |
2ms |
others: | 298ms |
total: | 483ms |
0 / 0 |