Transações entre contêineres

As transações entre contêineres são transações de usuário implícitas ou explícitas que incluem chamadas para procedimentos armazenados compilados nativamente ou operações em tabelas com otimização de memória.

No SQL Server, as chamadas para procedimentos armazenados não iniciam uma transação. Execuções de procedimentos compilados nativamente no modo de confirmação automática (não no contexto de uma transação de usuário) não são consideradas transações entre contêineres.

Qualquer consulta interpretada que faça referência a tabelas com otimização de memória é considerada parte de uma transação entre contêineres, seja executada de uma transação explícita ou implícita ou no modo de confirmação automática.

Isolamento de operações individuais

Cada transação do SQL Server tem um nível de isolamento. O nível de isolamento padrão é Read Committed. Para usar um nível de isolamento diferente, você pode definir o nível de isolamento usando SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

Geralmente, é necessário executar operações em tabelas com otimização de memória em um nível de isolamento diferente das operações em tabelas baseadas em disco. Em uma transação, é possível definir um nível de isolamento diferente para uma coleção de instruções ou para uma operação de leitura individual.

Especificando o nível de isolamento de operações individuais

Para definir um nível de isolamento diferente para um conjunto de instruções em uma transação, você pode usar SET TRANSACTION ISOLATION LEVEL. O exemplo a seguir de uma transação usa o nível de isolamento serializável como padrão. As operações de inserção e seleção em t3, t2 e t1 são executadas sob isolamento de leitura repetível.

set transaction isolation level serializable  
go  
  
begin transaction  
 ......  
  set transaction isolation level repeatable read  
  
  insert t3 select * from t1 join t2 on t1.id=t2.id  
  
  set transaction isolation level serializable  
 ......  
commit  

Para definir um nível de isolamento para operações de leitura individuais que seja diferente do padrão da transação, você pode usar um indicador de tabela (por exemplo, serializável). Cada seleção corresponde a uma operação de leitura e a cada atualização e cada exclusão corresponde a uma leitura, pois a linha sempre precisa ser lida antes de ser atualizada ou excluída. As operações de inserção não têm um nível de isolamento, pois as gravações são sempre isoladas no SQL Server. No exemplo a seguir, o nível de isolamento padrão da transação é "read committed", mas a tabela t1 é acessada sob o modo "serializable" e t2 sob "snapshot isolation".

set transaction isolation level read committed  
go  
  
begin transaction  
 ......  
  
  insert t3 select * from t1 (serializable) join t2 (snapshot) on t1.id=t2.id  
  
  ......  
commit  

Semântica de isolamento para operações individuais

Uma transação serializável T é executada em isolamento completo. É como se todas as outras transações tenham sido confirmadas antes de T iniciar ou tenham sido iniciadas após a confirmação de T. Torna-se mais complexo quando operações diferentes em uma transação têm níveis de isolamento diferentes.

A semântica geral dos níveis de isolamento da transação no SQL Server, juntamente com as implicações no bloqueio, é explicada em SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

Para transações entre contêineres em que operações diferentes podem ter níveis de isolamento diferentes, você precisa entender a semântica de isolamento de operações de leitura individuais. As operações de gravação são sempre isoladas. Gravações em transações diferentes não podem afetar umas às outras.

Uma operação de leitura de dados retorna várias linhas que atendem a uma condição de filtro.

As leituras são executadas como parte de uma transação T. Os níveis de isolamento para operações de leitura podem ser compreendidos em termos de,

Status de confirmação
O status de confirmação refere-se a se a leitura de dados tem garantia de ser confirmada.

(Transacional) Consistência
A consistência transacional para um conjunto de leituras refere-se a verificar se as versões de linha lidas têm garantia de incluir atualizações precisamente do mesmo conjunto de transações.

A estabilidade garante que o sistema dê à transação T sobre a leitura de dados.
A estabilidade refere-se a se as leituras da transação são repetíveis. Ou seja, se as leituras fossem repetidas, elas retornariam as mesmas linhas e versões de linha?

Determinadas garantias referem-se à hora de término lógica da transação. Em geral, a hora de término lógico é a hora em que a transação é confirmada no banco de dados. Se as tabelas otimizadas para memória forem acessadas pela transação, o momento lógico de término será tecnicamente o início da fase de validação. (Para obter mais informações, consulte a discussão de tempo de vida da transação em Transações em tabelas de Memory-Optimized.

Independentemente do nível de isolamento, uma transação (T) sempre vê suas próprias atualizações:

LEITURA NÃO COMMITADA
A leitura de dados pode não ser confirmada, nem consistente, nem estável. No entanto, ele incluirá operações de gravação anteriores realizadas por T.

LEITURA CONFIRMADA
Os dados lidos serão confirmados.

INSTANTÂNEO
Todas as operações de leitura realizadas por T sob isolamento por instantâneo têm o mesmo tempo lógico de leitura: o início da transação. A leitura de dados tem a garantia de ser confirmada e consistente a partir do tempo de leitura lógico. A repetição de uma leitura no momento da leitura original é garantida para retornar o mesmo resultado.

LEITURA REPETÍVEL
A leitura de dados tem a garantia de ser confirmada e estável até a hora de término lógica da transação.

SERIALIZÁVEL
Todas as garantias de REPEATABLE READ, além da evitação de phantom e consistência transacional em relação a todas as operações de leitura serializáveis executadas por T. Evitação de phantom significa que a operação de varredura só pode retornar linhas adicionais que foram gravadas por T, sem incluir linhas que foram gravadas por outras transações.

Considere a transação a seguir,

set transaction isolation level read committed  
go  
  
begin transaction  
  -- remove all rows from t3; the related read operation is performed under read committed   
  -- isolation, as this is the default for the transaction  
  delete from t3  
  
  -- copy the contents from t1 to t3; the read on t1 is performed under the serializable   
  -- isolation level  
  insert t3 select * from t1 (serializable)  
  
  -- compare t3 and t1; note: the result set may not be empty, as rows may have been added   
  -- by other transaction before this select, due to the read committed isolation level  
  select * from t3 except t1  
  
  -- compare t1 and t3; note: the result set is empty, as no rows have been added to t1   
  -- since its contents were copied to t1, due to the serializable isolation level  
  select * from t1 except t3  
commit  

Essa transação exclui todas as linhas do t3 sob isolamento confirmado de leitura, copia todas as linhas de t1 para t3 sob isolamento serializável e compara t1 e t3. Algumas linhas [não em t1] podem ter sido adicionadas a t3 desde que a tabela foi esvaziada. Nenhuma linha foi adicionada a t1, pois a cópia era serializável.

Embora a leitura de t1 no final da transação seja sintaticamente leitura cometida, ela é efetivamente serializável, pois a mesma leitura foi executada anteriormente na transação em isolamento serializável: a serializabilidade garante que, se a leitura for executada em qualquer ponto subsequente da transação, as mesmas linhas serão retornadas.

Transações entre contêineres e níveis de isolamento

Uma transação entre contêineres pode ser vista como tendo dois lados: um lado baseado em disco (para operações em tabelas baseadas em disco) e um lado com otimização de memória (para operações em tabelas com otimização de memória). Esses dois lados podem ter níveis de isolamento diferentes. Na verdade, as operações de leitura individuais em cada lado podem ter níveis de isolamento diferentes.

O lado baseado em disco de uma determinada transação T atingirá um determinado nível de isolamento X se uma das seguintes condições for atendida:

• Ele começa em X. Ou seja, o padrão da sessão era X, seja porque você executou SET TRANSACTION ISOLATION LEVELou é o padrão do SQL Server.

• Durante a transação, o nível de isolamento padrão é alterado para X usando SET TRANSACTION ISOLATION LEVEL.

• Uma operação de leitura em uma tabela baseada em disco é executada no nível de isolamento X, usando a sintaxe WITH (X).

O lado com otimização de memória de T atingirá um nível de isolamento Y se durante a execução de T, qualquer operação de leitura em uma tabela com otimização de memória ou qualquer procedimento armazenado compilado nativamente for executado no nível de isolamento Y.

Considere a transação a seguir como um exemplo. Aqui, t1 e t2 são tabelas baseadas em disco e t3 e t4 são tabelas com otimização de memória.

O lado baseado em disco da transação atinge o nível de isolamento lido confirmado, porque ele começa nesse nível. O lado baseado em disco também atinge leitura repetível, pois a primeira operação de leitura é executada nesse nível de isolamento. A exclusão no final da transação é executada no nível de isolamento confirmado de leitura e, portanto, não introduz um novo nível de isolamento.

O lado com otimização de memória da transação pode atingir um dos dois níveis: se a condição1 for verdadeira, ela alcançará serializável, enquanto se for falsa, o lado com otimização de memória alcançará apenas o isolamento de instantâneos.

set transaction isolation level read committed  
go  
  
begin transaction  
  select * from t1 (repeatableread)  
  
  if condition1 begin  
    insert t3 select * from t4 (serializable)  
  end  
  else begin  
    insert t3 select * from t4 (snapshot)  
  end  
  
  delete from t1  
commit  

Níveis de isolamento com suporte para transações entre contêineres

Há limitações nos níveis de isolamento usados com operações em tabelas com otimização de memória em transações entre contêineres.

Tabelas otimizadas para memória oferecem suporte aos níveis de isolamento SNAPSHOT, REPEATABLE READ e SERIALIZABLE. Para transações de confirmação automática, as tabelas com otimização de memória dão suporte ao nível de isolamento READ COMMITTED.

Os cenários a seguir têm suporte:

• Transações READ UNCOMMITTED, READ COMMITTED e READ_COMMITTED_SNAPSHOT realizadas entre diferentes contêineres podem acessar tabelas otimizadas para memória em isolamento SNAPSHOT, REPEATABLE READ e SERIALIZABLE. A garantia READ COMMITTED é garantida para a transação; todas as linhas lidas pela transação foram confirmadas no banco de dados.

• As transações REPEATABLE READ e SERIALIZABLE podem acessar tabelas com otimização de memória em isolamento SNAPSHOT.

Transações somente leitura entre contêineres

A maioria das transações somente leitura no SQL Server são desfeitas no momento da confirmação. Como não há alterações para confirmar no banco de dados, o sistema simplesmente libera os recursos usados pela transação. Para transações baseadas em disco somente leitura, todos os bloqueios feitos pela transação são soltos neste momento. Para transações de otimização de memória somente leitura que abrangem a execução de um único procedimento compilado nativamente, não é realizada nenhuma validação.

Transações entre contêineres e somente leitura no modo de confirmação automática são simplesmente revertidas no final da transação. Nenhuma validação é executada.

Transações de somente leitura, explícitas ou implícitas, entre contêineres, executam a validação no momento da confirmação se a transação acessa tabelas otimizadas para memória em isolamento REPEATABLE READ ou SERIALIZABLE. Para obter detalhes sobre a validação, consulte a seção sobre Detecção de Conflitos, Validação e Confirmação de Verificações de Dependência em Transações em Tabelas Memory-Optimized.

Consulte Também

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