[konopello]

Могу только подвести итог из прочитанного по тегам архивирование:

Цитата:

Всем привет! Отвечу самому себе на вопрос и закрою тему. На MS Technical Airlift в Мюнхене удалось поговорить с неким ответственным датчанином и послушать его презентацию.

Архивирование в 5.0?
Так вот, архивирования [складских проводок] в 5.0 не будет, но планируется в 6.0. Они, типа, пытались, но пришли к выводу, что на постройку общего механизма в 5.0 им не хватит времени. С учетом того, что изначально архивирование планировалось для 5.0, а затем они сместили номера версии 4.1 -> 5.0 и 5.0 -> 6.0, то они даже не обманули.

DAX 3.0 SP5FP2 - Архивация прошлых лет

Цитата:

Немного поделюсь опытом:
(Огромное спасибо Torin за помощь на начальном этапе)
1. база ~200 гиг.
2. партицирование делалось по дате только для огромных таблиц
3. при партицировании, главное условие: значимое поле (дата в моем случае) должно входить в кластерный индекс (что косвенно увеличивает размер базы)
4. приведенный скрипт by Torin, не подошел, т.к. я не все таблицы партицировал.
5. я создал отдельные filegroup, files, функцию и схему партицирования по полю типа "дата"
6. для каждой таблицы (12 штук) был отдельный скрипт
7. вручную удалял кластерный индекс для таблицы
8. добавлял в кластерный индекс поле "дата" если это требовалось
9. запускал скрипт из п.6.
10. затем filegroup делал readonly и средствами NTFS сжимал фалы этой группы. (мне хотелось именно это сделать)

В итоге база стала 110 гиг из них 20 занимает на диске (реально 60) созданная партиция.
Проверял отчеты по данным таблицам, работают без проблемм и снижения производительности не заметил.
Конечно это не серьезное исследование, но кое какие выводы сделал, например, то что в моем случае, никакие структурные изменения для партицированных таблиц невозможны (ибо readonly)

Цитата:

Ну и чтобы завершить тему рекомендую зайти по ссылке:
https://emea.msconvergence.com/Publi...?categories=ax и внимательно посмотреть на презентацию AX10.
На всякий случай - дисклеймер: Страница найдена гуглом, никакого разглашения инсайда, никого не трогаю - починяю примус

Существуют ли механизмы свертывания базы?

Цитата:

Перекресток
Ну раз спросили, то отвечу
В Перекрестке Аксапта использовалась без финансового модуля, то есть проводки были, но никто их не смотрел, так что эта часть чистилась очень просто.
Сокращение InventTrans делалось созданием новой базой с переносом остатков на дату (с сохранением соотношения открытые-закрытые).
Процесс выглядил примерно так:
1. Перед полной инвентаризацией в обязательном порядке закрываются все "зависшие" документы, вычищаются "повисшие" проводки (не продано-приобретено и не заказано- в заказе)
2. Создается новая база, в которую заливаются мастер-данные, открытые документы (с проводками заказано-в заказе)
3. После подсчета (до разноски или параллельно разноске журналов) в новой базе создаются приходные проводки с типом перенос и "красивым" номером по количествам, аналитикам из журналов инвентаризации и средней себестоимостью.
4. Переносятся все InventDim, которые используются в новой базе и все партии которые используются в этих аналитиках.
5. Новая Аксапта запускается ... ночь прошла! ура! домой!
6. После закрытия периода в старой базе, в новой создается приходная накладная (либо стандартно, либо генерация записей своей процедурой) на резервный склад с правильной суммой и создаются расходные проводки с "красивым" журналом переноса с резервного склад со старой себестоимостью. (Создание приходной накладной на несколько тысяч строк - отдельная большая тема)
7. Часть приходных проводок "закрывается" для сопоставления. Можно было бы и помельче подробить для сохранения ФИФО, но это оказалось никому не нужно.

Делается в инвентаризацию, так как система в это время не работает, остатки после инвентаризации близки к реальности, все аналитики старого резервного склада становятся неактуальными и не переносятся.

Удаление журнала спецификаций

Цитата:

Я и говорю - соображения производительности.

Смотрите сегментирование в Оракле.
Суть (очень грубо и очень неточно): можно разбить одну таблицу на несколько сегментов. Каждый сегмент можно хранить в отдельном... хм... на отдельном диске (так проще для понимания). Оракл умеет делить данные на сегменты при помощи различных критериев. В частности может делить на сегменты по датам. Так, например, текущий год размещаем на быстрый(ые) диск(и), а данные прошлых лет на медленный(ые). В результате Оракл при запросах к текущему году не обращается к медленному диску (сознательно написал очень грубо, если кому интересно обращайтесь к документации)

Так вот, имея под рукой функцию сегментирования не надо заботиться о СВЕРТКЕ. Данные могут оставаться в первоначальном виде. При больших объемах производительность существенно не падает. Но зато запросы БЕЗ изменений работают по ЛЮБОМУ периоду. Надеюсь вы понимаете, что это означает для получения статистики.

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

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

Справедливости надо отметить, что и буржуи не всегда молодцы. Так бывают запросы в банке, HRM, управлении цехом, где суммируются все данные от царя гороха. Но основные тяжелые запросы в западном функционале сделаны правильно, с учетом сегментирования.