Codificando transações eficientes
É importante manter as transações tão curtas quanto possível. Quando uma transação é iniciada, um DBMS (Sistema de administração de banco de dados), deve manter muitos recursos, até o término da transação, para proteger as propriedades (ACID) de atomicidade, consistência, isolamento e durabilidade da transação. Se os dados forem modificados, as linhas modificadas devem ser protegidas com bloqueios exclusivos que evitem a leitura das linhas por qualquer outra transação, e os bloqueios exclusivos devem ser mantidos até que a transação seja confirmada ou revertida. Dependendo das configurações de nível de isolamento da transação, as instruções SELECT podem obter bloqueios que devem ser mantidos até que a transação esteja confirmada ou revertida. Especialmente em sistemas com muitos usuários, as transações devem ser mantidas tão curtas quanto possível para reduzir a contenção de bloqueios de recursos em conexões simultâneas. Transações longas e ineficazes podem não causar problemas com um número pequeno de usuários, mas são intoleráveis em um sistema com milhares de usuários.
Codificando diretrizes
Estas são diretrizes para codificar transações eficazes:
Não solicite entradas de usuários durante a transação.
Obtenha todas as entradas necessárias da parte dos usuários antes do início de uma transação. Sendo necessária uma entrada adicional de usuário durante uma transação, reverta a transação atual e reinicie a transação depois que a entrada do usuário for fornecida. Mesmo que os usuários respondam imediatamente, a reação humana é muito mais lenta que a velocidade do computador. Todos os recursos mantidos pela transação são retidos por um tempo extremamente longo, criando potencial para causar problemas de bloqueio. Se os usuários não responderem, a transação permanecerá ativa, bloqueando recursos críticos até que eles respondam, o que pode não acontecer por vários minutos ou até mesmo horas.
Não abra uma transação enquanto estiver navegando pelos dados, se possível.
As transações não devem ser iniciadas até que toda a análise preliminar de dados tenha terminado.
Mantenha a transação tão curta quanto possível.
Depois de saber quais são as modificações que precisam ser feitas, inicie uma transação, execute as instruções de modificação e, em seguida, confirme ou reverta imediatamente. Só abra a transação quando for necessário.
Para reduzir o bloqueio, considere usar um nível de isolamento de linha baseado em versão para consultas somente leitura. Para obter mais informações, consulte Usando níveis de isolamento com base em controle de versão de linha.
Utilize bem os níveis de isolamento de transação inferiores.
Muitos aplicativos podem ser prontamente codificados para usar um nível de isolamento de transação confirmada por leitura. Nem todas as transações requerem nível de isolamento de transação serializável.
Utilize bem as opções inferiores de simultaneidade de cursor, como opções de simultaneidade otimista.
Em um sistema com pouca probabilidade de atualizações simultâneas, a sobrecarga de lidar com um erro ocasional quando "alguém altera seus dados depois que você os leu" pode ser muito inferior à sobrecarga de sempre bloquear linhas à medida que são lidas.
Acesse a menor quantidade de dados possível enquanto estiver em uma transação.
Isso reduz o número de linhas bloqueadas, reduzindo, portanto, a contenção entre transações.
Evitando problemas de simultaneidade e de recurso
Para impedir problemas de simultaneidade e de recurso, gerencie cuidadosamente as transações implícitas. Ao usar transações implícitas, a próxima instrução do Transact-SQL após COMMIT ou ROLLBACK iniciará automaticamente uma nova transação. Isso pode fazer com que uma nova transação seja aberta enquanto o aplicativo navega pelos dados, ou até mesmo quando solicita entradas da parte do usuário. Depois de completar a última transação necessária à proteção contra modificações de dados, desative as transações implícitas até que a transação seja novamente necessária para proteger as modificações de dados. Esse processo deixa o Mecanismo de Banco de Dados do SQL Server usar o modo autocommit enquanto o aplicativo navega pelos dados e obtém entradas do usuário.
Além disso, quando o nível de isolamento do instantâneo estiver habilitado, embora uma nova transação não mantenha bloqueios, uma transação de execução longa impedirá que as antigas versões sejam removidas de tempdb.