Base de conhecimento / sql pratico
Bloqueios no SQL Server do MU Online: como investigar
Identifique sessões bloqueadas e diferencie espera no banco de outros problemas do servidor.
Colete evidências durante a lentidão
Atraso ao salvar personagem, executar reset ou consultar ranking não prova sozinho um bloqueio no SQL Server. Anote a operação, o horário, a duração e os componentes envolvidos. Compare os registros da aplicação com uma observação do banco no mesmo intervalo.
Use uma conta autorizada para diagnóstico. Para observar todas as sessões, a documentação de sys.dm_exec_requests exige VIEW SERVER STATE nas versões anteriores ao SQL Server 2022 e VIEW SERVER PERFORMANCE STATE a partir dessa versão. Uma visão limitada por permissões não permite concluir que não existem bloqueios.
1. Observe as requisições
SELECT session_id, blocking_session_id,
DB_NAME(database_id) AS database_name,
status, command, wait_type, wait_time,
wait_resource, total_elapsed_time
FROM sys.dm_exec_requests
WHERE session_id <> @@SPID
AND (blocking_session_id <> 0
OR wait_type IS NOT NULL)
ORDER BY wait_time DESC;Esta consulta lê informações de diagnóstico e não modifica tabelas do jogo. Faça algumas coletas espaçadas enquanto a operação lenta acontece; uma fotografia isolada pode perder uma espera curta. Registre os horários das amostras.
2. Leia as colunas no contexto
Um blocking_session_id positivo aponta para outra sessão SQL. Ele não é o PID de um processo Windows. Zero indica que não há uma sessão bloqueadora identificada nesse campo; ainda podem existir outras esperas. Valores negativos têm significados especiais documentados pela Microsoft.
wait_time mede a espera atual em milissegundos. Avalie wait_type e wait_resource junto da operação e compare as amostras. Nem toda espera é bloqueio por outra transação e nem todo bloqueio curto constitui um incidente.
3. Siga a cadeia
Se a sessão 62 espera pela 57 e a 57 espera pela 51, investigue a origem da cadeia. A sessão bloqueadora pode estar ociosa e manter uma transação aberta, portanto pode não aparecer como requisição ativa na mesma consulta. Aprofunde a análise de sessões e transações com o administrador do banco.
Correlacione o início do problema com rotinas de ranking, reset, recompensas, painéis web, manutenção e alterações recentes. Registre qual programa e rotina estão envolvidos antes de atribuir a causa ao GameServer.
4. Reproduza e corrija a causa
Em uma cópia de teste, execute as operações concorrentes observadas e confira se alguma transação permanece aberta ou mantém recursos por tempo excessivo. Revisões de consulta, índices e duração de transações precisam considerar o esquema específico da distribuição e ser verificadas com a mesma carga.
Não aplique KILL indiscriminadamente: encerrar sessões pode interromper operações e iniciar reversões demoradas. Reiniciar serviços apaga parte das evidências e pode não resolver a causa. NOLOCK e aumentos de timeout também não são correções universais; podem ocultar sintomas ou alterar a consistência das leituras.
Critério para encerrar o incidente
Repita a operação que falhava em condições comparáveis, confirme a gravação correta e acompanhe novas amostras. Documente a cadeia observada, o componente responsável, a mudança aplicada, sua reversão e o resultado medido. Se nenhuma espera relevante aparecer, continue investigando aplicação, rede e armazenamento sem presumir que o SQL é a origem.
Veja também performance e SQL prático.
Referência técnica
Microsoft: sys.dm_exec_requests, incluindo permissões e significado das colunas de diagnóstico.