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

[fed]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

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

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

[mazzy]

Цитата:

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

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

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

[Evgeniy2020]

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

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

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

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

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

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

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

[egorych]

Вообще ИМХО - не было озвучено какие мероприятия проводятся с базой вообще!
Если надежда только на галку автостатистики, то это неправильно в корне!
В бытность работы нашей базы на MSSQL (200Г) у меня каждую ночь делался регламент по реиндексации, дефрагментации таблиц, сбору статистики. В случае массовых изменений в рабочее время уже появилась (в MSSQL - в Oracle давно) online индексация и сбор статистики. В этом случае ее нужно настроить на обновление ну хотя-бы 2-3 раза за день.
И все будет нормально - 500Г не так уж и много.
Не помешает собрать инфу по очередям на дисковой системе, может уже пора дисков добавить.

[fed]

Цитата:

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

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

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

[egorych]

Цитата:

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

Позволю себе усомниться в необходимости собирать статистику 2-3 раза в день.

Для часто меняющихся таблиц нужно, хотя, конечно, все определяется данными. Знаю некоторые системы (не Ax, у знакомых) - они на Оракле чуть не каждые 2 часа собирают по некоторым таблицам. Хотя, справедливости ради - статистика на Оракле вообще больная тема . Мне сейчас хватает 1 раз в сутки - ночью. Может можно и реже, но оно особо не напрягает.

[Def]

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

0. в 2008 был проведен аудит оборудования, инфраструктуры и многое другой, аудит AXAPTA делал господин Алексей Еременко из мс, многое из его рекомендаций было выполнено, хотя мне очень понравились слова что переход на ax2009 решит наши проблемы с закрытием периода и расчетом средних цен, большая часть замечаний была отработана, с частью замечаний я сам лично был несогласен но это другая тема, тут начинается специфика (хотелок заказчика)

1. win 2008 server 64 (2 штуки ораганизован кластер), SQL 64 бит, aos 32 (на 4 физических серваках)

2. мероприятие которые проводятся в базе
- чистка логов ежемесячно и прочих "не очень нужных данных"
- есть база на другом сервере куда реплицируются необходимые таблицы штатным механизмом репликации
- по этой базе работает MS RS чтобы рабочую базу не нагружать выборками для отчетов
- для остатков заведена помесячная таблица остатков переписаны некоторые механизмы и отчеты которые работают с остатками
- для пакетных клиентов включен штатный механизм сбора журнала трассировки операторов SQL все что вылазит за рамки x выявялется анализируется и вносятся изменения в индекс либо выявляется косяк и хинт прописывается в код
- пытаемся не пропускать в разработку "мутные методики" чтобы не вносить грубых сильно нарушающих штатные механизмы алгоритмов, пытаемся наложить их на штатные алгоритмы и механизмы
- Upadte statistics каждые 3 часа по ключевым таблицм
- дефрагментация не помню что-то около раз в неделю по проценту дефрагментации

вот вроде и все

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

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

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

[mifi]

Цитата:

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

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

0. в 2008 был проведен аудит оборудования, инфраструктуры и многое другой, аудит AXAPTA делал господин Алексей Еременко из мс, многое из его рекомендаций было выполнено, хотя мне очень понравились слова что переход на ax2009 решит наши проблемы с закрытием периода и расчетом средних цен, большая часть замечаний была отработана, с частью замечаний я сам лично был несогласен но это другая тема, тут начинается специфика (хотелок заказчика)

1. win 2008 server 64 (2 штуки ораганизован кластер), SQL 64 бит, aos 32 (на 4 физических серваках)

2. мероприятие которые проводятся в базе
- чистка логов ежемесячно и прочих "не очень нужных данных"
- есть база на другом сервере куда реплицируются необходимые таблицы штатным механизмом репликации
- по этой базе работает MS RS чтобы рабочую базу не нагружать выборками для отчетов
- для остатков заведена помесячная таблица остатков переписаны некоторые механизмы и отчеты которые работают с остатками
- для пакетных клиентов включен штатный механизм сбора журнала трассировки операторов SQL все что вылазит за рамки x выявялется анализируется и вносятся изменения в индекс либо выявляется косяк и хинт прописывается в код
- пытаемся не пропускать в разработку "мутные методики" чтобы не вносить грубых сильно нарушающих штатные механизмы алгоритмов, пытаемся наложить их на штатные алгоритмы и механизмы
- Upadte statistics каждые 3 часа по ключевым таблицм
- дефрагментация не помню что-то около раз в неделю по проценту дефрагментации

вот вроде и все

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

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

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

Я, возможно, пропустил ответ на этот вопрос раньше, из-за большого числа новой и неожиданной информации, почерпнутой в данной ветке (вроде того, что Axapta писалась под Oracle) но хотелось бы спросить - а анализировали собственно разницу в планах исполнения "тормозящих" запросов - до и после обновления статистики?

[Def]

конечно, план строился по другому индексу по которому по идее должен

[mifi]

Цитата:

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

конечно, план строился по другому индексу по которому по идее должен

А можно указать, что именно за запрос и какой индекс оптимизатор выбирал? Еще лучше было бы план обнародовать