Как повысить производительность системы?

[DesertBrowser]

Добрый день!
Используем DAX 3.0 SP3, MS SQL 2000 SP4
Начало обсуждения http://www.sql.ru/forum/actualthread.aspx?tid=802622
Суть в том, что испытываем сильные проблемы с производительностью и ищем способы, как их решить.
Поможет ли нам использование модуля "Анализ производительности"? Пожалуйста, поделитесь опытом

[BOAL]

переход на Ах4 + скл2005 или уже ах2009+скл2008
или ах3 + оракл
ну и какое-то время действительно оптимизить индексы, наращивать мышцу у сервера БД (озу, хдд и тп), разносить таблицы БД по разным рейдам, проверить забитость канала сетевого.

На деле сам на раз-два три на АХ3+скл2000 на бис делал блокировку, когда два заказа на одну номенклатуру и аналитику жмем ОК
Забавно, что это лезло на обучении юзеров, когда они по команде ОК и жали
То есть блокировки не сильно зависят от колва юзеров, а от мест их обитания. Узких мест.
Найдя их, нужно их еще пооптемизить тоже.

В общем, процесс творческий. Знаю, что с Ах3+Оракл без потерь удалось вернуться на АХ4+скл2005\2008, через шаг Ах4 + оракл

[raz]

Оптимизация SQL сервера под Аксапту.

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

[DesertBrowser]

Спасибо за ссылку, правда ранее уже читали её, но хотелось бы кое-что обсудить более подробно.
>>Не должно быть такого, если нормально 'cost threshold for parallelism' настроен
Хотелось бы узнать поподробнее по поводу этой настройки. У нас сейчас MAXDOP=0, Стоимостной порог для параллелизма=5 (по умолчанию)

>>Отдельный сервер для отчётности
Как лучше поступить:
-сделать полную реплику базы при помощи механизма репликации, её использовать для отчётности, основную базу - для оперативного внесения данных?
-базу, в которую пользователи будут вносить данные, очистить и начать "с нуля". Статые данные для отчётности перенести в другую базу, потом дополнять их данными оперативной базы ручными скриптами/программами экспорта/импорта?
-вариант с резкой базы (предлагает наше руководство). Часть от базы за последние два года остаётся, остальное переносится в архивную базу. Поможет ли это, какими проблемами чревато, осуществима ли такая задача применительно к функционалу Аксапты, и если применима, то какова последовательность шагов при архивировании части базы?
PS По результатам изучения форума резать базу не рекомендуется, но некоторые (видели пример Перекрёстка) всё же нечто подобное делают. Подскажите, кто делал нечто подобное. А возможно, мы обойдёмся и без этого?

[Vadik]

Цитата:

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

Как лучше поступить:
-сделать полную реплику базы при помощи механизма репликации, её использовать для отчётности, основную базу - для оперативного внесения данных?
-базу, в которую пользователи будут вносить данные, очистить и начать "с нуля". Статые данные для отчётности перенести в другую базу, потом дополнять их данными оперативной базы ручными скриптами/программами экспорта/импорта?
-вариант с резкой базы (предлагает наше руководство). Часть от базы за последние два года остаётся, остальное переносится в архивную базу

Все подходы - суть второй пункт (do something) стратегии кальсонных гномов
Вместо того, чтобы "делать что-то", сделайте то, что необходимо сделать - локализуйте проблемы с производительностью (неоптимальные запросы, блокировки, конфигурация) и решайте их по отдельности. Нет здесь единственного быстрого и правильного решения, есть много работы, местами нудной

[DesertBrowser]

Понятно, что если делать что-то, то получишь какой-нибудь результат. Суть в том, как быстро и тот ли результат, что искали.
Поэтому мы советуемся, с чего нам начать при локализации проблем с производительностью? Мониторинг блокировок при помощи Профайлера подойдёт?
И стоит ли рассматривать перспективу резки базы как средство повышения производительности работы по занесению оперативной информации+получению отчётности за ряд периодов?И не обращать пока внимания на проблемы производительности, а сразу отрезать от базы кусок данных с давностью более 2 лет?

[Ivanhoe]

Без обрезки БД можно обойтись. Причем на значительно бОльшем по пользователям / объему данных внедрении. Для аналитической отчетности, особенно по складу, желательно ОЛАП, натравленный на отдельную БД (копию рабочей).

[DesertBrowser]

А как в таком случае реализовать копию? При помощи репликации? При помощи скриптов синхронизации? Или каким-либо другим способом?

[Zabr]

Цитата:

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

и тот ли результат, что искали

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

[sukhanchik]

Цитата:

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

А как в таком случае реализовать копию? При помощи репликации? При помощи скриптов синхронизации? Или каким-либо другим способом?

А зачем делать копию? Как тут уже говорили - ОЛАП спасает мир

[Wamr]

Если основные блокируемые таблицы не InventItemLocation & InventSum, то многие проблемы решаться исправлением кривого кода и индексов.

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

[Ivanhoe]

Цитата:

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

А зачем делать копию? Как тут уже говорили - ОЛАП спасает мир

Зависит от окружения, регламентных процедур и т.п. ОЛАПу же когда-нибудь нужно прочитать изменения и забрать себе. Если у вас всю ночь разносятся складские операции (например, реализация за день), то даже грязное чтение ОЛАПа может сильно снизить скорость.

[sukhanchik]

Цитата:

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

Зависит от окружения, регламентных процедур и т.п. ОЛАПу же когда-нибудь нужно прочитать изменения и забрать себе. Если у вас всю ночь разносятся складские операции (например, реализация за день), то даже грязное чтение ОЛАПа может сильно снизить скорость.

Согласен

[Vadik]

Цитата:

Сообщение от топикстартер на SQL.RU

Блокировки у нас в основном на
INVENTTABLE
INVENTDIM
SALESLINE
INVENTTRANS

Что как бы намекает на наличие кривых кастомизаций и на то, что внедрение OLAP-а, "очистка данных" и "разделение баз" займет его (топикстартера) на какое-то (продолжительное) время, но проблему скорее всего не решит

[Wamr]

"очистка данных" а-ля Перекресток на полгода хватало
блокировка InventTable - а не решение ли для РЦ от Коламбуса у вас?