Transações em tabelas de Memory-Optimized

O versionamento de linha nas tabelas em disco (usando isolamento SNAPSHOT ou READ_COMMITTED_SNAPSHOT) fornece uma forma de controle de concorrência otimista. Leitores e escritores não bloqueiam uns aos outros. Com tabelas otimizadas para memória, os escritores não bloqueiam outros escritores. Com o controle de versão de linha em tabelas baseadas em disco, uma transação bloqueia a linha e as transações simultâneas que tentam atualizar a linha são bloqueadas. Não há bloqueio para tabelas otimizadas para memória. Em vez disso, se duas transações tentarem atualizar a mesma linha, acontecerá um conflito de escrita/escrita (erro 41302).

Ao contrário das tabelas baseadas em disco, as tabelas otimizadas para memória permitem o controle de concorrência otimista com os níveis de isolamento mais elevados, REPEATABLE READ e SERIALIZABLE. Os bloqueios não são utilizados para impor os níveis de isolamento. Em vez disso, no final da validação da transação, garante as suposições de leitura ou serializabilidade repetíveis. Se as suposições forem violadas, a transação será encerrada. Para obter mais informações, consulte Níveis de isolamento de transações.

A semântica de transação importante para tabelas com otimização de memória é:

• Várias versões

• Isolamento de transação baseado em instantâneo

• Otimista

• Detecção de conflitos

Cada uma dessas semânticas é explicada nas seções a seguir.

Controle de versão múltipla em tabelas de Memory-Optimized

Linhas em tabelas com otimização de memória podem ter versões diferentes. Transações que ocorrem simultaneamente acessam versões potencialmente diferentes do mesmo registro.

Os dados da tabela com otimização de memória são baseados em versão. Para qualquer linha, pode haver versões de linha diferentes que são válidas em diferentes pontos no tempo. As tabelas baseadas em disco mantêm diferentes versões de linha quando READ_COMMITTED_SNAPSHOT ou ALLOW_SNAPSHOT_ISOLATION está ON. As tabelas com otimização de memória mantêm versões de linha diferentes, mesmo que READ_COMMITTED_SNAPSHOT e ALLOW_SNAPSHOT_ISOLATION estejam OFF. As versões de linha de tabelas com otimização de memória não são mantidas no tempdb. Em vez disso, as versões de linha são mantidas em linha, como parte das estruturas de dados com otimização de memória que armazenam as linhas na memória.

Isolamento de Transação Snapshot-Based para Tabelas Memory-Optimized

Todas as operações em uma única transação usam o mesmo instantâneo transacionalmente consistente das tabelas com otimização de memória. Todo o isolamento de transações para tabelas com otimização de memória é baseado em instantâneo. Por exemplo, uma transação usando o nível de isolamento serializável para acessar tabelas com otimização de memória executará todas as operações no mesmo instantâneo transacionalmente consistente.

As transações que acessam tabelas com otimização de memória usam esse controle de versão de linhas para obter uma visão transacionalmente consistente das linhas nas tabelas. Os dados lidos por qualquer instrução na transação serão a versão transacionalmente consistente dos dados que existiam no momento em que a transação foi iniciada. Portanto, as modificações feitas por transações em execução simultânea não são visíveis para instruções na transação atual.

Controle de concorrência otimista para tabelas de Memory-Optimized

Conflitos e falhas são raros e as transações em tabelas otimizadas para memória assumem que não há conflitos com transações simultâneas e que as operações são bem-sucedidas. Transações não utilizam bloqueios ou travas em tabelas otimizadas para memória para garantir o isolamento das transações. Escritores não bloqueiam leitores. Escritores não bloqueiam escritores. Em vez disso, as transações prossseguem sob a suposição (otimista) de que não haverá conflitos com outras transações. Não usar bloqueios e travas e não esperar que outras transações terminem de processar as mesmas linhas melhora o desempenho.

Além disso, se uma transação (TxA) ler linhas que foram inseridas ou modificadas por outra transação (TxB) que está em processo de confirmação, ela assumirá com otimismo que a outra transação será confirmada em vez de aguardar a confirmação ocorrer. Nesse caso, a transação TxA assumirá uma dependência de commit na transação TxB.

Detecção de Conflitos, Validação e Verificações de Dependência de Confirmação

O SQL Server detecta conflitos entre transações simultâneas, bem como violações de nível de isolamento e condena uma das transações conflitantes. Essa transação precisará ser repetida. (Para obter mais informações, consulte Diretrizes para lógica de repetição para transações em tabelas de Memory-Optimized.)

O sistema assume com otimismo que não há conflitos e nenhuma violação do isolamento de transações. Se ocorrerem conflitos que possam causar inconsistências no banco de dados ou que possam violar o isolamento da transação, esses conflitos serão detectados e a transação será encerrada.

Se um conflito for detectado, a transação será encerrada e o cliente precisará tentar novamente.

A tabela a seguir resume as condições de erro para transações que acessam tabelas com otimização de memória.

Condições de erro para transações que acessam tabelas com otimização de memória.

Erro	Cenário
Conflito de gravação. Tentando atualizar um registro que foi atualizado desde que a transação foi iniciada.	ATUALIZAR ou EXCLUIR uma linha que foi atualizada ou excluída por uma transação simultânea.
Falha de validação de leitura repetível.	Uma linha que foi lida pela transação foi alterada (atualizada ou excluída) desde que a transação foi iniciada. A validação de leitura repetível geralmente ocorre ao usar as opções de isolamento de transação REPEATABLE READ e SERIALIZABLE.
Falha de validação serializável.	Uma nova linha (fantasma) foi inserida em um dos intervalos de verificação na transação, desde que a transação foi iniciada. A linha estaria visível para a transação se a linha tivesse sido confirmada no banco de dados antes do início da transação. A validação SERIALIZABLE normalmente ocorre ao usar o isolamento SERIALIZABLE e validar restrições de chave primária.
Confirmar falha de dependência.	A transação dependia de outra transação que não conseguiu ser confirmada, seja por uma das falhas na tabela de erros, por uma condição de falta de memória, ou por falha na confirmação no log de transações. Essa falha pode ocorrer com transações de leitura/gravação e somente leitura.

Tempo de vida da transação

As falhas mencionadas na tabela anterior podem ocorrer em pontos diferentes durante uma transação. A figura a seguir ilustra as fases de uma transação que acessa tabelas com otimização de memória.

Tempo de vida de uma transação que acessa tabelas com otimização de memória.

Processamento regular

Durante essa fase, as instruções Transact-SQL emitidas pelo usuário são executadas. As linhas são lidas das tabelas e as novas versões de linha são gravadas no banco de dados. A transação é isolada de todas as outras transações simultâneas. A transação utiliza o instantâneo das tabelas otimizadas para memória que existem no início da transação.

As gravações nas tabelas nesta fase da transação ainda não estão visíveis para outras transações, com uma exceção: as atualizações e exclusões de linha são visíveis para operações de atualização e exclusão em outras transações, a fim de detectar conflitos de gravação.

Se uma operação de atualização ou exclusão vir que uma linha foi atualizada ou excluída desde o início lógico da transação, a operação falhará com o erro 41302. A mensagem para o erro 41302 é "A transação atual tentou atualizar um registro na tabela X que foi atualizado desde que essa transação foi iniciada. A transação foi anulada."

Esse erro condena a transação (mesmo que XACT_ABORT esteja OFF), o que significa que a transação será revertida quando a sessão do usuário terminar. Transações condenadas não podem ser confirmadas e só dão suporte a operações de leitura que não efetuam gravação no log e não acessam tabelas otimizadas para uso de memória.

Confirmar dependências

Durante o processamento regular, uma transação pode ler linhas gravadas por outras transações que estão na fase de validação ou confirmação, mas ainda não foram confirmadas. As linhas são visíveis porque a hora de término lógica das transações foi atribuída no início da fase de validação.

Se uma transação ler essas linhas não confirmadas, ela assumirá uma dependência de confirmação nessa transação. Isso tem duas implicações principais:

• Uma transação não pode ser confirmada até que as transações das quais ela depende tenham sido confirmadas. Em outras palavras, ele não pode entrar na fase de confirmação até que todas as dependências tenham sido resolvidas.

• Além disso, conjuntos de resultados não são retornados ao cliente até que todas as dependências tenham sido resolvidas. Isso impede que o cliente observe dados não confirmados.

Se alguma das transações dependentes falhar na confirmação, haverá uma falha de dependência de confirmação. Isso significa que a transação não será confirmada devido ao erro 41301 ("Uma transação anterior, da qual a transação atual dependia, foi anulada, e a transação atual não pode mais ser confirmada.").

Fase de validação

Durante a fase de validação, o sistema valida que as suposições necessárias para o nível de isolamento da transação solicitada eram verdadeiras entre o início lógico e o final lógico da transação.

No início da fase de validação, uma hora de término lógica é atribuída à transação. As versões de linha registradas no banco de dados ficam visíveis para outras transações no momento lógico de término. Para obter mais informações, consulte Commit Dependencies.

Validação de leitura repetível

Se o nível de isolamento da transação for REPEATABLE READ ou SERIALIZABLE, ou se as tabelas forem acessadas sob o isolamento REPEATABLE READ ou SERIALIZABLE (para obter mais informações, consulte a seção sobre Isolamento de Operações Individuais em Níveis de Isolamento de Transação), o sistema valida que as leituras são repetíveis. Isso significa que ela valida que as versões das linhas lidas pela transação ainda são versões de linha válidas na hora de término lógica da transação.

Se alguma das linhas tiver sido atualizada ou alterada, a transação falhará ao confirmar com o erro 41305 ("A transação atual não foi confirmada devido a uma falha de validação de leitura repetível.").

Esse erro também poderá ocorrer se uma tabela for descartada após uma operação de inserção, atualização ou exclusão e antes da confirmação da transação. Isso se aplica apenas a operações de inserção, atualização ou exclusão em procedimentos armazenados compilados nativamente. Essas operações de gravação realizadas por meio da interpretação de Transact-SQL fazem com que a instrução DROP TABLE seja bloqueada e aguarde até que a transação seja confirmada.

Validação serializável

A validação serializável é executada em dois casos:

• Se o nível de isolamento da transação for SERIALIZABLE ou se o acesso às tabelas ocorrer sob isolamento SERIALIZABLE.

• Se as linhas forem inseridas em um índice exclusivo, como o índice criado para uma restrição de chave primária. O sistema valida que nenhuma linha com a mesma chave foi inserida simultaneamente.

O sistema valida que nenhuma linha fantasma foi gravada no banco de dados. As operações de leitura executadas pela transação são avaliadas para determinar que nenhuma nova linha foi inserida nos intervalos de leitura dessas operações de leitura.

A inserção de uma chave em um índice exclusivo inclui uma operação de leitura implícita para determinar que a chave não é uma duplicata. A validação serializável para índices exclusivos garante que esses índices não possam ter duplicatas caso duas transações insiram simultaneamente a mesma chave.

Se linhas fantasmas forem detectadas, a transação falhará ao confirmar com o erro 41325 ("A transação atual não foi confirmada devido a uma falha de validação serializável).").

Processamento de Commit

Se a validação for bem-sucedida e todas as dependências de transação forem liberadas, a transação entrará na fase de processamento de confirmação. Durante essa fase, as alterações nas tabelas duráveis são registradas no log, que por sua vez é gravado em disco, para garantir a durabilidade. Depois que o registro de log da transação tiver sido gravado em disco, o controle será retornado ao cliente.

Todas as dependências de confirmação dessa transação são liberadas, e todas as transações que estavam aguardando a confirmação dessa transação podem prosseguir.

Limitações

• Não há suporte para transações entre bancos de dados com tabelas com otimização de memória. Cada transação que acessa tabelas com otimização de memória não pode acessar mais de um banco de dados, com exceção do acesso de leitura/gravação ao tempdb e acesso de somente leitura ao banco de dados mestre do sistema.

• Não há suporte para transações distribuídas com tabelas com otimização de memória. As transações distribuídas iniciadas com BEGIN DISTRIBUTED TRANSACTION não podem acessar tabelas com otimização de memória.

• Tabelas com otimização de memória não dão suporte ao bloqueio. Bloqueios explícitos por meio de dicas de bloqueio (como TABLOCK, XLOCK, ROWLOCK) não são suportados com tabelas otimizadas para memória.

Consulte Também

Noções básicas sobre transações em tabelas de Memory-Optimized