![]() |
#5 |
Участник
|
Цитата:
the customer had built up a database of 24 million inventory transactions,
there were 2,5 million lines in inventdim, inventsum had 6 million lines, the only active dimensions were the configuration on the inventory side and the warehouse, location and palett on the storage side. No serial numbers or Batch numbers so reasonably limited usage of inventdimid's. They used FIFO costing so inventsettlements were not too bad around 16 Million. We ran a valuation report as at 3 months in the past. The report was unable to complete after 100 hours of processing time. The server was a quad processor with 32 Gb of RAM and a dedicated 15 K RPM raid 0+1 array with 24 disks in it, no penny pinching there. посмотрел в средний размер записи на SQL-сервере на демобазе (в демобазе используется больше аналитик, чем в обсуждаемом примере) inventdim: avg size = 100, records = 2,500,000 inventsum: avg size = 327, records = 6,000,000 inventtrans: avg size = 413, records = 24,000,000 invetnsettlement: avg size = 302, records = 16,000,000 Общий размер данных ~= 17Гб (16,956,000,000) А у них сервер имеет память 32Гб. Понимаю, что индексы добавляют объем. Понимаю, что у них средний размер записей может быть другой (скорее всего, меньше). Но даже 30Гб данных с индексами такой сервер должен засосать почти полностью и держать в кэше. Даже на 40-50Гб должен справляться почти не затрагивая диск. Как они смогли получить на ТАКОМ сервере больше 100часов на отчет? Это ж постараться надо... Интересно, на какой версии тестировалось и на каком MS SQL? Если на ax3.0, то выполнялось ли выравнивание влево? http://axapta.mazzy.ru/lib/adjustment/ Цитата:
The problem lies in the volume of data.
|
|
Теги |
inventdim, inventsum, производительность, складские отчеты |
|
![]() |
||||
Тема | Ответов | |||
dynamicsmatters: Performance and InventDim | 52 | |||
dynamicsmatters: Dynamics AX Base Data Model Part II | 0 |
|