Поругайте MS Dynamics AX (AXAPT`У) / ERP и учетные системы

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / Поругайте MS Dynamics AX (AXAPT`У)

25 сообщений из 445, страница 12 из 18

все

Поругайте MS Dynamics AX (AXAPT`У)

#36009617

Ага

Гость

Volochkova

1. Первичен АЛГОРИТМ! а уже потом код...
И так... Процедура прихода...
Все что было описано с примером про приход и перемещение.. это все лажа...
В жизни ( мое имхо) должно быть так...

Берем накладную.... проверяем все ее признаки... +/-.. кто проверил, заполнены ли сроки годности и т.д.
А уж потом проводим по регистрам партий и в самом конце... Если нет партий, то регистр остатков.
И никакие блокировки не нужны. В самом примере нарушена сама логика прихода.

2. Теперь сам код...

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.

begin tran
Update 
     reg
From    
    InventStoc  reg inner join DocIncome docdetal on reg.ProductID = docdetal.ProductID and docdetal.DocHeadID = @DocHeadID
Set 
     reg.KolProd = reg.KolProd + docdetal.KolProd
commit

Обработается на 1000 порядков быстрее чем цикл на клиенте или АОСе...
И не надо никаких костылей из темы кеширования таблиц на АОСе...
MS SQL все сделает сам...

Update сделается (одновременно для всех записей).
Теперь про блокировки...
На момент выполнения транзакции, а это уж точно толика времени для документа в 1000 строк .
Записи с товаром будут заблокированы. Если нужен код MS SQL я его приведу..
И сканирование таблицы
А ля Аксапта

Код: plaintext

select * from InventStoc  (READPAST) Where KolProd  >  0

отдаст только те записи которые доступны и не заблокированы ТРАНЗАКЦИЯМИ!
Которые сделает один сервер MS SQL.
И в результате для продажи нельзя будет выбрать то, что сейчас заблокировано приходом.

Что мы имеем в сухом остатке?
Никаких гонений данных по сети, ни какого геморроя, простой доступный T-SQL.
Но этого движек Аксапты делать не умеет.

Мой же вариант

Код: plaintext

select * from InventStoc  Where KolProd  >  0

не споткнется об блокировки...
Т.к. у команды есть такая фишка - ExecTimeOut в результате... запрос на просмотр остатков подождет прихода всей партии 1000 СТРОК!!!! и тут же покажет их...

В варианте Аксапты.. будет While Select на приходе с блокировками или кешированием... на приходе и на просмотре остатков..

Счастливый Вы человек Volochkova, до сих пор живете в мире фантомов :).
Распостраните Вашу концепцию "жизнь без блокировок" на 100 конкурентых пользователей.

В Вашем варианте в последовательность выполнения с уровнем изоляции read uncommitted (привожу так любимый Вами T-SQL):

Код: plaintext

1.
2.
3.
4.
5.

Клиент  1 : begin transaction 
Клиент  1 : delete  from InventStoc  
Клиент  2 : select @qty=sum(quantity) from InventStoc  Where id_item='zuzu'
Клиент  1 : rollback transaction
Клиент  2 : if @qty= begin delete from  item where id_item='zuzu' end

Клиент 2 словит фантомные данные результат его выполнения явно приведет к логической ошибке.

Насколько я помню в Аксапте все данные читаются по умолчанию с хинтом read uncommitted (если иное явно не указано), при модификации данные пересчитываются с хинтом read committed. Такая схема гарантирует блокировки на минимальное время и отсутствие фантомов.

Засим откланиваюсь, уверен автор топика сделал для себя выводы. Уважаемой Волочковой хочу пожелать немного подучить матчасть на первом сверху форуме.

...

Рейтинг:

0 / 0

27.05.2009, 09:45

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36009627

belugin4

Гость

Volochkova
Update сделается (одновременно для всех записей).

я о том, как обсепечивается то, что он сделан одновременно.

Никаких гонений данных по сети, ни какого геморроя, простой доступный T-SQL.
Но этого движек Аксапты делать не умеет.

умеет, но возможностей меньше чем у Transact SQL

На всякий случай: Вот так сделано обновление остатков в 2009 (думаю в 4 так же)

\Classes\InventUpdateOnhand\sqlUpdateInventSumStrSQLServer

генерирует вот тако SQL

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.

/* This method will build following statement in a str:

execute sp_executesql N'UPDATE InventSum
    SET InventSum.CostAmountPhysical     = InventSum.CostAmountPhysical            +
                                           InventSumDelta.SUM_CostAmountPhysical,
        InventSum.PostedValue            = InventSum.PostedValue                   +
                                           InventSumDelta.SUM_PostedValue,
        InventSum.Qty                    = InventSum.Qty                           +
                                           InventSumDelta.SUM_Qty,
        .....
        .....

        InventSum.LastUpdDatePhysical    = CASE WHEN InventSum.LastUpdDatePhysical > InventSumDelta.MAX_LastUpdDatePhysical
                                                THEN InventSum.LastUpdDatePhysical
                                                ELSE InventSumDelta.MAX_LastUpdDatePhysical
                                           END,

        InventSum.LastUpdDateExpected    = CASE WHEN InventSum.LastUpdDateExpected > InventSumDelta.MAX_LastUpdDateExpected
                                                THEN InventSum.LastUpdDateExpected
                                                ELSE InventSumDelta.MAX_LastUpdDateExpected
                                           END,

        InventSum.ClosedQty              = CASE WHEN ((InventSum.PostedQty + InventSumDelta.SUM_PostedQty) = 0 AND
                                                      (InventSum.Deducted  + InventSumDelta.SUM_Deducted)  = 0 AND
                                                      (InventSum.Picked    + InventSumDelta.SUM_Picked)    = 0 AND
                                                      ....
                                                      ....
                                                     )
                                                THEN 1
                                                ELSE 0
                                           END,
        InventSum.Closed                 = CASE WHEN ((InventSum.PostedValue    + InventSumDelta.SUM_PostedValue)  = 0 AND
                                                     (InventSum.PhysicalValue  + InventSumDelta.SUM_PhysicalValue) = 0 AND
                                                      ....
                                                      ....
                                                     )
                                                THEN 1
                                                ELSE 0
                                           END
    FROM (SELECT SUM(CostAmountPhysical)    AS SUM_CostAmountPhysical,
                 SUM(PostedValue)           AS SUM_PostedValue,
                 SUM(Qty)                   AS SUM_Qty,
                 .....                      AS ...,
                 .....                      AS ...,
                 MAX(LastUpdDatePhysical)   AS MAX_LastUpdDatePhysical,
                 MAX(LastUpdDateExpected)   AS MAX_LastUpdDateExpected,
                 InventSumDelta.ItemId,
                 InventSumDelta.InventDimId
          FROM InventSumDelta
          WHERE InventSumDelta.DataAreaId   = @p2
          AND   InventSumDelta.TTSId        = @p3
          AND   InventSumDelta.IsAggregated = 0
          GROUP BY InventSumDelta.ItemId, InventSumDelta.InventDimId
         ) AS InventSumDelta
    WHERE InventSum.DataAreaId        = @p1
    AND   InventSum.ItemId            = InventSumDelta.ItemId
    AND   InventSum.InventDimId       = InventSumDelta.InventDimId
',N'@p1 NVARCHAR(3), @p2 NVARCHAR(3), @p3 BIGINT',@p1=%1,@p2=%2, @p3='%3'

*/

...

Рейтинг:

0 / 0

27.05.2009, 09:48

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36009739

iscrafm

Участник

Сообщения: 34 277

Рейтинг: 0 / 0

beluginmiklenew
Volochkova
3. Знания. Без знаний SQL и БД ставить даже не думай.

3.1 Перефразирую. Без хороших специалистов ставить даже не думай.

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

...

Рейтинг:

0 / 0

27.05.2009, 10:23

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36009790

iscrafm

Участник

Сообщения: 34 277

Рейтинг: 0 / 0

beluginЭто может привести к проблеме, если другая транзакция успеет прочитать обновленное значение записи 'гайки'.
..

Вопросы:
1. Я ответил?
2. Вы согласны ли вы с такой картиной, если не согласны в чем здесь ошибка?

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

beluginВ Ax2009 обновление остатков делается одним простым SQL запросом на транзакцию непосредственно перед коммитом
долгая дорога в дюнах.

...

Рейтинг:

0 / 0

27.05.2009, 10:35

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36009791

Volochkova

Участник

Сообщения: 1 704

Рейтинг: 0 / 0

VivernaVolochkova9. Кубы, Аксижен.. Якобы панацея, но сделаны тоже ректально. Учитывая что он берет данные с боевой базы, которая вся в блокировках.. то через год считать кубы уже просто невозможно.
Аха! Раз Аксижн - значит все таки Корус Ретайл :) Интересно какой версии.

Учитывая что он берет данные с боевой базы - а вы не пробовали настроить, чтобы он брал данные из хранилища? А хранилище часа так в 3 ночи обновлялось. И никаких вам блокировок.

Гы... Ну как то знаете не догадался....
300 гигов сливать в хранилища...
Решение сделал проще и быстрее...

Ага
Счастливый Вы человек Volochkova, до сих пор живете в мире фантомов :).
Распостраните Вашу концепцию "жизнь без блокировок" на 100 конкурентых пользователей.

В Вашем варианте в последовательность выполнения с уровнем изоляции read uncommitted (привожу так любимый Вами T-SQL):

Код: plaintext

1.
2.
3.
4.
5.

Клиент  1 : begin transaction 
Клиент  1 : delete  from InventStoc  
Клиент  2 : select @qty=sum(quantity) from InventStoc  Where id_item='zuzu'
Клиент  1 : rollback transaction
Клиент  2 : if @qty= begin delete from  item where id_item='zuzu' end

...

Рейтинг:

0 / 0

27.05.2009, 10:35

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36009805

Volochkova

Участник

Сообщения: 1 704

Рейтинг: 0 / 0

2belugin4

Ну и что Вы тут показали?
Можно перевести на просто язык?

2009 Аксапта это X++ с генерацией TSQL кода???? Не может быть!!! не верю!!!!

Я же это искал и не нашел в 3,5... а мне так объясняли что я лошарик.. Что Акспата это круто...
И что я слаще морковки ничего не пробовал :-)))

Ну и чем отличается X++ & T-SQL VS C# & T-SQL?
Если отбросить понты маркетинговые?

...

Рейтинг:

0 / 0

27.05.2009, 10:38

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36009853

iscrafm

Участник

Сообщения: 34 277

Рейтинг: 0 / 0

АгаСчастливый Вы человек Volochkova, до сих пор живете в мире фантомов :).
Распостраните Вашу концепцию "жизнь без блокировок" на 100 конкурентых пользователей.
....
В Вашем варианте в последовательность выполнения с уровнем изоляции read uncommitted...
Засим откланиваюсь, уверен автор топика сделал для себя выводы. Уважаемой Волочковой хочу пожелать немного подучить матчасть на первом сверху форуме.
А где Волочкова говорила о таком уровне изоляции?
Советчики учить матчасть, почему-то, придумывают "от себя" какие-то левые ситуации, потом объяснения этой глупости, а потом гордо откланиваются. Модель поведения получше, чем модель общения с СУБД, несомненно.

...

Рейтинг:

0 / 0

27.05.2009, 10:49

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36009909

belugin4

Гость

VolochkovaНу и чем отличается X++ & T-SQL VS C# & T-SQL?
Если отбросить понты маркетинговые?

Такие штуки используются очень редко.

Это как раньше ассемблерные вставки делали я ЯВУ.

Чем отличается прорамма на паскале с ассемблерными вставками от программы полностью на ассемблере.

...

Рейтинг:

0 / 0

27.05.2009, 11:04

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36009962

iscrafm

Участник

Сообщения: 34 277

Рейтинг: 0 / 0

прочитал статью про IMTS (Дениса Федотенко). Странно, что в 2009 году заговорили о классическом (шаблонном) механизме складских транзакций, да еще и название ему придумали.

...

Рейтинг:

0 / 0

27.05.2009, 11:17

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36009964

iscrafm

Участник

Сообщения: 34 277

Рейтинг: 0 / 0

2007.. опечатка

...

Рейтинг:

0 / 0

27.05.2009, 11:18

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36009965

Volochkova

Участник

Сообщения: 1 704

Рейтинг: 0 / 0

belugin4VolochkovaНу и чем отличается X++ & T-SQL VS C# & T-SQL?
Если отбросить понты маркетинговые?

Такие штуки используются очень редко.

Это или от безысходности.. Или кого то в разработке жутко достал маразм :-)))
Кстати код, приведенный Вами, работал бы быстрее, загрузив сначала под запрос в tmp табличку.

...

Рейтинг:

0 / 0

27.05.2009, 11:18

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36009973

Volochkova

Участник

Сообщения: 1 704

Рейтинг: 0 / 0

iscrafmАгаСчастливый Вы человек Volochkova, до сих пор живете в мире фантомов :).
Распостраните Вашу концепцию "жизнь без блокировок" на 100 конкурентых пользователей.
....
В Вашем варианте в последовательность выполнения с уровнем изоляции read uncommitted...
Засим откланиваюсь, уверен автор топика сделал для себя выводы. Уважаемой Волочковой хочу пожелать немного подучить матчасть на первом сверху форуме.
А где Волочкова говорила о таком уровне изоляции?
Советчики учить матчасть, почему-то, придумывают "от себя" какие-то левые ситуации, потом объяснения этой глупости, а потом гордо откланиваются. Модель поведения получше, чем модель общения с СУБД, несомненно.

Там не левая ситуация, а фантомная... ну пришел чел с другого измерения, с кем не бывает :-)

...

Рейтинг:

0 / 0

27.05.2009, 11:20

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36009979

belugin4

Гость

iscrafm1. не пойму зачем мне описание механизма работы транзакций.

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

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

В статье Федотенко, по которой задается вопрос облсуждаются просто блокировки.
Написано что в версии 4 они блокировнны на минимальное время.
Волочкова спросил зачем блокировать вообще.
Я ответил.

Еще раз: начиная с версии 4 остатки обновляются одним SQL запросом, который я приводил выше. Разумеется в ходе выполнения этого запроса они блокируются, потому, что при обновлении данных всегда происходит блокировка до конца транзакции.

beluginВ Ax2009 обновление остатков делается одним простым SQL запросом на транзакцию непосредственно перед коммитом
долгая дорога в дюнах.

В 4 то же самое.

...

Рейтинг:

0 / 0

27.05.2009, 11:21

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36009989

iscrafm

Участник

Сообщения: 34 277

Рейтинг: 0 / 0

belugin4,

понятно, спасибо. Удивляет только то, что до AX4 разработчики не знали что-ли элементарных шаблонов проектирования?

...

Рейтинг:

0 / 0

27.05.2009, 11:23

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36009991

belugin4

Гость

VolochkovaЭто или от безысходности..

От того, что update_recordset не поддерживает case.

...

Рейтинг:

0 / 0

27.05.2009, 11:24

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36010242

Volochkova

Участник

Сообщения: 1 704

Рейтинг: 0 / 0

belugin4iscrafm1. не пойму зачем мне описание механизма работы транзакций.

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

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

В статье Федотенко, по которой задается вопрос облсуждаются просто блокировки.
Написано что в версии 4 они блокировнны на минимальное время.
Волочкова спросил зачем блокировать вообще.
Я ответил.

Еще раз: начиная с версии 4 остатки обновляются одним SQL запросом, который я приводил выше. Разумеется в ходе выполнения этого запроса они блокируются, потому, что при обновлении данных всегда происходит блокировка до конца транзакции.

beluginВ Ax2009 обновление остатков делается одним простым SQL запросом на транзакцию непосредственно перед коммитом
долгая дорога в дюнах.

В 4 то же самое.

Это минимальное время умножается на цикл - кол-ва записей в купе с блокировками прорастает просто гроздью проблем...

И обсуждались Блокировки, т.к. товар могут списать, а его надо откатывать..
Вот чего понять не могу...
Зачем вставлять записи в регистр, для общего доступа, а пото их проверять.. Это же приход - голый Insert и все.
Проверки должны быть перед приходом...

А вот в расходе картинка ИНАЯ. Но презентация просто расписывается в беспомощности МС и Аксапты.

...

Рейтинг:

0 / 0

27.05.2009, 12:31

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36010255

Volochkova

Участник

Сообщения: 1 704

Рейтинг: 0 / 0

belugin4VolochkovaЭто или от безысходности..

От того, что update_recordset не поддерживает case.

Угадал.

VivernaVolochkova9. Кубы, Аксижен.. Якобы панацея, но сделаны тоже ректально. Учитывая что он берет данные с боевой базы, которая вся в блокировках.. то через год считать кубы уже просто невозможно.
Аха! Раз Аксижн - значит все таки Корус Ретайл :) Интересно какой версии.

Учитывая что он берет данные с боевой базы - а вы не пробовали настроить, чтобы он брал данные из хранилища? А хранилище часа так в 3 ночи обновлялось. И никаких вам блокировок.

Рецепт нужен? Могу поделится...

...

Рейтинг:

0 / 0

27.05.2009, 12:34

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36010395

belugin4

Гость

iscrafmbelugin4,

понятно, спасибо. Удивляет только то, что до AX4 разработчики не знали что-ли элементарных шаблонов проектирования?

Я точно не знаю, Ax4 это был первый релиз от Microsoft после поглощения Navision.

Кстати, какое название у этого шаблона проектирования?

...

Рейтинг:

0 / 0

27.05.2009, 13:12

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36010689

iscrafm

Участник

Сообщения: 34 277

Рейтинг: 0 / 0

belugin4
Кстати, какое название у этого шаблона проектирования?
не помню, давно это было. Может у него вообще нет названия. Описание того, что я применяю обзорно здесь . Без деталей, только как паттерн. Операция при которой остатки блокируются там в конце (Типовой вариант).

...

Рейтинг:

0 / 0

27.05.2009, 14:19

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36011113

Viverna

Гость

...

Рейтинг:

0 / 0

27.05.2009, 15:57

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36012209

Volochkova

Участник

Сообщения: 1 704

Рейтинг: 0 / 0

Viverna
Поделитесь - очень интересно!

Безвозмездно, т.е. даром. :-)
Выстраданный вариант..

Далее курю, как сделать DIFF AXISION, что бы пересчитывать не все данные , а только последний год. Тогда время не 6 часов, а уже 1,5.

...

Рейтинг:

0 / 0

28.05.2009, 02:49

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36012804

Viverna

Гость

Volochkova, посмотрела ваш "рецепт". Ощущение, что изобретаете велосипед. К примеру чем ваша база AxisionTmp - отличается от того же хранилища Axcision - вы же так же перезакачиваете данные в нее.

К слову будет сказано, Axcision сам способен осуществлять "инкрементальную" закачку данных в хранилище, т.е. не все 100% записей, а только удалять удалённые, добавлять новые и изменять изменённые строки

Только для этого надо, чтобы все таблицы, из которых берутся данные имели поля CreatedDate, CreatedTime, ModifiedDate и ModifiedTime
Если, хотя бы у одной из участвующих в объединении таблиц этих полей не будет - алгоритм не используется, происходит 100% закачка данных. (Проверить это можно просмотрев сообщения в Журнале процессов).

Однако на "сложных" фактах (объединяется много таблиц, с множеством условий и т.д.) инкрементальное обновление может и не дать выйгрыша в производительности - т.к. чудес не бывает и сначала нужно найти все добавленные записи, а для этого нужно выполнить по сути весь SQL запрос, формирующий таблицу фактов куба, но с фильтром по дате и времени создания записи и потом уже скопировать их в хранилище. Аналогично для изменённых и потом ещё и для удалённых записей. Выигрыш в меньшем копировании данных из БД в хранилище может быть потерян за выполнением "подготовительных" запросов к БД (для выборки нужных записей).

Контраргумент в защиту Axcision - произвести обновление хранилища "вручную":
У вас те же два варианта - либо закачать по новой все записи из БД в хранилище,
либо выбирать новые, изменённые, удалённые в БД и производить нужные изменения с хранилищем.
+ как вариант, настроить репликацию между БД и хранилищем

При любом варианте:
- не думаю, что это получится существенно быстрее Axcision;
- данные всё равно будут браться с "боевой БД, котрая вся в блокировках" (А откуда же их ещё брать??) -> не запускайте обновление днём, в часы, когда работают все пользователи, общепринятой практикой является ночное обновление
+ можно использовать режим Хранилища данных, чтобы свести время перекачки данных из БД в хранилище к минимуму (одномоментная закачка всех нужных исходных данных в промежёточное хранилище, с уже последующей их обработкой) (для этого, собственно, этот режим и существует)
+ если не включена, то нужно обязательно включить, а если включена, то не помешает периодическое обновление вручную статистики на рабочей БД (UPDATE STATISTICS.....). Работать сразу же начинает ВСЁ быстрее
+ можно проанализировать запросы, создаваемые при построении таблицы факта куба (в Журнале процессов) и создать дополнительные индексы в БД

Обвинять Axcision, в том, что мы вот запустили обновление кубов и пользователи Axapta все затормозились, по крайней мере смешно. Ведь никому же не приходит в голову начать массированную закачку данных (измеряемую гигабайтами) куда-нибудь из рабочей базы данных в рабочее время (средствами DTS/SSIS)?

P.S. Кстати вышла новая версия Axcision поддерживающая MS AS 2005. Может и поможет для ваших объемов.

...

Рейтинг:

0 / 0

28.05.2009, 12:06

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36014729

Volochkova

Участник

Сообщения: 1 704

Рейтинг: 0 / 0

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

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

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

Теперь третья нота :-)))

VivernaVolochkova, посмотрела ваш "рецепт". Ощущение, что изобретаете велосипед. К примеру чем ваша база AxisionTmp - отличается от того же хранилища Axcision - вы же так же перезакачиваете данные в нее.

К слову будет сказано, Axcision сам способен осуществлять "инкрементальную" закачку данных в хранилище, т.е. не все 100% записей, а только удалять удалённые, добавлять новые и изменять изменённые строки

Только для этого надо, чтобы все таблицы, из которых берутся данные имели поля CreatedDate, CreatedTime, ModifiedDate и ModifiedTime
Если, хотя бы у одной из участвующих в объединении таблиц этих полей не будет - алгоритм не используется, происходит 100% закачка данных. (Проверить это можно просмотрев сообщения в Журнале процессов).

Однако на "сложных" фактах (объединяется много таблиц, с множеством условий и т.д.) инкрементальное обновление может и не дать выйгрыша в производительности - т.к. чудес не бывает и сначала нужно найти все добавленные записи, а для этого нужно выполнить по сути весь SQL запрос, формирующий таблицу фактов куба, но с фильтром по дате и времени создания записи и потом уже скопировать их в хранилище. Аналогично для изменённых и потом ещё и для удалённых записей. Выигрыш в меньшем копировании данных из БД в хранилище может быть потерян за выполнением "подготовительных" запросов к БД (для выборки нужных записей).

Видал я это.... "инкрементальную" закачку
А что происходит по факту??

Код: plaintext

1.
2.

Truncate table - 
Insert into

Вот и вся "инкрементальная" закачка.. Так что лисапед рулит.

Viverna
Контраргумент в защиту Axcision - произвести обновление хранилища "вручную":
У вас те же два варианта - либо закачать по новой все записи из БД в хранилище,
либо выбирать новые, изменённые, удалённые в БД и производить нужные изменения с хранилищем.
+ как вариант, настроить репликацию между БД и хранилищем

У меня один вариант... если пересчитывается всё, то пересчитывать всё :-)

Viverna
При любом варианте:
- не думаю, что это получится существенно быстрее Axcision;
- данные всё равно будут браться с "боевой БД, котрая вся в блокировках" (А откуда же их ещё брать??) -> не запускайте обновление днём, в часы, когда работают все пользователи, общепринятой практикой является ночное обновление
+ можно использовать режим Хранилища данных, чтобы свести время перекачки данных из БД в хранилище к минимуму (одномоментная закачка всех нужных исходных данных в промежёточное хранилище, с уже последующей их обработкой) (для этого, собственно, этот режим и существует)
+ если не включена, то нужно обязательно включить, а если включена, то не помешает периодическое обновление вручную статистики на рабочей БД (UPDATE STATISTICS.....). Работать сразу же начинает ВСЁ быстрее
+ можно проанализировать запросы, создаваемые при построении таблицы факта куба (в Журнале процессов) и создать дополнительные индексы в БД

Делается... и обновление и реиндекс, где фрагментация сильная....
и ночью запускается... И по джобам, которые лезут через COM объекты....
и через саму Аксапту...
Эффект.. авно.....
20 часов если запустить НОЧЬЮ.... и база в дауне....

Посему???? Мало того что не иннер джоины, а перечисления таблиц в запросах, так еще и через линк сервер.. Т.е. запрос выполняется на сервере Аксижена, притянув туда по ГИГАБИТКЕ ГИГАБАЙТЫ с боевой базы... Где не поставишь даже NOLOCK, что бы хоть как то снять блокировку.
А еще ночью, надо продажи разнести..

Viverna
Обвинять Axcision, в том, что мы вот запустили обновление кубов и пользователи Axapta все затормозились, по крайней мере смешно. Ведь никому же не приходит в голову начать массированную закачку данных (измеряемую гигабайтами) куда-нибудь из рабочей базы данных в рабочее время (средствами DTS/SSIS)?

P.S. Кстати вышла новая версия Axcision поддерживающая MS AS 2005. Может и поможет для ваших объемов.

Это не смешно, читайте еще раз... НОЧЬЮ!!! НИКОГО НЕТ!!!! Получается МЕДЛЕННО!!! ОСЕНЬ :-)
Проблема не в объемах, а методах, технологиях.
Мне надо что бы работало, шустро, я этого добился.

Не поверишь... Это лисапед.. Аксижена.. был применен к новой отчетности.. ночью.. вытаскиваю все таблички, которые мне нужны с полями необходимыми для расчета.... Invnettrans, Inventtable т.д. ( 30 минут) потом среди бела дня.. ( правда пока раз в неделю) тажу на соседний сервер DTS-ом... База как страдала, так и страдает....

А уже на соседнем сервере, отчетность бегает как заведенная...
Через нормальные хранимки... и чистый T-SQL...
Отчеты считаются шустро, быстро... никого не лочат... база занимает копейки...
Пока не хватает времени, что бы заменить varchar на Int.. .тогда скорости вообще буду космические...

Вообщем.. если сие по скоростям буде не айс...
Ну значит не айс..

Но у меня сейчас время расчета сократилось минимум в 2 раза...
За ночь, успеваем все посчитать.
Лишние прокладки выкинул.
И рецепт, то какой? Если тормоза и надо, хоть что то сделать... то вперед..
А покупка новой версии, или переход на 2005 при такой же сохранении старых принципов.. веры в меня не всиляет..

...

Рейтинг:

0 / 0

29.05.2009, 04:09

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36015682

IgorK

Участник

Откуда: Краснодар

Сообщения: 426

Рейтинг: 0 / 0

Можно я свои 5 копеек вставлю.
Работаем с Аксаптой ~5 лет, база ~100G, активных юзеров - 100-150.
Что могу сказать - то что ядро Косяпты абсолютно неправильно работает с MSSQL - это факт. Вся работа построена на курсорах - sp_createcursor, sp_fetch ну и т.д. ИМХО круче метода чтобы замучить сервер нету. Это касается и 2000 и 2005 - зависы, блокировки и др. неприяности возникали с периодичностью, достойной лучшего применения! Какой выход? Мы его нашли!
Угадайте с 3-х раз какой?...
Oracle! После перевода базы на Oracle 10G практически все проблемы, связанные с производительностью, блокировками и т.д. ушли (тьфу*3)! Уже пол-года - полет нормальный!
При этом!!! Нагрузка на сервер упала НА ПОРЯДОК! (не шучу).
Вот такъ вотъ!

...

Рейтинг:

0 / 0

29.05.2009, 13:43

| Ответить | Цитировать | Написать

Поругайте MS Dynamics AX (AXAPT`У)

#36015765

mista2009

Участник

Сообщения: 267

Рейтинг: 0 / 0

IgorKМожно я свои 5 копеек вставлю.
Работаем с Аксаптой ~5 лет, база ~100G, активных юзеров - 100-150.
Что могу сказать - то что ядро Косяпты абсолютно неправильно работает с MSSQL - это факт. Вся работа построена на курсорах - sp_createcursor, sp_fetch ну и т.д. ИМХО круче метода чтобы замучить сервер нету. Это касается и 2000 и 2005 - зависы, блокировки и др. неприяности возникали с периодичностью, достойной лучшего применения! Какой выход? Мы его нашли!
Угадайте с 3-х раз какой?...
Oracle! После перевода базы на Oracle 10G практически все проблемы, связанные с производительностью, блокировками и т.д. ушли (тьфу*3)! Уже пол-года - полет нормальный!
При этом!!! Нагрузка на сервер упала НА ПОРЯДОК! (не шучу).
Вот такъ вотъ!

Не понял. А что в случае с Oracle 10G sp_createcursor, sp_fetch ну и т.д. не используются или Oracle 10G они по барабану?

...

Рейтинг:

0 / 0

29.05.2009, 14:06

| Ответить | Цитировать | Написать

25 сообщений из 445, страница 12 из 18

все

Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / Поругайте MS Dynamics AX (AXAPT`У)

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=29&msg=36009962&tid=1526681]:	0ms
get settings:	9ms
get forum list:	13ms
check forum access:	4ms
check topic access:	4ms
track hit:	149ms
get topic data:	11ms
get forum data:	3ms
get page messages:	57ms
get tp. blocked users:	1ms
others:	15ms

total:	266ms