Платформа: SQL 2000 Enterprise с пакетом обновления 4 (SP4), работающий под управлением Windows 2003 Enterprise, 8 ядер, 8 ГБ ОЗУ и внутреннее (!) Хранилище. Общий размер баз данных составляет примерно 100 ГБ.
Сценарий: Статистика ожидания сильно перекосилась на оборудование:
CXPACKET - 35.9%
WRITELOG - 18.4%
LCK_M_S - 13.2%
PAGEIOLATCH_SH - 10.9%
NETWORKIO - 10.4%
LATCH_EX - 5.6%
PAGEIOLATCH_EX - 2.6%
LCK_M_IX - 1.5%
LCK_M_IS - 1.2%
PAGELATCH_UP - 0.1%
Я пока игнорирую типы LATCH и LCK, потому что мы переходим на SAN вскоре во время обновления SQL 2005, а внутренние диски в любом случае сильно фрагментированы.
Однако меня беспокоит тип CXPACKET. В некоторых случаях из-за этого у меня было 80% времени ожидания. Нужно ли пересматривать настройку плана параллельного выполнения? (на данный момент установлено 5). Исправит ли это и переход на SAN? Стоит ли вообще волноваться?
Заранее спасибо!
Состояния ожидания CXPACKET связаны с параллелизмом - это стоимость разделения запросов на несколько процессоров. Запросы отчетов могут выиграть от параллелизма за счет разделения на более мелкие блоки между процессорами и объединения результатов.
Если ваше приложение является OLTP, вы можете поэкспериментировать, установив для всего экземпляра «Максимальная степень параллелизма» значение 1 (использовать только один процессор для выполнения запросов) или выше. Значение по умолчанию - 0 (все процессоры).
http://msdn.microsoft.com/en-us/library/aa196725(SQL.80).aspx
CXPACKET также имеет отношение к вводу-выводу, поэтому переход на SAN должен, по крайней мере, устранить проблему.