Database
 sql >> Base de Dados >  >> RDS >> Database

Noções básicas de sys.dm_exec_requests


Monitoramento de desempenho e solução de problemas no SQL Server é um tópico vasto. No SQL Server 2005, as visualizações de gerenciamento dinâmico, também conhecidas como DMVs, foram introduzidas e se tornaram uma ferramenta de ajuda essencial para diagnosticar problemas de desempenho do SQL Server. Ao mesmo tempo, podemos usar exibições de gerenciamento dinâmico para o Banco de Dados SQL do Azure. Alguns deles podem diferir do banco de dados local do SQL Server, mas a lógica de trabalho ainda é a mesma. A Microsoft tem uma documentação muito boa sobre exibições de gerenciamento dinâmico. A única coisa, você precisa ter cuidado com a versão e validação do produto de visualizações de gerenciamento dinâmico. Como sys.dm_exec_request, está disponível para SQL Server 2008 e versões posteriores e para o banco de dados SQL do Azure, mas sys.dm_db_wait_stats é válido apenas para o banco de dados SQL do Azure.





Neste post, falaremos sobre o básico do sys.dm_exec_request. sys.dm_exec_requests é uma exibição de gerenciamento dinâmico que retorna apenas as solicitações em execução no momento. Isso significa que quando você executa a consulta sys.dm_exec_requests, ela captura a solicitação que está sendo executada naquele momento e não inclui nenhum dado histórico. Portanto, essa visualização é muito útil para monitorar solicitações em tempo real. Em outras palavras, ele dá a resposta para “o que está acontecendo no meu servidor agora?” Essa visão inclui muitos detalhes, mas discutiremos os mais importantes.

session_id :Este valor define um número de identificação de sessão. No SQL Server, os IDs de sessão iguais ou inferiores a 50 são dedicados ao processo em segundo plano.

start_time :esse valor define a data e hora de início da solicitação.

estado :Este valor define um status da solicitação. Os status disponíveis são:
  • fundo
  • executando
  • executável
  • dormindo
  • suspenso
SELECT DISTINCT status
FROM sys.dm_exec_requests
WHERE session_id <>@@SPID



fundo :Este tipo de status define os processos em segundo plano. Alguns deles são LAZY WRITER, CHECKPOINT e LOG WRITER. 
select session_id, command, os_thread_id from sys.dm_exec_requests as r
 join sys.dm_os_workers as w on r.task_address = w.task_address
 join sys.dm_os_threads as t on t.thread_address = w.thread_address
 where session_id <= 50
 order by session_id



executando :Este tipo de status define que a solicitação está sendo processada pela CPU. 
 select * from sys.dm_exec_requests where status='running'
 and session_id <>@@SPID



executável :Este tipo de status pode ser definido simplesmente como um pedido que está esperando na fila da CPU para ser executado. Se você detectar muitos processos executáveis ​​em sys.dm_exec_requests, isso pode ser um sintoma de pressão da CPU. Essa métrica não é suficiente para diagnosticar esse problema de desempenho da CPU. Por esse motivo, precisamos apoiar este caso com mais evidências. Isso é significativo para provarmos nossa teoria. A exibição de gerenciamento dinâmico sys.dm_os_wait_stats inclui uma coluna que é signal_wait_time_ms. Este valor de coluna pode ajudar a determinar o problema da CPU. A consulta a seguir nos mostra a porcentagem de Signalwait. Se essa métrica tiver um valor alto, provavelmente você está enfrentando um problema de desempenho da CPU. Você pode aprofundar sua revisão dessa maneira. 
---https://sqlserverperformance.wordpress.com/page/146/
---Glenn Berry's SQL Server Performance 

SELECT signal_wait_time_ms=SUM(signal_wait_time_ms)
              ,'%signal (cpu) waits' = CAST(100.0 * SUM(signal_wait_time_ms) / SUM (wait_time_ms) AS NUMERIC(20,2))
              ,resource_wait_time_ms=SUM(wait_time_ms - signal_wait_time_ms)
              ,'%resource waits'= CAST(100.0 * SUM(wait_time_ms - signal_wait_time_ms) / SUM (wait_time_ms) AS NUMERIC(20,2))
FROM sys.dm_os_wait_stats;

suspenso :Este tipo de status define o processo de espera de algum recurso. Pode ser I/O, LOCK e LATCH etc. Conforme mencionado acima, podemos usar o sys.dm_os_wait_stats visualização de gerenciamento dinâmico para detectar wait_time_ms.

dormindo :significa que a solicitação está conectada ao SQL Server, mas não está executando nenhum comando no momento.

comando :Esta coluna define um tipo de comando que está sendo executado. Ao mesmo tempo, podemos encontrar informações adicionais para comandos específicos que são uma taxa de conclusão. De acordo com os livros online, estes são;

ALTER INDEX REORGANIZE

Opção AUTO_SHRINK com ALTER DATABASE

BANCO DE DADOS DE BACKUP

DBCC CHECKDB

DBCC CHECKFILEGROUP

TABELA DE VERIFICAÇÃO DBCC

DBCC INDEXDEFRAG

DBCC SHRINKDATABASE

DBCC SHRINKFILE

RECUPERAÇÃO

RESTAURAR BANCO DE DADOS

RECUPERAR

CRIPTOGRAFIA TDE

Demonstração :
  • Conecte o banco de dados mestre e inicie o backup para qualquer banco de dados.
    BACKUP DATABASE WideWorldImporters TO DISK ='NUL'

    Dica :Quando você leva o backup do banco de dados para o dispositivo “NUL”, o SQL Server não grava um arquivo de backup em nenhum lugar e você evita a exclusão de um arquivo de backup de teste. Mas não use este comando em seu ambiente de produção. Isso pode causar a quebra da cadeia LSN.

Execute a seguinte consulta:
SELECT command,percent_complete ,*
FROM sys.dm_exec_requests
WHERE session_id <>@@SPID
and session_id>50 and command='BACKUP DATABASE'

sql_handle :Este valor define a instrução SQL da solicitação. Mas esse valor está no formato bitmap. Por esse motivo, precisamos usar a função com valor de tabela sys.dm_exec_sql_text para converter o valor em texto significativo. 
select session_id ,command , sqltxt.text ,database_id
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
where session_id<>@@SPID AND session_id>50



database_id :Este valor define qual banco de dados faz a solicitação. Podemos juntar este campo com sys.databases para obter o nome do banco de dados. 
select session_id ,command , sqltxt.text ,db.name
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
inner join sys.databases db on db.database_id = req.database_id
where session_id<>@@SPID AND session_id>50

wait_type :Este valor define o tipo de espera atual da solicitação. Se a duração da execução da consulta demorar mais do que o esperado, você poderá verificar e determinar o tipo de espera da consulta.



transaction_isolation_level :Este valor define o nível de transação da consulta enviada:

0=Não especificado

1=Ler não confirmado

2=Ler Confirmado

3=Repetível

4=Serializável

5=Instantâneo 
select session_id ,command , sqltxt.text ,db.name,req.status,wait_type ,transaction_isolation_level,
CASE transaction_isolation_level
WHEN 0 THEN 'Unspecified'
WHEN 1 THEN 'ReadUncomitted'
WHEN 2 THEN 'ReadCommitted'
WHEN 3 THEN 'Repeatable'
WHEN 4 THEN 'Serializable'
WHEN 5 THEN 'Snapshot'
END
AS isolation_level_name
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
inner join sys.databases db on db.database_id = req.database_id
where session_id<>@@SPID AND session_id>50



blocking_session_id :É o id da sessão que está bloqueando a solicitação. Se esta coluna for NULL, a solicitação não bloqueou nenhuma sessão.

Demonstração :
  • Abra o SQL Server Management Studio e execute a seguinte consulta.
    DROP TABLE IF EXISTS TestPerfomon
GO
CREATE TABLE TestPerfomon
(ID INT ,
Nm VARCHAR(100))

INSERT INTO TestPerfomon
VALUES(1,1)
GO
BEGIN TRAN
UPDATE TestPerfomon SET Nm='2'
WHERE ID=1

SELECT @@SPID AS blocking_session_id


Abra uma nova janela de consulta e execute a seguinte consulta. 
SET TRANSACTION ISOLATION LEVEL Serializable
BEGIN TRAN
UPDATE TestPerfomon SET Nm='3'
WHERE ID=1

Abra outra nova janela de consulta e execute esta consulta DMV. 
select session_id ,command , sqltxt.text ,db.name,req.status,wait_type ,transaction_isolation_level,
CASE transaction_isolation_level
WHEN 0 THEN 'Unspecified'
WHEN 1 THEN 'ReadUncomitted'
WHEN 2 THEN 'ReadCommitted'
WHEN 3 THEN 'Repeatable'
WHEN 4 THEN 'Serializable'
WHEN 5 THEN 'Snapshot'
END
AS isolation_level_name ,
blocking_session_id
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
inner join sys.databases db on db.database_id = req.database_id
where session_id<>@@SPID AND session_id>50



Com esta demonstração, descobrimos o motivo pelo qual a segunda consulta está bloqueada e qual sessão está bloqueada a solicitação. Ao executar sp_BlitzWho 65, você pode descobrir os detalhes do bloqueio e os detalhes da sessão bloqueada. 
sp_BlitzWho 65

Nesta demonstração, recuperamos os detalhes do bloqueio e das sessões bloqueadas e, ao mesmo tempo, obtivemos os detalhes sobre essas sessões. Esta é uma demonstração muito básica, mas mostra como o problema pode ser resolvido.

Neste post, falamos sobre sys.sys.dm_exec_requests. Essa visualização de gerenciamento dinâmico nos dá a flexibilidade de obter um instantâneo durante a linha atual de uma solicitação. Além disso, esses dados de detalhes podem nos ajudar ou nos guiar pelo processo de descoberta do problema.

Referências
  • sys.dm_exec_requests (Transact-SQL)
  • Monitorando o Banco de Dados SQL do Azure usando exibições de gerenciamento dinâmico
  • sys.dm_db_wait_stats (Banco de Dados SQL do Azure)


Ferramenta útil:


dbForge Monitor – add-in para Microsoft SQL Server Management Studio que permite rastrear e analisar o desempenho do SQL Server.