Eu tenho um problema em que um sistema de replicação orientado por software falhará ao replicar totalmente quando o banco de dados principal estiver sob carga pesada. Por exemplo, se executarmos um sproc 500 vezes, talvez 450 realmente permaneçam. MAS apenas quando estamos sob carga louca de banco de dados (um exemplo são os administradores de SAN atualizando o firmware durante o horário comercial). Estou preocupado em criar transações para cada mensagem e aguardar o tempo limite e a reversão, pois existe a possibilidade de o servidor SQL de destino estar na WAN em outro datacenter.
Pergunta: Eu quero destruir meu servidor DEV SQL com tanta força para replicar esperas massivas de bloqueio/cxpacket no desenvolvimento. Mas não o suficiente para bloquear totalmente todo o acesso por horas, apenas talvez para simular a perda de pacotes.
Cenário: o servidor B (máquina utilitária) possui uma instância SQL Express local. É usado para dados transitórios. Ele dispara uma série de sprocs no banco de dados de destino para inserir novas linhas e, em seguida, insere novas linhas em tabelas filhas vinculadas por PKs. Assim por diante e assim por diante.
Normalmente funciona muito bem. Exceto que os DBAs de produção não permitem que os especialistas no assunto deste sistema tenham qualquer controle ou visibilidade das estatísticas de bloqueio. Tenho controle total e posso traçar o perfil do sistema que está propagando dados para o destino, mas nenhuma análise sobre o que acontece na outra ponta, além de esperar... esperar... esperar... Estou bloqueado? Eu não sei!
Quero simular isso no laboratório e tentar ajustar os sprocs que são usados. Estou pensando em uma atualização de pulsação anx atualização xp_cmdshell para uma tabela de contabilidade e também usando análise de ping usando xp_cmdshell para consultar / refinar / ajustar transações e reverter transações, se necessário, caso todas não sejam confirmadas. Em seguida, tente novamente, talvez em outro host distribuído.
Problema: A última vez que isso aconteceu foi devido ao fato de que o TEMPDB era ENORME (tabelas temporárias massivas sendo utilizadas) e precisava paginar. Os DBA's disseram que não havia nada de errado, mas também relataram comprimentos de fila de disco acima de 50+ por horas a fio. Tem que amar isto.
Acabei de descobrir o Hammer DB , que é um gerador de carga configurável e de código aberto. Estamos usando-o para avaliação de sobrecarga da VM. Você deve ser capaz de escolher apenas o número certo de usuários simulados para estressar seu sistema sem quebrá-lo.
Para estressar um sistema, você pode aumentar a carga ou diminuir os recursos.
Existem muitos pacotes comerciais de criação de carga por aí, e provavelmente alguns de freeware também. Parece que você o isolou em apenas um SP, portanto, um script personalizado para disparar 500 exemplos dele em paralelo deve funcionar. A execução do script no servidor de banco de dados induzirá ainda mais estresse ao SQL Server. Eu tenho alguns scripts do Powershell que podem maximizar um servidor de quatro núcleos por minutos de cada vez! Multiplicar os dados por alguns
INSERT dbo.Xx SELECT * FROM dbo.Xx(com ajustes de chave primária apropriados) também fará com que os SPs trabalhem mais.No lado dos recursos, reduzir a memória máxima do servidor causará mais paginação do pool de buffers e, talvez, mais recompilações de SP. Definir o affinint do processador de instância para que ele tenha menos núcleos disponíveis fará com que cada um trabalhe mais. É claro que isso pode causar mudanças secundárias sutis que afetam o que você está tentando medir. Planos de execução novos e diferentes, por exemplo.
No lado do monitoramento, achei esses DMVs úteis para entender o bloqueio.
HTH