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

[Recoilme]

Цитата:

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

P.P.S. с т.зр. производительности - какая разница системе, что в поле DataAreaId пишется?

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

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

[mit]

Цитата:

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

P.P.S. с т.зр. производительности - какая разница системе, что в поле DataAreaId пишется?

э неет! с этим оч. осторожно! с точки зрения производительности то конечно, с переносом там тоже все автоматом происходит, а вот нарушение целостности это получить оч. легко, так как в качестве ссылок нередки случаи использования recId как уникального идентификатора. думаю, что в этом случае легко просто "приплыть" к необъясниым сбоям

[7Up]

Цитата:

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

так у Вас счетчик RecId переполнится в любом случае очень скоро - они из общего пула берутся, никакая "проверка кодов записей" не поможет
- вариант с виртуальными компаниями конечно интересный, хотя и небезгеморройный с точки зрения настройки и переноса данных
- посмотрите на стр. 524 Databases Advanced - там описана возможность генерировать уникальные RecId в пределах таблицы и компании, а не компании. Вариант тоже не без проблем, первая же "проверка кодов записей" эту идиллию порушит, опять же надо что-то делать с существующими данными (ссылки по RecId)

P.S. как представил себе SysDatabaseLog по строкам заказов, которых до 400 тысяч в день - жуть
P.P.S. с т.зр. производительности - какая разница системе, что в поле DataAreaId пишется?

Не понял про стр. 524 Databases Advanced. Можно уточнить что за книжка имеется в виду. Если так можно - эффект будет тот же, только dataareaid меняться не будет.
Про dataareaid - оно первое во всех индексах. Специалистами высказывается опасение, что разные dataAreaId приведут к тормозам.

[Recoilme]

Цитата:

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

Про dataareaid - оно первое во всех индексах. Специалистами высказывается опасение, что разные dataAreaId приведут к тормозам.

Вот и слушайте Ваших специалистов, а не по форумам шляйтесь))

[7Up]

Цитата:

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

Честно говоря я в этом и не сомневался.
Конкретно по вопросу: использовать компании для увеличения времени жизни recid - крайне нерациональная трата ресурсов.

Можете обосновать вашу позицию?
Собственно интересует более рациональный способ. И в чем не рациональность предложенного.

[Recoilme]

Цитата:

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

Можете обосновать вашу позицию?
Собственно интересует более рациональный способ. И в чем не рациональность предложенного.

Обосновываю: засеките время создания/разноски документа с включенным dataareaid и с выключенным dataareaid на сопоставимых объемах.

Рациональный способ (на мой взгляд) я предлагал выше.

[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 и с выключенным dataareaid на сопоставимых объемах.

Рациональный способ (на мой взгляд) я предлагал выше.

Я правильнок понял, что рациональный способ - вынести основную функциональность аксапты во вне. (еще раз подчеркиваю - recid в основном выделяются для стандартных аксаптовских таблиц).

[7Up]

Цитата:

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

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

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

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

[Vadik]

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

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

[Writer]

Господа, если мы с вами пока говорим о теоретическом проекте, то давайте говорить об Axapta 4.0 и 64 битной версии. Тогда recid будет 64 бита и количество записей будет ± 9 223 372 036 854 775 808 вопрос будет снят с повестки дня

[db]

Цитата:

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

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

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

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

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

[7Up]

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

[Recoilme]

Цитата:

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

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

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

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

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

[Recoilme]

Цитата:

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

Я правильнок понял, что рациональный способ - вынести основную функциональность аксапты во вне. (еще раз подчеркиваю - recid в основном выделяются для стандартных аксаптовских таблиц).

Нет, я писал по поводу функциональности "жрущей" recid. Например сводное планирование создает reqtrans. По сути это временная таблица. Она "жрет" recid вхолостую. Вынесите этот функционал во вне и съэкономите. Как кончится recid - придется резать базу. Переносить остатки и т.п.
В любом случае проблемы с производительностью начнутся не сразу после запуска. Главное здесь - успеть подписать акт))

[Михаил Андреев]

Цитата:

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

до 400 тыс строк заказов в день. Все остальное пропорциоанально.
ЛОги на все основные таблички.

Любопытно, откуда возьмутся эти поллимона строк? Кто их набьёт? Если люди, то их не менее 1-2 тыс. должно быть. И зачем логи на все основные таблицы?
Напоминает анекдот про бензопилу и суровых сибирских мужиков.
Либо дерево не то, либо инструмент не тот.
При таком объёме дублирование RecId - мелочь по сравнению с кучей других проблем. Как вы склад закрывать собираетесь? А сводное планирование как будет работать? И как одновременно тысяча человек будут работать с одними и теми же таблицами, взаимными блокировками и т.п.?
Чисто гипотетически:
1. Создание виртуальных компаний проблему RecId вряд ли решит. Да и ни к чему её таким образом решать: реально важно отсутствие дублирования RecId в одной компании одной таблицы.
2. Убирание dataareaid тоже вряд ли даст эффект в проблеме RecId. Не думаю, что эффект по производительности будет очень существенен: в большинстве таблиц индексы строятся с его учётом, а базы данных очень хорошо умеют сами оптимизировать запросы. Поэтому, на мой взгляд, гораздо эффективнее построить администратора базы данных, чем убрать dataareaid.

[Vadik]

Цитата:

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

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

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

[glibs]

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

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

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

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

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

[7Up]

Цитата:

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

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

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

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

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