Estamos no SQL Server 2008 R2 Standard Edition. Algumas tabelas são altamente fragmentadas. Eu quero ver se a desfragmentação vai melhorar o desempenho e vale a pena o esforço e tabelas/índices sendo bloqueados durante o processo. Portanto, desejo restaurar o backup completo em um ambiente de teste e simular um ambiente ativo.
Qual é o melhor caminho a seguir? Como posso capturar os eventos acontecendo em um ambiente ao vivo por algum período? Quais ferramentas estão disponíveis para isso?
obrigada
Você tem poucas opções. Existem ferramentas de terceiros que podem ajudar a simular uma carga em seu banco de dados. Existem utilitários simples abertos, como o SQL Query Stress , que pode executar quaisquer consultas que você fornecer na frequência que desejar.
Há também a combinação de execução de rastreamentos do lado do servidor e reprodução desses rastreamentos. Isso pode ser tão simples quanto coletar scripts de um rastreamento (como Dan apontou corretamente acima, não use a GUI do Profiler para capturar eventos, mas capture o rastreamento em um arquivo usando o rastreamento do lado do servidor) e, em seguida, reproduza a carga de trabalho se você mais se importa sobre o desempenho de consulta individual se você se preocupa mais com o desempenho de consulta individual e menos com a simultaneidade.
Se você precisar se aprofundar na simultaneidade e ver a carga de trabalho em tempo real de vários ângulos, convém usar os recursos do Distributed Replay. Isso permite que você aponte para um rastreamento em qualquer versão do SQL Server de volta ao SQL Server 2005 e execute-o em qualquer versão do SQL Server, também de volta ao SQL Server 2005. Jonathan Kehayias tem uma explicação passo a passo de como configurar Distributed Repetir. Isso permitiria que você configurasse a reprodução de vários clientes distribuindo a carga - uma única reprodução do criador de perfil nunca permitiria escalar. (Observe - você verá que a ferramenta é uma ferramenta SQL Server 2012. Não deixe que isso o assuste, a ferramenta foi lançada na época, mas pode lidar com seu ambiente SQL Server 2008 R2)
Tudo isso dito - há complexidade nisso de qualquer maneira. Fazer um rastreamento para reprodução tem alguns requisitos e etapas. A reprodução também tem algumas etapas a serem seguidas para garantir que você esteja começando do mesmo ponto de partida, etc. Vale a pena entender essa complexidade, pode ajudar a realizar testes de prontidão de atualização, ajudar a entender as alterações de hardware no aplicativo total, etc. Utilitários RML para analisar os traços anteriores e posteriores também, o que pode ajudar a mostrar como as coisas melhoraram ou não depois.
Se você quiser apenas ver se a reconstrução de índices fez alguma alteração, você também pode fazer testes mais simples. Você pode pegar uma grande inserção repetível e executar apenas isso antes e depois. Você pode fazer algumas consultas com altas varreduras e algumas com altas buscas e executá-las antes e depois. Eu garantiria que você ainda reconstruísse as estatísticas de qualquer maneira, já que a reconstrução de seus índices reconstrói as estatísticas de nível de índice e isso às vezes oferece mais benefícios do que a reconstrução de índices e as pessoas atribuem o benefício às reconstruções do índice em vez das estatísticas do índice que obtiveram reconstruído. Costumo cair no campo "reconstruir" com mais frequência, mas as mudanças de hardware no desempenho de E/S, padrões de carga de trabalho, etc., tornam essa regra não rígida e rápida necessariamente para mim.