Производительность

[cryomice]

Тоже подключусь к дискуссии.

По поводу отношения размера таблицы к размер индексов, для inventtrans и prodbom включена компрессия на таблицу, но на индексы компрессия не включена, отсюда такая разница в занимаемом месте. Без сжатия inventtrans занимает порядка 120ГБ. Отношение изменится, но все равно будет в районе 1, так что по всем вами указанным таблицам необходимо пересмотреть индексы.

Цитата:

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

2. таблицы inventtrans, prodbom, имеют Page Compression

[mazzy]

спасибо. отлично.
тогда, судя по таблицам, особо лишнего в таблицах нет. похоже таблицы уже подчистили.

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

[Evgeniy2020]

При таких объемах, АОС и MS SQL естественно должны быть 64 битными.
и для того чтобы ОЗУ эффективно обрабатывать свыше 4 ГБ
(а не через PAE).

а вообще надеюсь что сеть у вас хотя бы Gigabit ethernet.

а вообще конечно здорово было бы, исторические данные поместить
в другой сервер, скажем те данные 2010 - 3 года, то есть до 2008 года
наверно желательно поместить в другую историческую базу.
ну и для отчетов за весь период дописать обращение к историческим данным.

можно еще технический аудит заказать из МС кажется,
но это не дешево.

для таких объемов даже элементарные join будут громадными, по выборке,
просто не будут в оперативку помещаться.

размеры индексов возможно гововорят о не малом их числе.
я лично не сторонник отключать auto update statistics
так как в прошлом у нас так одна база настолько замедлилась,
что мы не смогли даже понять где получились тормоза.

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

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

[mazzy]

Цитата:

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

можно еще технический аудит заказать из МС кажется,
но это не дешево.

Цитата:

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

для таких объемов даже элементарные join будут громадными, по выборке,
просто не будут в оперативку помещаться.

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

В стандартных отчетах будут использоваться гораздо меньшие выборки.
http://axapta.mazzy.ru/lib/inventsumdate/

Цитата:

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

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

не, это плохой совет.

дело в том, что стандартная международная Аксапта изначально писалась под Оракл, в котором очень давно была возможность сегментировать данные по датам. И предполагалось, что старые данные просто будут вынесены в отдельный сегмент и размещены на отдельном диске.

Такое предположение позволяло оставить одну таблицу и один набор отчетов (как для старых, так и для новых данных). Разница была только во времени доступа.

И, соответственно, все отчеты писались так, чтобы с как можно меньшей вероятностью дергать старые данные (хотя такие отчеты и были конечно).

Но в результате такого подхода в Аксапте нет инструментов архивирования, переноса в другие таблицы и/или на другие сервера. Мало того, вся функциональность построена так, что в системе будут присутствовать все данные

Поэтому совет "перенести на другой сервер" - скорее всего, очень дорого обойдется предприятию.

==============
Да, Майкрософт готовил функционал архивирования в Акс6. но толком так и не смог его отладить. Поэтому будьте осторожны с таким советом. Особенно для ax4.

[Evgeniy2020]

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

в крайнем случае можно было бы посчитать сальдо 3 года назад,
и сооотвественно создать архивную базу а в новой от сальдо 3 ех летней давности, за то база будет на 70% меньше в среднем.

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

но это конечно помогло бы кардинально.

[mazzy]

Цитата:

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

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

в крайнем случае можно было бы посчитать сальдо 3 года назад

архивная база - это не только сальдо.
придется что-то делать с сопоставлениями.
сопоставлений в аксапте - много.

это и сопоставления проводок клиентов (CustSettlement), и проводок поставщиков (VendSettlement). Это и складские сопоставления приходов и расходов (InventSettlement). и так далее.

От сопоставлений зависят курсовые/суммовые. себестоимость и куча всего.

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

Разве что в каком-нибудь вырожденном случае

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

[_scorp_]

Цитата:

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

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

Очень популярный способ в 1С Если мне не изменяет память, в 1С v7.7 была даже штатная операция закрытия базы для типовых, т.к. с какого то момента база 1С-ка не могла уже эффективно работать с большими таблицами.

[mazzy]

Цитата:

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

Очень популярный способ в 1С Если мне не изменяет память, в 1С v7.7 была даже штатная операция закрытия базы для типовых, т.к. с какого то момента база 1С-ка не могла уже эффективно работать с большими таблицами.

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

кроме того, так делают в 1С:Бухгалтерии.
Но вот с 1С:Торговлей все уже не так просто.
А вот в УПП уже практически невозможно корректно разорвать данные.

В общем, как только система перестает быть тривиальным калькулятором. И как только система начинает более-менее использовать старые данные (например, планировать)... то архивирование становится нетривиальной операцией

[fed]

Цитата:

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

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

Вообще-то в readme к версии 2.1 было написано, что в этой версии работа с Oracle вышла из бета-тестирования и официально поддерживается.
Так что они не рассчитывали на Oracle, они просто не подумали

[mazzy]

Цитата:

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

Вообще-то в readme к версии 2.1 было написано, что в этой версии работа с Oracle вышла из бета-тестирования и официально поддерживается.
Так что они не рассчитывали на Oracle, они просто не подумали

или так.
можно думать как угодно и как нравится исходя из оптимистичности/пессимистичности своих взглядов на...
но изначально в ней не предусмотрено архивирование.

[Evgeniy2020]

Вообще конечно искренне хочется помочь, так как ваша база с 550 ГБ
это явно пионеры первопроходцы, думаю не только надо постить на Аксфоруме, наверно даже и в technet форумы.

и для таких размеров стоило бы подумать о привлечении мировых специалистов и по erp и по ms sql server для технического аудита.

вот когда однажды на западе одна фармо производственная компания
встала из за того что сводное планирование не успевало за выходные создавать мастер план производственных закзаов.

вот сразу спецы выехали на место и седлали какие то специализированные
решения.

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

явно напрашивается какой то механизм создавать с такими объемами.
тут уже не стыдно обратится и к самым крупным пром компаниям на западе за техническими советами. обратится может даже в мс консалтинг,
подыскать правильные технические решения и привести аналоги оборудования в других крупных западных компаниях с размером базы
от 500 го и далее. Так мжет дойти и до CORE разработчиков из редмонда или из команды Manufacturing и Логистика.
может стоит озадачить их.

теория больших чисел а тут теория больших баз прямо.