стоит задумается а том что следует в AX дописать что то аналогичное в SAP типа архивирование

[konopello]

Цитата:

Парни говорят что все просто летает по сравнению с тем что было - через пол года посмотрим. Dynamics Ax 2012 -> General Availability Q3 201

Я как человек проработавший с AX всего три года и уже столько же в SAP скажу принцип работы складской и теперь уже финансовой аналитике очень даже хороший, вот только стоит задумается а том что следует в AX дописать что то аналогичное в SAP типа архивирование (Все не нужные данные перекидываем в архив), ну я так думаю меня поддержат? или я не прав?

[Ievgenii]

Цитата:

AX дописать что то аналогичное в SAP типа архивирование (Все не нужные данные перекидываем в архив),

Зачем писать -

Intelligent Data Management Framework for Microsoft Dynamics AX

уже есть и активно используеться (бета была в марте прошлого года кажеться). Эту проблему должен и будет решать МС, начиная с DAX2009


http://daxguy.blogspot.com/2009/06/i...framework.html

http://blogs.msdn.com/b/ukax/archive...d-details.aspx

[konopello]

Цитата:

Intelligent Data Management Framework for Microsoft Dynamics AX

ну да мои знания новинок AX уже не те времени не хватает.... Да вот только по ссылкам которые вы дали очень смутно можно понять что это за вещь и с чем ее едят (красиво написать это одно), к сожалению у меня нет доступа к внутреннему порталу MS куда ссылаются эти приложения....

Обращусь тогда к форумчанам что это за вещь и как ее едят? Я раньше не видел подобных обсуждения, хотя каждый день открываю форум. Кто нибудь хотя бы в кратце может объяснить что этот модуль может делать пока имеется только

Цитата:

The Intelligent Data Management Framework for Microsoft Dynamics® AX helps administrators optimize Dynamics AX database layout by intelligently monitoring index usage, index layout, fragmentation and query patterns thru indices. The framework allows reduction of the database size by purging transaction records from a set of related entities, while maintaining the consistency and integrity of production data. The Intelligent Data Management Framework provides customers and partners the ability to identify and discover related entities based on Microsoft Dynamics AX metadata and to determine the purging criteria for entities and transactions. The Intelligent Data Management Framework also analyzes the production database to determine current usage patterns and assesses the health of the Microsoft Dynamics AX application.

И

Цитата:

Click here to download [ Requires Partnersource Access]

[gl00mie]

Цитата:

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

Я раньше не видел подобных обсуждения, хотя каждый день открываю форум.

• Arijit Basu: Intelligent Data Management Framework for Microsoft Dynamics AX
• Arijit Basu: AX Intelligent Data Management Tool : Inside look
• axinthefield: Podcast - AX Intelligent Data Management Framework

"purging transaction records" и "архивирование" как-то не одно и то же...

[konopello]

2 gl00mie: Спасибо за ссылки посмотрел но конкретики нет.

Приведу пример что есть Архивирование в SAP:

Цитата:

Data Archiving removes from the database application data from closed business transactions that are no longer relevant for the operational business. The archived data is stored in archive files that can be accessed by the system in read-only mode.

Цитата:

Data Archiving – a service provided by SAP NetWeaver – removes mass data that the system no longer needs online, but which must still be accessible at a later date if required, from the database. The following graphic illustrates the archiving process: Archiving objects are used to write documents to archive files, which can be stored on other media.

he archiving procedure is divided into three main steps:
· Creation of archive files
In the write phase the data to be archived is written sequentially into newly created archive files.
· Delete from the database
The delete program reads the data from the archive files and then deletes it from the database.
· Storage of archive files
The newly created archive files can then be moved to a storage system or copied to a tape. The removal to an external storage system can be triggered manually or automatically. It is also possible to store the data before the delete phase.
In XML-based archiving this phase does not exist as a separate step. The data can be written directly to a WebDAV system.
The archiving programs are generally scheduled in the background. However, they can also run in online mode.
The following documentation describes ADK-based archiving. It is important that you understand the basic archiving concepts described in this documentation before you begin with XML-based archiving. The differences between the two technologies and processes are described under XML-based Archiving.

См. http://help.sap.com/saphelp_erp60_sp...a/frameset.htm

[SolNik]

Цитата:

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

2 gl00mie: Спасибо за ссылки посмотрел но конкретики нет.

Приведу пример что есть Архивирование в SAP:




См. http://help.sap.com/saphelp_erp60_sp...a/frameset.htm

Функционал IDM на первый взгляд очень похож на то, что есть в SAP-е. Также есть, некая read-only база, куда специальным сервисом в фоновом режиме (через SSIS) балк инсеротм копируются данные, а потом удаляются из продакшн-базы. Периоды архивирования можно привязать к периодам закрытия ГК.
Пока конечно - это просто мощный конструктор. Готовых шаблонов архивирования не так много. И я так понимаю, MS еще сам не очень уверен, что система не развалится, если их применить без тщательного тестирования и допилки (по крайней мере об этом постоянно говорится в мануале). Но - это все вопрос времени...

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

В DAX сейчас все так. А было бы круто, если бы была какая-то бесшовная технология для доступа только на чтение к архивным данным.

[konopello]

Цитата:

НО, интересен вот какой момент - в SAP-е архивные данные можно посмотреть только на каком-то отдельном инстансе?

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

Цитата:

Т.е., я не могу построить какой-нибудь стандартный отчет, за период, который захватывает, как данные из архивного периода, так и из текущего?

Отчет построить можно главное что бы первичные ключи данных которые лежат в архиве были в рабочей базе.

Цитата:

И соответственно, следующий вопрос - бизнес-логика SAP-а после архивирования данных "забывает" о них? Считает, что их как-будто никогда и не было?

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

[mazzy]

добавил к теме тег Архивирование.
посмотрите что писали по этому поводу раньше архивирование

[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, управлении цехом, где суммируются все данные от царя гороха. Но основные тяжелые запросы в западном функционале сделаны правильно, с учетом сегментирования.

[Zabr]

Цитата:

Конечно это не серьезное исследование, но кое какие выводы сделал, например, то что в моем случае, никакие структурные изменения для партицированных таблиц невозможны (ибо readonly)

А вот это очень серьезный вопрос. Например, упомянутый Intelligent Data Management Framework for Microsoft Dynamics AX - разрешает или запрещает модифицировать архивированные таблицы. Например, добавить свое поле. Или включить новую аналитику, что по сути одно и тоже. Или построить новый индекс.
Допускаю, что для больших баз и долго работающих систем - inventtrans вряд ли поменяется. Но мало ли в Аксапте других больших таблиц.