Nível de isolamento de uma transacção

Vamos considerar uma transacção que apenas lê dados. Enquanto está a ser executada, o que pode demorar uns segundos ou algumas horas, os dados que ela lê podem ser alterados por outras transacções, o que coloca em perigo a integridade do seu resultado. Este problema coloca-se apenas com os dados de leitura, pois quando a transacção altera dados a base de dados activa LOCKS que impedem a sua modificação em simultâneo por outras transacções.

Em termos teóricos, enquanto a transacção decorre os dados por ela vistos não podem ser alterados. A solução fácil para este problema é bloquear os dados que estão a ser lidos(LOCK), o que impediria alterações por outros utilizadores. Mas isto viola um princípio importante: numa base de dados quem lê dados não pode prejudicar quem escreve. Para ultrapassar este problema a base de dados deve fornecer um mecanismo que permita à transacção, durante a sua duração, trabalhar com a imagem inicial dos dados, tornando-a assim imune a alterações.

O nível de isolamento de uma transacção mede a independência desta em relação às alterações nos dados por ela lidos feitas por outras transacções. Uma transacção tem um elevado nível de isolamento se for absolutamente imune a essas alterações. Pelo contrário, será pouco isolada se os seus resultados perderem integridade com as alterações feitas por outras transacções.

A norma SQL92 define 4 níveis de isolamento de transacções aos quais correspondem diferentes graus de impacto nos resultados. Estes níveis são definidos tendo em conta 3 situações que podem ocorrer quando são executadas simultaneamente duas transacções que acedem aos mesmos dados concorrentemente:

• DIRTY READS - A transacção 2 consegue ler dados que foram alterados pela transacção 1 embora a transacção 1 ainda não tenha confirmado essas alterações;
• NONREPEATABLE (FUZZY) READS - Dentro da mesma transacção são executadas duas consultas. O resultado da primeira difere do resultado da segunda porque tem menos uma linha ou porque uma linha tem um conteúdo diferente. Isto porque entre a primeira e a segunda consulta outra transacção apagou uma linha ou modificou uma linha;
• PHANTOM READS - Dentro da mesma transacção são executadas duas consultas. O resultado da primeira difere do resultado da segunda porque tem menos linhas. Isto porque entre a primeira e a segunda consulta outra transacção inseriu uma nova linha;

O quadro abaixo descreve a forma como os 4 níveis de isolamento definidos pela norma SQL92 se comportam perante as 3 situações referidas antes:

Os níveis de isolamento disponibilizados na base de dados Oracle são READ COMMITTED e SERIALIZABLE. Por omissão funciona no modo READ COMMITTED o que significa que não é possível ocorrerem DIRTY READS, mas podem ocorrer NONREPEATABLE (FUZZY) READS ou PHANTOM READS. O exemplo a seguir apresentado comparam os dois níveis de isolamento e a forma como a transacção é por eles afectada.

• READ COMMITTED
• SERIALIZABLE

READ COMMITTED

O nível de isolamento usado por omissão pela base de dados Oracle é READ COMMITED. No exemplo abaixo vamos abrir duas sessões e vamos executar comandos em cada uma delas.

drop table teste;
create table teste (
   id number(10,0),
   nome varchar2(10),
   constraint pk_teste primary key (id)
);

commit;
select * from teste;

insert into teste (id,nome) 
    values (1,'aaaaaa');
insert into teste (id,nome) 
    values (2,'bbbbbb');
insert into teste (id,nome) 
    values (3,'cccccc');

select * from teste;

select * from teste;

commit;

select * from teste;

update teste
  set nome = 'CCCCCC'
  where id=3;
commit;
select * from teste;

select * from teste;

delete from teste 
  where id = 2;
commit;
select * from teste;

select * from teste;

insert into teste (id,nome) values (4,'dddddd');
commit;
select * from teste;

select * from teste;

commit;

select * from teste;

• Este exemplo mostra que a Sessão 2 só consegue ver as alterações feitas pela Sessão 1 que foram confirmadas;
• Este exemplo mostra que a Sessão 2 executou o mesmo SELECT várias vezes dentro da mesma transacção, tendo obtido resultados diferentes em cada execução o que mostra que foi sensível a alterações feitas aos dados por outras transacções;

Este nível de isolamento evita DIRTY READS, mas não garante REPEATABLE READS. Por ser um bom compromisso entre desempenho e coerência de dados é o nível de isolamento usado por omissão na base de dados Oracle.

Topo

SERIALIZABLE

Se o utilizador quizer um elevado nível de isolamento para a sua transacção a base de dados disponibiliza o modo de funcionamento SERIALIZABLE, que pode ser activado ao nível da sessão ou ao nível da transacção, usando os comandos abaixo:

--alterar ao nível da sessão
ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE;

--alterar ao nível da transacção
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

O nível de isolamento por omissão pode ser reposto com os comandos abaixo:

--alterar ao nível da sessão
ALTER SESSION SET ISOLATION_LEVEL = READ COMMITTED;

--alterar ao nível da transacção
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

No exemplo abaixo os comandos executados nas duas sessões são identicos aos que foram usados no ponto anterior, mas a sessão 2 activa o modo SERIALIZABLE.

drop table teste;
create table teste (
   id number(10,0),
   nome varchar2(10),
   constraint pk_teste primary key (id)
);

commit;
SET TRANSACTION 
    ISOLATION LEVEL SERIALIZABLE;
select * from teste;

insert into teste (id,nome) 
    values (1,'aaaaaa');
insert into teste (id,nome) 
    values (2,'bbbbbb');
insert into teste (id,nome) 
    values (3,'cccccc');

select * from teste;

select * from teste;

commit;

select * from teste;

update teste
  set nome = 'CCCCCC'
  where id=3;
commit;
select * from teste;

select * from teste;

delete from teste 
  where id = 2;
commit;
select * from teste;

select * from teste;

insert into teste (id,nome) values (4,'dddddd');
commit;
select * from teste;

select * from teste;

commit;

select * from teste;

• Este exemplo mostra que a Sessão 2 só consegue ver as alterações feitas pela Sessão 1 que foram confirmadas;
• Este exemplo mostra que a Sessão 2 executou o mesmo SELECT várias vezes dentro da mesma transacção, tendo obtido sempre o mesmo resultado, mesmo com transacções externas a fazerem INSERT, UPDATE e DELETE. O grau de isolamento foi total;

Como o isolamento foi definido ao nível da transacção, quando esta termina a sessão volta a trabalhar com o nível READ COMMITED. Do ponto de vista teórico o nível SERIALIZABLE é muito interessante, mas na prática obriga a base de dados a um trabalho extra muito pesado, pois tem que guardar uma fotografia dos dados num determinado instante no tempo. Isto consome espaço adicional nos segmentos de rollback, que têm armazenamento finito, e obriga a uma carga acrescida de I/O e CPU. Na maior parte das situações o nível READ COMMITED é suficiente, sendo por isso o nível por omissão. O programador deve estar atento às situações especiais onde é requerido o nível SERIALIZABLE para o activar.

Até há pouco tempo atrás algumas bases de dados disponíveis no mercado não faziam sequer READ COMMITED.

Topo

Realizado por Turtle Learning ®. Última alteração em 2011-02-26