Проблема производительности при использовании виртуальных компаний.

[7Up]

Цитата:

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

Полностью согласен с участником Михаил Андреев.

Не с того конца проблемы ищете.

И что у вас за компания (чем конкретно занимаетесь)? Склько человек там сидит на вводе только одних заказов?

Офис у вас один? А складское помещение у вас тоже одно?

Неужели нельзя разделить на несколько компаний?

Народу сидит относительно не много, компанию и сферу деятельности называть не буду. Заказы генерятся по шаблонам, а затем редактируются пользователями. Естественно индивидуальный подход к клиенту весьма ограничен, а менеджер должен обеспечить определенные итоговые параметры. Логи нужны для выяснения истории возникших проблем (отгрузили не то, не тому и т.д.) и виновных.
Разумеется recId не самый главный вопрос, но данная тема посвящена именно ему.

[Writer]

Цитата:

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

Хорошо. Давйте вернемся ))
Допустим завтра к Вам приходят и говорят, через месяц у нас в аксапте будет до 400 000 строк заказов в день. Т.е. 2000 заказов по 200 строк.
Знаете что я посоветую? Подумать о количестве записей? 64 битный ключ на 4 аксапте? Нет! Я посоветую подумать о смене работы))

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

ЗЫ Ждем официальных тестов от Майкорсофт по производительности Ax 4.0 в сравнении с 3.0

[Writer]

Цитата:

Сообщение от 7Up

Логи нужны для выяснения истории возникших проблем (отгрузили не то, не тому и т.д.) и виновных.

А зачем вам все логи в данном случае. Включите на таблицах аудит записи кто создал, кто модифицировал. Логами отслеживайте только ключевые моменты. Опыт показывает, что 90% процентов всех вопросов можно решить с помощью аудита записи и выстроенного бизнес-процесса по сферам ответственности.

[ziva]

Цитата:

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

Почитать можно в документе, полное название - "Microsoft® Business Solutions-
Axapta® V3.0 Databases Advanced".
Выглядит настройка незатейливо - взводится флаг (бит) 64 в поле VALUE записи INDEX в SQLSYSTEMVARIABLES

Не все так просто под луной. Когда устанавливаете данный флаг и перезаходите в Axapta, RecId действительно выбираются для определенной таблицы, примерно вот так:
SELECT NEXTVAL FROM SYSTEMSEQUENCES WHERE DATAAREAID = 'dat' AND
ID = -1 AND TABLID = 33
а вот когда происходит следующий оператор обновления последовательности, то этого не происходит:
UPDATE SYSTEMSEQUENCES SET NEXTVAL = 12322 WHERE DATAAREAID = 'dat' AND ID = ... AND TABLID = 0

Вот и получается что эта "фича" не работает. После продолжительных переговоров с поддержкой MBS выяснилось что это "by design" и соответственно корректную работу данной функциональности никто не обещал.

По результатам телефонного митинга с John McBride (менеджер команды разработки) и Mathieu Kemenovic (глобальная служба поддержки) мне подтвердили что они ничего менять в 3.0 не будут (и даже не будут делать private hot-fix) и предоставлили набор SQL-скриптов, которые ищут большие "дырки" последовательности идентификаторов записей и используют их. Данные скрипты неавтоматические и необходимо выполнять ряд шаманских танцев с бубнами...

Кроме того, если у Вас действительно имеются проблемы с нехваткой RecId и это является ну очень-очень критичным для бизнеса, единственным приемлимым вариантом решения проблемы является переход на 4ку. Поскольку для Вас это вынужденное обновление, то представляется вероятным получение от Microsoft каких-либо benefits. Каких? Тут все зависит от Вас. Сами понимаете, что Microsoft-у не нужен негативный отклик на рынке по причине отказа крупного клиента от Axapta.

[Recoilme]

Цитата:

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

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

ЗЫ Ждем официальных тестов от Майкорсофт по производительности Ax 4.0 в сравнении с 3.0

Я не стал бы завязываться на Аксапту на таких объемах независимо от результатов официальных тестов от Майкорсофт по производительности. Естественно это моё ИМХО. В конце-концов если у кого-то много лишних денег - вай нот?

Вся эта ветка честно говоря все больше напоминает фарс. Какие то роботопользователи долбят 2000 заказов.. по каким-то шаблонам.. в какой-то тайной компании..
Я ничего не понимаю уже.

2 7up: Успехов Вам вобщем.

[7Up]

2 ziva. Она работает несколько иначе - когда кончается выделенный пул номеров для таблицы, она перещелкивает следующий номер для всех таблиц. Что действительно делает эту настройку бессмысленной.

[ziva]

Прошу прощения за оффтопик:

Цитата:

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

... если у Вас действительно имеются проблемы с нехваткой RecId ...

Возвращаясь к теме...

Цитата:

Сообщение от 7Up

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

Это самое простое и быстрое решение, которое позволит оттянуть "конец" Аксапты на вашем предприятии.
На производительность никак не повлияет (ядро вместо одного кода компании будет просто подставлять другой).

[ziva]

Цитата:

Сообщение от 7Up

2 ziva. Она работает несколько иначе - когда кончается выделенный пул номеров для таблицы, она перещелкивает следующий номер для всех таблиц. Что действительно делает эту настройку бессмысленной.

Действительно, опетатался.

Ядро посылает вот примерно такой запрос при обновлении последовательности:
UPDATE SYSTEMSEQUENCES SET NEXTVAL = 12322 WHERE DATAAREAID = 'dat' AND ID = -1
т.е. БЕЗ указания TABLID, а значит обновляются все записи.

[raz]

http://blogs.msdn.com/aeremenk/archi...14/825247.aspx

Цитата:

Saturday, October 14, 2006 6:19 PM by aeremenk
Порядок полей в индексе для DAX 3.0
Все время забываю записать, что есть параметр для конфигурационной утилиты, позволяющий допускать изменение полей в индексе.

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

Параметр должен быть указан в поле Advanced конфигурационной утилиты:

-internal=CROSSCOMPANY

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

Применять осторожно, тестировать в любом случае.

Есть ли клиенты, использующие данный параметр длительное время? Есть, я знаю как минимум одного, но не в России.

[Dron AKA andy]

В блоге комментариев нет; может, здесь кто прокомментирует, как это дело работает. Пробовал запускать систему с указанным параметром - видимых изменений не обнаружил. Ожидал увидеть чуть ли не поле dataareaId в явном виде во всех уже созданных индексах, ан нет. Хотя, фразу "Параметр не влияет на прочие индексы" можно понять и как уничтожающую мое предположение...

[Delfins]

Dron AKA andy, помоему имелось ввиду, что если ты добавишь сам поле в индекс, то сможешь поменять позицию.. По дефолту оно первое идет, как скрытое (если таблица c SaveDataPerCompany )

[Garic]

Цитата:

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

Почитать можно в документе, полное название - "Microsoft® Business Solutions-Axapta® V3.0 Databases Advanced".

А где его можно взять?
Что-то не нашёл на parnerSource.