.gif "1") |
Problema de design de banco de dados se…
Operações de classificação excessivas forem realizadas. Se as mesmas operações de classificação são realizadas continuamente, os problemas podem ser evitados com uma indexação apropriada. Pesquisas de RID excessivas forem realizadas em tabelas de heap. Pesquisas de RID significam que são necessárias mais E/S para recuperar colunas que não se encontram no índice utilizado. Isso pode ser evitado com índices não agrupados abrangidos. Pesquisas de chave nas chaves de cluster aparentarem junções, ainda que estejam marcadas como apenas “pesquisas” no showplan XML. Isso pode ser evitado com índices não agrupados abrangidos. Um índice potencialmente benéfico estiver faltando em colunas de junção, resultando em junções de HASH. Índices em colunas de junção podem evitar o hash. |
.gif "2") |
Armadilhas de CPU...
Se a espera de sinal representar > 25% da espera total, há um afunilamento de CPU. Consulte sys.dm_os_wait_stats quanto a esperas de Sinal e espera Total. Esperas de sinal medem o tempo gasto na fila executável à espera de CPU. Altas esperas de sinal indicam um afunilamento de CPU. Evite reuso impróprio de plano. Se a consulta for idêntica, o reuso de plano será adequado. Contudo, a parametrização de consulta que permite o reuso de plano é apropriada somente quando o conjunto de resultados (e as tabelas de trabalho de intermediação) é de tamanho similar ao plano original. Se os tamanhos dos conjuntos de resultados variarem significativamente, devido a valores divergentes de parâmetros comuns em cenários de data warehouse, o reuso de plano pode ser prejudicial. Planos ruins podem levar, também, a um tempo maior de execução nas consultas e pressão sobre E/S ou a memória. Portanto, o custo de geração de planos em tais casos é preferível ao reuso de plano. Ao contrário de OLTP, as consultas de data warehouse nem sempre são idênticas em termos de conjuntos de resultados ou planos de consulta ideais. |
.gif "3") |
Afunilamento de memória se...
Houver uma grande queda repentina na expectativa de vida da página. Aplicativos de data warehouse (por exemplo, transações grandes) podem experimentar grandes quedas na expectativa de vida da página. Isso se deve a uma baixa de cache causada por uma leitura intensa. Consulte o Gerenciador de Buffer de SQL Server do objeto Perfmon. Houver concessões de memória pendentes. Consulte o contador Concessões de Memória Pendentes no Gerenciador de Memória de SQL Server do objeto Perfmon. Grandes concessões de memória podem ser comuns em aplicativos de data warehouse. Mais memória pode ajudar; do contrário, o usuário não conseguirá executar até que ocorra concessão de memória. Houver liberações repentinas ou a taxa de acertos do Cache de SQL for consistentemente baixo. Liberações ou acertos de cache baixos podem indicar pressão sobre a memória ou índices faltantes. |
.gif "4") |
Afunilamento de E/S se...
A melhor métrica de desempenho de gravação for segundos em disco por leitura e segundos em disco por gravação. Quando o sistema de E/S NÃO está sob carga significativa, não haverá fila em disco e, assim, segundos em disco por leitura ou gravação deve ser bastante adequado. Normalmente, levam-se de 4 a 8 milissegundos para completar uma leitura quando não há pressão sobre E/S. São fatores da produtividade de E/S o número de eixos e produtividade da unidade, como E/Ss seqüenciais e aleatórias por segundo (de acordo com o fornecedor). À medida que as solicitações de E/S aumentarem, poderão ser observadas filas em disco. Os efeitos do enfileiramento se refletem em um valor maior de segundos em discos por leitura ou gravação. Valores mais altos periódicos de segundos em disco por leitura podem ser aceitáveis para muitos aplicativos. No caso de aplicativos de OLTP de alto desempenho, subsistemas de SAN sofisticados proporcionam maior escalabilidade e resiliência de E/S na manipulação de picos de atividade de E/S. Valores altos persistentes de segundos em disco por leitura (>15 ms) indicam um afunilamento de disco. Houver uma média alta de segundos em disco por gravação. Consulte o disco Lógico ou Físico do Perfmon. Cargas de data warehouse podem tanto ser registradas, com inserções, atualizações ou exclusões, como não registradas, por meio de cópia em massa. Operações registradas exigem gravações no log de transações. Uma gravação no log de transações pode ser tão rápida quanto 1 ms (ou menos) em ambientes de SAN de alto desempenho. Em muitos aplicativos, um pico periódico na média de segundos em disco por gravação é aceitável, considerando-se o alto custo dos sofisticados subsistemas de SAN. No entanto, valores altos persistentes na média de segundos em disco por gravação são um indicador confiável de afunilamento de disco. Operações com E/Ss intensas, como verificações de tabelas e intervalos, podem dever-se a índices faltantes. |
.gif "5") |
Afunilamento bloqueador se….
Houver contenção de índice. Procure por altas esperas de bloqueio e travamento em sys.dm_db_index_operational_stats. Compare com as solicitações de bloqueio e travamento. Houve uma média alta de esperas de bloqueio ou travamento de linha. A média de esperas de bloqueio ou travamento de linha é calculada dividindo-se os milissegundos (ms) da espera total de bloqueio ou travamento pelo número de esperas. Os milissegundos da média de espera de bloqueio em sys.dm_db_index_operational_stats representam o tempo médio para cada bloqueio. O relatório de processos de bloqueio exibe os bloqueios longos. Consulte “limite de processo bloqueado” do sp_configure e “Relatório de processos bloqueado” do Profiler, no evento Erros e Avisos. Houver um número alto de deadlocks. Consulte “Deadlock Gráfico” do Profiler, no evento Bloqueios para identificar as instruções envolvidas no deadlock. |
.gif "6") |
Afunilamento de rede se...
Houver alta latência de rede acoplada a um aplicativo que incorre em muitas viagens de ida e volta ao banco de dados. A largura de banda da rede se esgotar. Consulte os contadores de pacotes por segundo e os contadores de largura de banda atual no objeto de interface de rede do Monitor de Desempenho. Para quadros de TCP/IP, a largura de banda real é calculada como pacotes/s * 1500 * 8 /1000000 Mbps. |
.gif "7") |
Armadilhas das estatísticas de espera...
Uma vez que as cargas de trabalho de data warehouse e relatórios são, largamente, leituras compatíveis com outras leituras, esperas de bloqueios exclusivas e incompatíveis entrariam em cena, ordinariamente, apenas durante cargas em lotes ou alimentações periódicas. Se as estatísticas de espera mais altas forem LCK_x. ou PAGELATCH_EX, consulte “Ajuste de desempenho do SQL Server 2005 por meio de esperas e filas” para ler uma explicação sobre sys.dm_os_wait_stats. Haverá um afunilamento de E/S se as estatísticas de espera mais altas em sys.dm_os_wait_stats estiverem relacionadas a E/Ss tais como ASYNCH_IO_COMPLETION, IO_COMPLETION, LOGMGR, WRITELOG ou PAGEIOLATCH_x. |
.gif "8") |
Armadilhas de indexação.
Um data warehouse grande pode se beneficiar de mais índices. Os índices podem ser usados para abranger consultas e evitar classificação. Em um aplicativo de data warehouse, o custo de sobrecarga de índice é pago apenas quando os dados são carregados. Verifique se há índices faltando em sys.dm_db_missing_index_group_stats, sys.dm_db_missing_index_groups e sys.dm_db_missing_index_details. |
.gif "9") |
Fique atento à fragmentação.
A fragmentação excessiva é problemática em grandes operações de E/S. A função com valor sys.dm_db_index_physical_stats da tabela Gerenciamento Dinâmico, retorna o percentual de fragmentação na coluna avg_fragmentation_in_percent. A fragmentação não deve exceder os 25%. Reduzir a fragmentação de índices pode beneficiar verificações de grandes intervalos, comuns em cenários de data warehouse e relatórios. |
.gif "10") |
Considere particionamento de tabela para cargas rápidas
Para as tabelas grandes, comuns em data warehouse, o particionamento de tabela oferece importantes vantagens no desempenho e na capacidade de gerenciamento. Por exemplo, o tipo mais rápido de carga é uma cópia em massa não registrada. O requisito para uma cópia em massa não registrada é que os índices devem ser liberados. Isso não é viável em tabelas enormes, de bilhões de linhas, A MENOS que você use particionamento de tabela. Ele permite que se crie uma tabela temporária idêntica à tabela grande (menos os índices). Uma cópia em massa não registrada é usada para carregar dados. Depois, os índices são adicionados à tabela temporária, seguidos por restrições. Então, uma operação de metadados apenas SWITCH IN alterna os locais dos ponteiros para a tabela temporária preenchida e a partição de destino vazia da tabela particionada, resultando em uma partição totalmente preenchida e uma tabela temporária vazia. Além de uma cópia em massa rápida, a tabela temporária nos permite eliminar o bloqueio na tabela particionada grande durante a carga. Para obter mais informações, consulte “Loading Bulk Data into Partitioned Tables” (em inglês). Além de cargas rápidas, as tabelas particionadas permitem rápidas exclusões (para fins de arquivamento ou exclusões de janela deslizante), nas quais grandes exclusões registradas são substituídas por operações de partição de metadados apenas SWITH OUT, que alternam os locais dos ponteiros para a partição total (a ser ‘excluída’) e uma tabela monolítica vazia. A operação de SWITCH OUT resulta em uma partição vazia e uma tabela temporária monolítica totalmente preenchida. Depois, a tabela monolítica pode ser liberada ou adicionada a uma tabela particionada de arquivo morto, por meio de uma operação de SWITCH IN. Partições também proporcionam aperfeiçoamentos na capacidade de gerenciamento quando combinadas com posicionamentos de grupo de arquivos, o que permite backup e estratégias de restauração personalizados. |