AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 09.05.2004, 21:03   #1  
KonSA is offline
KonSA
Участник
 
3 / 10 (1) +
Регистрация: 09.05.2004
? А "потянет" ли Axapta такой объем данных ?
Хочется узнать принципиальную возможность работы Axapta со следующими объемами данных. Контора занимается ночной развозкой продуктов питания с оптового склада в розничные точки. Основной объем обрабатываемой информации составляют заказы на развозку. Статистика примерно следующая:

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

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

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

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

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

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

Буду благодарен за любую информацию.
Старый 09.05.2004, 21:50   #2  
AKIS is offline
AKIS
Учаснег
Аватар для AKIS
 
392 / 19 (1) ++
Регистрация: 18.08.2002
Адрес: За морями, за океанами
Цитата:
Были ли внедрения Axapta с такими объемами ?
Можно ли прикинуть размер базы данных через год работы ?
Здравствуйте.

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

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

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

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

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

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

Цитата:
для учета отгрузки по каждой товарной позиции делаем 3 проводки (себестоимость, реализация, НДС)
- для учета каждой тарной позиции делаем 2 проводки (вешаем тару на клиента и амортизация тары)
Опять-таки - надо ли делать проводки по каждой позиции? Может можно как-то их собирать-группировать (аналитика глубже товара у вас вряд ли будет в бухгалтерии)... Все легче будет, глядишь вместо 50 станет 5 миллионов
__________________
Strictly IMHO & nothing personal
Старый 09.05.2004, 21:58   #3  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Re: А "потянет" ли Axapta такой объем данных ?
Цитата:
Изначально опубликовано 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
ситуация осложняется тем, что работа круглосуточная и остановка базы даже на полчаса (например, для "закрытия" склада ) невозможна
Аксапта очень хочет, чтобы у нее было время на регламентные процедуры. В частности, на закрытие склада. Если ситуацию запускать, то закрытие может длиться долго.

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

Именно момент с регламентными процедурами в Аксапте, скорее всего, будет вашим узким местом.
Старый 09.05.2004, 21:59   #4  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
В целом согласен с AKIS'ом.
Старый 09.05.2004, 22:35   #5  
KonSA is offline
KonSA
Участник
 
3 / 10 (1) +
Регистрация: 09.05.2004
Спасибо mazzy и AKIS за ответ, честно говоря, не ожидал в праздник после 21 часа. Есть еще непьющие люди в России :-)

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

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

Можно ли прикинуть, сколько времени будет составляться отчет по реализации за месяц, если для его составления нужно будет перебрать 7-8 млн. проводок ?
Старый 09.05.2004, 23:49   #6  
Тимур is offline
Тимур
Аксакал в отставке
 
2,457 / 50 (6) ++++
Регистрация: 31.01.2003
Адрес: Москва
Скажите, если Вы не закрываете склады, хотя бы поочередно, то как у вас осуществляется инвентаризация??? :о

На мой взгляд тут надо брать систему, которая рассчитывает FIFO сразу, а не в конце периода.
__________________
Девочка, никогда не произноси слова только за то, что они такие длинные и красивые; говори только то, что знаешь. (Л.Кэрролл "Алиса в стране чудес").
Старый 10.05.2004, 00:09   #7  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Изначально опубликовано AKIS
Внутренний голос мне подсказывает, что вам надо сразу думать про Оракл. Майкрософт такие, и даже бОльшие объемы потянет - но через пару-тройку лет все равно переходить, так что...
К своему удивлению, не раз сталкивался на technet с людьми, сознательно или переходящих с оракла на MSSQL, или делающих первоначальный выбор в пользу последнего. Основные причины - стоимость лицензий и сложность администрирования. А через пару-тройку лет (вернее, гораздо раньше) выйдет Yukon - так что время покажет

Цитата:
Изначально опубликовано AKIS
Остановки баз будут, без этого просто никак нельзя. Так что сразу закладывайте кластер с двумя параллельно работающими и взаимно реплицирующимися базами: отвалилась одна, подключилась другая...
как вариант - одна БД для оперативной деятельности и вторая - для аналитической отчетности, связь - репликацией или log shipping
Старый 10.05.2004, 00:15   #8  
KonSA is offline
KonSA
Участник
 
3 / 10 (1) +
Регистрация: 09.05.2004
Цитата:
Изначально опубликовано Тимур
Скажите, если Вы не закрываете склады, хотя бы поочередно, то как у вас осуществляется инвентаризация??? :о

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

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

Axapta умеет закрывать склад каждый день ?
Старый 10.05.2004, 00:33   #9  
Тимур is offline
Тимур
Аксакал в отставке
 
2,457 / 50 (6) ++++
Регистрация: 31.01.2003
Адрес: Москва
Хотите сказать, что закупочные партии продаются целиком, без расщепления на партии продажи?
Ведь путаница бывает: продали один товар, а отгрузили иной. Банальная пересортица. Если же только транспортируете один в один, то это не FIFO, а скорее партионная цена в учете, а FEFO (first expired - first out) складское.

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

Закрывать склад можно теоретически после каждой транзакции - вопрос в производительности. Я бы посоветовал Вам передать реальные данные вашей компании для расчета на Axapta.
__________________
Девочка, никогда не произноси слова только за то, что они такие длинные и красивые; говори только то, что знаешь. (Л.Кэрролл "Алиса в стране чудес").
Старый 10.05.2004, 01:28   #10  
AKIS is offline
AKIS
Учаснег
Аватар для AKIS
 
392 / 19 (1) ++
Регистрация: 18.08.2002
Адрес: За морями, за океанами
Извините, конечно, за назойливость, но я все-таки не понял вот это:

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

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

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

Насчет закрытий склада - полностью согласен с предыдущими ораторами. Для справки: мы закрываем склад за предыдущий месяц в первых числах следующего. База сейчас 14 Гб (это "чистый вес", без транзакшн логов). Примерно 80% складских транзакций идут с учетом партии-места хранения - это, считай, их удесятеряет, т.е. вместо отпуска 100 штук отпускается 10 раз по 10, в разных партиях. На закрытие уходит порядка 7 часов, и с каждым месяцем это время чуть-чуть но подрастает. Во время закрытия теоретически работать можно, практически - система становится ооочень медленной. Правда и сервера у нас не ахти... Каждый день - закрывать можно (вернее, пересчитывать себестоимость, это то же самое закрытие только без физической блокировки старых данных) - но возможны разные "веселые" цифры коррекции себестоимости, в 3-й версии алгоритм пересчета... хм... не полностью отлажен еще, с ним надо осторожно...
__________________
Strictly IMHO & nothing personal
Старый 10.05.2004, 04:00   #11  
AKIS is offline
AKIS
Учаснег
Аватар для AKIS
 
392 / 19 (1) ++
Регистрация: 18.08.2002
Адрес: За морями, за океанами
Re: Re: А "потянет" ли Axapta такой объем данных ?
Цитата:
Изначально опубликовано mazzy


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

Я лично был бы ОЧЕНЬ благодарен
__________________
Strictly IMHO & nothing personal
Старый 10.05.2004, 14:53   #12  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10


Вопрос распадается на два.
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 процедуру очистки наконец включили в главное меню (Главное меню \ Расчеты с клиентами \ Периодические операции \ Очистка \ Очистка истории обработки заказов). Детальное обоснование требует отдельной статьи.

Полный список таблиц, которые в стандартной версии можно безболезненно удалять, постараемся сделать позже в рамках создания советов.
Старый 10.05.2004, 15:22   #13  
AKIS is offline
AKIS
Учаснег
Аватар для AKIS
 
392 / 19 (1) ++
Регистрация: 18.08.2002
Адрес: За морями, за океанами
Сергей, большое спасибо!

Тяжелые таблицы я вроде и сам нашел: Tools-> Development Tools -> Number of records. У меня среди рекордсменов оказались NumberSeqenceList, NumberSequenceTTS - и конечно InventSettlement... Это те, у которых количество записей зашкаливает далеко за миллион... Некоторые я сообразил, как чистить (в смысле - в каком случае...), но по некоторым сомневаюсь.... Так что за "полный список" буду благодарен вдвойне!
__________________
Strictly IMHO & nothing personal
Старый 10.05.2004, 15:44   #14  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
NumberSeqence?

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

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

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

Тяжелая таблица - это такая таблица, по которой генерируется много операций чтения/записи на сервере. Тут надо смотреть скорее не колическо записей, а на размер занимаемый таблицей и индексами на диске
Старый 10.05.2004, 16:44   #15  
AKIS is offline
AKIS
Учаснег
Аватар для AKIS
 
392 / 19 (1) ++
Регистрация: 18.08.2002
Адрес: За морями, за океанами
Да, непрерывных числовых последовательностей у нас много Так сделали еще до меня, при первоначальной настройке... Я сейчас потихоньку от них избавляюсь, т.к. вижу что трешка их "не любит" (в частности, уже не первый раз наблюдаю как она пытается брать "свободные" номера, которые на самом деле несвободные...).


А как
Цитата:
Изначально опубликовано mazzy
смотреть а на размер занимаемый таблицей и индексами на диске
?
__________________
Strictly IMHO & nothing personal
Старый 10.05.2004, 17:33   #16  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
в свою очередь, не понял вопроса.
Старый 10.05.2004, 18:09   #17  
AKIS is offline
AKIS
Учаснег
Аватар для AKIS
 
392 / 19 (1) ++
Регистрация: 18.08.2002
Адрес: За морями, за океанами
Я, может, туплю и задаю совсем детские вопросы, но...

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

В Enterprise Manager-e узнать "размер занимаемый таблицей и индексами на диске" - где и как? Не знаю...
__________________
Strictly IMHO & nothing personal
Старый 10.05.2004, 18:26   #18  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Я же писал
[sql]DBCC SHOwCONTIG WITH TableResults[/sql]
стоит прочитать BOL по этой команде.
Правда это в Query Analyzer.

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

Хм... похоже и по этому поводу можно совет писать...
Стоит походиьт по сайтам администраторов СУБД типа www.sql.ru, www.databases.ru и почитать там про оптимизацию...
Старый 10.05.2004, 22:30   #19  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Изначально опубликовано 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

сразу оговорюсь, авторство - не мое
Старый 11.05.2004, 00:33   #20  
AKIS is offline
AKIS
Учаснег
Аватар для AKIS
 
392 / 19 (1) ++
Регистрация: 18.08.2002
Адрес: За морями, за океанами
Спасибо, Сергей и Vadik!

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


http://www.sql.ru/forum/actualthread...id=1&tid=91942
__________________
Strictly IMHO & nothing personal
Теги
sql, производительность

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
gatesasbait: Something to check if the Dynamics Ax 4 client throws the "failed to logon to axapta" error Blog bot DAX Blogs 0 08.09.2008 19:05
gatesasbait: "Go to the Main Table Form" differences between Axapta 2.x and Dynamics AX 4 Blog bot DAX Blogs 0 12.08.2008 19:05
casperkamal: InventDim id blank from "Axapta" to "AllBlank" in Dynamics Ax Blog bot DAX Blogs 4 27.02.2007 10:36
Передача данных из 1С в Axapta 3.0 через COM Connector isbist DAX: Программирование 10 03.12.2004 10:58
Введение в Аксапту Роман Кошелев DAX: Прочие вопросы 0 18.12.2001 14:00
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 18:35.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.