Неймовірно довге відновлення резервної копії

Обговорення питань, пов'язаних з функціонуванням програми
Сообщение poltava_energy
ОТ: 16 дек 2015, 10:23
Сообщения: 232
Зарегистрирован: 13 июн 2012, 09:38
Откуда: Полтава
Благодарил (а): 12 раз.
Поблагодарили: 87 раз.

Якщо ще квартал тому відновлення резервної копії займало 4-5 годин, що було забагато, але хоч вкладалося у рамки робочого дня.
То відновлення резервної копії, яка зроблена на останньому оновленні 087 відбувалося забагато навіть по звичайним тормознутим медковськм міркам - більше 21 години.

У Диспетчері задач параметри просессів медка після закінчення відновлення такі
medoc_restore_from_reserve.PNG
medoc_restore_from_reserve.PNG (10.2 КБ) Просмотров: 1415


Як це чудово видно на скріншоті, під час оновлення проссесси Firebird за сеанс прочитали 22 а записали більше 68 ГІГАБАЙТ інформації, при тому що розмір бази ZVIT.FDB становить 6 202 793 984 байти. Тобто записано інформації у чисту базу у ДЕСЯТЬ раз більше.

Сообщение priup
ОТ: 16 дек 2015, 12:03
Сообщения: 4034
Зарегистрирован: 22 июн 2011, 12:23

Благодарил (а): 1337 раз.
Поблагодарили: 1412 раз.

Мой совет - обратиться с ЭТИМ непосредственно к Вашему дилеру по Медку - Пусть пишет в БО и там разбираются!!!

Сообщение poltava_energy
ОТ: 19 май 2016, 10:01
Сообщения: 232
Зарегистрирован: 13 июн 2012, 09:38
Откуда: Полтава
Благодарил (а): 12 раз.
Поблагодарили: 87 раз.

медок пробив нове дніще :lol:
Відновлення з резервної копії відбувалося більше 25 годин :shock:

medoc_restore_from_reserve02.PNG
medoc_restore_from_reserve02.PNG (3.56 КБ) Просмотров: 1294


За цей час сервером було записано майже 90 ГІГАБАЙТ, хоча розмір БД змінився за півроку не так значуще. Розмір .ZBK 1.5GB, розмір кінцевого ZVIT.FDB біля 6.5GB.
Прогресс оптимізації алгоритмів на ліцо :twisted: :twisted: :twisted:

Сообщение Charg
ОТ: 19 май 2016, 10:17
Сообщения: 18
Зарегистрирован: 23 мар 2015, 18:11

Благодарил (а): 0 раз.
Поблагодарили: 1 раз.

Офигеть, а я только пару дней назад жаловался что 1гиговый бэкап в 4гиговую бд 5.5 часов восстанавливался долго...
Мда.

Что за софт замеры делает, кстати?

Сообщение poltava_energy
ОТ: 19 май 2016, 10:45
Сообщения: 232
Зарегистрирован: 13 июн 2012, 09:38
Откуда: Полтава
Благодарил (а): 12 раз.
Поблагодарили: 87 раз.

Charg писал(а):Что за софт замеры делает, кстати?
Звичайнісінький Диспетчер задач Windows XP

Сообщение bandurovskiy
ОТ: 19 май 2016, 13:59
Сообщения: 62
Зарегистрирован: 21 сен 2012, 16:32
Откуда: Уездный город
Благодарил (а): 36 раз.
Поблагодарили: 26 раз.

А какая дисковая подсистема на сервере медка? SATA, SAS, SSD, присутствует ли рейд масив?

Сообщение AllexL
ОТ: 19 май 2016, 14:09
Сообщения: 45
Зарегистрирован: 19 дек 2011, 20:16
Откуда: Kyiv
Благодарил (а): 20 раз.
Поблагодарили: 19 раз.

poltava_energy писал(а):медок пробив нове дніще :lol:
Відновлення з резервної копії відбувалося більше 25 годин :shock:
За цей час сервером було записано майже 90 ГІГАБАЙТ, хоча розмір БД змінився за півроку не так значуще. Розмір .ZBK 1.5GB, розмір кінцевого ZVIT.FDB біля 6.5GB.


А что за железо? Базу проверяли на ошибки? А пробовали средствами Firebird бэкап / рестор делать? (может, там в базе мусора много)

Сообщение Charg
ОТ: 19 май 2016, 16:32
Сообщения: 18
Зарегистрирован: 23 мар 2015, 18:11

Благодарил (а): 0 раз.
Поблагодарили: 1 раз.

AllexL писал(а):Базу проверяли на ошибки?

А как?
AllexL писал(а):А пробовали средствами Firebird бэкап / рестор делать? (может, там в базе мусора много)

А что если сделать бэкап\рестор средствами firebird - база очистится от мусора? О.о
Как это сделать?

Сообщение Колпаков Б.И.
ОТ: 19 май 2016, 17:11
Сообщения: 7900
Зарегистрирован: 29 июл 2011, 14:59
Откуда: Украина, Донецкая область, Бахмут
Благодарил (а): 7444 раз.
Поблагодарили: 2319 раз.

Charg писал(а):
AllexL писал(а):Базу проверяли на ошибки?

А как?

Менеджером архивов.
Charg писал(а):
AllexL писал(а):А пробовали средствами Firebird бэкап / рестор делать? (может, там в базе мусора много)

А что если сделать бэкап\рестор средствами firebird - база очистится от мусора? О.о
Как это сделать?

Вы это сделали когда восстановили zbk.

Сообщение Charg
ОТ: 19 май 2016, 17:29
Сообщения: 18
Зарегистрирован: 23 мар 2015, 18:11

Благодарил (а): 0 раз.
Поблагодарили: 1 раз.

Колпаков Б.И. писал(а):Вы это сделали когда восстановили zbk.

Не знаю как у poltava_energy дела обстоят, но лично у меня zbk генерировался средствами самого медка, восстанавливался соответственно тоже.

Сообщение poltava_energy
ОТ: 20 май 2016, 09:35
Сообщения: 232
Зарегистрирован: 13 июн 2012, 09:38
Откуда: Полтава
Благодарил (а): 12 раз.
Поблагодарили: 87 раз.

bandurovskiy писал(а):А какая дисковая подсистема на сервере медка? SATA, SAS, SSD, присутствует ли рейд масив?
Якщо чесно, мене такі подробиці не дуже цікавлять :? і у даному випадку я виступаю в ролі software engineer - а не hardware.
Подав заявку згідно до вимог серверної частини медка із цього розділу і мені надали сервер із потрібними характеристиками.

Є пакет даних підприємства у вигляді .ZBK файлу, є свіжепоставлений медок версії 122 із чистою базою ZVIT.FDB розміром близько 100M.
От на цій платформі я відновлюю підприємство за звичною процедурою. Так що ніяка база та сміття у базі тут нідочого.
І мене вкрай турбує те, що за рік час відновлення із резервної копії збільшився із 5 годин до 25, тобто у 5 :!: разів.
І ця проблема не є апаратною, а зумовлена лише неоптимальними алгоритмами відновлення резервної копії.

Сообщение AllexL
ОТ: 20 май 2016, 11:00
Сообщения: 45
Зарегистрирован: 19 дек 2011, 20:16
Откуда: Kyiv
Благодарил (а): 20 раз.
Поблагодарили: 19 раз.

Charg писал(а):Как это сделать?

Проверку БД можно осуществлять (при установленной серверной части вкупе с утилитами fireBird, конечно же):
Код: Выделить всё
gfix -validate -full -no_update zvit.fdb -user <user> -password <pass>

user & pass по-умолчанию Вы без труда найдете на форумах по firebird-у.
Возможно, при выполнении данной команды Вам встретятся очень "интересные" сообщения.
Нелишне будет создание / восстановление архива средствами сервера ;)
Код: Выделить всё
backup: gbak  -b -v zvit.fdb zvit.fbk  -user <user> -password <pass>
restore: gbak  -c  zvit.fbk zvit.fdb -user <user> -password <pass>

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

poltava_energy писал(а):І мене вкрай турбує те, що за рік час відновлення із резервної копії збільшився із 5 годин до 25, тобто у 5 :!: разів.
І ця проблема не є апаратною, а зумовлена лише неоптимальними алгоритмами відновлення резервної копії.

Не судите так категорично об "неоптимальних алгоритмах", т.к., судя по всему, с СУБД Вы не знакомы и разработчиком не являетесь.
Колпаков Б.И. писал(а):Вы это сделали когда восстановили zbk.

Вообще-то - нет. ZBK - zip-архив программного каталога + файла БД, поэтому при восстановлении области файла с "мусором", присутствовавшие в файле zvit.fbk, успешно вернулись после восстановления.


p.s. Да, не злоупотребляйте бэкап/рестором средствами БД, т.к. большого эффекта постоянное выполнение этой процедуры не даст. (если, конечно, вы периодически не дополняете в базу / удаляете из базы огромные массивы данных) :roll: :roll:

Сообщение bandurovskiy
ОТ: 20 май 2016, 11:38
Сообщения: 62
Зарегистрирован: 21 сен 2012, 16:32
Откуда: Уездный город
Благодарил (а): 36 раз.
Поблагодарили: 26 раз.

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

П.С. Ощутимый прирост будет заметен при работе с первичкой, к примеру подписание и отправление на регистрацию нескольких тысяч документов одновременно.

Сообщение poltava_energy
ОТ: 20 май 2016, 14:27
Сообщения: 232
Зарегистрирован: 13 июн 2012, 09:38
Откуда: Полтава
Благодарил (а): 12 раз.
Поблагодарили: 87 раз.

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%
Розмір аномалії збільшується :?

Сообщение Колпаков Б.И.
ОТ: 20 май 2016, 16:31
Сообщения: 7900
Зарегистрирован: 29 июл 2011, 14:59
Откуда: Украина, Донецкая область, Бахмут
Благодарил (а): 7444 раз.
Поблагодарили: 2319 раз.

AllexL писал(а):
Колпаков Б.И. писал(а):Вы это сделали когда восстановили zbk.

Вообще-то - нет. ZBK - zip-архив программного каталога + файла БД, поэтому при восстановлении области файла с "мусором", присутствовавшие в файле zvit.fbk, успешно вернулись после восстановления.

Вы говорите о bkz - zip-архив программного каталога + файла БД,
а zbk - свернутая средствами ФБ РК, без мусора. Соответственно ее восстановление на чистой базе дает тот же результат.

Сообщение AllexL
ОТ: 25 май 2016, 09:06
Сообщения: 45
Зарегистрирован: 19 дек 2011, 20:16
Откуда: Kyiv
Благодарил (а): 20 раз.
Поблагодарили: 19 раз.

Колпаков Б.И. писал(а):
AllexL писал(а):
Колпаков Б.И. писал(а):Вы это сделали когда восстановили zbk.

Вообще-то - нет. ZBK - zip-архив программного каталога + файла БД, поэтому при восстановлении области файла с "мусором", присутствовавшие в файле zvit.fbk, успешно вернулись после восстановления.

Вы говорите о bkz - zip-архив программного каталога + файла БД,
а zbk - свернутая средствами ФБ РК, без мусора. Соответственно ее восстановление на чистой базе дает тот же результат.

А, действительно, там пакованый ZIP-ом XML. Признаю, был неправ.

Сообщение Юра_01
ОТ: 17 авг 2016, 16:26
Сообщения: 289
Зарегистрирован: 24 окт 2012, 15:45
Откуда: Харьков
Благодарил (а): 36 раз.
Поблагодарили: 56 раз.

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%
Розмір аномалії збільшується :?

Много букаф не осилил :lol:
У Вас есть проблема с быстродействием БД?

Сообщение Колпаков Б.И.
ОТ: 18 авг 2016, 11:25
Сообщения: 7900
Зарегистрирован: 29 июл 2011, 14:59
Откуда: Украина, Донецкая область, Бахмут
Благодарил (а): 7444 раз.
Поблагодарили: 2319 раз.

А у Вас есть оригинальное решение?

Сообщение Юра_01
ОТ: 18 авг 2016, 11:32
Сообщения: 289
Зарегистрирован: 24 окт 2012, 15:45
Откуда: Харьков
Благодарил (а): 36 раз.
Поблагодарили: 56 раз.

да, есть. увел. быстродействие БД (не путать с восстановлением созданием рк)

Сообщение Колпаков Б.И.
ОТ: 18 авг 2016, 11:37
Сообщения: 7900
Зарегистрирован: 29 июл 2011, 14:59
Откуда: Украина, Донецкая область, Бахмут
Благодарил (а): 7444 раз.
Поблагодарили: 2319 раз.

Расскажите.

След.

Вернуться в Помилки у роботі програми

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0

cron