Compartilhar via

Diretrizes para níveis de isolamento de transações com tabelas Memory-Optimized

Em muitos cenários, você deve especificar o nível de isolamento da transação. O isolamento de transações para tabelas com otimização de memória difere das tabelas baseadas em disco.

Requisitos para especificar o nível de isolamento da transação:

  • TRANSACTION ISOLATION LEVEL é uma opção necessária para o bloco ATOMIC que abrange o conteúdo de um procedimento armazenado compilado de forma nativa.

  • Devido a restrições no uso do nível de isolamento em transações entre contêineres, o uso de tabelas otimizadas para memória em Transact-SQL interpretado deve frequentemente ser acompanhado por uma dica de tabela que especifique o nível de isolamento utilizado para acessar a tabela. Para obter mais informações sobre dicas de nível de isolamento e transações entre contêineres, consulte Níveis de Isolamento de Transação.

  • O nível de isolamento de transação desejado deve ser declarado explicitamente. Não é possível usar dicas de bloqueio (como XLOCK) para garantir o isolamento de determinadas linhas ou tabelas na transação.

  • O aplicativo que acessa o banco de dados deve implementar a lógica de tentativas para lidar com erros resultantes de conflitos que inviabilizam transações, falhas de validação e falhas de dependência de confirmação. Observe que falhas de dependência de confirmação podem ocorrer mesmo com transações somente leitura.

  • Transações de longa duração devem ser evitadas com tabelas otimizadas para memória. Essas transações aumentam a probabilidade de conflitos e terminações de transação subsequentes. Uma transação de execução prolongada também adia a coleta de lixo. Quanto mais tempo uma transação durar, mais In-Memory OLTP manterá versões de linhas recentemente excluídas, o que pode reduzir o desempenho de consulta para novas transações.

As tabelas baseadas em disco normalmente dependem do bloqueio e da obstrução para isolamento de transações. As tabelas com otimização de memória dependem do controle de versão múltiplo e da detecção de conflitos para garantir o isolamento. Para obter detalhes, consulte a seção sobre detecção de conflitos, validação e verificações de dependência de commit em Transações em Tabelas de Memory-Optimized.

Tabelas baseadas em disco permitem multiversionamento com os níveis de isolamento SNAPSHOT e READ_COMMITTED_SNAPSHOT. Para tabelas com otimização de memória, todos os níveis de isolamento são baseados em várias versões, incluindo REPEATABLE READ e SERIALIZABLE.

Tipos de transações

Cada consulta no SQL Server é executada no contexto de uma transação.

Há três tipos de transações no SQL Server:

  • Transações de confirmação automática. Se não houver nenhum contexto de transação ativo e as transações implícitas não forem definidas como ON na sessão, cada consulta terá seu próprio contexto de transação. A transação começa quando a instrução inicia a execução e termina quando a instrução é concluída.

  • Transações explícitas. O usuário inicia a transação por meio de um BEGIN TRAN explícito ou BEGIN ATOMIC. A transação é concluída mediante COMMIT, ROLLBACK ou END correspondentes (END no caso de um bloco atômico).

  • Transações implícitas. Quando a opção IMPLICIT_TRANSACTIONS é definida como ON, uma transação é iniciada implicitamente sempre que o usuário executa uma instrução e não há nenhum contexto de transação ativo. A transação é concluída através de um COMMIT e um ROLLBACK explícitos.

Isolamento padrão READ COMMITTED

READ COMMITTED é o nível de isolamento padrão no SQL Server.

O nível de isolamento READ COMMITTED garante que as transações não vejam dados não confirmados de alterações fora da transação atual. Em outras palavras, a transação lê apenas os dados que foram confirmados no banco de dados ou foram alterados pela transação atual.

Todos os níveis de isolamento com suporte para tabelas otimizadas para memória oferecem a garantia de leitura confirmada. Portanto, se a transação não exigir garantias mais fortes, você poderá usar qualquer um dos níveis de isolamento com suporte para tabelas com otimização de memória. O SNAPSHOT usa o menor número de recursos do sistema em comparação com outros níveis de isolamento.

A garantia fornecida pelo nível de isolamento SNAPSHOT (o nível mais baixo de isolamento com suporte para tabelas com otimização de memória) inclui as garantias de READ COMMITTED. Cada declaração na transação lê a mesma versão consistente do banco de dados. Não só todas as linhas são lidas pela transação confirmada no banco de dados, como também todas as operações de leitura veem o conjunto de alterações feitas pelo mesmo conjunto de transações.

Diretriz: Se apenas a garantia de isolamento READ COMMITTED for necessária, use o isolamento SNAPSHOT com procedimentos armazenados que são compilados nativamente e para acessar tabelas otimizadas para memória utilizando o Transact-SQL interpretado.

Para transações de confirmação automática, o nível de isolamento READ COMMITTED é mapeado implicitamente para SNAPSHOT para tabelas com otimização de memória. Portanto, se a configuração da sessão TRANSACTION ISOLATION LEVEL estiver definida como READ COMMITTED, não será necessário especificar o nível de isolamento por meio de uma dica de tabela ao acessar tabelas com otimização de memória.

O exemplo de transação de confirmação automática a seguir mostra uma junção entre uma tabela com otimização de memória Clientes e uma tabela regular [Histórico de Pedidos], como parte de um lote ad hoc:

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;  
GO  
SELECT *   
FROM dbo.Customers AS c   
LEFT JOIN dbo.[Order History] AS oh   
    ON c.customer_id = oh.customer_id;

O exemplo de transações explícitas ou implícitas a seguir mostra a mesma junção, mas desta vez em uma transação de usuário explícita. A tabela otimizada para memória Customers é acessada sob isolamento de instantâneo, conforme indicado por meio da dica de tabela WITH (SNAPSHOT), e a tabela regular [Histórico de Pedidos] é acessada sob isolamento de leitura confirmada:

SET TRANSACTION ISOLATION LEVEL READ COMMITTED  
GO  
BEGIN TRAN  
SELECT * FROM dbo.Customers c with (SNAPSHOT)   
LEFT JOIN dbo.[Order History] oh   
    ON c.customer_id=oh.customer_id  
...  
COMMIT

Diferenças operacionais

Além da garantia confirmada de leitura, também há dois detalhes de implementação importantes nos quais os aplicativos que usam tabelas baseadas em disco podem depender. Lembre-se do seguinte ao converter uma tabela baseada em disco que é acessada usando o isolamento READ COMMITTED em uma tabela com otimização de memória acessada usando o isolamento SNAPSHOT:

  • A implementação do nível de isolamento READ COMMITTED para tabelas armazenadas em disco (supondo que READ_COMMITTED_SNAPSHOT seja OFF) usa bloqueios para evitar conflitos entre processos de leitura e escrita. Quando um escritor começa a atualizar uma linha, ele usa um bloqueio e não libera o bloqueio até que a transação seja concluída. As operações de leitura são bloqueadas, aguardando a confirmação da transação de escrita.

    Alguns aplicativos podem supor que os leitores sempre esperam que os gravadores cometam, especialmente se houver alguma sincronização entre as duas transações na camada de aplicação.

    Regra: Os aplicativos não podem depender do comportamento de bloqueio. Se um aplicativo precisar de sincronização entre transações simultâneas, essa lógica poderá ser implementada na camada de aplicativo ou na camada de banco de dados, por meio de sp_getapplock (Transact-SQL).

  • Em transações que utilizam o isolamento READ COMMITTED, cada declaração acessa a versão mais recente das linhas no banco de dados. Portanto, as instruções subsequentes presenciam alterações no estado do banco de dados.

    Sondar uma tabela usando um loop WHILE até que uma nova linha seja encontrada é um exemplo de um padrão de aplicativo que usa essa suposição. Com cada iteração do loop, a consulta verá as atualizações mais recentes no banco de dados.

    Regra: Se um aplicativo precisar sondar uma tabela com otimização de memória para obter as linhas mais recentes gravadas na tabela, mova o loop de sondagem para fora do escopo da transação.

    Veja a seguir um exemplo de padrão de aplicativo que usa essa suposição. Sondando uma tabela usando um loop WHILE até que uma nova linha seja encontrada. Em cada iteração de loop, a consulta acessará as atualizações mais recentes no banco de dados.

O script de exemplo a seguir sonda uma tabela t1 até que ela tenha uma linha. Em seguida, ele remove uma única linha da tabela para processamento adicional.

Observe que a lógica de consulta precisa estar fora do escopo da transação, pois está usando o isolamento por snapshot para acessar a tabela t1. Usar a lógica de sondagem dentro do escopo de uma transação criaria uma transação de execução longa, o que é uma má prática.

-- poll table  
WHILE NOT EXISTS (SELECT 1 FROM dbo.t1)  
BEGIN   
  -- if empty, wait and poll again  
  WAITFOR DELAY '00:00:01'  
END  
  
BEGIN TRANSACTION  
  DECLARE @id int  
  SELECT TOP 1 @id=id FROM dbo.t1 WITH (SNAPSHOT)  
  DELETE FROM dbo.t1 WITH (SNAPSHOT) WHERE id=@id  
  
  -- insert processing based on @id  
COMMIT

Dicas de tabela de bloqueio

Dicas de bloqueio (Dicas de Tabela (Transact-SQL)) como HOLDLOCK e XLOCK podem ser usadas com tabelas baseadas em disco para que o SQL Server tenha mais bloqueios do que o necessário para o nível de isolamento especificado.

Tabelas com otimização de memória não usam bloqueios. Níveis de isolamento mais altos, como REPEATABLE READ e SERIALIZABLE, podem ser usados para declarar as garantias desejadas.

Não há suporte para dicas de bloqueio. Em vez disso, declare as garantias necessárias por meio dos níveis de isolamento da transação. (Há suporte para NOLOCK porque o SQL Server não realiza bloqueios em tabelas com otimização de memória. Observe que, ao contrário das tabelas baseadas em disco, NOLOCK não implica comportamento READ UNCOMMITTED para tabelas com otimização de memória.)

Consulte Também

Noções básicas sobre transações em tabelas de Memory-Optimized
Diretrizes para a lógica de repetição de transações em tabelas de Memory-Optimized
Níveis de isolamento de transação

  • Last updated on