Архивация данных в AX2009. Подходы

[Lankey]

AX2009
Есть очень большая база(несколько терратабайтов). Судя по всему, она на треть еще вырастет к тому времени, когда компания перейдет на новую ERP
Соответственно, бэкапы уже длятся по часа 4-5. Будет еще хуже. Прерформанс системы тоже будет только ухудшаться.
Надо архивировать старые данные(старше х лет)
Какие есть опции помимо IDXF ?
Я пообщалась с иск интеллектом и мы решили (ну, или мне кажется, из обсужденного), что можно для самых больших тебалиц попробовать скинуть старые данные в отдельный partition (например, все ledgerTrans по TransDate < today - x лет) и этот partition заархивировать в отдельную базу.
Поэтому, получится объем текущей базы меньще, но можно быстро, при надобности этот кусок таблицы восстановить их архива и прикрепить к текущей базе
Если, допатим, в базе 15 лет данных, а хранить надо 7, а отрежем все, что старше 10, то, по идее, должно быть быстро и просто и на отчетность не повлиять(, что макс за 7 лет) и data intergrity

Каждый год можно переносить допоснительный год в архив после закрытия года, т.о постепенно уменьшая объем базы

Какие есть за и против?

[axm2017]

За - вроде понятны.
Против - проще спросить бизнес но по факту, подозреваю, что количество обращений к 10 летним данным - 0

[Pandasama]

Отрезать все данные старше N лет, загрузив вместо кучи проводок начальное сальдо?

[Владимир Максимов]

Практика показывает, что общего решения по архивированию не существует. Хотя можно сделать частичное архивирование наиболее проблемных (больших) таблиц

Проблема здесь в том, что невозможно получить ясный и однозначный критерий "архива". Т.е. какие именно записи в каких таблицах можно перенести в архив, а какие - нельзя.

Ну, допустим, с LedgerTrans - все понятно. Но, как правило, в таких старых решениях сделано много своего кода. Со своей спецификой. И вот в этом-то "своем" коде все не так однозначно. Хорошо, если там дата вообще есть. Хотя бы в виде системных дат создания/изменения.

Это надо долго и мучительно разбирать с бизнесом. Хотя бы на уровне документов. По каким критериям можно определить, что вот этот документ уже не актуален и его можно переместить в архив

Потом повторить все то же самое с системой отчетности. Особенно, если есть кубы. Подозреваю, что именно там будут основные проблемы. Не с самими документами, а с отчетами. Наверняка есть какой-нибудь показатель, который собирает данные "с начала времен"

Ну, а в самом общем виде, решение уже описали

1. Расчет и запись баланса на дату архива
2. Перенос всех документов с датой меньше расчетной, в отдельную (архивную) базу

В стандартном функционале есть тип проводки "Входящее сальдо". Если функционал не стандартный, то создавать соответствующие таблицы, поля, элементы Enum (тут надо смотреть по функционалу) и внести нужные изменения в функционал

PS: Решение с partition хорошо только тем, что есть стандартные инструменты в MS SQL по ее использованию. Но по сути, чем это отличается от прямого копирования в отдельную (архивную) базу выделенных записей?

PPS: Если планируется переход на новую ERP в ближайшие год-два, то поиск "общего" решения по архивированию не имеет особого смысла. Просто "отрежьте" самые большие таблицы по дате и перенесите это все в архив. Думаю, если нет показателей, рассчитывающих что-то по этим таблицам "с начала времен", то никто ничего не заметит

[Lankey]

Цитата:

Сообщение от Владимир Максимов

Ну, а в самом общем виде, решение уже описали

1. Расчет и запись баланса на дату архива)

Спасибо
Поясните по входящему сальдо, пожалуйста.
Я так понимаю, что при закрытии финансового года они все равно формируются. То есть, если "отрезать" после закрытия, то все будет ок и не надо доп проводок делать? Я не права?
Что произойдет с остатками по складам при отрезании?

Цитата:

Сообщение от Владимир Максимов

PS: Решение с partition хорошо только тем, что есть стандартные инструменты в MS SQL по ее использованию. Но по сути, чем это отличается от прямого копирования в отдельную (архивную) базу выделенных записей?

Из того, что прочитала, если

• сравнивать с ручным отрезанием, то это должно быть быстро и надежно (подключить-отключить), что уже немало . Особенно для ситуаций аудита.
• А по сравнению с IDXF намного меньше мороки

[Владимир Максимов]

Да. Для бух.проводок это есть. Здесь речь идет о том функционале, где нет проводок по закрытию периода. Например, складские проводки. А "входящее сальдо" - это просто пояснение, о чем речь, на наглядном примере

Идея с проводкой по входящему сальдо заключается в том, чтобы иметь инструмент "ремонта" текущего остатка, если вдруг, что случиться. Ведь текущий остаток - это сумма всех без исключения проводок. Но если отрезать архив, то часть данных "пропадет"

То же самое касается "расчета на дату", если вдруг кто-то захочет посчитать остаток на дату, раньше архива. При наличии входящего сальдо он получит остаток 0. А если входящего сальдо нет, то получит некий не нулевой остаток, что будет вводить в заблуждение

PS: Про partition не в курсе, как он себя поведет при добавлении полей/индексов? Автоматически добавит или запрет на такие операции?

[Lankey]

Спасибо, Владимир. Есть какие-то штатные механизмы(как-то применить стд классы, например) для коррекции входящего сальдо по состоянию на X лет назад? По кр мере, складских проводок?

[Владимир Максимов]

Не знаю. Специально не искал. Подозреваю, что таких инструментов нет из-за очень уж специфической проблемы и способа решения. Если кривой баланс, то обычно ищут те проводки, которые породили ошибку. А баланс исправляют добавлением новых проводок или удалением/правкой проблемных

[Товарищ ♂uatr]

Цитата:

Сообщение от Lankey

AX2009
Я пообщалась с иск интеллектом и мы решили (ну, или мне кажется, из обсужденного), что можно для самых больших тебалиц попробовать скинуть старые данные в отдельный partition

Обсудать с "искусственным интеллектом" Аксапту - себе дороже, очень сладко врёт. Например: поддержка партиции появились только в 2012 версии Аксапты.

Дайте больше деталей.
Тип резервного копирования дифференциальный или полный столько времени занимает?
Какие топ 10 таблиц входят в TSQL-отчёт "disk usage by top tables"? Скорее всего, первые 5 таблиц занимают 80% дискового пространства и содержат:
- blob поля;
- денормализованные данные (которым место в SSAS);
- бесконтрольно "пухнущие" (SysDataBaseLog, AIF*, Batch*..) данные.

Источник проблемы не в количестве данных - это борьба со следствием. Никто не запрещает составить план действий по урезанию данных, но решение находится в области архитектуры решений. Повысьте требования к нормализации таблиц и жизненному циклу записей находящихся в них на уровне решений, а не регламентных процедур.

PS рекомендую ознакомиться с паттерном Event Sourcing, он может помочь в разработке решения по "архивации" проводок.
PS2 проблема быстродействия и проблема объёма данных должны рассматриваться раздельно.

[Lankey]

Спасибо. LedgerTrans(800GB), CustinvoiceTrans(600GB), InventTrans(180GB), SalesLine (150GB), custinvoiceTrans(150GB), TaxTrans(60GB) - самые большие
Я уже нашла неиспользуемые распухщие кастомные индесы на них , но не смотрела есть ли кастомные поля, что съедают много места. Хотя если есть, менять структуру вряд ли будет возможно. SysDataBaseLog, AIF*, Batch*.. это все уже обрезается и по максимому и минимизирован трэкинг .
Надо продлить жизнь этого дела лет на 5. Хотят резать данные.
Я хочу понять, есть ли у кого-то опыт подрезания.
В частности:
а) Можно ли подрезать только фин часть (LedgerTrans и связанные таблицвы), но не трогать складские.
б) Если трогать складские, то как корректно воссоздать остатки по складам после обрезания?

[sukhanchik]

Вообще, если уж говорить с т.з. денег - то дешевле купить побольше дисков и не мучаться с местом. "Несколько терабайтов" - это не несколько "десятков терабайтов".
У обрезания много проблем. То пользователи захотят видеть старые данные, то где-нибудь логика "стрельнет" по старым данным и т.д. Т.е. обрезание БД - это будет целый проект, в результате которого от старой БД никто не откажется )))). Сначала сделаете интеграцию между базами... а потом она так и останется на постоянке )))).
Если проблема в скорости - то она решается оптимизацией индексов и программного кода. Если проблема в месте на дисках - то докупкой дисков. Какие бы ни были дорогие диски - это будет дешевле интеллектуального труда разработчика

Сделать можно всё, но с нюансами. Вот, к примеру, Вы подрежете LedgerTrans. А потом не сойдется оборотка по складу и ГК. Или люди от разнесенной складской проводки не увидят проводки ГК. Ну.. это первое, что приходит в голову.
Просто тут оцените эффект. Подрезали, допустим, LedgerTrans. Потратили на это 100500 часов разработки (корректно воссоздав остатки; решив кучу сопутствующих проблем и т.д.). И тут люди захотели увидеть старые данные.

Смотрим на итог - что получилось ? А в итоге всё равно пришлось докупить диски, но теперь зато у нас имеются 2 базы, 2 приложения и необходимость условной синхронизации между ними (в части меняющегося программного кода).

Т.е. можно без всего этого - просто докупить диски; таблицы раскидать по разным файлам БД, а их раскидать на разные диски. И ... всё

[Lankey]

Спасибо, но мой вопрос был про конкретный опыт подрезания / архивации.