Медленное архивирование периодов

Обговорення питань, пов'язаних з функціонуванням програми
Відповісти
ITkachuk
Повідомлень: 18
З нами з: 11 липня 2017, 17:47

Медленное архивирование периодов

Повідомлення ITkachuk » 30 січня 2020, 11:31

Файл БД Firebird 2 порядка 26GB
Работа данного ПО довольно медленная.
Решил как мне посоветовали на этом форуме выполнить архивирование периодов. Но и попутно оттестировать переход на Firebird 3.
Дабы исключить неприятные моменты при миграции - все действия выполняю на копии данных на машине сходной по характеристиками с рабочей системой.

Итак выполняю резервное копирование БД
| Показать
"C:\Program Files (x86)\Common Files\Firebird_M1\bin\gbak.exe" -b -se service_mgr -user SYSDBA -password pa$$w0rd D:\Medoc\db\zvit.fdb D:\TMP\zvit.fbk
Переношу zvit.fbk на тестовую машину.
На тестовой машине устанавливаю MEDOC из дистрибутива скаченного с сайта медка.
Догоняю свежеустановленное ПО до версии БД обновлениями с того же сайта.
Восстанавливаю БД из zvit.fbk, но уже свежеустановленным при инсталяции медка Firebird 3
| Показать
gbak -V -C -USER SYSDBA -PAS pa$$w0rd F:\backup\zvit.fbk F:\Medoc_DB\zvit.fdb
В ConnectionSetup "Налаштування Firebird - Розміщення БД" прописываю путь к восстановленному файлу БД.
Возникают некоторые проблемы с доступом к файлу БД - но это решается предоставлением прав доступа на чтение/запись в файл для "Сетевой службы"

Все запускается. Данные на месте.

Выполняю настройку в диалоговом окне медка "Архівування документів". Период архивации - квартал.
Поехали... Но это у меня выполняется очень, очень долго.
На скриншоте далее можно видеть, что каждый файл создается порядка часа. В файле порядка 25 тыс. записей.
База содержит документы с 2011 года.
| Показать
medoc01.png
medoc01.png (19.23 Кіб) Переглянуто 2081 раз
Хорошо. Возможно есть какие-то различия в структуре баз данных (эталона - файла БД созданного во время инсталяции ПО и восстановленной из резервной копии)?
Беру IBExpert и сравниваю.
Предлагаются такие изменения в целевой (рабочей БД на основании структуры эталона). Вроде как подобные изменения не должны влиять на производительность. Однако пробую накатить изменения.

Скрипт обновления структуры
| Показать
CONNECT 'LOCALHOST/3050:F:\Medoc_DB\ZVIT.FDB' USER 'SYSDBA' PASSWORD '';

SET AUTODDL ON;

/******************************************************************************/
/**** Dropping primary key constraints ****/
/******************************************************************************/
RECONNECT;

ALTER TABLE DSGFUNC DROP CONSTRAINT PK_DSGFUNC;


/******************************************************************************/
/**** Creating primary key constraints ****/
/******************************************************************************/
RECONNECT;

ALTER TABLE DSGFUNC ADD CONSTRAINT PK_DSGFUNC PRIMARY KEY (CODE);


/******************************************************************************/
/**** Creating foreign key constraints ****/
/******************************************************************************/
RECONNECT;

ALTER TABLE CARDVAL ADD CONSTRAINT FK_CARDVAL FOREIGN KEY (CARD) REFERENCES CARD (CODE) ON DELETE CASCADE;
ALTER TABLE DSGFUNCPARAMS ADD CONSTRAINT FK_DSGFUNCPARAMS_1 FOREIGN KEY (IDFUNC) REFERENCES DSGFUNC (CODE) ON DELETE CASCADE;
ALTER TABLE FJ0500102_MAIN ADD CONSTRAINT FK_FJ0500102_MAIN FOREIGN KEY (CARDCODE) REFERENCES CARD (CODE) ON DELETE CASCADE;
ALTER TABLE FJ0500102_TAB1 ADD CONSTRAINT FK_FJ0500102_TAB1 FOREIGN KEY (CARDCODE) REFERENCES CARD (CODE) ON DELETE CASCADE;
ALTER TABLE FJ1201002_MAIN ADD CONSTRAINT FK_FJ1201002_MAIN FOREIGN KEY (CARDCODE) REFERENCES CARD (CODE) ON DELETE CASCADE;
ALTER TABLE FJ1201002_TAB1 ADD CONSTRAINT FK_FJ1201002_TAB1 FOREIGN KEY (CARDCODE) REFERENCES CARD (CODE) ON DELETE CASCADE;
ALTER TABLE FJ1201102_MAIN ADD CONSTRAINT FK_FJ1201102_MAIN FOREIGN KEY (CARDCODE) REFERENCES CARD (CODE) ON DELETE CASCADE;
ALTER TABLE FJ1201102_TAB1 ADD CONSTRAINT FK_FJ1201102_TAB1 FOREIGN KEY (CARDCODE) REFERENCES CARD (CODE) ON DELETE CASCADE;
ALTER TABLE FJ1201202_MAIN ADD CONSTRAINT FK_FJ1201202_MAIN FOREIGN KEY (CARDCODE) REFERENCES CARD (CODE) ON DELETE CASCADE;
ALTER TABLE FJ1201202_TAB1 ADD CONSTRAINT FK_FJ1201202_TAB1 FOREIGN KEY (CARDCODE) REFERENCES CARD (CODE) ON DELETE CASCADE;
ALTER TABLE FJ1201501_MAIN ADD CONSTRAINT FK_FJ1201501_MAIN FOREIGN KEY (CARDCODE) REFERENCES CARD (CODE) ON DELETE CASCADE;
ALTER TABLE FJ1201501_TAB1 ADD CONSTRAINT FK_FJ1201501_TAB1 FOREIGN KEY (CARDCODE) REFERENCES CARD (CODE) ON DELETE CASCADE;
ALTER TABLE FJ1201501_TAB2 ADD CONSTRAINT FK_FJ1201501_TAB2 FOREIGN KEY (CARDCODE) REFERENCES CARD (CODE) ON DELETE CASCADE;
ALTER TABLE FORMCLS ADD CONSTRAINT FK_FORMCLS2 FOREIGN KEY (IDCLASSIF) REFERENCES CLASSIF (CODE) ON DELETE CASCADE;
ALTER TABLE HBBUDGETLGOT ADD CONSTRAINT FK_HBBUDGETLGOT_1 FOREIGN KEY (BUDJET_NUM) REFERENCES HBBUDJET (CODE) ON DELETE CASCADE;
Результат его выполнения - полностью отрицательный:
| Показать
medoc02.png
medoc02.png (81.42 Кіб) Переглянуто 2081 раз
Далее экспортированная структура рабочей БД.
medoc_sql.zip
(164.24 Кіб) Завантажено 8 разів
Буду рад любому совету.

priup
Повідомлень: 7713
З нами з: 22 червня 2011, 12:23

Re: Медленное архивирование периодов

Повідомлення priup » 30 січня 2020, 12:12

Модераторам форума : просьба перенести ЭТУ ТЕМУ СЮДА:
viewforum.php?f=78

так как это не ошибки программы!!

priup
Повідомлень: 7713
З нами з: 22 червня 2011, 12:23

Re: Медленное архивирование периодов

Повідомлення priup » 30 січня 2020, 12:19

1. Немного(не в разы) быстрее производить АРХИВИРОВАНИЕ в локальной версии МЕДОКА.

2. А можно параметры компа, где делаете архивирование?

3.
ITkachuk писав:
30 січня 2020, 11:31
......
Период архивации - квартал.
Поехали... Но это у меня выполняется очень, очень долго.
На скриншоте далее можно видеть, что каждый файл создается порядка часа. В файле порядка 25 тыс. записей.
База содержит документы с 2011 года.
......
Это нормальная скорость архивации (правда на SSD- винчестере не пробовал).

ITkachuk
Повідомлень: 18
З нами з: 11 липня 2017, 17:47

Re: Медленное архивирование периодов

Повідомлення ITkachuk » 30 січня 2020, 12:29

priup писав:
30 січня 2020, 12:19
...
2. А можно параметры компа, где делаете архивирование?
medoc03.png
medoc03.png (7.86 Кіб) Переглянуто 2043 разів
HDD Samsung HD103SJ ATA

priup
Повідомлень: 7713
З нами з: 22 червня 2011, 12:23

Re: Медленное архивирование периодов

Повідомлення priup » 30 січня 2020, 13:07

Так нормальная скорость архивирования!................
У меня:
| Показать
5.jpg
5.jpg (49.14 Кіб) Переглянуто 2028 разів
архив с чуть более 1200 документов создаётся 20 минут........

ITkachuk
Повідомлень: 18
З нами з: 11 липня 2017, 17:47

Re: Медленное архивирование периодов

Повідомлення ITkachuk » 30 січня 2020, 14:24

priup писав:
30 січня 2020, 13:07
Так нормальная скорость архивирования!................
Чтож! Видимо придется смириться. Спасибо!

priup
Повідомлень: 7713
З нами з: 22 червня 2011, 12:23

Re: Медленное архивирование периодов

Повідомлення priup » 30 січня 2020, 15:11

ITkachuk писав:
30 січня 2020, 14:24
priup писав:
30 січня 2020, 13:07
Так нормальная скорость архивирования!................
Чтож! Видимо придется смириться. Спасибо!
Если делать каждый год за предыдущий год - то и не долго... А вот если сразу с 2011 по 2017 - то канешно ...... фиговатенько!!

Medoc Man
Повідомлень: 864
З нами з: 07 червня 2018, 14:28
Звідки: Kiev

Re: Медленное архивирование периодов

Повідомлення Medoc Man » 30 січня 2020, 15:32

ITkachuk писав:
30 січня 2020, 14:24
Чтож! Видимо придется смириться. Спасибо!
На практике, архивирование долгий и трудоёмкий процесс. Это проходил каждый и не раз :)
Насколько я понимаю, связано это с тем, что каждый отдельно взятый документ приходится "выносить" в отдельную ("архивную") базу данных и строить там какие-то связи, чтобы такую "архивную" базу можно было потом подключать обратно к основной для доступа к старым документам.
Но результат себя окупает.

Попробуйте посмотреть на это с другой точки зрения. Имхо, возможно, разработчиком подразумевается, что выполнять такое "архивирование" рекомендуется не тогда, когда уже что-то еле открывается, а регулярно, помесячно, либо поквартально.
Соответственно, объём документов при регулярном архивировании меньше, а значит и времязатраты меньше.
Схема получается примерно такая же, как и банальная настройка в планировщике создания бэкапов.
Человек-волшебник
Людина-чарівник
Wizard man

ITkachuk
Повідомлень: 18
З нами з: 11 липня 2017, 17:47

Re: Медленное архивирование периодов

Повідомлення ITkachuk » 30 січня 2020, 15:54

Спасибо за разбор ситуации!

Вот меня гложет вопрос.
Процесс в моем случае будет длительный. В процессе переноса документов в архив всякое может случиться (упала служба, вырубили питание, не удержал ИБП).
Не окажется ли база после такого падения в каком-либо неконсистентом состоянии?

Что тогда? Смогу ли я рестартануть процесс архивации снова?
Есть ли какие-либо идеи на этот счет? Прецеденты, опыт?

Medoc Man
Повідомлень: 864
З нами з: 07 червня 2018, 14:28
Звідки: Kiev

Re: Медленное архивирование периодов

Повідомлення Medoc Man » 30 січня 2020, 17:12

ITkachuk писав:
30 січня 2020, 15:54
В процессе переноса документов в архив всякое может случиться (упала служба, вырубили питание, не удержал ИБП).
Не окажется ли база после такого падения в каком-либо неконсистентом состоянии?
Что тогда? Смогу ли я рестартануть процесс архивации снова?
Есть ли какие-либо идеи на этот счет? Прецеденты, опыт?
У меня на практике самое длительное архивирование длилось около 16 часов (БД около 55 Гб). Очень много первичных документов и очень вяло шёл процесс.
Поначалу пробовал запустить на ночь - не успевало, к утру приходили коллеги из бухгалтерии и приходилось прерывать.
В итоге дождался вечера ближайшей пятницы, запустил - и к обеду в субботу получил успешный результат: на выходе, после бэкап/рестора основной БД получил её в размере всего ~4 Гб. Ну и реестры, соответственно, ожили и подгружались существенно быстрее. Архивные БД я вынес затем на общий ресурс, чтоб бухгалтерия могла подключать/отключать их безпрепятственно, а основную БД с серверной частью переместил на SSD (суммарно, занимаемое Медком место составило чуть больше 5 Гб). И коллегам работать стало комфортнее.

Касательно "падения чего-либо там" - тут рулетка в чистом виде. Может повезти и просто понадобится перезапустить процесс, а можете поймать повреждения БД.
Превентивно, просто скопируйте файл БД в отдельный каталог и со спокойной душой приступайте к делу. В случае неприятностей легко можно будет вернуть всё обратно без потери чего либо. Саму процедуру, разумеется, запускайте только при отсутствии работающих в Медке пользователей.
Так же рисков меньше, если БД не содержит ошибок. Перед началом архивирования проверьте Вашу БД Менеджером архивов M.E.Doc (создав архив с отметкой "Створювати з перевіркою бази даних").
Человек-волшебник
Людина-чарівник
Wizard man

ITkachuk
Повідомлень: 18
З нами з: 11 липня 2017, 17:47

Re: Медленное архивирование периодов

Повідомлення ITkachuk » 30 січня 2020, 17:56

Medoc Man писав:
30 січня 2020, 17:12
У меня на практике самое длительное архивирование длилось около 16 часов (БД около 55 Гб). Очень много первичных документов и очень вяло шёл процесс.
....
Большое спасибо, что нашли время поделиться опытом! :D

Відповісти

Повернутись до “Помилки у роботі програми”