А "потянет" ли Axapta такой объем данных ?

[KonSA]

Хочется узнать принципиальную возможность работы Axapta со следующими объемами данных. Контора занимается ночной развозкой продуктов питания с оптового склада в розничные точки. Основной объем обрабатываемой информации составляют заказы на развозку. Статистика примерно следующая:

- отгрузка 364 дня в году (1 янв. выходной :-) )
- в день 1200 заказов
- один заказ в среднем содержит 30 позиций товара + 5 позиций тары
- для учета отгрузки по каждой товарной позиции делаем 3 проводки (себестоимость, реализация, НДС)
- для учета каждой тарной позиции делаем 2 проводки (вешаем тару на клиента и амортизация тары)

итого 356*1200*(30*3+5*2)=43 млн проводок в год
с учетом приходных накладных и всего остального дойдет до 50 млн. в год

алгоритм списания со склада - FIFO по партиям (партия - сертификат качества со сроком годности товара)

количество юзеров 30-35

ситуация осложняется тем, что работа круглосуточная и остановка базы даже на полчаса (например, для "закрытия" склада ) невозможна

Были ли внедрения Axapta с такими объемами ?
Можно ли прикинуть размер базы данных через год работы ?

Буду благодарен за любую информацию.

[AKIS]

Цитата:

Были ли внедрения Axapta с такими объемами ?
Можно ли прикинуть размер базы данных через год работы ?

Здравствуйте.

Внедрения с такими, и даже бОльшими объемами - точно были. За подробными справками и координатами советую обращаться в офис МБС

Насчет объема. Рискну сделать смелое предположение. 15 Гб за год. Чисто эмпирически, доказать затруднюсь...

Внутренний голос мне подсказывает, что вам надо сразу думать про Оракл. Майкрософт такие, и даже бОльшие объемы потянет - но через пару-тройку лет все равно переходить, так что...

Цитата:

ситуация осложняется тем, что работа круглосуточная и остановка базы даже на полчаса (например, для "закрытия" склада ) невозможна

Остановки баз будут, без этого просто никак нельзя. Так что сразу закладывайте кластер с двумя параллельно работающими и взаимно реплицирующимися базами: отвалилась одна, подключилась другая... Хотя ресурсов это у вас потребует ой-ой-ой... Может все ж таки не так все страшно? Я вот насколько знаю, даже в банках, и даже в очень крупных, бывают периоды отключения системы. А критичным считается останов сервера на 2-3 часа, но никак не на 30 минут... А вы все ж таки не банк...
В первое время после старта, во всяком случае, останов возможен очень часто (это из опыта, причем не только и не столько по Аксапте)... Так что продумывайте, что все ж таки будете делать при таких остановах, временные процедуры регистрации заказов и пр...

Цитата:

количество юзеров 30-35

Вот этот момент - самый непонятный в вашем описании. Как такое маленькое количество юзеров справится с таким огромным объемом данных? 1200 заказов в день = 50 заказов в час (при том что работают ровно 24 часа) = почти по заказу в минуту... Т.е 35 новых строчек заказов в минуту, не считая времени на собственно регистрацию шапки заказа... Или это только те юзера, которые непосредственно вбивают заказы - а бухгалтерия, финансы, склад и прочая братия сверх того? Даже в этом случае, получается что каждый юзер каждую минуту суток должен вбивать по одной строчке заказа... Без перерыва на пописать и обед... Даже меняться они у вас должны со скоростью электровеников, секунд за 15... Нереально это.

Рискну сделать предложение: может вам, ребята, как-то внутренне поделить предприятие и соответственно систему: по региональному (одни обслуживают только сибирь, другие только москву и область, третьи поволжье и пр..) или еще какому-нибудь признаку? В том смысле что сделать не одну, а пять-семь систем. Естественно, с увязкой данных, но не в он-лайне а скажем в конце дня. Плюс центральная, консолидирующая система. А то вы ж замаетесь потом с таким монстром... Вы представьте, сколько будет занимать одна операция вынимания базы из бэкапа - пару-тройку часов..

Цитата:

для учета отгрузки по каждой товарной позиции делаем 3 проводки (себестоимость, реализация, НДС)
- для учета каждой тарной позиции делаем 2 проводки (вешаем тару на клиента и амортизация тары)

Опять-таки - надо ли делать проводки по каждой позиции? Может можно как-то их собирать-группировать (аналитика глубже товара у вас вряд ли будет в бухгалтерии)... Все легче будет, глядишь вместо 50 станет 5 миллионов

[mazzy]

Цитата:

Изначально опубликовано KonSA
Хочется узнать принципиальную возможность работы Axapta со следующими объемами данных.

Принципиально да. Дьявол в деталях. См. ниже.

Цитата:

Изначально опубликовано KonSA
итого 356*1200*(30*3+5*2)=43 млн проводок в год
с учетом приходных накладных и всего остального дойдет до 50 млн. в год

стоит еще умножить на 10-20, поскольку каждая проводка может отображаться несколькими записями в разных таблицах.

Тут, конечно надо прикидывать и делать макет, но в вашем случае можно взять оценочную среднуюю длину записи 400 байт.
Получится 50 млн * 10-20 записей * 400 байт= 20..40 Гиг.

Естественно, это ОЧЕНЬ ГРУБАЯ оценка. Почему? В Аксапте многие таблицы носят характер черновиков или логов.

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

Еще пример, заказы - это план. После исполнения (документы) план можно и нужно удалять. Поэтому все заказы со строками тоже можно (и нужно удалять). А тяжелая таблица Строки заказа (Sales Line) имеет среднюю длину больше 500 байт.

Поэтому, если базой не заниматься, то размер будет до 50 гигов. Если базой таки заняться по-правильному, то будет около 10 гигов.

Но в обоих случаях будет работать нормально. Не в этом проблема. А в этом:

Цитата:

Изначально опубликовано KonSA
ситуация осложняется тем, что работа круглосуточная и остановка базы даже на полчаса (например, для "закрытия" склада ) невозможна

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

Да, во время закрытия можно организовать ввод заказов в режиме журнала, но...

Именно момент с регламентными процедурами в Аксапте, скорее всего, будет вашим узким местом.

[mazzy]

В целом согласен с AKIS'ом.

[KonSA]

Спасибо mazzy и AKIS за ответ, честно говоря, не ожидал в праздник после 21 часа. Есть еще непьющие люди в России :-)

Насчет "непоняток" с количеством юзеров проясню. 30-35 - это без операционисток, которые принимают заказы, там специальная программа для call-центра.

С остановками на 30 мин. а неясно выразился. Имелись ввиду не аварийные (незапланированные) остановки, тут контора может пережить остановку на 2-3 часа раз в 2-3 месяца. Я имел ввиду плановые ежедневные, ежемесячные остановки. Отсюда вопрос, нужны ли будут плановые остановки и с какой периодичностью?

Можно ли прикинуть, сколько времени будет составляться отчет по реализации за месяц, если для его составления нужно будет перебрать 7-8 млн. проводок ?

[Тимур]

Скажите, если Вы не закрываете склады, хотя бы поочередно, то как у вас осуществляется инвентаризация??? :о

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

[Vadik]

Цитата:

Изначально опубликовано AKIS
Внутренний голос мне подсказывает, что вам надо сразу думать про Оракл. Майкрософт такие, и даже бОльшие объемы потянет - но через пару-тройку лет все равно переходить, так что...

К своему удивлению, не раз сталкивался на technet с людьми, сознательно или переходящих с оракла на MSSQL, или делающих первоначальный выбор в пользу последнего. Основные причины - стоимость лицензий и сложность администрирования. А через пару-тройку лет (вернее, гораздо раньше) выйдет Yukon - так что время покажет

Цитата:

Изначально опубликовано AKIS
Остановки баз будут, без этого просто никак нельзя. Так что сразу закладывайте кластер с двумя параллельно работающими и взаимно реплицирующимися базами: отвалилась одна, подключилась другая...

как вариант - одна БД для оперативной деятельности и вторая - для аналитической отчетности, связь - репликацией или log shipping

[KonSA]

Цитата:

Изначально опубликовано Тимур
Скажите, если Вы не закрываете склады, хотя бы поочередно, то как у вас осуществляется инвентаризация??? :о

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

Проблем с инвентаризацией особых нет, потому что 90% товара приходит и сразу уходит (транзит получается).

Какую систему ("рассчитывает FIFO сразу") Вы могли бы порекомендовать?

Axapta умеет закрывать склад каждый день ?

[Тимур]

Хотите сказать, что закупочные партии продаются целиком, без расщепления на партии продажи?
Ведь путаница бывает: продали один товар, а отгрузили иной. Банальная пересортица. Если же только транспортируете один в один, то это не FIFO, а скорее партионная цена в учете, а FEFO (first expired - first out) складское.

Если это к вам не относится, то сорри.
Хм. Трудно ответить на вопрос про системы. Если у Вас задача управления запасами, да плюс партионные цены, то, например, BAAN, Oracle, да и Axapta подойдут.

Закрывать склад можно теоретически после каждой транзакции - вопрос в производительности. Я бы посоветовал Вам передать реальные данные вашей компании для расчета на Axapta.

[AKIS]

Извините, конечно, за назойливость, но я все-таки не понял вот это:

Цитата:

30-35 - это без операционисток, которые принимают заказы, там специальная программа для call-центра.

Дык это число все-таки кого себя включает?

- Склад?
- Финансы/Бухгалтерию?
- Закупщиков?
- Плановиков отдела продаж (которые расчитывают потребности)?

Потом, насчет этой самой "специальной программы". А как вы думаете передавать из нее данные в Аксапту? Программно? А резервировать товар тогда как (оперативные складские остатки-то, как я понимаю, все равно в Аксапте будут, и нигде более).

Насчет закрытий склада - полностью согласен с предыдущими ораторами. Для справки: мы закрываем склад за предыдущий месяц в первых числах следующего. База сейчас 14 Гб (это "чистый вес", без транзакшн логов). Примерно 80% складских транзакций идут с учетом партии-места хранения - это, считай, их удесятеряет, т.е. вместо отпуска 100 штук отпускается 10 раз по 10, в разных партиях. На закрытие уходит порядка 7 часов, и с каждым месяцем это время чуть-чуть но подрастает. Во время закрытия теоретически работать можно, практически - система становится ооочень медленной. Правда и сервера у нас не ахти... Каждый день - закрывать можно (вернее, пересчитывать себестоимость, это то же самое закрытие только без физической блокировки старых данных) - но возможны разные "веселые" цифры коррекции себестоимости, в 3-й версии алгоритм пересчета... хм... не полностью отлажен еще, с ним надо осторожно...

[AKIS]

Цитата:

Изначально опубликовано mazzy


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

Между прочим, а не затруднит ли уважаемого Аксакала Маззи "огласить полный список пжалста" всех аксаптовых "тяжелых" таблиц, кои рекомендуется чистить? И почему (в смысле - не нанесет ли их чистка непоправимый моральный и материальный урон)?

Я лично был бы ОЧЕНЬ благодарен

[mazzy]

Вопрос распадается на два.
1. Какие таблицы являются тяжелыми
2. Какие таблицы можно удалять безболезненно


1. Тяжелые таблицы можно посмотреть в MS SQL командой DBCC SHOwCONTIG WITH TableResults, а в Orcale, например, в утилите TOAD.

2. Безболезнено можно удалять таблицы, у которых свойство TableContent установлено в WorksheetLine и WorksheetHeader. См. руководство разработчика. Ключевое слово "Table groups: What they are". К сожалению, таким простым способом можно определить не все таблицы (У SalesParmLine, например, это свойство равно Transaction).

Насчет почему не наснесет урон SalesParmLine - в Аксапте 3.0 процедуру очистки наконец включили в главное меню (Главное меню \ Расчеты с клиентами \ Периодические операции \ Очистка \ Очистка истории обработки заказов). Детальное обоснование требует отдельной статьи.

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

[AKIS]

Сергей, большое спасибо!

Тяжелые таблицы я вроде и сам нашел: Tools-> Development Tools -> Number of records. У меня среди рекордсменов оказались NumberSeqenceList, NumberSequenceTTS - и конечно InventSettlement... Это те, у которых количество записей зашкаливает далеко за миллион... Некоторые я сообразил, как чистить (в смысле - в каком случае...), но по некоторым сомневаюсь.... Так что за "полный список" буду благодарен вдвойне!

[mazzy]

NumberSeqence?

У вас много непрерывных нумераторов?

В форме Number Seqence есть кнопочка Clean Up.
Поставьте это задание в периодический пакет. Выполняйте периодически.

По поводу тяжелости. тяжелыми могут быть не только таблицы с большым количеством записей. Тяжелыми могут быть таблицы с большой средней длиной записи и с громадными индексами.

Тяжелая таблица - это такая таблица, по которой генерируется много операций чтения/записи на сервере. Тут надо смотреть скорее не колическо записей, а на размер занимаемый таблицей и индексами на диске

[AKIS]

Да, непрерывных числовых последовательностей у нас много Так сделали еще до меня, при первоначальной настройке... Я сейчас потихоньку от них избавляюсь, т.к. вижу что трешка их "не любит" (в частности, уже не первый раз наблюдаю как она пытается брать "свободные" номера, которые на самом деле несвободные...).


А как

Цитата:

Изначально опубликовано mazzy
смотреть а на размер занимаемый таблицей и индексами на диске

?

[mazzy]

в свою очередь, не понял вопроса.

[AKIS]

Я, может, туплю и задаю совсем детские вопросы, но...

База данных MS SQL представляет собой физически три файла: один собствено БД и два - логи.

В Enterprise Manager-e узнать "размер занимаемый таблицей и индексами на диске" - где и как? Не знаю...

[mazzy]

Я же писал
[sql]DBCC SHOwCONTIG WITH TableResults[/sql]
стоит прочитать BOL по этой команде.
Правда это в Query Analyzer.

Если хочется именно в EM, то нужно переключиться в режим просмотра TaskPad и перейти на закладку Tables. Правда это менее удобно на мой взгляд, поскольку таблицу, полученную командой DBСС, можно перегнать в Excel и делать там что хочешь...

Хм... похоже и по этому поводу можно совет писать...
Стоит походиьт по сайтам администраторов СУБД типа www.sql.ru, www.databases.ru и почитать там про оптимизацию...

[Vadik]

Цитата:

Изначально опубликовано AKIS
Я, может, туплю и задаю совсем детские вопросы, но...

База данных MS SQL представляет собой физически три файла: один собствено БД и два - логи.

В Enterprise Manager-e узнать "размер занимаемый таблицей и индексами на диске" - где и как? Не знаю...

DECLARE @pagesizeKB int
SELECT @pagesizeKB = low / 1024 FROM master.dbo.spt_values
WHERE number = 1 AND type = 'E'

SELECT
table_name = OBJECT_NAME(o.id),
rows = i1.rowcnt,
reservedKB = (ISNULL(SUM(i1.reserved), 0) + ISNULL(SUM(i2.reserved), 0)) * @pagesizeKB,
dataKB = (ISNULL(SUM(i1.dpages), 0) + ISNULL(SUM(i2.used), 0)) * @pagesizeKB,
index_sizeKB = ((ISNULL(SUM(i1.used), 0) + ISNULL(SUM(i2.used), 0))
- (ISNULL(SUM(i1.dpages), 0) + ISNULL(SUM(i2.used), 0))) * @pagesizeKB,
unusedKB = ((ISNULL(SUM(i1.reserved), 0) + ISNULL(SUM(i2.reserved), 0))
- (ISNULL(SUM(i1.used), 0) + ISNULL(SUM(i2.used), 0))) * @pagesizeKB
FROM sysobjects o
LEFT OUTER JOIN sysindexes i1 ON i1.id = o.id AND i1.indid < 2
LEFT OUTER JOIN sysindexes i2 ON i2.id = o.id AND i2.indid = 255
WHERE
OBJECTPROPERTY(o.id, N'IsUserTable') = 1 OR
(OBJECTPROPERTY(o.id, N'IsView') = 1 AND OBJECTPROPERTY(o.id, N'IsIndexed') = 1)
GROUP BY o.id, i1.rowcnt
ORDER BY 3 DESC

сразу оговорюсь, авторство - не мое

[AKIS]

Спасибо, Сергей и Vadik!

У меня нынче проблема похуже.... Умирает мой сервер, совсем...


http://www.sql.ru/forum/actualthread...id=1&tid=91942