Запустил тест на 1 час.
Результаты теста:

***total***    16878177.0    100.0
SLEEP_TASK    5080609.0    30.1
LAZYWRITER_SLEEP    3546843.0    21.0
SQLTRACE_BUFFER_FLUSH    3396031.0    20.1
LCK_M_U    1238109.0    7.3
PAGEIOLATCH_SH    1061515.0    6.3
WRITELOG    1034968.0    6.1
SLEEP_BPOOL_FLUSH    455203.0    2.7
CXPACKET    373390.0    2.2
PAGEIOLATCH_EX    272281.0    1.6
SOS_SCHEDULER_YIELD    189312.0    1.1

Подскажите, плиз, куда копать.

начните отсюда: http://msdn.microsoft.com/ru-ru/library/ms179984.aspx

(0) что за тест?

(1) Я там уже был...  Нифига не понял.

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

(2) http://info start.ru/public/16681/

Ап!

(3) да вы вообще не на том заморачиваетесь..

"A session status of ‘Sleeping’ indicates SQL Server is waiting for the next SQL Server command."
http://download.microsoft.com/download/4/7/a/47a548b9-249e-484c-abd7-29f31282b04d/Performance_Tuning_Waits_Queues.doc

Посмотрите еще ссылки ниже (они на буржуйском). Там SLEEP_* ожидания исключаются на этапе сбора статиситики ожиданий.

http://www.sqlskills.com/BLOGS/PAUL/post/Wait-statistics-or-please-tell-me-where-it-hurts.aspx

http://blog.sqlauthority.com/2011/02/01/sql-server-wait-stats-wait-types-wait-queues-day-0-of-28-2/

(6) Спасибо за ссылки. Буду дальше копать.

ап! Может еще кто-нидь че-нидь подскажет?

(8)А в чем вопрос-то?

(9) Вопрос в следующем: в базе имеют место быть блокировки, усложняющие работу. Можно ли их как-то разрулить?

(10) Разрешаю.

(10)Можно.Поставить помощней железо(чтобы узнать что именно - пользуйтесь замером производительности).Либо перевести конфу(если речь об 1с) в режим управляемых блокировок.Если это еще не сделано конечно.

(11) Спасибо, мне этого не хватало.

(12) Это не 1С.
Это Оптимум Мобильная Торговля. См. http://www.cdc.ru/solutions/optimum-asumt/
SQL уже перетащили на другую тачку. Проблема осталась.

(13) буэээ. Не разрешаю. Оптимум - говнище редкое. Надо было у наших земляков, "Системных технологий" проект заказывать.

(13) Выбором ПО я не занимаюсь...  Мое дело - ямки закапывать..  :)

(15) -> (14)

(13) вы в этом оптимуме код править можете? без этого особого толка не будет.
тут все равно рекомендации будут стандартные - дефрагментация\перестройка индексов и обновление статистики. Про шринк, если есть - забыть.

Судя по этому:
PAGEIOLATCH_SH
WRITELOG
PAGEIOLATCH_EX
У вас могут быть проблемы с дисковой подсистемой - растащить файл данных и журнал траназкций на разные физические устройства. И чем они быстрее тем лучше.

Какой у вас SQL Server? Если 2005 и старше - используйте dmv sys.dm_os_wait_stats  или стандартный отчет. В dmv данные собираются с момента запуска службы sql server, чтобы получить более актуальные данные - запустите DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR); и смотрите как там что со временем изменяется.
Смотрите счетчики ОС - они вам могут больше сказать о проблемах в системе.

(17) А почему именно на эти вещи нужно обратить внимание: PAGEIOLATCH_SH, WRITELOG, PAGEIOLATCH_EX? Они ж не в первой тройке?

У нас SQL 2005.

(18) Ожидания SLEEP_* - это вообще не те ожидания, о которых вам надо беспокоиться.
SQLTRACE_BUFFER_FLUSH - "Имеет место, когда задача ожидает сохранения фоновой задачей буферов трассировки на диск каждые четыре секунды." (msdn, ссылка выше) - не нравится это ожидание - отключите трассировку по умолчанию, 99%, что дело в ней. Это тоже можете не учитывать, просто оно все время висит и ждет. Откинув их, получите:
LCK_M_U - это ваши ожидания на блокировках, фактически - на первом месте.
PAGEIOLATCH_SH - "Имеет место, когда задача ожидает кратковременной блокировки буфера, находящегося в состоянии запроса ввода-вывода. Запрос на кратковременную блокировку производится в режиме общего доступа. Длительное время ожидания может указывать на проблемы с дисковой подсистемой." (msdn)
WRITELOG - тоже диск "Имеет место при ожидании завершения записи журнала. Обычно запись журнала вызывается такими операциями, как контрольные точки и фиксации транзакций."
CXPACKET - процессор, можете попробовать повысить cost treshold для параллелизма
PAGEIOLATCH_EX - диск
SOS_SCHEDULER_YIELD - процессор

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

(19) Очистил утром статистику (DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR)).

Запрос
select * from  sys.dm_os_wait_stats
order by wait_time_ms desc

Выдает следующее:
wait_type/waiting_tasks_count/wait_time_ms/max_wait_time_ms/signal_wait_time_ms
LCK_M_S    115    21299156    1211640    46
SLEEP_TASK    807083    12235796    890    112906
LAZYWRITER_SLEEP    13397    8647093    1015    2078
SQLTRACE_BUFFER_FLUSH    2115    8460046    4015    0
LCK_M_U    176    4041281    528906    15
PAGEIOLATCH_SH    56033    1533281    2062    1718
WRITELOG    17011    889359    2343    765
LCK_M_X    21    790843    772125    0
SLEEP_BPOOL_FLUSH    65162    778468    46    11156
CXPACKET    20618    752781    30250    7203
SOS_SCHEDULER_YIELD    308334    515265    375    515265
PAGEIOLATCH_EX    23302    395453    2062    46
ASYNC_NETWORK_IO    15607    51562    984    203
SQLTRACE_LOCK    241    51562    1015    140
LOGBUFFER    1650    29187    656    62
IO_COMPLETION    1558    27484    1078    15
OLEDB    84669    23031    8156    0
PAGELATCH_UP    97904    15718    31    2625
PAGEIOLATCH_UP    87    6750    2140    0
PAGELATCH_SH    2926    5828    562    1734
LATCH_EX    599    2125    515    0
PAGELATCH_EX    2621    781    171    78
LATCH_SH    37    578    203    15
MSQL_XP    61    46    15    0
MSQL_DQ    161    46    15    0
CMEMTHREAD    160    31    15    31
THREADPOOL    4    15    15    0
LCK_M_IX    2    15    15    0
LCK_M_SIU    0    0    0    0

я-бы обратил внимание на длительность сесий, а конкретнее на "зависшие" такое бывает если клиент отваливается но конект остается.

Лечится установкой в биосе отключением питания сетевых карт (в частности при "sleep" компа)

(20) да вы как не понимаете, что эти цифры - это НИ О ЧЕМ! Они имеют смысл в том случае, если у вас есть baseline, с которым вы можете сравнить результат и сделать вывод - стало лучше, хуже, или осталось как было. Это как обратиться с вопросом - "У меня счетчик Transactions\sec показывает 1000 транзакций в секунду. Это нормально?". Ответа на такой вопрос никто не может знать кроме вас - только вы можете знать какое количество транзакций в секунду нормально для ВАШЕЙ системы. Со статистикой ожиданий тоже самое. Ожидание LCK_M_S будет всегда, пока будут блокировки. А блокировки будут всегда, пока у вас с одними и теми же данными работает больше 1 человека.

Я уже давал вам ссылку: http://www.sqlskills.com/BLOGS/PAUL/post/Wait-statistics-or-please-tell-me-where-it-hurts.aspx

Оттуда: LCK_M_XX
This is simply the thread waiting for a lock to be granted and indicates blocking problems. These could be caused by unwanted lock escalation or bad programming, but could also be from IOs taking a long time causing locks to be held for longer than usual. Look at the resource associated with the lock using the DMV sys.dm_os_waiting_tasks.

Т.е. возможные причины: unwanted lock escalation (кривая структура данных\мало памяти), bad programming, IOs taking a long time (медленные диски).
Ну и по второй ссылке можно перейти на это: http://blog.sqlauthority.com/2011/02/15/sql-server-lck_m_xxx-wait-type-day-15-of-28/

(0) Если кому-то интересно: проблема была не в железе. Проблема в структуре БД.