serialização da execução das transações. Para isto, utiliza um conjunto de regras, também chamadas de protocolos. Para melhor entendimento desses protocolos, temos de compreender, primeiro, os problemas que podem ocorrer em um banco de dados e, obviamente, sobre as transações sobre ele executadas.
4.2 Problemas de concorrência
Existem três problemas cruciais que os mecanismos de controle de concor- rência de um SGBD devem tratar:
atualização perdida ( • lost update ) dependência sem • commit análise inconsistente •
Esses três problemas podem ocorrer mesmo que a transação esteja correta respeitando as propriedades de uma transação. A seguir, vamos entender o que ocorre em cada um dos problemas citados.
4.2.1 Atualização perdida (lost update)
A melhor maneira de entendermos os problemas citados anteriormente é aplicando exemplos. Então vamos ao primeiro exemplo, que apresentará a atua- lização perdida. A Tabela 1 apresenta duas transações A e B, que, em momentos distintos, acessam uma tupla de dados ou como também pode ser expresso um item de dados.
Tabela 1 Problema de atualização perdida.
TRANSAçãO A TEMPO TRANSAçãO B
– | – ler (t) T1 – – T2 ler(t) alterar(t) T3 – – T4 alterar(t) – ↓ – Fonte: Date (2003, p. 400).
Observando a Tabela 1, podemos notar que a transação A acessou uma tupla t e leu o seu valor em um tempo T1; a transação B acessou a mesma tupla e também realizou a leitura de seu valor em um tempo T2; a transação A realizou uma alteração no valor da tupla t em um tempo T3; e nalizando, a transação B atualizou o valor da mesma t no tempo T4. Porém essa atualização na tupla é realizada com base em seu acesso ao valor de t no tempo T2, perdendo, assim, a atualização realizada pela transação A no tempo T3. Resumidamente, o problema da atualização perdida consiste no ato que uma transação B em algum momento sobrescreve uma atualização realizada por uma transação A, com valores muitas vezes incorretos devido a um processo de concorrência inadequado.
4.2.2 Dependência sem commit
Assim como realizado na seção anterior, vamos a um exemplo para uma melhor compreensão sobre o problema da dependência sem commit . Observe
a Tabela 2, na qual é apresentada a seqüencia de transações e suas operações para descrever o problema.
Tabela 2 Problema da dependência sem commit com leitura de valores.
TRANSAçãO A TEMPO TRANSAçãO B
– | – – T1 alterar(t) ler(t) T2 – – T3 rollback – T4 – – ↓ – Fonte: Date (2003, p. 400).
Como pode ser observado na Tabela 2, o problema da dependência sem
commit reside na inconsistência dos dados devido a uma transação não ser
completada com sucesso. Note na tabela, que em um tempo T1, a transação B altera os valores do item de dados t; em seguida, a transação A, no tempo T2, lê os valores de t; porém a transação B realiza um comando de rollback , ou seja,
a alteração não é completada. Assim o valor lido pela transação A, no tempo T2, é incoerente, passando valores inconsistentes devido à incompletude na tran- sação B que ainda não havia sido nalizada.
Outra vertente desse problema e que é considerada mais séria, consiste em transações que, ao invés de somente realiza a leitura, realiza operações de escrita, sem que outra transação iniciada anteriormente tenha sido completada, como é demonstrado na Tabela 3.
Tabela 3 Problema da dependência sem commit com alteração de valores.
TRANSAçãO A TEMPO TRANSAçãO B
– | – – T1 alterar(t) alterar(t) T2 – – T3 rollback – T4 – – ↓ – Fonte: Date (2003, p. 400).
Note que o problema é o mesmo apresentado na Tabela 2. Porém, ao invés de um acesso de leitura sobre a tupla t, é realizada uma operação de escrita, o que pode tornar tudo mais complexo, já que esses dados passam a estar incoe- rentes e persistentes no banco de dados.
4.2.3 Análise inconsistente
O último problema a ser apresentado dos citados no início desta aula é a análise inconsistente. Ele, sob um ponto de vista mais supercial, é semelhante ao problema apresentado na seção anterior, já que resulta na leitura inconsis- tente de valores por uma transação. A dierença é que a leitura ocorre sem que tenham ocorrido problemas com a transação concorrente, ou seja, as operações da transação são nalizadas usando o comando commit . Para exemplicar esse
problema, imaginemos um banco que tem três contas correntes, contendo respec- tivamente os valores 40, 50 e 30, sobre as quais duas transações acontecem simultaneamente. A transação A realizará a soma dos valores das contas e a transação B realizará operações de atualização no banco de maneira concor- rente. A Tabela 4 demonstra a seqüência de eventos.
Tabela 4 Problema da análise inconsistente.
TRANSAçãO A TEMPO TRANSAçãO B
– | – ler conta1(40) soma = 40 T1 – ler conta2 (50) soma = 90 T2 – – T3 altera conta3 30 → 20 altera conta1 40 → 50 commit ler conta3 (20) soma = 110 T4 – – ↓ – Fonte: Date (2003, p. 401).
É importante observar que o resultado nal da soma realizada na tran- sação A é 110, enquanto o resultado correto seria 120. Esse problema se deve ao ato de que, enquanto a transação A, nos tempos T1 e T2, lê e soma os valores das contas conta1 e conta2, em um tempo T3, a transação B realiza uma atualização nos valores das contas conta3 e conta1, sendo nalizada com sucesso por meio do comando commit . Porém, no tempo T4, a
transação A realiza a soma do valor contido na conta3, que oi alterado no tempo T3 pela transação B, causando o problema de inconsistência no valor nal da soma.
Assim podemos dizer que o problema de análise inconsistente geralmente acontece devido a diversos acessos de leitura a linhas de maneira que, a cada acesso, é lido um novo valor gerado devido à concorrência com outras transa- ções, causando a inconsistência no valor nal.
4.3 Técnicas de controle de concorrência
Para sanar os problemas mencionados anteriormente, são utilizadas técnicas, também denominadas protocolos, para tratar do controle de concorrência. Nesta disciplina, serão consideradas apenas escalas ditas serializáveis, que podem ser classicadas em técnicas pessimistas e otimistas. Elmasri e Navathe (2005) citam a seguinte classicação:
a) pessimista
bloqueio
•
• timestamp (marcas de tempo) b) otimista
validação
•
As técnicas pessimistas presumem que sempre ocorrerá intererência entre as transações e, então, buscam sempre garantir a serialização enquanto uma transação estiver ocorrendo. Já as técnicas otimistas supõem que raramente ocorrerá a intere- rência entre as transações e somente verifcam o aspecto da serialização ao fnal.
Vamos à análise dos protocolos de controle de concorrência.
4.3.1 Bloqueio
Um protocolo consiste em uma padronização de procedimentos utilizados para a execução de uma tarea. Logo o que ocorre em todos os protocolos nada mais é que uma denição de regras a serem seguidas. O bloqueio é certamente o mais utilizado entre os protocolos de controle de concorrência pelos bancos de dados disponíveis no mercado (ELMASRI; NAVATHE, 2005).
Diversos modos de bloqueio podem ser utilizados para trabalhar com transa- ções concorrentes, porém iremos assumir apenas os dois modos mais diundidos e que são mencionados por Silberschatz, Korth e Sudarshan (2006). Vejamos quais são esses dois modos.
a) Compartilhado: se uma transação obtiver um bloqueio compartilhado
(indicado por S, do inglêsShare ) sobre um dado, então poderá ler, mas
b) Exclusivo: se uma transação obtiver um bloqueio do tipo exclusivo (indi-
cado por X , do inglês exclusive ) sobre um dado, então ela poderá ler e
escrever sobre o item de dados bloqueado.
Cada transação deve, no momento de execução, solicitar o bloqueio obser- vando o modo mais apropriado sobre os dados a serem utilizados. O que ocorre é que a transação lança uma solicitação ao gerenciador de controle de concor- rência, que só autoriza o seu prosseguimento, apósconceder (grants )o bloqueio
sobre os dados a serem manipulados.
Entender a compatibilidade de bloqueios é de extrema importância, pois, por meio dela são baseadas as atividades permitidas ou não em um controle de concor- rência. Observe a Tabela 5, na qual é apresentada a matriz de compatibilidade. Tabela 5 Matriz de compatibilidade de bloqueio.
TRANSAçõES Lock S Lock X
Lock S Verdadeiro Falso
Lock X Falso Falso
Vamos entender melhor a matriz de compatibilidade apresentada. Nos eixos dos comandos de bloqueiolock , estão dispostos valores que determinam se duas
transações ocorrem no modo compartilhado ou exclusivo. Note que apenas no caso em que duas ou mais transações estiverem bloqueando um mesmo item de dados Q no modo compartilhado (lock S), elas poderão ser executadas ao
mesmo tempo. O modo compartilhado permite apenas ler dados, logo a leitura de ambas as transações ao mesmo tempo não aetará em momento algum nos dados que ambas estão acessando.
Nas demais situações expostas pela matriz de compatibilidade, sempre que uma transação solicitar o bloqueio, uma deve aguardar a outra ser concluída para ter acesso aos dados. A liberação de recursos ocorre com a utilização do comando
unlock . Vamos a um exemplo para entender a técnica de bloqueio em transações.
Relembrando o exemplo apresentado anteriormente sobre contas correntes, duas transações azem acesso às contas, consultam e alteram valores, bloqueiam os dados quando necessário. Essas transações são apresentadas na Tabela 6.
Tabela 6 Controle de concorrência com bloqueios.
TRANSAçãO A TEMPO TRANSAçãO B
GERENCIAMENTO DE CONTROLE DE CONCORRêNCIA – | – – lock X (conta1) T1 – – – T2 – X(conta1,Transação A)grant lock X (conta2) T3
TRANSAçãO A TEMPO TRANSAçãO B GERENCIAMENTO DE CONTROLE DE CONCORRêNCIA – T4 – X(conta2,Transação A)grant altera conta1 40 → 30 altera conta2 50 → 60 commit aux1 = ler(conta1) unlock (conta1) unlock (conta2) T5 – – – T6 lock S (conta2) – – T7 – S(conta2,Transação B)grant –
lock S (conta2) T8 aux3 = ler(conta2) –
– T9 – S(conta2,Transação A)grant aux2 = ler(conta2) unlock (conta2) mostrar(aux1 + aux2) T10 unlock (conta2) – – ↓ – –
Ok, pessoal, vamos à explicação. Nesse exemplo, é realizada a apresen- tação da soma dos valores da conta1 e conta2, além de realizar a transe- rência da conta1 para a conta2. Do tempo T1 ao T4, a transação A solicita o bloqueio exclusivo da conta1 e conta2 que aguarda a liberação do gerenciador do controle de concorrência que acontece nos tempos T2 e T4, é uma permissão com exclusividade. No tempo T5, a transação A eetua uma alteração no valor da conta1 e na conta2, realiza a persistência dos valores por meio da instrução
commit e emite um aviso ao gerenciador de concorrência que libera a conta1
e conta2 para outras transações, por meio da instrução unlock . Note que, do
tempo T6 a T10, as duas transações, A e B, realizam acesso compartilhado aos dados autorizados pelo gerenciador de controle de concorrência por meio dos
grants, imprimindo a soma dos valores das contas. É importante lembrar que
são realizadas apenas atividades de leitura aos valores nas contas no reerido intervalo de tempo (T6 a T 10).
Com isso, podem ser controlados os acessos e, assim, garantir o isolamento das transações. Porém, com o bloqueio, surge um novo problema, denominado impasse ou deadlock . Na Tabela 7, a transação A solicita o bloqueio da conta2,
realiza a leitura e a atualização dos valores no tempo T1, porém não realiza a liberação do recurso conta2. No tempo T2, a transação B solicita o bloqueio compartilhado da conta1, lê os valores e, então, solicita o bloqueio da conta2, criando, assim, um impasse com a transação A, já que está não liberou os dados da conta2. Para tornar o processo mais problemático, a transação A ainda soli- cita o bloqueio da conta1 de maneira exclusiva e, como pode ser observado, ainda está bloqueada para a transação B.
Tabela 7 Impasse ou deadlock entre transações.
TRANSAçãO A TEMPO TRANSAçãO B
– | – lock X(conta2) ler conta2 (50) altera conta2 60 -> 50 commit T1 – – T2 lock S(conta1) ler conta1 lock S(conta2) lock X(conta1) T3 – – ↓ –
Quando o banco se depara com uma situação de deadlock , o sistema deve
se encarregar de reverter uma das transações para que a outra prossiga. Logo, quando uma transação é revertida, os itens de dados bloqueados para essa tran- sação são desbloqueados. Silberschatz, Korth e Sudarshan (2006) mencionam que o deadlock é um mal necessário, evitando estados inconsistentes.
4.3.2 Timestamp
Timestampé um método que determina a ordem de serialização das transações
ordenando-as antes de sua execução. O método mais comum para isso consiste na ordenação por timestamp (marcas de tempo) representado como TS. Nesse
modelo de ordenação, é atribuído um valor de timestamp pelo banco de dados
antes que a transação se inicie. Uma transação posterior sempre terá um times- tamp maior que o da transação anterior. Segundo Silberschatz, Korth e Sudarshan
(2006), dois modos são utilizados para implementar esse esquema. Vejamos. Utilização do valor do
• clock (hora do sistema) como timestamp de uma
Utilização de um contador lógico para denir o
• timestamp de uma
transação.
É por meio desses timestampdenidos para as transações que é assegurada
a ordem de serialização das transações. Logo, se TS(A) < TS(B), o sistema deve garantir que o esquema de execução montado privilegie a transação A em detri- mento de B. Conorme Elmasri e Navathe (2005), para garantir essa ordem, são associados a cada item de dados dois valores de timestamp:
Write
• _TS(Q): que indica o maior timestamp de qualquer transação que
executou uma escrita com sucesso;
Read
• _TS(Q): que indica o maior timestamp de qualquer transação que
executou uma leitura com sucesso.
Esses valores são atualizados a cada execução de instruções de leitura ou escrita em uma transação. Assim o protocolo de ordenação de timestamp deve
garantir que operações confitantes sejam executadas segundo a ordem de cada valor de timestamp denido para cada operação sobre o item de dados Q de
uma transação. Esse protocolo, conorme Elmasri e Navathe (2005), trabalha da seguinte orma:
a) suponha que a transação A realize uma leitura(Q): Se TS(A) < Read_TS(Q), então
•
existe outra operação sobre Q com
• timestamp maior e a tran-
sação A é revertida. Senão
•
a operação de leitura é executada e Read_TS(Q) é denido
•
como o novo maior timestamp de leitura.
b) suponha que a transação A realize uma escrita(Q):
Se TS(A) < Read_TS(Q) ou TS(A) < Write_TS(Q) então,
•
existe outra operação de leitura ou escrita com
• timestamp maior
e a transação é revertida Senão
•
o sistema executa a operação de escrita e dene Write_TS(Q)
•
como o novo maior timestamp para escrita.
Quando uma transação é revertida pelo controle de concorrência, um novo valor de timestamp é denido. Um importante detalhe a ser considerado sobre
a técnica de timestamp é que por não utiliza bloqueio, não ocorrem deadlocks.
Porém esse protocolo abre espaço para o problema de estagnação de transa- ções longas, se uma seqüência de outras transações curtas em confito causarem o reinício da transação longa.
4.3.3 Validação
A validação consiste no último protocolo de controle de concorrência a ser analisado nesta aula. Essa técnica consiste em um esquema de monitoramento, ou seja, uma visão otimista, pois nenhuma vericação é realizada durante a execução das transações. Com isso, tem-se um ganho considerável sobre o
overhead criado por um controle de concorrência pessimista. Nessa técnica,
as operações de uma transação são realizadas por cópias locais dos itens de dados. Para tanto, uma transação tem duas ou três ases dependendo se elas realizam a leitura ou escrita respectivamente. Silberschatz, Korth e Sudarshan (2006) apresentam essas ases. Vejamos.
Fase de leitura
• : a transação A lê os dados e os atualiza em cópias locais.
Fase de validação
• : nessa ase, ocorre a análise da serialização dos
confitos caso as alterações nas cópias sejam eetivadas.
Fase de escrita
• : se a ase de validação ocorrer sem problemas, aplicam-se
as atualizações no banco, caso contrário a transação é revertida.
Para a realização dos testes de validação, devem ser denidos três times- tampsdierentes para cada operação de uma transação. Conorme Silberschatz,
Korth e Sudarshan (2006), são eles:
start
• (transação): momento em que a transação oi iniciada; validation
• (transação): momento em que a transação terminou a ase de
leitura e iniciou a ase de validação;
fnish
• (transação): momento em que se termina a ase de escrita.
O teste de validação para uma transação A e B exige que TS(A) seja menor que TS(B). Segundo Elmasri e Navathe (2005), uma das condições a seguir necessita ser mantida.
Finish
• (A) < Start (B): a transação A termina a execução de suas opera-
ções antes da transação B;
O conjunto de dados escritos por A não tem interseção com os dados
•
lidos por B, e A completa sua ase de escrita antes que B inicie sua ase de validação.
O esquema de validação protege contra rollbacks em cascata, pois o
processo de escrita real somente ocorre depois que a transação tenha sido vali- dada (SILBERSCHATZ; KORTH; SUDARSHAN, 2006).
A partir do que vimos nesta aula, podemos concluir que a aplicação de meca- nismos de controle de concorrência é muito importante quando existe a possibili- dade de acessos simultâneos a um banco de dados. Essa situação é muito comum nas organizações de maneira geral, e a tendência é que os bancos de dados com
acessos concorrentes sejam cada vez mais presentes, sobretudo pelo crescimento acessos concorrentes sejam cada vez mais presentes, sobretudo pelo crescimento dos sistemas de inormação cuja plataorma é o ambiente da
dos sistemas de inormação cuja plataorma é o ambiente da Internet Internet ..
Nesta aula, apresentamos os conceitos básicos relacionados ao
Nesta aula, apresentamos os conceitos básicos relacionados ao controle decontrole de concorrência
concorrência, que é um mecanismo utilizado para garantir as propriedades das, que é um mecanismo utilizado para garantir as propriedades das transações e a consistência do banco de dados. Vimos os três tipos de
transações e a consistência do banco de dados. Vimos os três tipos de problemasproblemas
que podem ocorrer em um SGBD devido à alta do controle de concorrência. que podem ocorrer em um SGBD devido à alta do controle de concorrência. Consideramos as principais
Consideramos as principais técnicastécnicas, ou como também são conhecidas, protocolos, ou como também são conhecidas, protocolos para o controle de concorrência: bloqueio,
para o controle de concorrência: bloqueio, timestamptimestampe validação.e validação.BloqueiosBloqueiospodempodem ser compartilhados, quando o item de dados é utilizado por outras transações ser compartilhados, quando o item de dados é utilizado por outras transações (normalmente em operações somente de leitura), ou exclusivos (geralmente usados (normalmente em operações somente de leitura), ou exclusivos (geralmente usados em operações de escrita). A técnica de
em operações de escrita). A técnica de timestamp timestamp defne a serialização das transa-defne a serialização das transa- ções em intervalos de tempo. Enquanto a
ções em intervalos de tempo. Enquanto a validação validação defne ases para as transaçõesdefne ases para as transações de maneira que as ases de escrita não se sobreponham, mantendo a consistência. de maneira que as ases de escrita não se sobreponham, mantendo a consistência.
1.
1. Três Três problemas que podem problemas que podem ocorrer devido à ocorrer devido à alta de alta de controlcontrole de e de concor-concor- rência entre transações são:
rência entre transações são: a)
a) isolamento, isolamento, durabilidade durabilidade e e integridade;integridade; b)
b) antasmas, antasmas, isolamento isolamento e e atualização atualização perdida;perdida; c)
c) atualização atualização perdida, perdida, dependência dependência semsem commit commit e análise inconsistente;e análise inconsistente;
d)
d) deadlock deadlock , integridade e análise inconsistente., integridade e análise inconsistente.
2.
2. As principais As principais técnicas ou técnicas ou protocolos utilizados protocolos utilizados para o para o controle de controle de concor-concor- rência entre transações são:
rência entre transações são: a)
a) bloqueio bloqueio em dem duas auas ases, gereses, gerenciamento nciamento de concde concorrência e orrência e transação;transação; b) bloqueio,
b) bloqueio, timestamptimestamp e validação;e validação;
c)
c) start start , validação e, validação e nishnish;;
d)
d) read_TS(), read_TS(), Write_TS Write_TS ee timestamptimestamp..
3.
3. O bloqueO bloqueio consiste io consiste na técnica na técnica mais utilizadmais utilizada pelos a pelos SGBDs paSGBDs para o ra o controle dcontrole dee concorrência. Uma das suas desvantagens consiste no
concorrência. Uma das suas desvantagens consiste no deadlock deadlock ou tambémou também
conhecido como impasse. Descreva o que consiste o
conhecido como impasse. Descreva o que consiste o deadlock deadlock e como oe como o
banco deve proceder caso uma situação
banco deve proceder caso uma situação de impasse seja encontrada.de impasse seja encontrada. 4.
4. Explique Explique o uncionao uncionamento mento do pdo protocolo drotocolo dee timestamptimestamp, considerando duas, considerando duas
operações concorrentes A e B sobre um mesmo i
Na
Na atividade umatividade um, a alternativa correta é a l, a alternativa correta é a letraetra (c)(c), visto que conorme apre-, visto que conorme apre-
sentado em aula, os principais problemas de concorrência consistem na atuali- sentado em aula, os principais problemas de concorrência consistem na atuali- zação perdida, dependência sem
zação perdida, dependência sem commit commit e análise inconsistente.e análise inconsistente.
Já na
Já na atividade doisatividade dois, a opção correta é a alternativa, a opção correta é a alternativa (b)(b), já que as princi-, já que as princi-
pais técnicas ou protocolos utilizados para a gerência do controle de concor- pais técnicas ou protocolos utilizados para a gerência do controle de concor- rência consistem no bloqueio,
rência consistem no bloqueio, timestamptimestamp e validação conorme oi consideradoe validação conorme oi considerado
nesta aula. nesta aula.
Na
Na atividade trêsatividade três, você expôs que o, você expôs que o deadlock deadlock é um problema gerado peloé um problema gerado pelo
controle de concorrência que utilize o bloqueio, visto que duas ou mais transa- controle de concorrência que utilize o bloqueio, visto que duas ou mais transa- ções podem tentar azer uso de um mesmo item de dados, criando, assim, um