¶ Удаление фото из базы данных
¶ Планирование
Первым делом, необходимо обращение, в котором мы будем согласовывать с клиентом нюансы. Например:
- Когда проводить работы. Удаление может занять много время, нужно согласовать с клиентом время работ, чтоб не мешать их работе;
- Есть ли возможность занять начало рабочего дня, если вдруг удаление не успевает пройти;
- Дату, до которой очищаем фото;
При планировании надо проверить:
*Наличие свободного места для:
* бэкапа базы __с фото__;
* оптимизации(это минимум размер БД*3). Понадобится делать backup/restore, для этого нужно будет место;
* Наличие и правильность процедуры для удаления фото;
* Отсутствие у клиента облачного хранилища или использования для хранения фотографий локального хранилища (Химчистка/Сервис/Другие сервисы/Настройка хранилища данных - на закладке "Локальное хранилище" не активен чекбокс "Включить хранение фото в локальном хранилище", на закладке "Облачное хранилище" не активен чекбокс "Активировано"). **При наличии облачного или использовании для хранения фотографий локального хранилища удаление по сценарию, указанному в этой инструкции, не производить**.
¶ Удаление старых фото
1. Сделать копию БД. Делается для того, чтоб при возникновении какого-то сбоя или если клиент неожиданно передумает, у нас была БД от куба мы могли бы восстановить данные или полностью заменить этой базой
-
Проверить наличие в БД процедуры SP_DEL_OLD_PHOTOS_DT. Для этого открываем IBExpert, в в поиск копируем название этой процедуры и убеждаемся в ее наличие. Данная процедура необходима для удаления старых фотографий за указанный период
-
Убедиться что код в процедуре соответствует скрипту, см. ниже. У клиента может находится старая версия этой процедуры, а выполнять нужно только в актуальном состоянии
SET TERM \^ ;
CREATE OR ALTER procedure SP_DEL_OLD_PHOTOS_DT (
DATE_FIRST D_TIMESTAMP,
DATE_LAST D_TIMESTAMP)
as declare variable DOSP_ID D_INT64; begin
for
select dp.id
from docs_order dor
left join doc_order_services dos on dos.doc_order_id=dor.id
left join doc_order_serv_photos dp on dp.dos_id = dos.id
where dor.date_out_fact is not null and
cast(dor.date_out_fact as date) >= :DATE_FIRST and -- начало периода
cast(dor.date_out_fact as date) <= :DATE_LAST and -- конец периода
dor.status_id in (5, 6, 7) and
dp.id is not null
into :DOSP_ID
do
begin
delete
from doc_order_serv_photos dp
where dp.id = :DOSP_ID and
coalesce(dp.is_main_photo, 0) = 0; --Если в таблице нет колонки is_main_photo, то убрать условие "and coalesce(dp.is_main_photo, 0) = 0"
end
end\^
SET TERM ; \^
4. Отключить триггер DOC_ORDER_SERV_PHOTOS_AD (если триггера нет, пропускаем этот пункт). Для этого убираем галочку с "IsActive", потом жмем "Compile". Триггет мы отключаем для того, чтоб удаленные данные не попали в лог репликации и это удаление не уходило по репликации (если не пунктах нужно будет уменьшить место, то нужно будет делать новую БД на основе центральной)
Если этого не сделать, то информация об удалении фото попадет в репликацию, что, свою очередь, очень сильно навредит клиенту и нам!
5. Отключить остальные триггеры на удаление по таблице DOC_ORDER_SERV_PHOTOS (как отключить см. п.4)
6. Убедиться в наличие индекса DOR_IDX_DT_OUT_FACT в таблице DOCS_ORDER. Без этого индекса скрипт по удалению фото может очень долго работать.
Если индекса нет, провести скрипт:
CREATE INDEX DOR_IDX_DT_OUT_FACT ON DOCS_ORDER (DATE_OUT_FACT);
execute procedure SP_DEL_OLD_PHOTOS_DT('01.01.2021', '31.12.2021'); commit;
Время удаления зависит от размера БД, периода удаления фото и мощности ПК.
8. Включить триггер DOC_ORDER_SERV_PHOTOS_AD (если триггера нет, пропускаем этот пункт). Для этого ставим галочку с "IsActive", потом жмем "Compile". Возвращаем триггер к прежнему состоянию, чтоб он все действия фиксировал в логе репликации
-
Включить остальные триггеры на удаление (которые были выключены в п.4)
-
Сделать backup/restore. Без этой операции размер БД не уменьшится, только после restore мы увидим каким размером БД стала после удаления старых фото.