Неймовірно довге відновлення резервної копії
-
- Повідомлень: 717
- З нами з: 13 червня 2012, 09:38
Неймовірно довге відновлення резервної копії
Якщо ще квартал тому відновлення резервної копії займало 4-5 годин, що було забагато, але хоч вкладалося у рамки робочого дня.
То відновлення резервної копії, яка зроблена на останньому оновленні 087 відбувалося забагато навіть по звичайним тормознутим медковськм міркам - більше 21 години.
У Диспетчері задач параметри просессів медка після закінчення відновлення такі Як це чудово видно на скріншоті, під час оновлення проссесси Firebird за сеанс прочитали 22 а записали більше 68 ГІГАБАЙТ інформації, при тому що розмір бази ZVIT.FDB становить 6 202 793 984 байти. Тобто записано інформації у чисту базу у ДЕСЯТЬ раз більше.
То відновлення резервної копії, яка зроблена на останньому оновленні 087 відбувалося забагато навіть по звичайним тормознутим медковськм міркам - більше 21 години.
У Диспетчері задач параметри просессів медка після закінчення відновлення такі Як це чудово видно на скріншоті, під час оновлення проссесси Firebird за сеанс прочитали 22 а записали більше 68 ГІГАБАЙТ інформації, при тому що розмір бази ZVIT.FDB становить 6 202 793 984 байти. Тобто записано інформації у чисту базу у ДЕСЯТЬ раз більше.
Re: Неймовірно довге відновлення резервної копії
Мой совет - обратиться с ЭТИМ непосредственно к Вашему дилеру по Медку - Пусть пишет в БО и там разбираются!!!
https://www.youtube.com/watch?v=1Q54t3-3ZaE
ХутинПуйло!
ХутинПуйло!
-
- Повідомлень: 717
- З нами з: 13 червня 2012, 09:38
Re: Неймовірно довге відновлення резервної копії
медок пробив нове дніще
Відновлення з резервної копії відбувалося більше 25 годин
За цей час сервером було записано майже 90 ГІГАБАЙТ, хоча розмір БД змінився за півроку не так значуще. Розмір .ZBK 1.5GB, розмір кінцевого ZVIT.FDB біля 6.5GB.
Прогресс оптимізації алгоритмів на ліцо
Відновлення з резервної копії відбувалося більше 25 годин
За цей час сервером було записано майже 90 ГІГАБАЙТ, хоча розмір БД змінився за півроку не так значуще. Розмір .ZBK 1.5GB, розмір кінцевого ZVIT.FDB біля 6.5GB.
Прогресс оптимізації алгоритмів на ліцо
Re: Неймовірно довге відновлення резервної копії
Офигеть, а я только пару дней назад жаловался что 1гиговый бэкап в 4гиговую бд 5.5 часов восстанавливался долго...
Мда.
Что за софт замеры делает, кстати?
Мда.
Что за софт замеры делает, кстати?
-
- Повідомлень: 717
- З нами з: 13 червня 2012, 09:38
Re: Неймовірно довге відновлення резервної копії
Звичайнісінький Диспетчер задач Windows XPCharg писав:Что за софт замеры делает, кстати?
-
- Повідомлень: 66
- З нами з: 21 вересня 2012, 16:32
- Звідки: Уездный город
- Контактна інформація:
Re: Неймовірно довге відновлення резервної копії
А какая дисковая подсистема на сервере медка? SATA, SAS, SSD, присутствует ли рейд масив?
Re: Неймовірно довге відновлення резервної копії
А что за железо? Базу проверяли на ошибки? А пробовали средствами Firebird бэкап / рестор делать? (может, там в базе мусора много)poltava_energy писав:медок пробив нове дніще
Відновлення з резервної копії відбувалося більше 25 годин
За цей час сервером було записано майже 90 ГІГАБАЙТ, хоча розмір БД змінився за півроку не так значуще. Розмір .ZBK 1.5GB, розмір кінцевого ZVIT.FDB біля 6.5GB.
Re: Неймовірно довге відновлення резервної копії
А как?AllexL писав:Базу проверяли на ошибки?
А что если сделать бэкап\рестор средствами firebird - база очистится от мусора? О.оAllexL писав:А пробовали средствами Firebird бэкап / рестор делать? (может, там в базе мусора много)
Как это сделать?
-
- Повідомлень: 8802
- З нами з: 29 липня 2011, 14:59
- Звідки: Украина, Донецкая область, Бахмут
- Контактна інформація:
Re: Неймовірно довге відновлення резервної копії
Менеджером архивов.Charg писав:А как?AllexL писав:Базу проверяли на ошибки?
Вы это сделали когда восстановили zbk.Charg писав:А что если сделать бэкап\рестор средствами firebird - база очистится от мусора? О.оAllexL писав:А пробовали средствами Firebird бэкап / рестор делать? (может, там в базе мусора много)
Как это сделать?
Re: Неймовірно довге відновлення резервної копії
Не знаю как у poltava_energy дела обстоят, но лично у меня zbk генерировался средствами самого медка, восстанавливался соответственно тоже.Колпаков Б.И. писав: Вы это сделали когда восстановили zbk.
-
- Повідомлень: 717
- З нами з: 13 червня 2012, 09:38
Re: Неймовірно довге відновлення резервної копії
Якщо чесно, мене такі подробиці не дуже цікавлять і у даному випадку я виступаю в ролі software engineer - а не hardware.bandurovskiy писав:А какая дисковая подсистема на сервере медка? SATA, SAS, SSD, присутствует ли рейд масив?
Подав заявку згідно до вимог серверної частини медка із цього розділу і мені надали сервер із потрібними характеристиками.
Є пакет даних підприємства у вигляді .ZBK файлу, є свіжепоставлений медок версії 122 із чистою базою ZVIT.FDB розміром близько 100M.
От на цій платформі я відновлюю підприємство за звичною процедурою. Так що ніяка база та сміття у базі тут нідочого.
І мене вкрай турбує те, що за рік час відновлення із резервної копії збільшився із 5 годин до 25, тобто у 5 разів.
І ця проблема не є апаратною, а зумовлена лише неоптимальними алгоритмами відновлення резервної копії.
Востаннє редагувалось 20 травня 2016, 13:45 користувачем poltava_energy, всього редагувалось 1 раз.
Re: Неймовірно довге відновлення резервної копії
Проверку БД можно осуществлять (при установленной серверной части вкупе с утилитами fireBird, конечно же):Charg писав: Как это сделать?
Код: Виділити все
gfix -validate -full -no_update zvit.fdb -user <user> -password <pass>
Возможно, при выполнении данной команды Вам встретятся очень "интересные" сообщения.
Нелишне будет создание / восстановление архива средствами сервера
Код: Виділити все
backup: gbak -b -v zvit.fdb zvit.fbk -user <user> -password <pass>
restore: gbak -c zvit.fbk zvit.fdb -user <user> -password <pass>
Про решение проблем с базой данных писать не буду, т.к. это непрофильный форум
Не судите так категорично об "неоптимальних алгоритмах", т.к., судя по всему, с СУБД Вы не знакомы и разработчиком не являетесь.poltava_energy писав: І мене вкрай турбує те, що за рік час відновлення із резервної копії збільшився із 5 годин до 25, тобто у 5 разів.
І ця проблема не є апаратною, а зумовлена лише неоптимальними алгоритмами відновлення резервної копії.
Вообще-то - нет. ZBK - zip-архив программного каталога + файла БД, поэтому при восстановлении области файла с "мусором", присутствовавшие в файле zvit.fbk, успешно вернулись после восстановления.Колпаков Б.И. писав:Вы это сделали когда восстановили zbk.
p.s. Да, не злоупотребляйте бэкап/рестором средствами БД, т.к. большого эффекта постоянное выполнение этой процедуры не даст. (если, конечно, вы периодически не дополняете в базу / удаляете из базы огромные массивы данных)
-
- Повідомлень: 66
- З нами з: 21 вересня 2012, 16:32
- Звідки: Уездный город
- Контактна інформація:
Re: Неймовірно довге відновлення резервної копії
Перенесите на сервере папку с БД медка на отдельный SSD диск, и будет вам радость.
И бекапы будут быстрее делаться, копия веселей разворачиваться и работа медка заметно ускорится.
П.С. Ощутимый прирост будет заметен при работе с первичкой, к примеру подписание и отправление на регистрацию нескольких тысяч документов одновременно.
И бекапы будут быстрее делаться, копия веселей разворачиваться и работа медка заметно ускорится.
П.С. Ощутимый прирост будет заметен при работе с первичкой, к примеру подписание и отправление на регистрацию нескольких тысяч документов одновременно.
-
- Повідомлень: 717
- З нами з: 13 червня 2012, 09:38
Re: Неймовірно довге відновлення резервної копії
Лише одна ця фраза довіру до ваших висловів множить на нульAllexL писав:ZBK - zip-архив программного каталога + файла БД, поэтому ...
Певно ви не дуже уважно читали моє попереднє повідомлення.bandurovskiy писав:Перенесите на сервере папку с БД медка на отдельный SSD диск, и будет вам радость.
Сервер для мене чорна скринька із заданими характеристиками. Підтримкою заліза, підтримкою серверної ОС та підтримкою прикладного ПЗ у нас займаються три різні групи, і навіть при всьому моєму бажанні я не можу зробити "на сервере папку с БД медка на отдельный SSD диск" оскільки я не оперую такими поняттями.
Проблема у іншому.
За останній рік технічні параметри сервера медка не змінилися. Індекс PassMark, IOPS, RAW read/write ціїє чорної скриньки знаходяться у тих же межах що і рік тому.
Але у останньому кварталі 2015 року в якомусь із чергових оновлень у алгоритмах відновлення резервної копії медка відбулися зміни, які У РАЗИ збільшили час відновлення.
У грудні вказував розмір бази ZVIT.FDB = 6 202 793 984 байти та кількість прочитаного (22 ГІГАБАЙТИ) та записаного (68 ГІГАБАЙТИ) процессами fb_inet_server під час процедури відновленя з резерної копії.
Зараз розмір свіжої бази ZVIT.FDB = 6 739 664 896 байт, при цьому прочитано 49 ГІГАБАЙТ - а записано 90 ГІГАБАЙТ.
Тобто порівняно із груднем відносне збільшення:
- у розмірі бази (6 739 664 896 - 6 202 793 984) / 6 202 793 984 = 8,65%
у записаному (90 - 68) / 68 = 32%
у прочитаному (49 - 22) / 22 = 122%
-
- Повідомлень: 8802
- З нами з: 29 липня 2011, 14:59
- Звідки: Украина, Донецкая область, Бахмут
- Контактна інформація:
Re: Неймовірно довге відновлення резервної копії
Вы говорите о bkz - zip-архив программного каталога + файла БД,AllexL писав:Вообще-то - нет. ZBK - zip-архив программного каталога + файла БД, поэтому при восстановлении области файла с "мусором", присутствовавшие в файле zvit.fbk, успешно вернулись после восстановления.Колпаков Б.И. писав:Вы это сделали когда восстановили zbk.
а zbk - свернутая средствами ФБ РК, без мусора. Соответственно ее восстановление на чистой базе дает тот же результат.
Re: Неймовірно довге відновлення резервної копії
А, действительно, там пакованый ZIP-ом XML. Признаю, был неправ.Колпаков Б.И. писав:Вы говорите о bkz - zip-архив программного каталога + файла БД,AllexL писав:Вообще-то - нет. ZBK - zip-архив программного каталога + файла БД, поэтому при восстановлении области файла с "мусором", присутствовавшие в файле zvit.fbk, успешно вернулись после восстановления.Колпаков Б.И. писав:Вы это сделали когда восстановили zbk.
а zbk - свернутая средствами ФБ РК, без мусора. Соответственно ее восстановление на чистой базе дает тот же результат.
Re: Неймовірно довге відновлення резервної копії
Много букаф не осилилpoltava_energy писав:Лише одна ця фраза довіру до ваших висловів множить на нульAllexL писав:ZBK - zip-архив программного каталога + файла БД, поэтому ...
Певно ви не дуже уважно читали моє попереднє повідомлення.bandurovskiy писав:Перенесите на сервере папку с БД медка на отдельный SSD диск, и будет вам радость.
Сервер для мене чорна скринька із заданими характеристиками. Підтримкою заліза, підтримкою серверної ОС та підтримкою прикладного ПЗ у нас займаються три різні групи, і навіть при всьому моєму бажанні я не можу зробити "на сервере папку с БД медка на отдельный SSD диск" оскільки я не оперую такими поняттями.
Проблема у іншому.
За останній рік технічні параметри сервера медка не змінилися. Індекс PassMark, IOPS, RAW read/write ціїє чорної скриньки знаходяться у тих же межах що і рік тому.
Але у останньому кварталі 2015 року в якомусь із чергових оновлень у алгоритмах відновлення резервної копії медка відбулися зміни, які У РАЗИ збільшили час відновлення.
У грудні вказував розмір бази ZVIT.FDB = 6 202 793 984 байти та кількість прочитаного (22 ГІГАБАЙТИ) та записаного (68 ГІГАБАЙТИ) процессами fb_inet_server під час процедури відновленя з резерної копії.
Зараз розмір свіжої бази ZVIT.FDB = 6 739 664 896 байт, при цьому прочитано 49 ГІГАБАЙТ - а записано 90 ГІГАБАЙТ.
Тобто порівняно із груднем відносне збільшення:Розмір аномалії збільшується
- у розмірі бази (6 739 664 896 - 6 202 793 984) / 6 202 793 984 = 8,65%
у записаному (90 - 68) / 68 = 32%
у прочитаному (49 - 22) / 22 = 122%
У Вас есть проблема с быстродействием БД?
-
- Повідомлень: 8802
- З нами з: 29 липня 2011, 14:59
- Звідки: Украина, Донецкая область, Бахмут
- Контактна інформація:
Re: Неймовірно довге відновлення резервної копії
А у Вас есть оригинальное решение?
Re: Неймовірно довге відновлення резервної копії
да, есть. увел. быстродействие БД (не путать с восстановлением созданием рк)
-
- Повідомлень: 8802
- З нами з: 29 липня 2011, 14:59
- Звідки: Украина, Донецкая область, Бахмут
- Контактна інформація:
Re: Неймовірно довге відновлення резервної копії
Расскажите.