Plataforma : SQL 2000 Enterprise com SP4, em execução no Windows 2003 Enterprise, 8 núcleos, 8 GB de RAM e armazenamento interno (!). Os bancos de dados são aproximadamente 100 GB no total.
Cenário : os waitstats estão strongmente distorcidos para o hardware:
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%
Estou ignorando os tipos LATCH e LCK por enquanto, porque estamos mudando para SAN logo durante uma atualização do SQL 2005, e as unidades internas estão muito fragmentadas de qualquer maneira.
No entanto, estou preocupado com o tipo CXPACKET. Em alguns casos, tive 80% de tempo de espera relacionado a isso. A configuração do plano de execução paralela precisa ser revisada? (está definido para 5 no momento). A mudança para SAN também corrige isso? Eu deveria me preocupar em primeiro lugar?
Obrigado antecipadamente!
Os estados de espera do CXPACKET estão relacionados ao paralelismo - é o custo da divisão de consultas em vários processadores. As consultas de relatórios podem se beneficiar do paralelismo dividindo-se em partes menores entre os processadores e amalgamando os resultados.
Se o seu aplicativo for OLTP, você pode experimentar definindo a instância como 'Max Degree of Parallelism' como 1 (use apenas um processador para executar consultas) ou superior. O valor padrão é 0 (todos os processadores).
O CXPACKET também está relacionado à E / S, portanto, a mudança para a SAN deve atenuar o problema pelo menos.
Tags performance sql-server