Descrever concorrência

  • 4 minutos

Um recurso principal de bancos de dados multiusuários é a simultaneidade. A simultaneidade usa bloqueios para permitir que os dados permaneçam consistentes quando há muitos usuários atualizando e lendo dados ao mesmo tempo. Por exemplo, devido aos custos de envio, todos os nossos produtos têm um aumento de preço de US$ 5. Ao mesmo tempo, devido a taxas de moeda, todos os produtos têm uma redução de preço de 3%. Se essas atualizações ocorrerem exatamente ao mesmo tempo, o preço final será variável e provavelmente haverá muitos erros. Usando o bloqueio, você pode garantir que uma atualização será concluída antes do início da outra.

A concorrência ocorre no nível da transação. Uma transação de gravação pode impedir que outras transações atualizem e até mesmo leiam os mesmos dados. Da mesma forma, uma transação de leitura pode bloquear outros leitores ou até mesmo alguns escritores. Por esse motivo, é importante evitar transações ou transações desnecessariamente longas que abrangem quantidades excessivas de dados.

Há muitos níveis de isolamento de transações específicos que podem ser usados para definir como um sistema de banco de dados lida com vários usuários. Para fins deste módulo, examinaremos categorias amplas de nível de isolamento, bloqueio otimista e bloqueio pessimista.

Observação

O detalhe completo do bloqueio de transações além da simultaneidade está relacionado mais ao desempenho e não apenas dependendo do código, embora um bom código tenha um desempenho melhor. Para obter mais detalhes, examine o SQL Server guia de bloqueio de transações e controle de versão de linha. Para obter informações sobre bloqueio, examine também a documentação de desempenho do SQL Server.

Concorrência otimista

Com o bloqueio otimista, há uma suposição de que algumas atualizações conflitantes ocorrerão. No início da transação, o estado inicial dos dados é registrado. Antes que a transação seja confirmada, o estado atual é comparado com o estado inicial. Se os estados forem os mesmos, a transação será concluída. Se os estados forem diferentes, a transação será revertida.

Por exemplo, você tem uma tabela que contém os pedidos de vendas dos últimos anos. Esses dados são raramente atualizados, mas os relatórios são executados com frequência. Usando o bloqueio otimista, as transações não bloqueiam umas às outras e o sistema é executado com mais eficiência. Infelizmente, erros foram encontrados nos últimos anos e as atualizações precisam ocorrer. Enquanto uma transação está atualizando cada linha, outra transação faz uma pequena edição para uma única linha ao mesmo tempo. Como o estado dos dados foi alterado enquanto a transação inicial estava em execução, toda a transação é revertida.

Concorrência pessimista

Com o bloqueio pessimista, há uma suposição de que muitas atualizações estão ocorrendo com os dados ao mesmo tempo. Usando bloqueios, apenas uma atualização pode ocorrer ao mesmo tempo e as leituras dos dados são evitadas enquanto as atualizações estão ocorrendo. Isso pode impedir grandes reversões, como visto no exemplo anterior, mas pode fazer com que as consultas sejam bloqueadas desnecessariamente.

É importante considerar a natureza de seus dados e as consultas em execução nos dados ao decidir se deseja usar simultaneidade otimista ou pessimista para garantir o desempenho ideal.

Isolamento de instantâneo

SQL Server dá suporte a cinco níveis de isolamento de transação—READ UNCOMMITTED e REPEATABLE READREAD COMMITTEDSNAPSHOT— definidos SERIALIZABLEpor sessão com .SET TRANSACTION ISOLATION LEVEL Separadamente, READ_COMMITTED_SNAPSHOT é uma opção no nível do banco de dados (definida com ALTER DATABASE) que altera a forma como o READ COMMITTED nível de isolamento se comporta. Para este módulo, nos concentramos nessas duas configurações de opção de banco de dados, pois elas determinam se as transações padrão READ COMMITTED usam bloqueio pessimista ou controle de versão de linha.

  • Com READ_COMMITTED_SNAPSHOT OFF (o padrão para SQL Server), READ COMMITTED as transações adquirem bloqueios compartilhados em linhas que leem e as mantêm até que a leitura seja concluída. Isso impede que as alterações mais conflitantes nos dados sejam lidas e é uma forma de simultaneidade pessimista.
  • Com READ_COMMITTED_SNAPSHOT ON (o padrão para Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure), READ COMMITTED as transações usam o controle de versão de linha armazenado em tempdb. Cada instrução vê a última versão confirmada de cada linha a partir de quando essa instrução começou, de modo que os leitores nunca bloqueiam escritores e escritores nunca bloqueiam os leitores. Os escritores ainda adquirem bloqueios exclusivos padrão, portanto, gravações simultâneas na mesma linha ainda bloqueiam umas às outras. Essa é uma forma de simultaneidade otimista para leituras, mas observe que não há detecção automática de conflito de tempo de confirmação para gravações; esse comportamento pertence ao nível de isolamento separado SNAPSHOT .

Para ativar READ_COMMITTED_SNAPSHOT , execute:

ALTER DATABASE <db_name> SET READ_COMMITTED_SNAPSHOT ON;

Para desativá-lo:

ALTER DATABASE <db_name> SET READ_COMMITTED_SNAPSHOT OFF;

Se o banco de dados tiver sido alterado para ativar o instantâneo confirmado de leitura, qualquer transação que use o nível de isolamento padrão READ COMMITTED usará o controle de versão de linha em vez de bloqueios de leitura compartilhados.

Observação

A opção READ_COMMITTED_SNAPSHOT de banco de dados afeta apenas as transações em execução no READ COMMITTED nível de isolamento. As transações que usam explicitamente outros níveis de isolamento (REPEATABLE READSERIALIZABLEou SNAPSHOT) não são afetadas por essa opção.