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

[7Up]

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

[mit]

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

[7Up]

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

[mit]

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

[7Up]

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

[mit]

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

[Vadik]

Цитата:

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

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

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

[Recoilme]

Цитата:

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

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

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

[7Up]

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

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

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

[7Up]

Цитата:

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

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

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

[mit]

Цитата:

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

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

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

[Recoilme]

Цитата:

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

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

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

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

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

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

[7Up]

Цитата:

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

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

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

[mit]

Цитата:

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

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

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

[7Up]

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

[Recoilme]

Цитата:

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

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

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

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

[7Up]

Цитата:

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

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

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

Проект в стадии разработки. Все цифры оценочные. На мой взгляд правильнее решать проблемы до того, как они появятся.
Из имеющихся цифр следует, что одна из проблем будет с recid. Отсюда и родился этот вопрос.

[mit]

это в разработке и уже 500 гиг?
с виртуальными компаниями точно не решение. в таком случае придется писать процедуру дефрагментации на t-sql и трогать только нужные таблицы

[Vadik]

Цитата:

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

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

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

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

[Recoilme]

Цитата:

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

Проект в стадии разработки. Все цифры оценочные. На мой взгляд правильнее решать проблемы до того, как они появятся.
Из имеющихся цифр следует, что одна из проблем будет с recid. Отсюда и родился этот вопрос.

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