Solucionar problemas de erros de tempdb em um pool de SQL dedicado

  • Artigo

Aplica-se a: Azure Synapse Analytics

Em um pool de SQL dedicado, o banco de dados tempdb é usado para tabelas temporárias e espaço intermediário para movimentações de dados (por exemplo: movimentações de embaralhar, cortar movimentos), classificações, cargas, derramamentos de memória e outras operações. Além disso, uma transação não comprometida em uma sessão que interage com o banco de dados tempdb impedirá que o log libere todas as outras sessões, fazendo com que os arquivos de log sejam preenchidos. Como o banco de dados tempdb é um recurso compartilhado, o grande consumo do espaço tempdb pode fazer com que as consultas de outros usuários falhem e possam escalar para impedir que novas conexões sejam estabelecidas.

O que fazer se eu não puder me conectar ao pool de SQL dedicado?

Se você não tiver conexões existentes para identificar conexões ou consultas problemáticas, o único método para resolver a incapacidade de criar uma nova conexão será Pausar e Retomar ouDimensionar o pool de SQL dedicado. Essa ação encerrará as transações de usuário que levaram a esse problema e recriará o banco de dados tempdb quando o serviço for reiniciado.

Nota: Certifique-se de dar tempo extra ao serviço para desfazer todas as transações em execução, pois as operações de pausa e escala podem levar mais tempo do que o normal para serem concluídas nesse cenário.

Solucionar problemas de arquivos de dados tempdb completos

Etapa 1: identificar a consulta que preenche o banco de dados tempdb

Certifique-se de identificar a consulta que preenche o banco de dados tempdb enquanto a consulta está sendo executada, a menos que você tenha implementado um componente de log em sua estrutura ETL ou auditoria de suas instruções dedicadas do pool de SQL. Na maioria dos casos, nem sempre, a consulta de execução mais longa executada durante o período em que o problema ocorreu é a causa dos erros temporários fora do espaço. Execute a consulta a seguir para obter uma lista de consultas de longa duração:

SELECT TOP 5 *
FROM sys.dm_pdw_exec_requests
WHERE status = 'running'
ORDER BY total_elapsed_time desc;

Depois de ter uma consulta razoavelmente suspeita, experimente uma das seguintes opções:

  • Mate a instrução.
  • Tente impedir que qualquer outra carga de trabalho consuma ainda mais o espaço tempdb para que o corredor longo possa ser concluído.

Etapa 2: impedir a recorrência

Depois de identificar e tomar medidas contra a consulta responsável, considere implementar mitigações para evitar que o problema se repita. A tabela a seguir mostra mitigações para as causas mais comuns de erros completos de tempdb:

Motivo Descrição Atenuação
Plano mal distribuído O plano distribuído gerado para uma determinada consulta pode introduzir inadvertidamente a movimentação de dados de alta frequência como resultado de estatísticas de tabela mal mantidas. Atualize as estatísticas para tabelas relevantes e verifique se elas são mantidas em uma agenda regular.
Integridade de CCI (índice columnstore clusterizado) ruim Ele consome o espaço tempdb devido a derramamentos de memória. Recompile as CCIs e verifique se elas são mantidas em uma agenda regular.
Transações grandes Um grande volume de CREATE TABLE AS SELECT (CTAS) instruções ou INSERT SELECT preenche o tempdb durante as operações de movimentação de dados. Quebre sua CTAS instrução ou INSERT SELECT em várias transações menores.
Alocação de memória insuficiente Consultas com memória insuficiente alocada (por meio de classe de recurso ou grupo de carga de trabalho) podem ser derramadas em tempdb. Execute suas consultas com uma classe de recurso maior ou um grupo de carga de trabalho com mais recursos.
Consultas de tabela externa do usuário final Consultas em tabelas externas não são ideais para consultas de usuário final porque o mecanismo precisa ler todo o arquivo tempdb antes de processar os dados. Carregue os dados em uma tabela permanente e, em seguida, direcione as consultas de usuário para lá.
Recursos globais insuficientes Você pode descobrir que o pool de SQL dedicado está próximo à capacidade máxima de tempdb durante a alta atividade. Considere escalar o pool de SQL dedicado em combinação com qualquer uma das mitigações acima.

Solucionar problemas de arquivos de log de transações tempdb completos

Normalmente, o log de transações tempdb só é preenchido quando um cliente/usuário:

  • Abre uma transação explícita, mas nunca emite um COMMIT ou ROLLBACK.
  • Conjuntos IMPLICIT_TRANSACTION = ON (especialmente para clientes JDBC e ferramentas que usam recursos do AutoCommit).

Etapa 1: identificar transações abertas

As conexões problemáticas podem ser de clientes que têm uma transação aberta, mas estão em um status "Ocioso". Execute a consulta a seguir para ajudar a identificar este cenário:

SELECT *
FROM sys.dm_pdw_exec_sessions
WHERE is_transactional = 1
AND status = 'Idle';

Observação: nem todas as conexões retornadas como resultado dessa consulta são necessariamente problemáticas. Execute a consulta pelo menos duas vezes com mais de 15 minutos entre execuções e veja quais conexões persistem nesse estado.

Etapa 2: Mitigar e impedir o problema

Depois de identificar quais clientes estão realizando transações abertas, trabalhe com os usuários para alterar ou ambos:

  • Configuração do driver (por exemplo: configuração do JDBC AutoCommit como off, que define IMPLICIT_TRANSACTIONS = ON)
  • Comportamentos de consulta ad hoc (por exemplo: executar BEGIN TRAN incorretamente sem/COMMITROLLBACK )

Como alternativa, você pode considerar a criação de um processo automatizado para detectar periodicamente esse cenário e eliminar sessões potencialmente problemáticas.

Recursos