sql - Qual é o melhor nível de isolamento de transação padrão para um ERP, se houver?

99 vezes em 100, ler confirmado é a resposta certa. Isso garante que você veja apenas as alterações que foram confirmadas pela outra sessão (e, portanto, os resultados que são consistentes, supondo que você projetou suas transações corretamente). Mas não impõe a sobrecarga de bloqueio (particularmente em bancos de dados não Oracle) que a leitura repetível ou serializável impõe.

Muito ocasionalmente, você pode desejar executar um relatório no qual está disposto a sacrificar a precisão pela velocidade e definir um nível de isolamento de leitura não confirmado. Isso raramente é uma boa ideia, mas às vezes é uma solução alternativa razoavelmente aceitável para bloquear problemas de contenção.

Leituras serializáveis e repetíveis são ocasionalmente usadas quando você tem um processo que precisa ver um conjunto consistente de dados durante toda a execução, independentemente do que outras transações estão fazendo no momento. Pode ser apropriado definir um processo de reconciliação de final de mês para serializável, por exemplo, se houver muito código procedural, uma possibilidade de que os usuários façam alterações enquanto o processo está em execução e um requisito de que o processo precisa certifique-se de que ele está sempre vendo os dados como eles existiam no momento em que a reconciliação foi iniciada.

Não se esqueça de SNAPSHOT, que está logo abaixo de SERIALIZABLE.

Depende de quão importante é que os dados sejam precisos nos relatórios. É realmente uma tarefa tarefa a tarefa.

Realmente depende muito de como você projeta seu aplicativo, a resposta fácil é simplesmente executar em READ_COMMITTED.

Você pode argumentar que, se projetar seu sistema com isso em mente, poderá usar READ_UNCOMMITTED como o padrão e apenas aumentar o nível de isolamento quando necessário. A grande maioria de suas transações terá sucesso de qualquer maneira, portanto, ler dados não confirmados não será um grande problema.

A forma como os níveis de isolamento afetam suas consultas depende do banco de dados de destino. Por exemplo, bancos de dados como Sybase e MSSQL devem bloquear mais recursos quando você executa READ_COMMITTED do que bancos de dados como Oracle.

Para o SQL Server (e provavelmente a maioria dos principais RDBMS), eu ficaria com o padrão. Para o SQL Server, é READ COMMITTED. Qualquer coisa a mais e você começa a sobrecarregar o DB, qualquer coisa menos e você terá problemas de consistência.

Read Uncommitted é definitivamente o azarão na maioria dos fóruns. No entanto, há razões para usá-lo que vão além da questão de "velocidade versus precisão" que é freqüentemente apontada.

Digamos que você tenha:

• Transação T1: Escreve B, Lê A, (mais alguns trabalhos), Commit.
• Transação T2: Grava A, Lê B, (mais trabalho), Commit.

Com a leitura confirmada, as transações acima não serão liberadas até a confirmação. Então você pode se deparar com uma situação em que T1 está esperando T2 para liberar A, e T2 está esperando T1 para liberar B. Aqui as duas transações colidem em um bloqueio.

Você pode reescrever esses procedimentos para evitar este cenário (exemplo: adquira recursos sempre em ordem alfabética!). Ainda assim, com muitos usuários simultâneos e dezenas de milhares de linhas de código, esse problema pode se tornar muito provável e muito difícil de diagnosticar e resolver.

A alternativa é usar Read Uncommitted. Então você projeta suas transações assumindo que pode haver leituras sujas. Pessoalmente, acho esse problema muito mais localizado e tratável do que os destroços de trens interligados.

Os problemas de leituras sujas podem ser eliminados por

• (1) Rollbacks: não. Esta deve ser a última linha de defesa em caso de falha de hardware, falha de rede ou falha do programa apenas.

• (2) Use bloqueios de aplicativo para criar um mecanismo de bloqueio que opera em um nível mais alto de abstração, onde cada bloqueio está mais próximo de um recurso ou ação do mundo real.