Início / dba / Perguntas / 343062
Accepted
J. Mini
Asked: 2024-10-17 23:51:26 +0800 CST

SELECTs paralelos criam uma transação?

  • 772

Ao executar sob READ COMMITTED(o tipo pessimista, não RCSI), acabei de ver um UPDATEdeadlock de bloqueio IX de 's com um SELECTbloqueio compartilhado de 's no PAGEnível -. Eles SELECTexecutaram com um plano de execução paralelo. Nenhum deles usou explicitamente uma transação. Entendo que UPDATEs implicitamente criam transações. Isso sugere que SELECTs paralelos também criam transações implícitas? Isso não é verdade para s não paralelos SELECT?

Estou achando isso um tanto confuso, porque nenhum dos exemplos de deadlocks nos livros didáticos mostra duas consultas sem transação gerando deadlocks.

sql-server

2 respostas

  1. Best Answer

    não é a transação

    Se você jogar Lock Compatibility Battleship ™️, verá que os Shared Locks não podem afundar seu destroyer facilmente, mas os Object-Level Shared Locks são um tipo diferente de torpedo. Você nem terá tempo para um ping apenas.

    NOZES

    Na maioria dos casos, os bloqueios S são tomados e liberados muito rapidamente, mas há certas coisas que prolongarão esses bloqueios. Eu bloguei sobre eles em relação a Key Lookups com Prefetching:

    A primeira coisa que eu olharia é o plano de consulta para a consulta de seleção paralela e veria se há alguma pesquisa com o atributo prefetch. Em alguns casos, consertar a pesquisa com colunas de índice adicionais é fácil o suficiente. Em outros casos, você pode precisar sugerir um índice diferente.

    Se a pesquisa foi escolhida com base em estimativas de cardinalidade ruins ou por causa da detecção de parâmetros, você pode decidir por um caminho diferente para resolver o problema.

    Caso esse não seja o caso, forneça os planos de consulta para a seleção e para a consulta de modificação, juntamente com qualquer informação contextual útil, como definições de tabela e índice, gatilhos, visualizações indexadas, etc.

    • 4

  2. Sim, o SELECTserá executado em uma transação (e criará uma se necessário, pois ou você está executando no modo de confirmação automática ou está executando com transações implícitas ativadas e SELECTnão é a exceção mencionada aqui ). Isso se aplica igualmente a planos de execução serial ou paralela.

    Se você começar a partir SELECTde uma tabela grande no modo de confirmação automática em uma janela e for para outra e executar

    SELECT request_mode, request_type,request_status, request_owner_id, request_owner_type
FROM sys.dm_tran_locks
WHERE request_session_id = <id_from_original_session> AND request_owner_type = 'TRANSACTION'

    enquanto o original SELECTainda estiver em execução, você verá que o(s) bloqueio(s) mantido(s) pelo SELECTsão alocados para uma transação e se você repetir o experimento e adicionar CURRENT_TRANSACTION_ID()à SELECTlista na tabela grande, verá que o valor retornado por corresponde ao request_owner_idretornado pela sys.dm_tran_locksconsulta.

    Essas SELECTtransações de confirmação automática não parecem aparecer sys.dm_tran_session_transactions, como mostrado abaixo (onde dm_tran_current_transactionfelizmente relata detalhes de uma transação não mostrada no outro DMV).

    SELECT *,
       SessionTransactionCount = (SELECT COUNT(*) FROM sys.dm_tran_session_transactions WHERE session_id = @@SPID)
FROM sys.dm_tran_current_transaction

    Eles também não disparam nenhum evento estendido relacionado a transações, até onde pude ver, então eles parecem uma variante muito leve do tema.

    • 3

relate perguntas