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

[7Up]

Цитата:

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

Если буквально и в двух словах : "Пипец производительности"

Конечно я говорю о разнице - в использовании поля DataAreaId (его нет, включен ключ nodataareaid) и когда оно есть и используется во всех индексах напропалую, а не о том случае - писать туда "DAT" или хрень какую ещё

select * from table1 where table1.dataareaId == "dat"
join * from table2 where table2.dataareaId == "vir"

что помешает БД использовать правильные индексы?

[Recoilme]

Цитата:

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

select * from table1 where table1.dataareaId == "dat"
join * from table2 where table2.dataareaId == "vir"

что помешает БД использовать правильные индексы?

Ещё раз: ОТКЛЮЧЕНИЕ DATAAREAID ДАСТ ОФИГЕННЫЙ ВЫИГРЫШ ПО ПРОИЗВОДИТЕЛЬНОСТИ
Ключевое слово: NODATAAREAID

Не будет этого поля там "dataareaId ". Совсем не будет.

[7Up]

Цитата:

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

Ещё раз: ОТКЛЮЧЕНИЕ DATAAREAID ДАСТ ОФИГЕННЫЙ ВЫИГРЫШ ПО ПРОИЗВОДИТЕЛЬНОСТИ
Ключевое слово: NODATAAREAID

Не будет этого поля там "dataareaId ". Совсем не будет.

NODATAAREAID - имеется в виду SaveDataPerCompany = No?

[db]

Цитата:

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

NODATAAREAID - имеется в виду SaveDataPerCompany = No?

Эта картинка как отключить в конф утилите. Такой же параметр есть и в настройка аоса. Делать надо на базе, в которой только одна компания - DAT. Естественно надо отсинхронизировать базу после запуска с таким ключом. Поле DataAreaId испарится из всех таблиц и индексов

По поводу опасений использования данной возможности - по крайней мере три очень нехилые розничные сети работают несколько лет с таким ключиком. Версии 3.0 от без СП до KR1. Проблем никаких.

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

[7Up]

2 vadic. Все-таки насчет настройки выделения recId для отдельных таблиц не могли бы вы уточнить как именно это можно настроить или где посмотреть.
Если вдруг волшебный ключ noDataAreaId дает существенное улучшение производительности ваш вариант становится оптимальным.

[Vadik]

Цитата:

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

2 vadic. Все-таки насчет настройки выделения recId для отдельных таблиц не могли бы вы уточнить как именно это можно настроить или где посмотреть

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

[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.

[Garic]

Цитата:

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

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

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

[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. Она работает несколько иначе - когда кончается выделенный пул номеров для таблицы, она перещелкивает следующий номер для всех таблиц. Что действительно делает эту настройку бессмысленной.