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

[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

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

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