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

[Vadik]

Ничего не имею против NODATAAREAID, однако хотел бы предложить вернуться к обсуждению проблемы генерации RecId в системе с 400000 строками заказов в день. Правда, проблема оказалась виртуальной , но осталась интересной (по крайней мере, до выхода четверки), и NODATAAREAID ее вроде как не решает (насколько я понимаю). Бенчмаркинг с т.зр. влияния NODATAAREAID разумеется проведу - на каких документах, из скольких проводок и на каких объемах? Ну и Ваши результаты само собой интересно было бы увидеть, чтобы знать, к чему стремиться

P.S. И, раз уж пошла такая пьянка, предпочел бы вместо NODATAAREAID отключить SaveDataPerCompany на "больших" таблицах в AOT. Надежнее как-то

[Recoilme]

Цитата:

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

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

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

Резюме надо составлять при таких объемах, а не по форуму писать))

Засим теоретическую часть обсуждения аксапты на 400000 строк продаж предлагаю закрыть.
Желающие могут засечь время создания и разноски заказа на 200 строк, умножить на 2000 , мыслено представить блокировки,24 на 6 и прочие прелести. Людям с развитым воображением лучше поберечь здоровье и не представлять))

[7Up]

Цитата:

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

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

Резюме надо составлять при таких объемах, а не по форуму писать))

Засим теоретическую часть обсуждения аксапты на 400000 строк продаж предлагаю закрыть.
Желающие могут засечь время создания и разноски заказа на 200 строк, умножить на 2000 , мыслено представить блокировки,24 на 6 и прочие прелести. Людям с развитым воображением лучше поберечь здоровье и не представлять))

Финансовая разноска до 2000 строк в минуту - итого 400тыс строк за 4-8 часов.
Сервер БД IBM 460 с одной стойкой, БД-Oracle. Единственное но: базенка всего 30 Гб.
В целом понимаю предыдущего оратора. Рассматриваемые объемы велики для аксапты.
Да, аосы - 3 штуки 2-х процессорные.

[Writer]

Цитата:

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

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

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

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

[Recoilme]

Цитата:

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

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

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

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

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

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

[7Up]

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

[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 в индекс, соответственно, можно самому определять порядок. Параметр не влияет на прочие индексы.

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

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