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

[7Up]

Есть проблема: количество создаваемых записей в системе настолько велико, что recId кончатся довольно быстро. Хотелось бы этого избежать. Предлагается: разнести таблички с большим количеством записей по разным виртуальным компаниям. Разносить планируем: salesLine, wmsJournalTrans, custInvoiceTrans, sysDataBaseLog, salesParmLine возможно inventTrans ну и собственные таблички, которые активно потребляют recId. Эта мера позволит в несколько раз уменьшить скорость выделения recId и соответственно продлить жизнь компании до приемлемого срока.
Возникло опасение, что использование виртуальных компаний приведет к ухудшению производительности. Хотелось бы услышать мнение опытных людей по этому вопросу.

[mit]

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

[7Up]

Такой функционал есть, но, на большом объеме данных
это будет работать не шустро, а время ограничено.

[mit]

ну, это будет работать долго, если запускать редко, а если запускать чаще, то быстрее.

[7Up]

Расчетный объем базы ~500 Gb. Было бы приемлемо, если дефрагментация проходила за 1-2 суток.
На мой взгляд сие сомнительно.
Регулярная дефрагментация - должна гарантированно укладываться в сутки. Организация работает 24*6.

[Vadik]

Цитата:

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

Разносить планируем: salesLine, wmsJournalTrans, custInvoiceTrans, sysDataBaseLog, salesParmLine возможно inventTrans ну и собственные таблички, которые активно потребляют recId
..
Расчетный объем базы ~500 Gb

Не поделитесь средним количеством новых записей по SalesLine, CustInvoiceTrans, InventTrans в неделю (хотя бы порядок)? Жутко интересно

[mit]

не, думаю сутки - раз в неделю реально

[7Up]

Цитата:

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

не, думаю сутки - раз в неделю реально

На какой платформе с каким оборудованием?

[Recoilme]

Цитата:

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

Есть проблема: количество создаваемых записей в системе настолько велико, что recId кончатся довольно быстро. Хотелось бы этого избежать.
...
Хотелось бы услышать мнение опытных людей по этому вопросу.

Попробуйте вынести во внешние программы особо жрущие recid алгоритмы. Мы например перенесли среднедневные остатки и ещё часть "прожорливых" алгоритмов из аксапты и оттянули время "Ч" на пару лет. Если припечет - Сводное планирование полностью из системы вынесем, ещё съэкономим годик ))

[7Up]

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

2 mit. Сутки - имеется в виду время работы процедуры, а не периодичность.

2 recoilme. Можно все вынести. Зачем тогда аксапта.

[mit]

Цитата:

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

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

в таком случае, может и не потянуть. но в любом случае нужно тестировать. а если Вы перенесете в витруальные компании свои таблицы, recid все равно кончатся. придется заводить новую компанию, тогда нелостность нарушается. вся фишка в уникальности. поправьте меня

[7Up]

Цитата:

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

в таком случае, может и не потянуть. но в любом случае нужно тестировать. а если Вы перенесете в витруальные компании свои таблицы, recid все равно кончатся. придется заводить новую компанию, тогда нелостность нарушается. вся фишка в уникальности. поправьте меня

По оценке recid кончатся через полгода-год, что неприемлемо. Виртуальные компании позволяют увеличить срок до 2-3 лет. После этого при таких объемах все равно придется переливать в новую компанию начальные остатки и начинать снова, иначе система загнется.

[mit]

Цитата:

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

По оценке recid кончатся через полгода-год, что неприемлемо. Виртуальные компании позволяют увеличить срок до 2-3 лет. После этого при таких объемах все равно придется переливать в новую компанию начальные остатки и начинать снова, иначе система загнется.

а какая история? сколько лет? какая версия?

[Recoilme]

Цитата:

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

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

2 mit. Сутки - имеется в виду время работы процедуры, а не периодичность.

2 recoilme. Можно все вынести. Зачем тогда аксапта.

Слишком много. Или что-то путаете. Или Вы провакатор-конкурент, зашли поиздеваться.

Расскажите в каой отрасли пол лимона в день строк продаж?? М.б. Вы ... строки чеков запихать в старушку хотите????? Нельзя впихать невпихуемое!

[7Up]

Порядка 1000 клиентво, ассортимент до нескольких тыс. единиц. Ежедневные отгрузки до 200 единиц товара в среднем. И не только отгрузки, а много еще чего.

[Recoilme]

Цитата:

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

Порядка 1000 клиентво, ассортимент до нескольких тыс. единиц. Ежедневные отгрузки до 200 единиц товара в среднем. И не только отгрузки, а много еще чего.

Нельзя ли из обозревателя таблицы выполнить запрос и сообщить его результаты??

SELECT count(recid) FROM CustInvoiceTrans where CustInvoiceTrans.invoicedate==20\07\2006

[Vadik]

Цитата:

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

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

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

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

[Recoilme]

Цитата:

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

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

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

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

[7Up]

Цитата:

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

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

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

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

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

[mit]

Цитата:

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

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

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