Acabei de ler um excelente artigo sobre níveis de isolamento aqui . Nossa empresa iniciará em breve o desenvolvimento de uma reescrita e expansão de nosso produto atual. Meu desejo é ter um banco de dados OLTP e um banco de dados de relatórios separado, mais desnormalizado. Supondo que sejamos um pouco disciplinados e que a maioria de nossas consultas ad-hoc e de tipo de relatório vá para o banco de dados de relatórios, parece apropriado que nosso banco de dados OLTP tenha um nível de isolamento padrão de Read Committed (não precisaremos de um isolamento mais rigoroso level para OLTP) e nosso banco de dados de relatórios seja Snapshot Isolation (provavelmente RCSI)?
Meu pensamento é que, se nosso banco de dados OLTP for realmente um banco de dados OLTP verdadeiro e não servir como um banco de dados de relatórios, não precisaremos de isolamento de instantâneo e da sobrecarga associada que isso acarreta. Mas o isolamento de instantâneo seria desejável no banco de dados de relatórios para que os leitores não sejam bloqueados pelo fluxo constante de dados que chegam, e a leitura da última versão salva de uma linha seria aceitável.
Apenas para adicionar à outra resposta.
O SQL Server oferece suporte a dois tipos diferentes de READ COMMITTED, travamento herdado READ COMMITTED e READ COMMITTED SNAPSHOT. Se você já criou e deu suporte a um aplicativo OLTP de alto volume no bloqueio de READ COMMITTED, sabe por que o RCSI foi introduzido (além de facilitar a portabilidade de aplicativos Oracle para o SQL Server).
Bloquear READ COMMITTED é complicado para obter simultaneidade e é propenso a bloqueios, pois leitores bloqueiam escritores e escritores bloqueiam leitores. Deadlocks são um tipo de bug em seu aplicativo, mas são difíceis de encontrar em testes. Assim, você tem a chance de fazer uma escolha que reduz o número de bugs difíceis de encontrar nos testes. Isso vale muito. O RCSI também aumenta a simultaneidade de seu aplicativo, permitindo que você escale verticalmente para usar vários núcleos com mais facilidade.
Assim, o RCSI aumenta a escalabilidade e a confiabilidade do seu aplicativo, ao custo de um pouco de contabilidade extra para UPDATES e DELETES (e INSERTS se você tiver um gatilho) e 14 bytes extras por linha.
O RCSI é mais simples de programar, o principal é que às vezes você precisa optar por uma leitura de bloqueio usando a dica de tabela UPDLOCK quando quiser ler uma linha e atualizá-la imediatamente e precisar garantir que nenhuma outra sessão faça o mesma coisa simultaneamente.
Eu não suporia que o instantâneo ou o INSTANTÂNEO COMMITIDO DE LEITURA necessariamente aumentarão sua sobrecarga que pode levar à degradação do desempenho - os tempos de espera reduzidos podem aumentar a taxa de transferência.
O perigo com RCS e SNAPSHOT tem mais a ver com como o aplicativo é codificado - se seus programadores assumirem a semântica de bloqueio de READ COMMITTED quando as consultas forem executadas no modo Snapshot, você poderá ter problemas. Por exemplo
provavelmente causará problemas em situações de alto rendimento porque vários leitores obterão o mesmo valor MAX(bar) ao mesmo tempo.
No entanto, você provavelmente ainda precisará de alguma forma de relatórios e consultas operacionais não OLAP, e o modo de instantâneo pode ser um grande benefício para o desempenho.
Meu ponto é que você pode projetar e desenvolver seu sistema OLTP para o modo RCS e deve considerá-lo. Afinal, é assim que a maioria dos sistemas OLTP no Oracle são escritos.