тема вдогонку к v7: 1С 7.7 SQL база то тормозит, то не тормозит
система SQL 2005 на Win2003 64bit, базы 1С 7.7 по сети клиенты 25шт, на серваке SQL процессор 2ядра Xeon 771сокет, 8гиг ram

провел тестирование,
***total***    37666617.0    100.0
LAZYWRITER_SLEEP    17936546.0    47.6
SQLTRACE_BUFFER_FLUSH    17936000.0    47.6
PAGEIOLATCH_SH    891281.0    2.4
CXPACKET    402828.0    1.1
SLEEP_BPOOL_FLUSH    156781.0    0.4
PAGEIOLATCH_EX    113531.0    0.3
MISCELLANEOUS    57937.0    0.2
LCK_M_S    20765.0    0.1
LCK_M_X    48515.0    0.1
SLEEP_TASK    23281.0    0.1
SOS_SCHEDULER_YIELD    19312.0    0.1
WRITELOG    34046.0    0.1
PAGEIOLATCH_UP    1281.0    0.0
LCK_M_IX    4656.0    0.0
IO_COMPLETION    1281.0    0.0
ASYNC_NETWORK_IO    16953.0    0.0

провел тестирование по "скрипту vde69"
1. SQLTRACE_BUFFER_FLUSH половину времени SQL сбрасывает буферы на диск, стоит ли это отключить (к каким последствиям может привести) и как отключить это сбрасывание, чтобы не было "SQLTRACE_BUFFER_FLUSH"
2. PAGEIOLATCH_SH, PAGEIOLATCH_EX и тп говорят о иногда возникающих проблемах с дисковой подсистемой, насколько они существенны судями по приведенным цифрам ?
3. аналогично, ASYNC_NETWORK_IO говорит о иногда проблемах с сетью - я правильно понял ? насколько существенными можно считать эти проблемы исходя из приведенных цифр ?
я не привел параметры набравшие 1000единиц и меньше

1. SQLTRACE_BUFFER_FLUSH - если вам не нравится это ожидание, отключите все трассировки, в т.ч. трассировку по умолчанию. Трассировка по умолчанию отключается так:
exec sp_configure 'show advanced options', 1
reconfigure
exec sp_configure 'default trace enabled', 0
reconfigure
exec sp_configure 'show advanced options', 0
reconfigure

2-3. честно говоря, хрен его знает, кто решил, что по этим цифрам можно что-то путнее узнать. По хорошему, у вас должен быть "baseline" - тот же самый скрипт должен был выполняться тот же промежуток времени, что и сейчас - в те моменты, когда работа кипит, но у всех все было хорошо. И вы, сравнивая полученный результат с этим baseline'ом, сразу увидите, что у вас обычно, например, растет ожидание PAGEIOLATCH_SH, в то время как остальные цифры в пределах нормы, отсюда уже можно делать вывод, что нынешние тормоза связаны именно с этим ожиданием и имеет смысл проверить диски или перестроить индексы.

Раз у вас сервер 2005-й, вы можете забыть про эти скрипты, которые надо запускать и ждать три часа выполнения, и делать так:

/*начали мониторинг, обнулили представление sys.dm_os_wait_stats*/
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR)
/*ждем три часа, или сколько мы там хотим */
SELECT *
FROM sys.dm_os_wait_stats

sys.dm_os_wait_stats содержит в себе всю информацию, которая выводится вашим скриптом и является кумулятивным - обнуляется только после перезапуска сервера или принудительно, с помощью DBCC SQLPERF.

(1) спасибо, к чему плохому может привести отключение трассировки ?

(2) Содержимое трассировки по-умолчанию, может помочь разобраться почему рухнул сервер (если вдруг он рухнет) - по крайней мере понять чем занимался сервер перед падением. Это его "черный ящик".

ЕМНИП это автообновление статистики

(4) что именно? SQLTRACE_BUFFER_FLUSH?

(5) SQLTRACE. а сброс буферов - это её "высер"

(6) >>ЕМНИП
изменяет она вам :)
SQLTRACE_BUFFER_FLUSH    
Имеет место, когда задача ожидает сохранения фоновой задачей буферов трассировки на диск каждые четыре секунды.
http://msdn.microsoft.com/ru-ru/library/ms179984.aspx
ну и плюс к (0): http://www.sql.ru/forum/actualthread.aspx?bid=1&tid=790402

(7) буферов трассировки... а что же такое трассировка, вот в чем вопрос?

(8) http://msdn.microsoft.com/ru-ru/library/ms191120.aspx
http://msdn.microsoft.com/ru-ru/library/ms187933.aspx