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

[poltava_energy]

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

У Диспетчері задач параметри просессів медка після закінчення відновлення такі

medoc_restore_from_reserve.PNG (10.2 Кіб) Переглянуто 5416 разів

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

[priup]

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

[poltava_energy]

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

medoc_restore_from_reserve02.PNG (3.56 Кіб) Переглянуто 5295 разів

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

[Charg]

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

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

[poltava_energy]

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

Звичайнісінький Диспетчер задач Windows XP

[bandurovskiy]

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

[AllexL]

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

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

[Charg]

Базу проверяли на ошибки?

А как?

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

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

[Колпаков Б.И.]

Базу проверяли на ошибки?

А как?

Менеджером архивов.

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

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

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

[Charg]

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

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

[poltava_energy]

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

Якщо чесно, мене такі подробиці не дуже цікавлять і у даному випадку я виступаю в ролі software engineer - а не hardware.
Подав заявку згідно до вимог серверної частини медка із цього розділу і мені надали сервер із потрібними характеристиками.

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

[AllexL]

Как это сделать?

Проверку БД можно осуществлять (при установленной серверной части вкупе с утилитами 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 (про всяк випадок) .
Про решение проблем с базой данных писать не буду, т.к. это непрофильный форум

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

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

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

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


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

[bandurovskiy]

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

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

[poltava_energy]

ZBK - zip-архив программного каталога + файла БД, поэтому ...

Лише одна ця фраза довіру до ваших висловів множить на нуль

Перенесите на сервере папку с БД медка на отдельный 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%

Розмір аномалії збільшується

[Колпаков Б.И.]

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

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

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

[AllexL]

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

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

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

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

[Юра_01]

ZBK - zip-архив программного каталога + файла БД, поэтому ...

Лише одна ця фраза довіру до ваших висловів множить на нуль

Перенесите на сервере папку с БД медка на отдельный 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%

Розмір аномалії збільшується

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

[Колпаков Б.И.]

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

[Юра_01]

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

[Колпаков Б.И.]

Расскажите.