По памяти  SQL обрезали  чтобы все не жрало а вот по процикам есть такая возможность?  объясняю :   обработка расчета себестоимости занимает 3 - 4 часа  занимает ресурсы SQL сервера на 100%  чтобы не мешать народу работать  подняли SQL на терминале  и пробные  просчеты проводим  там  а финишный  уже в рабочей БД.  вот тока  днем иногда  хочется посчитать  но в момент расчета  сервер занят только этим.  Как  SQL  ограничить чтобы  хоть капельку  оставляло  остальным  в идеале  по ядрам  пусть берет 6 из 8ми и лопатит.

Свойства сервера - процессоры.

Закиньте его в виртуалку...

(0) max degree of parallelism = 1  для начала поставьте

(3)  это куда  ?

(4) в свойствах сервера, вкладка Advanced

(0) В свойствах SQL сервера, вкладка "Memory" и "Processor" рули как хочешь?

спасибо буду пробовать

(7) сначала именно (3) попробуй. процессоры не трогай.

(3) последствия?

(9) самые благоприятные. проблема из сабжа должна исчезнуть.

(10)   а подробнее нельзя?   интересна физика.  попробовать смогу тока завтра.  вчерашний расчет обработают.

нашел.  у меня SQL 2008  но не думаю  что смысл параметра отличается

Если SQL Server 2005 работает на многопроцессорном компьютере, он определяет оптимальную степень параллелизма, то есть количество процессоров, задействованных для выполнения одной инструкции для каждого из планов параллельного выполнения. Для ограничения количества процессоров в плане параллельного выполнения может быть использован параметр max degree of parallelism. Установленное по умолчанию значение 0 использует все доступные процессоры. Чтобы отключить формирование параллельных планов, присвойте параметру max degree of parallelism значение 1. Значение выше 1 (до 64) позволяет ограничить максимальное количество процессоров, используемых при выполнении одного запроса. Если указано значение, превышающее число доступных процессоров, используется фактическое число доступных процессоров. Если у компьютера только один процессор, то значение параметра max degree of parallelism учитываться не будет.

(10) Причем тут это? Всё равно будет жрать процессоры.

только не понимаю  почему  = 1  а не трем например.  :-)

(12) ограничить максимальное количество процессоров, используемых при выполнении ОДНОГО ЗАПРОСА

когда 0, тяжелый запрос раскидывается по всем доступным процам, и все остальные курят и ждут пока он выполнится

(11) физика простая - запрещает выполнение запроса параллельно

больше чем уверен, что сабж можно ускорить раз в 10!

обычно основное время занимает запись, если обрабработка долго работает без записи объектов в базу - то на 99% хреновая это обработка (или база слишком нормализована)

(16)  вот и вопрос  почему =1  а не например = 3  ядер все равно много  а вот насколько замедлится выполнение  при сокращении с неограниченно (в данном случае 8) до одного.

(17)  не думаю  что имеет смысл обсуждать оптимизацию  конкретного расчета  в этой ветке.  да и писал не я  а франчи.  разгребать и оптимизировать  если надо у меня сейчас нет ни знаний ни времени.  там  очень развернутый просчет.  в не сезон считает работы компании расчет занимает 30-40 минут.  сейчас  растут объемы производства.

(18) во многих случаях параллелизм становится причиной медленой работы (возникают ожидания потоков)

(13) будет. но не все и сразу.

блин  много поначитался про этот max degree of parallelism

такое  впечатление  что лагерь разбит на две части  в какое значение его взводить.  
1.  в какой момент изменения вступят в силу , в момент сохранения параметра или нужно пере запускать сервис?
2.  все таки  при работе  7-8 десятков  пользователей в УПП  какое значение  выгоднее?  (причем на SQL  еще живет бухия  с 15 пользователями и архивная 8.1 УПП)

почитай http://msdn.microsoft.com/ru-ru/library/ms179984.aspx

ищи у себя статистику по этим видам блокировок...

а вообще если регулярно не делать обновление статистики - то лучше ставить параллелизм = 1, ведь именно на основании статистики он и строит планы запроса, и если статистика старая он строится далеко не оптимально, тогда и возникают блокировки

(23) ну и до кучи http://infostart.ru/public/16681/

Для 1С вроде однозначно сошлись на том, что выгоднее параллелизм отключать.

(3)Это не всегда хорошо для производительности, да он и сам больше выделенных процессоров не должен параллелить

(25) виртуальные таблицы при параллельности часто быстрее работают

да и вообще запросы из слабо связанных кусков - типа объекдинений

иногда просто лучше трешхолд поднять немного

(23) в свойствах базы можно поставить автоактуализацию статистики же

(25) для 77 однозначно отключать, для 8.х включать, но с обновлением статистики и прочим "приглядом"

для 77 там отключать его надо из-за блокировок а не из-за производительности

(30) хммм не знал, а где там?

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