APOSTILA - Banco de dados aplicados

Prévia do material em texto

Banco de Dados 
Aplicados
Professora Dra. Gisele Alves Santana
Reitor 
Prof. Ms. Gilmar de Oliveira
Diretor de Ensino
Prof. Ms. Daniel de Lima
Diretor Financeiro
Prof. Eduardo Luiz
Campano Santini
Diretor Administrativo
Prof. Ms. Renato Valença Correia
Secretário Acadêmico
Tiago Pereira da Silva
Coord. de Ensino, Pesquisa e
Extensão - CONPEX
Prof. Dr. Hudson Sérgio de Souza
Coordenação Adjunta de Ensino
Profa. Dra. Nelma Sgarbosa Roman 
de Araújo
Coordenação Adjunta de Pesquisa
Prof. Dr. Flávio Ricardo Guilherme
Coordenação Adjunta de Extensão
Prof. Esp. Heider Jeferson Gonçalves
Coordenador NEAD - Núcleo de 
Educação à Distância
Prof. Me. Jorge Luiz Garcia Van Dal
Web Designer
Thiago Azenha
Revisão Textual
Beatriz Longen Rohling
Caroline da Silva Marques
Carolayne Beatriz da Silva Cavalcante
Geovane Vinícius da Broi Maciel
Jéssica Eugênio Azevedo
Kauê Berto
Projeto Gráfico, Design e
Diagramação
André Dudatt
Carlos Firmino de Oliveira
2022 by Editora Edufatecie
Copyright do Texto C 2022 Os autores
Copyright C Edição 2022 Editora Edufatecie
O conteúdo dos artigos e seus dados em sua forma, correçao e confiabilidade são de responsabilidade 
exclusiva dos autores e não representam necessariamente a posição oficial da Editora Edufatecie. Per-
mitido o download da obra e o compartilhamento desde que sejam atribuídos créditos aos autores, mas 
sem a possibilidade de alterá-la de nenhuma forma ou utilizá-la para fins comerciais. 
 Dados Internacionais de Catalogação na Publicação - CIP 
 
S235b Santana, Gisele Alves 
 
 Banco de dados aplicados / Gisele Alves Santana 
 Paranavaí: EduFatecie, 2022. 
 86 p.: il. Color. 
 
 
 
1. Banco de dados. 2. Recuperação da informação. 3. 
 Recuperação de dados. 4.. Segurança de sistemas. I. Centro 
 Universitário UniFatecie. II. Núcleo de Educação a Distância. 
 III. Título. 
 
 CDD: 23 ed. 005.74 
 Catalogação na publicação: Zineide Pereira dos Santos – CRB 9/1577 
 
 
 
UNIFATECIE Unidade 1 
Rua Getúlio Vargas, 333
Centro, Paranavaí, PR
(44) 3045-9898
UNIFATECIE Unidade 2 
Rua Cândido Bertier 
Fortes, 2178, Centro, 
Paranavaí, PR
(44) 3045-9898
UNIFATECIE Unidade 3 
Rodovia BR - 376, KM 
102, nº 1000 - Chácara 
Jaraguá , Paranavaí, PR
(44) 3045-9898
www.unifatecie.edu.br/site
As imagens utilizadas neste
livro foram obtidas a partir 
do site Shutterstock.
AUTORA
Professora Dra. Gisele Alves Santana
● Doutora em Engenharia Elétrica pela UTFPR (Universidade Tecnológica Federal 
do Paraná). 
● Mestra em Engenharia Elétrica pela UTFPR (Universidade Tecnológica Federal 
do Paraná). 
● Graduada em Análise e Desenvolvimento de Sistemas pela UTFPR (Universidade 
Tecnológica Federal do Paraná). 
● Técnica em Eletrotécnica pela UTFPR (Universidade Tecnológica Federal do 
Paraná). 
● Pesquisadora do grupo de Telecom da UEL (Universidade Estadual de Londrina).
 
Ampla experiência como professora do ensino superior nas modalidades EAD e 
presencial para cursos de Engenharias e Tecnologias das instituições Unopar, Pitágoras, 
Anhanguera e UTFPR. Desenvolvedora de livros e materiais didáticos. Revisora convidada 
do “Transactions on Emerging Telecommunications Technologies”. Membro honorário da 
“London Journals Press”.
CURRÍCULO LATTES: http://lattes.cnpq.br/8230832906458617
http://lattes.cnpq.br/8230832906458617
APRESENTAÇÃO DO MATERIAL
Seja muito bem-vindo (a)!
Prezado (a) aluno (a), se você se interessou pelo assunto desta disciplina, isso 
já é o início de uma grande jornada que vamos trilhar juntos a partir de agora. Proponho, 
junto com você, construir nosso conhecimento sobre os conceitos fundamentais de Banco 
de Dados Aplicados. 
Na unidade I começaremos a nossa jornada pelo conceito de transações e suas 
principais propriedades. Geralmente, em um Banco de Dados existem várias transações 
ocorrendo ao mesmo tempo, e por este motivo, deve-se controlar a ordem de execução 
dessas transações para assegurar que as propriedades não sejam violadas. Neste contexto, 
o escalonamento de transações impõe uma ordem de execução das transações, com o 
objetivo de garantir a consistência e a integridade dos dados do Banco de Dados.
Já na unidade II vamos ampliar nossos conhecimentos sobre os mecanismos 
de controle de concorrência das transações. Como principais técnicas de controle de 
concorrência temos os bloqueios, que podem ser binários, múltiplos ou de duas fases. O 
objetivo principal dos bloqueios é garantir que os dados de um Banco de Dados apresentem 
consistência e integridade após a execução de várias transações ao mesmo tempo.
Depois, na unidade III vamos conhecer os principais tipos de sistemas de 
recuperação, como a técnica de arquivos de log e checkpoints. Esses sistemas garantem 
que, mesmo em caso da ocorrência de algumas falhas, os dados armazenados no Banco 
de Dados possam ser recuperados.
Finalmente, na unidade IV são apresentados os principais mecanismos usados 
para garantir a segurança de um Banco de Dados. Geralmente, a criptografia e o controle 
de acesso são empregados para assegurar a confidencialidade e integridade dos dados 
armazenados. Além disso, nesta unidade você vai conhecer alguns tipos de ameaças que 
podem comprometer a segurança de um Banco de Dados.
Aproveito para reforçar o convite a você, para junto conosco percorrer esta jornada 
de conhecimento e multiplicar os conhecimentos sobre tantos assuntos abordados em 
nosso material. Esperamos contribuir para seu crescimento pessoal e profissional. 
Muito obrigada e bons estudos!
SUMÁRIO
UNIDADE I ...................................................................................................... 4
Escalonamento de Transações
UNIDADE II ................................................................................................... 26
Controle de Concorrência
UNIDADE III .................................................................................................. 46
Sistemas de Recuperação
UNIDADE IV .................................................................................................. 65
Segurança
3
Plano de Estudo:
● Estados das transações, propriedades ACID e Comandos em SQL;
● Execuções Simultâneas;
● Escalonamento.
Objetivos da Aprendizagem:
● Conceituar e contextualizar as propriedades das transações;
● Compreender os tipos de escalonamento utilizados
para a execução simultânea de transações;
● Estabelecer a importância da execução simultânea de transações.
UNIDADE I
Escalonamento 
de Transações
Professora Doutora Gisele Alves Santana
4UNIDADE I Escalonamento de Transações
INTRODUÇÃO
Em um Sistema de Banco de Dados, no momento em que ações como atualização, 
inserção ou remoção de registros são realizadas, o resultado destas ações é instantâneo. 
Isso significa, por exemplo, que ao executar um script SQL e a mensagem de confirmação 
surgir na tela, a ação já foi executada e confirmada. 
Porém, em muitos casos é necessário se trabalhar com mais de um comando 
que dependerá de um outro comando para ser realizado. Imagine, por exemplo, quando 
é necessário gravar os dados em uma tabela, mas antes é preciso gravar o registro em 
uma outra tabela. Se ao se gravar os dados na primeira tabela acontecer algo de errado, 
o registro da segunda tabela poderá ficar inconsistente. Sendo assim, é necessário que os 
dados da primeira tabela sejam salvos com sucesso para que depois os dados da segunda 
tabela possam ser salvos também. 
Por essa razão, para garantir que todo o processo aconteça sem qualquer tipo de 
inconsistência, é que existem as transações. Seria muito conveniente se você pudesse 
assegurar que a sequência de ações elementares tivesse a propriedade de que “ou todas 
as ações elementares executam com sucesso ou nenhuma delas é executada”. Em outraspalavras, o ideal seria estender o conceito de atomicidade e consistência de maneira a 
envolver também sequências de ações elementares, como: adições, atualizações etc. 
Geralmente, várias transações que possuem algumas ações são executadas ao 
mesmo tempo em um Banco de Dados. Considerando esse contexto, qual seria a ordem 
correta para a execução de várias transações? Como garantir a consistência dos dados 
que são utilizados por várias transações ao mesmo tempo?
Essas e outras questões serão abordadas na Unidade I desta apostila.
5UNIDADE I Escalonamento de Transações
1. ESTADOS DAS TRANSAÇÕES, PROPRIEDADES ACID E COMANDOS EM SQL
Normalmente, os Sistemas de Gerenciamento de Banco de Dados (SGBDs) 
permitem que várias transações sejam executadas simultaneamente, isso pode causar 
várias complicações, como por exemplo, a inconsistência de dados (ELMASRI e NAVATHE, 
2011). Então, deve-se garantir a consistência com a execução simultânea das transações, 
ou seja, as transações precisam ser executadas de acordo com alguma ordem. 
Para assegurar a ordem de execução das transações em um BD, deve-se utilizar o 
escalonamento, que indica a sequência cronológica de execução das transações. Para que 
um bom plano de escalonamento seja implementado, deve-se conhecer primeiramente os 
conceitos fundamentais sobre transações, principalmente as propriedades que devem ser 
respeitadas para que o BD apresente um correto funcionamento.
Em um SGBD, uma transação é considerada como uma unidade única de lógica ou de 
trabalho, que na maioria das vezes é composta por várias operações ou ações elementares 
(ELMASRI e NAVATHE, 2011). Qualquer cálculo lógico realizado de modo consistente em 
um BD é conhecido como transação. Por exemplo, para a operação de transferência de 
dinheiro de uma conta bancária ser completa, é necessário que seja realizada a subtração 
do valor a ser transferido de uma conta e a adição desta mesma quantia à outra conta.
Então, uma transação consiste em validar uma sequência de comandos que são 
executados no Banco de Dados, tendo como ideia básica de que todos os passos da 
sequência sejam validados e somente no final do processo (com tudo certo) é que as 
alterações devem ser efetivamente implementadas no BD.
6UNIDADE I Escalonamento de Transações
Uma transação simboliza uma unidade de trabalho executada dentro de um 
SGBD, que deve ser tratada de maneira coerente e confiável, independente de outras 
transações (MEDEIROS, 2013). 
Uma das principais vantagens das transações diz respeito à alta eficácia quando se 
tem a necessidade de trabalhar com uma grande quantidade de sequência de comandos, 
pois as transações garantem que somente depois de todos os passos serem executados 
com sucesso é que o BD sofrerá alterações.
Geralmente, uma transação representa qualquer alteração em um banco de dados, 
sendo seus propósitos principais (ELMASRI e NAVATHE, 2011):
● Fornecer unidades de trabalho confiáveis que permitam a recuperação de falhas;
● Manter o banco de dados consistente mesmo em casos de falha do sistema; 
● Proporcionar isolamento entre programas que acessam o Banco de Dados 
simultaneamente. 
Basicamente, uma transação possui algumas operações básicas, sendo elas 
(MEDEIROS, 2013):
1.1 read 
● Operação de leitura.
● Transfere um item de dado do BD para um buffer local pertencente à transação 
que executou essa operação.
1.2 write
● Operação de escrita.
● Transfere um item de dado do buffer local da transação que executou essa 
operação de volta ao Banco de Dados (atualiza o BD).
1.3 commit
● Efetiva a transação corrente. 
1.4 rollback
● Aborta a transação corrente. 
Suponha que um cliente de uma agência bancária deseja realizar a transferência de 
uma certa quantia de dinheiro de sua conta-correte para uma outra conta. Essa operação 
deve ser única do ponto de vista do cliente, mas dentro do sistema de Banco de Dados, ela 
consiste em várias operações, como: adições e subtrações. 
7UNIDADE I Escalonamento de Transações
Em uma transação, é fundamental que todas essas operações ocorram ou que, em 
caso de alguma falha, nenhuma delas seja executada (ELMASRI e NAVATHE, 2011). Por 
exemplo, seria inaceitável se em uma das contas fosse debitada uma quantia de dinheiro, 
mas na outra conta a quantia não fosse creditada. 
Para o usuário, essa coleção de operações deve aparecer como uma única 
unidade, e assim deve ser a transação: executada em sua totalidade ou não executada. 
Se uma transação começa a ser executada, mas falha por um motivo qualquer, quaisquer 
mudanças que a transação possa ter feito no BD devem ser desfeitas. 
Para que as condições citadas anteriormente sejam respeitadas, as transações 
devem respeitar algumas propriedades básicas, sendo as mesmas denominadas pelo 
acrônimo ACID: Atomicidade, Consistência, Integridade e Durabilidade (ELMASRI e 
NOVATHE, 2011), conforme ilustrado na Figura 1:
FIGURA 1 – PROPRIEDADES ACID
 
Fonte: Adaptado de: ELMASRI e NOVATHE (2011).
Em relação à atomicidade, cada transação deve ser executada em sua totalidade, 
e não somente partes da mesma (MEDEIROS, 2013). É a propriedade “tudo ou nada”, ou 
seja, ou a transação é executada na sua totalidade, ou então nada é executado. No caso 
da ocorrência de uma falha durante a execução de uma transação, o sistema de BD deve 
voltar ao mesmo estado em que estava antes do início dessa transação.
Na propriedade de consistência, todas as regras e restrições definidas no banco 
de dados devem ser obedecidas, por exemplo, relacionamentos por chaves estrangeiras 
e checagem de valores para campos restritos ou únicos, devem ser obedecidos para que 
uma transação possa ser completada com sucesso e consistência.
Já a propriedade de isolamento garante que a execução de uma transação não 
seja afetada por outras transações que estejam executando ao mesmo tempo (ELMASRI 
e NAVATHE, 2011). Em outras palavras, deve-se ter a impressão de que cada transação 
seja executada uma de cada vez, como se todos os recursos estivessem disponíveis para 
aquela única transação. 
8UNIDADE I Escalonamento de Transações
Cada transação deve funcionar completamente à parte de outras transações, o 
princípio é que nenhuma outra transação, operando no mesmo sistema, possa interferir no 
funcionamento da transação corrente. 
Além disso, as modificações realizadas por uma transação em um BD não devem 
ser visíveis por outras transações até que ela seja efetivada com sucesso. Dessa maneira, 
outras transações não podem visualizar os resultados parciais das operações de uma 
transação em andamento, essa é a característica principal da propriedade de isolamento. 
Por sua vez, a propriedade de durabilidade assegura que os efeitos de uma 
transação efetivada ou confirmada não sejam desfeitos (MEDEIROS, 2013). Para garantir 
que o sistema do banco de dados não perca uma transação completada com sucesso a partir 
de uma falha posterior, as ações de uma transação precisam persistir entre as falhas. Além 
disso, os resultados de uma transação só podem ser desfeitos por outra transação e uma vez 
executada com sucesso, as alterações feitas por uma transação devem persistir, mesmo se 
houver falhas subsequentes no sistema. Essa propriedade é conhecida como durabilidade. 
Para exemplificar a importância de se garantir as propriedades das transações, 
observe a Figura 2 e suponha que T1 seja uma transação que transfere R$ 50,00 da 
conta A para a conta B.
FIGURA 2 – EXEMPLO DE TRANSAÇÃO
Fonte: A autora (2021).
Suponha que antes da execução de da transação T1 a conta A tenha o saldo de 
R$ 1.000,00 e a conta B R$ 2.000,00. Durante a execução de T1 acontece alguma falha 
que impede que a transação seja executada com sucesso. Suponha também que a falha 
ocorreu depois da operação write(A) e antes da operação write(B). 
9UNIDADE I Escalonamento de Transações
Perceba que nesse caso, os valores finais das contas A e B seriamR$ 950,00 
e RS 2000,00, sendo que o sistema “destruiu” R$ 50,00 como resultado da falha. 
Consequentemente, as propriedades de atomicidade e consistência não foram respeitadas, 
pois a soma de A+B deveria permanecer inalterada após a execução da transação, ou seja, 
o BD não poderia ter “destruído” ou “criado” dinheiro. Além disso, a transação deve ser 
atômica (ou todas as operações são executadas ou nada é realizado).
Para que essa situação não ocorra, o sistema de BD deve armazenar os valores 
antigos dos dados em que uma transação realiza uma escrita ou atualização. Assim, no 
caso de uma transação não completar sua execução, o sistema de BD deve restaurar os 
valores antigos dos dados (como se a transação nunca tivesse ocorrido).
Em relação à durabilidade, quando a execução da transação termina com 
sucesso e o usuário que iniciou a transação foi notificado de que a transferência de 
fundos aconteceu, é preciso que nenhuma falha no sistema resulte em perda dos dados. 
Então, a durabilidade deve garantir que quando uma transação é executada com sucesso, 
todas as atualizações que ela executou no BD persistam, mesmo que haja uma falha no 
sistema após a finalização da transação.
Em relação às falhas que podem acontecer durante a execução de uma transação, 
pode-se citar (ELMASRI e NAVATHE, 2011):
● Falha por hardware, software ou rede;
● Erro durante a execução de operações (por exemplo: estouro de variáveis);
● Condições de exceção detectadas pela transação (por exemplo: saldo insuficiente 
em conta);
● Falta de energia;
● Etc.
Como visto anteriormente, uma transação é efetivada corretamente quando todas 
as suas operações são executadas respeitando as propriedades ACID. 
Mas, quais são os estados de uma transação? 
No modelo transacional clássico, uma transação sempre termina (com ou sem 
falha), possuindo os seguintes estados (ELMASRI e NAVATHE, 2011): é um programa 
1.5 Ativa (estado inicial)
● A transação permanece nesse estado enquanto está executando.
10UNIDADE I Escalonamento de Transações
1.6 Parcialmente confirmada 
● Depois que a instrução final foi executada.
1.7 Falha
● Depois de descoberta que a execução normal não pode mais prosseguir.
1.8 Abortada
● Depois que a transação foi revertida e o BD foi restaurado ao seu estado 
anterior antes do início da transação.
1.9 Confirmada
● Após o término bem sucedido.
A Figura 3 ilustra todos os estados possíveis de uma transação
FIGURA 3 – ESTADOS DAS TRANSAÇÕES
 
Fonte: Adaptado de: ELMASRI e NOVATHE (2011).
Basicamente, os estados funcionam da seguinte maneira (ELMASRI e NAVATHE, 2011):
● Uma transação começa no estado Ativo. 
● Quando termina sua última instrução ou operação, entra no estado Parcialmente 
Efetivada. Nesse ponto, a transação completou sua execução, mas ainda pode ser 
abortada (a saída ainda pode estar na memória principal). 
● Quando a última informação for gravada em disco, a transação entra no estado 
Efetivada. 
● Uma transação entra no estado de Falha depois que o sistema determina que a mesma 
não pode mais prosseguir com sua execução normal (transação precisa ser revertida). 
● Depois, em quaisquer dos dois casos anteriores, a transação entra no estado 
Encerrada.
11UNIDADE I Escalonamento de Transações
2. EXECUÇÕES SIMULTÂNEAS
Até agora, foram vistos os conceitos básicos sobre transações, mas em um SGBD, 
as transações não são executadas de maneira sequencial (uma de cada vez), mas sim de 
maneira concorrente (várias transações executando ao mesmo tempo).
Em um banco de dados multiusuário, que permite que vários usuários acessem os 
dados do banco simultaneamente, tem-se a execução simultânea ou concorrente de várias 
transações (MEDEIROS, 2013). 
Normalmente, os SGBDs permitem que várias transações sejam executadas ao 
mesmo tempo, onde se tem várias transações ocorrendo simultaneamente, isso pode 
causar várias complicações, como por exemplo, a inconsistência de dados. Garantir a 
consistência com a execução simultânea exige um trabalho extra, sendo muito mais fácil 
insistir que as transações sejam executadas serialmente (uma de cada vez) (ELMASRI e 
NAVATHE, 2011). Porém, garantir a concorrência proporciona melhor utilização de recursos 
e tempo de processamento (MEDEIROS, 2013).
Alguns problemas que podem ser gerados pela ocorrência de transações 
simultâneas são (MEDEIROS, 2013):
● Atualizações perdidas;
● Atualização temporária ou leitura suja: a consulta retorna dados gerados por 
outra transação, mas que ainda não foram confirmados por esta transação;
● Resumo incorreto: a consulta retorna dados para calcular uma agregação, mas 
o resumo resultante está desatualizado;
● Leitura não repetitiva: a consulta não repete o mesmo resultado, pois os dados 
foram alterados por outra transação.
12UNIDADE I Escalonamento de Transações
Para evitar esses e outros problemas, deve-se implementar algum mecanismo que 
permita que as transações ocorram ao mesmo tempo, de maneira consistente, e que exista 
o isolamento entre as mesmas. 
Nesse sentido, as diversas operações das transações precisam ser executadas em 
alguma ordem, essa ordem é chamada de escalonamento ou plano (schedule) que determina 
a ordem cronológica de execução das transações, ou seja, a sequência (ordenação) em que 
as operações das transações devem ser executadas. O escalonamento é fundamental para 
permitir o uso mais eficiente dos recursos computacionais (ELMASRI e NAVATHE, 2011). 
Para entender de maneira mais prática a execução simultânea ou concorrente das 
transações, imagine duas transações T1 e T2, ilustradas na Figura 4. A Transação T1 é 
responsável por transferir a quantia de R$100,00 da conta A para a conta B. Já a transação 
T2 transfere 10% do saldo da conta A para a conta B. Agora, suponha que os valores 
iniciais das contas sejam:
● Conta A: R$ 1.000,00
● Conta B: R$ 2.000,00
FIGURA 4 – EXEMPLO DE EXECUÇÃO SIMULTÂNEA
 
Fonte: A autora (2021).
No escalonamento, deve-se decidir em qual ordem as operações de cada transação 
devem ser executadas. Para esse exemplo, vamos analisar dois casos: 
● Caso 1: Execução de T1 e depois T2;
● Caso 2: Execução de T2 e depois T1.
Você acha que os valores finais de cada conta serão iguais nos dois casos?
Vamos conferir!
13UNIDADE I Escalonamento de Transações
A Figura 5 ilustra o primeiro caso, no qual as duas transações (T1 e T2) são 
executadas, uma de cada vez, nesta ordem. Primeiramente, em T1 é lido (read(A)) o valor 
inicial (R$ 1.000,00) da conta A e depois é subtraído R$ 100,00 deste valor, ficando a conta 
A com R$ 900,00 (o comando write(A) atualiza o novo valor de A). Após, o valor inicial da 
conta B (R$ 2,000,00) é lido através do comando read(B), e a este valor é adicionado R$ 
100,00. Finalmente, o novo valor da conta B (R$ 2.100,00) é atualizado através do comando 
write(B) e a transação T1 termina sua execução.
Após o término de T1, a transação T2 inicia sua execução. Primeiramente, é lido o 
valor da conta A (read(A)), que agora tem o saldo de R$ 900,00, depois uma variável auxiliar 
(aux) armazena 10% deste valor, que é subtraído da conta A, e então atualizada (write(A)). 
Na sequência, é lido o valor do saldo atual da conta B (R$ 2.100,00) e então, adicionado 
o valor de 10% (R$ 90,00) que foi subtraído da conta A. Repare que agora o valor final da 
conta B é atualizado através do comando write(B). 
Assim, com essa ordem de execução, tem-se que as contas ficaram com os 
seguintes saldos finais:
● Conta A: R$ 810,00
● Conta B: R$ 2.190,00
FIGURA 5 – EXECUÇÃO SIMULTÂNEA (CASO 1)
 
Fonte: A autora (2021).
A Figura 6 ilustra o segundo caso, no qual as transações (T2 e T1) são executadas, 
uma de cada vez, nesta ordem. Primeiramente, na transação T2 é lido (read(A)) o valor 
inicial (R$ 1.000,00) da conta A e depois é calculado 10% deste valor, sendo o resultado 
armazenado em uma variável auxiliar (aux). Após, o valor de aux é subtraído do saldo da 
conta A, então o saldodesta conta é atualizado (write(A)) para R$ 900,00.
14UNIDADE I Escalonamento de Transações
Em seguida, é lido o valor da conta B (write(B)) e à este valor é adicionado os 10% 
que foram retirados da conta A, atualizando então o valor da conta B para R$ 2.100,00. 
Nesse momento, a transação T2 é finalizada e T1 é iniciada com a leitura do valor da 
conta A (read(A)), que agora possui saldo de R$ 900,00. A próxima operação subtrai 100,00 
desse valor e depois atualiza o novo valor da conta (write(A)). Após, é lido o valor da conta B 
(read(B)), que possui saldo de R$ 2.100,00. Então, é adicionado R$ 100,00 ao saldo, e o novo 
valor da conta B é atualizado (write(B)) para R$ 2.200,00. Assim, a transação T1 é finalizada.
Perceba que com essa ordem de execução, as contas ficaram com os seguintes 
saldos finais:
● Conta A: R$ 800,00
● Conta B: R$ 2.200,00
FIGURA 6 – EXECUÇÃO SIMULTÂNEA (CASO 2)
 
Fonte: A autora (2021).
Respondendo à pergunta anterior, a ordem de execução das transações afetou o 
resultado, já que os valores finais das contas correntes foram diferentes nos dois casos. 
Porém, a atomicidade foi respeitada, pois a soma do saldo das duas contas (A+B = 3.000,00) 
foi preservada para ambos os casos, assim como a propriedade de consistência, já que as 
transações não criaram ou destruíram dinheiro durante suas execuções.
15UNIDADE I Escalonamento de Transações
3. ESCALONAMENTO
Os planos de execução são utilizados para definir a ordem de execução das transações. 
Basicamente, existem dois tipos principais de planos (ELMASRI e NAVATHE, 2011):
● Planos seriais;
● Planos não seriais.
Nos planos seriais, todas as operações das transações são executadas 
sequencialmente (ELMASRI e NAVATHE, 2011). Cada plano (schedule) serial consiste em 
uma sequência de instruções de várias transações, em que as instruções pertencentes a 
uma ÚNICA transação aparecem juntas.
Considere a Figura 7, que apresenta dois planos seriais de execução. No Plano 1, 
a transação T1 é executada e após sua finalização, a transação T2 inicia sua execução. 
Repare que todos os comandos de T1 são executados e só então a transação T2 é iniciada, 
executando assim todas as suas operações. Já no Plano 2, a transação T2 é executada 
primeiramente e após sua finalização, é dado início à execução das operações da tran-
sação T1, ocorrendo tudo de maneira sequencial. Dessa maneira, os Planos 1 e 2 são 
considerados planos seriais.
16UNIDADE I Escalonamento de Transações
FIGURA 7 – EXEMPLO DE PLANOS SERIAIS
 
Fonte: A autora (2021).
Por outro lado, nos planos não seriais as operaçoes das transações são executadas 
simultaneamente (ELMASRI e NAVATHE, 2011), ou seja, pode-se ter a execução de algumas 
operações de uma transação T1, depois algumas operações de uma transação T2, depois 
outras de T1 e o restante das operações de T2, por exemplo. A Figura 8 apresenta dois 
planos de execução não serial de transações.
FIGURA 8 – EXEMPLO DE PLANOS NÃO SERIAIS
 
Fonte: A autora (2021).
Como visto anteriormente, supondo os mesmos valores iniciais para as contas A e 
B, dependendo do tipo de plano adotado, os saldos finais de cada conta serão diferentes.
17UNIDADE I Escalonamento de Transações
Para garantir que os resultados finais sejam aqueles desejados, o ideal seria que 
os planos garantissem a consistência dos dados. Para tal, é utilizada a técnica chamada 
de serialidade ou escalonamento de planos, que identifica quais planos são corretos 
quando há intercalação das operações das transações. As operações significativas para o 
escalonamento são (ELMASRI e NAVATHE, 2011):
●	read;
●	write.
A ideia é fazer com que planos não seriais se tornem seriais, pois esses últimos são 
mais fáceis de serem controlados (MEDEIROS, 2013). Porém, não são todas as operações 
que podem ser trocadas de qualquer maneira, pois isso pode causar algum conflito. Assim, 
são necessárias algumas regras.
Considere um Plano P com duas operações consecutivas I1 e I2 das transações T1 e T2:
● Se I1 e I2 se referem a diferentes itens de dados, então elas podem ser invertidas 
sem afetar os resultados;
● Se I1 e I2 se referem ao mesmo item de dado, então a ordem das duas pode importar.
Para melhor entendimento, considere os seguintes casos (ELMASRI e NAVATHE, 2011):
a) I1 = read(A), I2 = read(A)
● A ordem de I1 e I2 não importa, pois, o mesmo valor de A é lido por T1 e T2 
(independente da ordem). 
● Então, as operações I1 e I2 podem ser trocadas.
b) I1 = read(A), I2 = write(A)
● Se I1 vem antes de I2, então T1 não lê o valor de A que é escrito por T2 na 
instrução I2.
● Se I2 vem antes de I1, então T1 lê o valor de A que é escrito por T2 na instrução I2.
c) Ii = write(A), Ij = read(A)
● A ordem de I1 e I2 importa.
● Então, não pode trocar as operações.
d) I1= write(A), Ij2 = write(A)
● Como as duas operações são de escrita, a ordem a ordem dessas instruções 
não afeta T1 ou T2.
● Porém, o valor obtido pela próxima instrução de read(A) é afetada, pois o 
resultado apenas da última das duas instruções write é preservado no BD.
18UNIDADE I Escalonamento de Transações
RESUMINDO: Somente no caso em que se tem instruções de leitura (read), a 
ordem de sua execução não importa.
Então, existe CONFLITO quando operações de diferentes transações sobre o MESMO 
ITEM DE DADO são executadas e PELO MENOS UMA dessa operações for WRITE.
Considere o exemplo da Figura 9, que apresenta duas transações T1 e T2.
FIGURA 9 – EXEMPLO DE ESCALONAMENTO
 
Fonte: A autora (2021)
Para esse caso, tem-se que:
3.1 write(A) de T1 conflita com read(A) de T2.
● Então, não pode inverter.
3.2 write(A) de T2 não conflita com read(B) de T1.
● Então, pode inverter.
Assim, com as inversões de write((A) de T2 com read(B) de T1, tem-se a primeira 
inversão, observada na Figura 10.
FIGURA 10 – ESCALONAMENTO (1ª INVERSÃO)
 
Fonte: A autora (2021).
19UNIDADE I Escalonamento de Transações
Além da inversão já realizada, existem outras situações possíveis de inversões, 
sendo elas:
a) Inverter a instrução read(B) de T1 por read(A) de T2.
b) Inverter a instrução write(B) de T1 por write(A) de T2.
c) Inverter a instrução write(B) de T1 por read(A) de T2.
Dessa maneira, a situação final do escalonamento ou serialização do plano com o 
passo-a-passo das inversões pode ser observado nas Figuras 11, 12 e 13. Repare que com 
a técnica de serialização, o plano com as duas transações se tornou serial.
FIGURA 11 – ESCALONAMENTO (2ª INVERSÃO)
 
Fonte: A autora (2021).
FIGURA 12 – ESCALONAMENTO (3ª INVERSÃO)
 
Fonte: A autora (2021).
FIGURA 13 – ESCALONAMENTO (4ª INVERSÃO)
 
Fonte: A autora (2021).
20UNIDADE I Escalonamento de Transações
Até aqui, as falhas não foram tratadas, porém, se uma transação falhar, é necessário 
desfazer o efeito da mesma para garantir a propriedade de atomicidade. Para isso, é 
necessário substituir restrições sobre os tipos de planos permitidos no sistema. Nesse caso, 
é desejável que um sistema de BD possua planos que sejam recuperáveis e não em cascata.
Considere o plano da Figura 14 com duas transações:
FIGURA 14 – EXEMPLO DE PLANO NÃO RECUPERÁVEL
 
Fonte: A autora (2021).
Perceba que T2 foi confirmada (commit) antes de T1, agora, suponha que T1 falhe 
antes de ser confirmada. Como T2 já leu o valor do item de dado A escrito por T1, o correto 
seria abortar T2. Porém, T2 já foi confirmada e não pode ser abortada, sendo impossível a 
recuperação da falha de T1. Com a operação de commit acontecendo imediatamente após 
read(A) na transação T2, essa situação é considerada um exemplo de plano não recuperável.
Com o objetivo de evitar essa situação indesejável, para cada par de transações 
(T1 e T2), tal que T2 leia um item de dado previamente escrito por T1, a operação de 
commit de T1 deve aparecer antes da operação commit de T2.
Agora, considere um plano com três transações, apresentado na Figura 15: 
FIGURA 15 – EXEMPLO DE ROLLBACK EM CASCATAFonte: A autora (2021).
21UNIDADE I Escalonamento de Transações
Perceba que T1 escreve um valor de A que é lido por T2. Por sua vez, T2 escreve 
um valor de A que é lido por T3. Agora, suponha que nesse ponto, T1 falhe, dessa maneira, 
T1 precisa ser revertida, porém, T2 depende de T1, então T2 também precisa ser revertida. 
Como T3 depende de T2, T3 também precisa ser revertida, essa situação é conhecida 
como rollback em cascata e deve ser evitada em um sistema de BD. 
Assim, em um BD deve-se tentar implementar apenas planos que possam 
ser recuperáveis ou aqueles que não apresentem rollbacks em cascata (ELMASRI e 
NAVATHE, 2011).
Na próxima unidade, você irá aprender que existem alguns protocolos ou conjunto 
de regras que podem assegurar a serialidade dos planos de execução das transações, 
garantindo assim, a consistência e atomicidade dos dados.
22UNIDADE I Escalonamento de Transações
SAIBA MAIS
A linguagem SQL é muito utilizada para a definição e manipulação de dados de um modelo 
relacional. Com essa linguagem é possível realizações operações de manipulação de dados 
de um BD, como: criação de tabelas, seleção de atributos, alteração de dados de uma 
tabela etc. No link a seguir, você pode aprofundar seus estudos sobre a implementação de 
transações utilizado SQL, conhecendo a sintaxe e estrutura de cada bloco de transações: 
Fonte: DEVMEDIA. Transações SQL Server. Disponível em: https://www.devmedia.com.br/transacoes-
sql-server/15331. Acesso em: 06 out. 2021.
REFLITA
É muito importante que todas as ações de uma transação sejam executadas para garantir 
a atomicidade e a consistência de um Banco de Dados. No caso da ocorrência de uma 
falha, se a transação ainda não tiver sido efetivada, todas as ações já implementadas 
por ela devem ser desfeitas. 
Então, todo o tempo e custo computacional empregado para a realização dessas ações 
foi perdido. Nesse sentido, por que o SGBD não implementa um mecanismo para evitar 
esse desperdício de tempo de computação? 
Fonte: A autora (2021).
https://www.devmedia.com.br/transacoes-sql-server/15331
https://www.devmedia.com.br/transacoes-sql-server/15331
23UNIDADE I Escalonamento de Transações
CONSIDERAÇÕES FINAIS
Nesta Unidade, você aprendeu os conceitos básicos sobre transações, 
principalmente a importância de garantir que as propriedades ACID sejam respeitadas na 
execução das transações. 
E para melhor aproveitamento dos recursos computacionais e menor tempo 
de execução, as transações devem executar de maneira simultânea. Porém, isso pode 
ocasionar alguns problemas, principalmente relacionados à perda de consistência dos 
dados em caso de falha de alguma transação. 
Para contornar essas limitações, deve-se tentar implementar transações com 
planos sequenciais, pois eles são mais simples de serem controlados. Se algum plano não 
for sequencial, o ideal é tentar escalonar as operações deste plano, respeitando sempre os 
casos possíveis de inversões de instruções. 
Além disso, para a implementação de bons planos de execução de transações, 
deve-se evitar aqueles que não sejam recuperáveis ou que apresentem rollback em cascata.
24UNIDADE I Escalonamento de Transações
MATERIAL COMPLEMENTAR
 
LIVRO 
Título: Governança de Dados: Práticas, conceitos e novos caminhos
Autor: Carlos Barbieri.
Editora: Alta Books.
Sinopse: Neste livro você entenderá o conceito de Governança de 
Dados, os fatores críticos de sucesso e as dificuldades e desafios 
na sua implementação, conhecerá uma breve história dos dados 
digitais, que precederá o direcionamento que essa nova linha de 
atuação ganhará com os conceitos emergentes de: IoT (Internet 
das Coisas); Big Data; Ciência de Dados; Inteligência Artificial. 
Neste último, tocaremos no sensível e inquietante ponto de ética 
nos dados. Governança de Dados: Práticas, Conceitos e Novos 
Caminhos traz uma nova abordagem sobre o que é considerado 
o maior recurso organizacional da sociedade digital: O dado. 
Com o crescimento dos conceitos de Big Data, IoT (Internet das 
Coisas) e Inteligência Artificial, torna-se imperativa a adoção de 
um novo olhar das empresas sobre esses recursos, por meio 
de uma governança e gerência profissional, viável, moderna e, 
principalmente, efetiva em resultados. Para a criação, consumo 
e descarte controlado desses ativos, algumas regras (políticas, 
padrões, processos, procedimentos etc.) deverão ser definidas 
nas empresas, regulando o seu uso e minimizando os seus riscos. 
As diversas gerências (Segurança, Qualidade, Bancos de Dados, 
Dados Mestres, Metadados etc.) formam o arco operacional 
executivo dos dados na empresa. As duas visões, governança e 
gerência, em convergência e harmonia, criam a gestão de dados. 
 
FILME/VÍDEO
Título: Sujeito a Termos e Condições
Ano: 2013.
Sinopse: O que acontece quando o usuário clica em “aceitar” 
um contrato de termo de uso na internet? O documentário busca 
revelar o que vem sendo feito pelas corporações e os governos 
que possuem acesso ilimitado as informações dos usuários através 
de bancos de dados em computadores e celulares, permitidos de 
serem acessados ao se clicar “aceitar” em um termo de uso. 
25
Plano de Estudo:
● Definições e protocolos de bloqueio;
● Bloqueio binário e múltiplo;
● Bloqueio em duas fases.
Objetivos da Aprendizagem:
● Conceituar e contextualizar os protocolos de bloqueio
 nas transações concorrentes;
● Compreender os tipos de bloqueio utilizados para bloquear 
itens compartilhado em transações simultâneas;
● Estabelecer a importância do bloqueio em 
situações com transações simultâneas.
UNIDADE II
Controle de Concorrência
Professora Doutora Gisele Alves Santana
26UNIDADE I Escalonamento de Transações 26UNIDADE II Controle de Concorrência
INTRODUÇÃO
Um Sistema de Gerenciamento de Banco de Dados que suporta bancos de dados com 
várias aplicações deve permitir acesso concorrente à esses dados. A concorrência proporciona 
melhor tempo de resposta e eficiência computacional, melhorando o desempenho do SGBD. 
Porém, para que a concorrência seja implementada, deve-se assegurar principalmente que 
as propriedades ACID, vistas na Unidade 1, não sejam violadas. 
Para garantir a harmonia dos procedimentos realizados simultaneamente são 
implementados mecanismos de controle de concorrência. Basicamente, um método 
de controle de concorrência deve garantir que em todas as execuções concorrentes de 
transações, cada uma dessas transações termine e que elas sejam executadas sem 
interferência das outras e sem irregularidades de sincronização. Alguns exemplos de 
irregularidades ou anomalias são: acesso a dados inconsistentes, perdas de atualizações 
e perda da consistência do BD.
Nesta Unidade, você vai aprender algumas técnicas utilizadas para o controle 
de concorrência como forma de assegurar a propriedade de não interferência entre uma 
operação e outra ou o isolamento das transações executadas ao mesmo tempo. Dentre 
essas técnicas de bloqueio, você vai conhecer o funcionamento e as características do 
bloqueio binário, bloqueio múltiplo e bloqueio em duas fases.
Você está pronto? Então vamos lá!
27UNIDADE I Escalonamento de Transações 27UNIDADE II Controle de Concorrência
1. DEFINIÇÕES E PROTOCOLOS DE BLOQUEIO
A concorrência pode ser definida como a propriedade de uma transação poder 
ser executada em paralelo com outras transações (ELMASRI e NAVATHE, 2011). Com a 
execução de várias transações ao mesmo tempo, o processador pode ser compartilhado 
entre essas transações, melhorando a eficiência global da máquina, já que uma quantidade 
maior de tarefas é executada em paralelo. 
Com várias transações concorrendo ao mesmo tempo, torna-se necessário que 
o sistema monitore a interação entre as mesmas, de maneira a evitar que a consistência 
do Banco de Dados seja violada (MEDEIROS, 2013). Geralmente, esse gerenciamento é 
realizado através de técnicas de bloqueio ou locks.
A Figura 1 ilustra a arquitetura de um SGBD, onde pode-seperceber que as transações 
são gerenciadas por um Gerenciador de Transações, que implementa alguma técnica de 
controle de concorrência. Após o gerenciamento, as transações são escalonadas, utilizando-
se de algum tipo de plano de execução, que você aprendeu na Unidade 1 desta disciplina. 
Após o escalonamento, os dados são gerenciados através de um gerenciador de 
recuperação, que é responsável por garantir a consistência do BD em caso de falhas. 
Você pode notar a importância do controle de concorrência, pois já no início da arquitetura 
do BD está o gerenciador de transações, responsável por implementar alguma técnica 
de controle, sendo que todas as demais partes da arquitetura são dependentes do bom 
funcionamento deste gerenciador.
28UNIDADE I Escalonamento de Transações 28UNIDADE II Controle de Concorrência
FIGURA 1 – ARQUITETURA DE UM SGBD
 
Fonte: Adaptado de: ELMASRI e NAVATHE (2011)
Qualquer banco de dados que seja utilizado por mais de um usuário deve administrar 
o controle de concorrência entre as informações que estão sendo acessadas pelos usuários. 
No controle de concorrência, usuários distintos ou transações diferentes tentam acessar a 
mesma informação ou item de dado ao mesmo tempo, então neste caso deve-se ter um 
controle entre essas transações (ELMASRI e NAVATHE, 2011). 
Como exemplo de concorrência, considere 4 transações, T1, T2, T3 e T4, ilustradas 
na Figura 2. Agora, imagine que o item de dado S represente o saldo da sua conta corrente e 
que todas essas transações sejam responsáveis por debitar um determinado valor do saldo S. 
FIGURA 2 – EXEMPLO DE CONCORRÊNCIA
 
Fonte: A Autora (2021).
29UNIDADE I Escalonamento de Transações 29UNIDADE II Controle de Concorrência
Agora suponha que o valor inicial de S é R$ 2.000,00 e que o plano de execução 
(schedule) dessas transações possui a seguinte sequência de ações:
● T1 lê o saldo S (read (S));
● T2 lê o saldo S (read (S));
● T3 lê o saldo S (read (S));
● T4 lê o saldo S (read (S));
● T4 debita uma quantia de S (S := S – 100);
● T4 escreve o novo valor de S (write (S));
● T3 debita uma quantia de S (S := S – 50);
● T3 escreve o novo valor de S (write (S));
● T2 debita uma quantia de S (S := S – 200);
● T2 escreve o novo valor de S (write (S));
● T2 debita uma quantia de S (S := S – 150);
● T1 escreve o novo valor de S (write (S)).
Você consegue dizer qual problema que ocorreu nesse caso?
Repare que quando as transações leem o valor do item de dado S, o valor lido por 
todas as transações é o valor inicial de S (R$ 2.000,00). Porém, a partir do momento em 
que a transação T3 debita uma quantia da conta (S := S - 50), o valor de S já foi alterado 
por T4, mas T3 não leu esse valor atual. Quando acontece esse tipo de problema, diz que 
ocorreu uma “leitura suja”, ou seja, a transação leu um valor que já não reflete mais o valor 
atual do item de dado. 
Além disso, como todas as transações estão executando concorrentemente e 
acessando o mesmo item de dado ao mesmo tempo e sem nenhum tipo de controle, a 
única atualização que será realmente efetivada é a última. Assim, neste caso, o valor final 
do saldo refletirá apenas a quantia debitada por T1, sendo que as atualizações realizadas 
por T2, T3 e T4 são perdidas. Quando esse tipo de problema acontece, diz-se que o BD 
sofreu “alterações perdidas”.
Ainda no exemplo, cada transação respeitou o princípio de acesso exclusivo ao 
item de dado S, mas isso não foi suficiente para garantir a execução correta das ações 
das transações. Dessa maneira, é fundamental que seja implementado um mecanismo de 
controle de concorrência eficiente.
O problema principal a ser resolvido pelas técnicas de controle de concorrência 
pode ser resumido como: assumir que todas as transações preservam a consistência lógica 
do BD e terminam, quando executadas sequencialmente (ELMASRI e NAVATHE, 2011). 
30UNIDADE I Escalonamento de Transações 30UNIDADE II Controle de Concorrência
Então, de acordo com Medeiros (2013), uma técnica de controle de concorrência 
deve garantir que:
● cada transação termina;
● cada transação seja executada sem interferência das outras e sem anomalias de 
sincronização.
Essas características devem ser atingidas permitindo-se o máximo de concorrência 
possível, de forma transparente para os usuários e para o conjunto de transações acessando 
qualquer parte do BD.
31UNIDADE I Escalonamento de Transações 31UNIDADE II Controle de Concorrência
2. BLOQEIO BINÁRIO E MÚLTIPLO
As técnicas de controle de concorrência, também chamadas de técnicas ou 
protocolos de bloqueio, são utilizadas para garantir a propriedade de não interferência 
entre as transações, assim como o isolamento de transações executadas simultaneamente 
(ELMASRI e NAVATHE, 2011). 
A maioria dessas técnicas garante a serialização, que é a execução das transações 
de maneira serial (MEDEIROS, 2013). É importante lembrar que uma transação compreende 
todas as operações ou ações executadas entre o início e o fim da mesma, e para gerenciar 
as transações é necessário que as técnicas de bloqueio implementadas pelo SGBD 
assegurem que as propriedades ACID sejam respeitadas.
Nas técnicas de bloqueio, geralmente uma variável de controle é associada a um 
item de dado no BD, representando o status desse item em relação a possíveis operações 
que podem ser aplicadas sobre ele. Então, os bloqueios são utilizados com o objetivo de 
sincronizar o acesso aos itens de um Banco de Dados por transações concorrentes. Os 
bloqueios possuem duas características fundamentais:
● Uma variável (lock) associada a um item de dado, que descreve o status do item 
em relação a possíveis operações que podem ser aplicadas ao mesmo.
● Geralmente, existe um bloqueio para cada item de dado no BD.
32UNIDADE I Escalonamento de Transações 32UNIDADE II Controle de Concorrência
As técnicas de bloqueio mais utilizadas pelos SGBDs são (MEDEIROS, 2013):
● Bloqueio binário;
● Bloqueio múltiplo;
● Bloqueio em duas fases.
A seguir, cada uma dessas técnicas é apresentada e exemplificada.
2.1 Bloqueio Binário
No bloqueio binário, a variável lock possui dois estados (ELMASRI e NAVATHE, 2011): 
● Bloqueado (locked);
● Desbloqueado (unlocked).
Um lock distinto é associado a cada item do BD, por exemplo: lock_item(X) para o 
item de dado x, lock_item(Y) para o item de dado Y, lock_item(A) para o item de dado A.
As operações realizadas pelo bloqueio binário são indivisíveis, sendo elas:
●	lock_item(X) – bloqueia o item de dado X;
●	unlock_item(X) – desbloqueia o item de dado X.
Um gerenciador é mantido pelo SGBD para gerenciar e controlar o acesso aos locks, 
sendo que para cada lock efetuado é mantido um registro no formato: <nome-item,LOCK> 
e esses registros são mantidos em uma tabela de lock.
Basicamente, no funcionamento do bloqueio binário é imposta a exclusão mútua 
em um item de dado, considerando dois importantes fatores:
● Se uma operação de bloqueio ou desbloqueio de X for iniciada, nenhum entrelaçamento 
é permitido até que a operação em questão termine ou a transação espere;
● O comando de espera coloca a transação em uma fila de espera pelo item X até 
que o mesmo seja desbloqueado.
Assim, o bloqueio binário impões as seguintes regras de gerenciamento (ELMASRI 
e NAVATHE, 2011): 
● Uma transação T tem que executar uma operação lock_item antes de qualquer 
read_item ou write_item executado por T;
● Uma transação T tem que executar a operação unlock_item(X) após todas as 
operações de read/write serem completadas em T;
● Uma transação não pode executar uma operação lock_item(X) se já possui um 
lock sobre X;
33UNIDADE I Escalonamento de Transações 33UNIDADE II Controle de Concorrência
● Uma operação T não pode executar um unlock_item(X) a menos que tenha um 
lock sobre X;
● Apenas uma transação pode ter um lock sobre um dado item.ao mesmo tempo.
O algoritmo dessa técnica é apresentado na Figura 3:
FIGURA 3 – ALGORITMO BLOQUEIOBINÁRIO
 
Fonte: Adaptado de: ELMASRI e NAVATHE (2011).
Basicamente, no algoritmo tem-se que:
● A transação que chegar primeiro, bloqueia o item de dado desejado.
● Se quiser bloquear, precisa saber se esse item já está bloqueado.
● Se o item não estiver bloqueado, então a variável lock desse item é setada para o 
valor 1;
● Se o item estiver bloqueado: deve-se aguardar até que o lock volte a ser zero.
Para garantir o adequado funcionamento desta técnica de bloqueio, existe um 
gerenciador de transações responsável por informar à transação que está em espera, que 
o item de dado solicitado por ela foi desbloqueado (MEDEIROS, 2013). Porém, esse aviso 
não garante a realização da transação (possibilidade de tentar novamente). Nesse intervalo, 
pode ser que outra transação chegue na frente ou pode haver uma fila. A Figura 4 ilustra um 
exemplo de schedule que utiliza o protocolo do bloqueio binário:
34UNIDADE I Escalonamento de Transações 34UNIDADE II Controle de Concorrência
FIGURA 4 – EXEMPLO DE SCHEDULE COM BLOQUEIO BINÁRIO
 
Fonte: A Autora (2021).
Como pode ser observado, de maneira resumida, no bloqueio binário:
2.2 lock_item(X)
● Antes de write(X) ou read(X).
● Se X ainda não tiver lock.
2.3 Unlock_item(X)
● Depois de todas as operações de write(X) ou read(X).
● Apenas se tiver o lock de X.
A maior desvantagem do bloqueio binário é que nem todas as operações realizadas 
devem bloquear o acesso a todas as transações, por exemplo, em uma operação de leitura, 
o acesso pode ser compartilhado com outras transações.
Como solução para este problema, tem-se a técnica de bloqueio de modo múltiplo, 
apresentada a seguir.
2.4 Bloqueio Múltiplo
No bloqueio de modo múltiplo, o item de dado é bloqueado exclusivamente apenas 
nas operações de escrita (ELMASRI e NAVATHE, 2011). Dessa maneira, todas as transações 
podem ler um determinado item de dado ao mesmo tempo, pois a leitura é compartilhada, 
mas apenas uma transação pode escrever ou atualizar este item.
Então, esse tipo de bloqueio possui três operações:
2.4.1 read_lock(X):
● Bloqueio compartilhado.
● Utilizado para leitura. 
35UNIDADE I Escalonamento de Transações 35UNIDADE II Controle de Concorrência
2.4.2 write_lock(X): 
● Bloqueio exclusivo.
● Utilizado para gravação.
● Somente uma transação pode solicitá-lo por vez.
2.4.3 unlock_item(X):
● Desbloqueia o item de dado.
Neste tipo de bloqueio, as seguintes regras devem ser observadas (ELMASRI; 
NAVATHE, 2011):
● Uma transação T tem que executar uma operação read_lock(X) ou write_lock(X) 
antes de qualquer read_item(X) executado por T;
● Uma transação T tem que executar uma operação write_lock(X) antes de qualquer 
write_item(X) em T;
● Uma transação T tem que executar uma operação unlock(X) após todas as 
operações read_item(X) ou write_item(X) completadas em T;
● Uma transação T não executará um read_lock(X) se já tem um lock compartilhado 
(read_lock) ou um lock exclusivo (write_lock) em X.
De acordo com os algoritmos de bloqueio e desbloqueio apresentados na Figura 5, 
você pode notar que essa técnica de bloqueio depende do estado da variável lock, ou seja:
● Se estiver em write_locked: tem apenas uma transação sendo executada;
● Se estiver em read_locked: pode ter várias transações executando 
simultaneamente.
36UNIDADE I Escalonamento de Transações 36UNIDADE II Controle de Concorrência
FIGURA 5 – ALGORITMOS DE BLOQUEIO MÚLTIPLO
 
Fonte: Adaptado de: ELMASRI e NAVATHE (2011).
Como regra, tem-se: decrementar o número de transações que estão bloqueando 
o item de dado; se este número chegar em zero (0), então o lock ficará desbloqueado e o 
próximo da fila será informado.
Então, para cada transação, tem-se:
2.5 read_lock(X)
● O antes de read(X).
● O se ainda não tiver read_lock ou write_lock.
2.6 write_lock(X)
● O antes de read(X) com intenção de write(X).
● O antes de write(X).
● O se ainda não tiver write_lock.
2.7 unlock(X)
● O depois de todas as operações read(X) ou write(X).
● O apenas se tiver o lock de X.
37UNIDADE I Escalonamento de Transações 37UNIDADE II Controle de Concorrência
A maior desvantagem relacionada à esse tipo de bloqueio é que o mesmo não 
garante a serialidade de escalonamentos nos quais as transações participam (MEDEIROS, 
2013). Para resolver esse problema é necessário um protocolo adicional que contempla o 
posicionamento dos locks e unlocks em cada transação e para ilustrar o bloqueio múltiplo, 
considere a Figura 6 que ilustra duas transações.
FIGURA 6 – EXEMPLOS DE BLOQUEIO MÚLTIPLOS
 
Fonte: A Autora (2021).
Colocando essas duas transações em um plano, tem-se o ilustrado na Figura 7. 
Repare que os itens de dados Y da transação T1 e X na transação T2 foram desbloqueados 
muito cedo, o que ocasionou um escalonamento não-serial.
FIGURA 7 – BLOQUEIO MÚLTIPLO NÃO SERIALIZÁVEL
 
Fonte: A Autora (2021).
Para contornar esse problema e garantir escalonamentos serializáveis, as operações 
de bloqueio e desbloqueio devem seguir protocolos, que são empregados pela técnica de 
bloqueio apresentada a seguir.
38UNIDADE I Escalonamento de Transações 38UNIDADE II Controle de Concorrência
3. BLOQUEIO EM DUAS FASES
A técnica de bloqueio em duas fases, também chamada de protocolo 2PL (Two-Phase 
Locking), controla a obtenção e liberação de bloqueios de forma que os escalonamentos 
sejam seriáveis, sendo a técnica mais utilizada pelos SGBDs (ELMASRI e NAVATHE, 2011).
Basicamente, esta técnica, como o próprio nome diz, possui duas fases: fase 
de crescimento e fase de encolhimento, sendo essas fases mutuamente exclusivas. Na 
fase de crescimento, é realizada a obtenção dos bloqueios dos itens de dados, ou seja, 
as transações obtêm os bloqueios de leitura ou escrita sobre itens de dados. Já na fase 
de encolhimento, é realizada a liberação dos bloqueios obtidos na fase anterior. Esse 
processo é ilustrado na Figura 8.
FIGURA 8 – FASES DE CRESCIMENTO E ENCOLHIMENTO
 
Fonte: Adaptado de ELMASRI e NAVATHE (2011).
39UNIDADE I Escalonamento de Transações 39UNIDADE II Controle de Concorrência
Então, a fase de crescimento está localizada na curva crescente e é nesta região 
que os bloqueios são realizados (nenhum desbloqueio). Na fase de encolhimento, que está 
localizada na descida da parábola, os bloqueios são liberados e nenhum novo bloqueio pode 
ser realizado (ELMASRI e NAVATHE, 2011). Se em um escalonamento todas as transações 
seguem o protocolo 2PL, então pode-se garantir que o escalonamento é seriável.
Alguns termos importantes utilizados pelo protocolo 2PL são:
3.1 Upgrade:
● Transformar um bloqueio de leitura para um de escrita. 
● Operação realizada apenas na fase de crescimento.
● Exemplo: read_lock(X) write_lock(X)
3.2 Downgrade:
● Transformar um bloqueio de escrita para um de leitura. 
● Operação realizada apenas na fase de encolhimento.
● Exemplo: write_lock(X) read_lock(X)
Para a obtenção dos bloqueios nesta técnica, as seguintes regras devem ser 
obedecidas (MEDEIROS, 2013):
● Uma transação deve bloquear todos os itens aos quais terá acesso, antes de iniciar 
o seu processamento. Se algum dos itens não puder ser bloqueado, a transação 
não bloqueia nenhum item e espera até que todos os itens estejam disponíveis para 
bloqueio.
● Após liberar o bloqueio, a transação não pode adquirir mais bloqueios;
● Em uma transação, todas as operações de bloqueio (read_lock, write_lock) 
precedem a primeira operação de desbloqueio na transação.
Uma grande desvantagem é que esse tipo de bloqueio pode limitar a concorrência 
do SGBD, pois uma transação T pode não ser capaz de liberar um item X depois de usá-lo, 
se T tiver de bloquear um item adicional Y depois. Reciprocamente, T precisa bloquear 
um item adicional Y antes que precise dele, de modo que possa liberar X. Logo, X precisa 
permanecer bloqueado por T até que todos os itens que a transação precisa ler ou gravar 
tenham sido bloqueados. Somente então X pode ser liberadopor T.
Na Figura 9 é apresentado um exemplo de transação que emprega o protocolo 2PL. 
Repare que na fase de crescimento apenas bloqueio dos itens de dados são realizados, e 
na fase de encolhimento os itens de dados são liberados.
40UNIDADE I Escalonamento de Transações 40UNIDADE II Controle de Concorrência
Também é ilustrado um exemplo de downgrade, no qual o item X estão bloqueados 
para escrita e depois foi bloqueado apenas para leitura.
FIGURA 9 – EXEMPLO DO PROTOCOLO 2PL
 
Fonte: A Autora (2021).
Já na Figura 10 é exemplificado um schedule com duas transações que também 
implementa o protocolo de bloqueio 2PL, pois os bloqueios precedem os desbloqueios 
em todos os casos.
FIGURA 10 – EXEMPLO DE SCHEDULE COM PROTOCOLO 2PL
Fonte: A Autora (2021).
Repare que no schedule apresentado na figura anterior, ocorre uma situação 
chamada deadlock, na qual uma ou mais transações estão em estado simultâneo de 
espera, cada uma aguardando que a outra libere um bloqueio para poder prosseguir com 
sua execução. Assim, a grande desvantagem desse protocolo de bloqueio é a ocorrência 
de deadlocks, mas ainda assim, é o tipo de protocolo mais utilizado pelos SGBDs.
41UNIDADE I Escalonamento de Transações 41UNIDADE II Controle de Concorrência
SAIBA MAIS
Em uma situação de deadlock, os processos já estão bloqueando um ao outro, portanto, 
é necessário que haja uma intervenção externa para resolver o impasse. Por esse 
motivo, os SGBDs possuem mecanismos de detecção e resolução de conflitos, em que 
um processo precisa ser escolhido como “vítima de deadlock” e ser eliminado para que 
o outro processo possa continuar funcionando. 
Quer saber mais sobre deadlock em um banco de dados? 
Acesse o link: https://dbabrasil.net.br/locks-blocks-deadlocks/
Fonte: Bernardes, 2012.
E você quer saber como resolver um deadlock? 
Então, acesse: https://cooperati.com.br/2012/07/quando-o-banco-apresenta-um-deadlock-o-que-fazer/.
Fonte: Mulotto (2018).
 
REFLITA
Os protocolos de bloqueio só existem porque existem problemas ao trabalhar-se com 
transações concorrentes.
Fonte: Date (2004).
https://cooperati.com.br/2012/07/quando-o-banco-apresenta-um-deadlock-o-que-fazer/
42UNIDADE I Escalonamento de Transações 42UNIDADE II Controle de Concorrência
CONSIDERAÇÕES FINAIS
Nesta Unidade, você conheceu a importância da implementação de técnicas de 
controle de concorrência em um SGBD. Quando várias transações estão sendo executadas 
simultaneamente, algum tipo de controle deve ser implementado, caso contrário, algumas 
inconsistências podem ocorrer, como leitura suja e atualização perdida.
Nesse contexto, as técnicas ou protocolos de bloqueio são empregados com o objetivo 
de garantir a consistência e o isolamento dos dados acessados por transações concorrentes. 
Você aprendeu também sobre três técnicas de controle de concorrência: bloqueio 
binário, bloqueio múltiplo e bloqueio em duas fases. No bloqueio binário, a variável associada 
ao bloqueio pode assumir dois valores: bloqueado ou desbloqueado. Apesar de ser uma 
técnica simples, possui algumas desvantagens, principalmente em relação ao bloqueio de 
acesso aos itens de dados, mesmo em caso de leitura. 
Já no bloqueio de modo múltiplo, existem dois tipos de boqueio, além do desbloqueio: 
bloqueio de leitura e bloqueio de escrita. No bloqueio de leitura, também chamado de 
bloqueio compartilhado, o item de dado bloqueado pode ser acessado para leitura por 
outras transações. No bloqueio de leitura, o acesso fica exclusivo apenas para a transação 
que realizou tal bloqueio.
Finalmente, vimos sobre a técnica de bloqueio em duas fases, que é a mais utilizada 
pelos SGBDS por garantir a serialidade dos planos de execução das transações. Esse 
protocolo possui duas fases, nas quais são realizados os bloqueios de todos os itens de 
dados que serão utilizados pelas transações (fase de crescimento) e depois é realizado o 
desbloqueio dos itens que já foram processados (fase de encolhimento).
Você percebeu que a concorrência proporciona melhor tempo de resposta e eficiência 
computacional e melhora o desempenho do SGBD. Porém, para que a concorrência seja 
corretamente realizada, técnicas de bloqueio devem ser implementadas. 
43UNIDADE I Escalonamento de Transações 43UNIDADE II Controle de Concorrência
LEITURA COMPLEMENTAR 
Para saber mais sobre o conteúdo abordado nesta unidade acesse os seguintes 
materiais:
● Sistemas de Banco de Dados:
http://tonysoftwares.com.br/attachments/article/5297/Sistema_de_banco_de_da-
dos_Navathe.pdf
● Projeto de Banco de Dados distribuídos:
https://www.ime.usp.br/~mfinger/home/papers/conf/MF98.pdf
● Injeção de falhas em banco de dados distribuídos:
https://www.lume.ufrgs.br/bitstream/handle/10183/2474/000320304.pdf?sequen-
ce=1&local
● Análise e modelagem de banco de dados distribuídos:
http://www.repositoriobc.unirio.br:8080/xmlui/bitstream/handle/unirio/12863/MI%20
15%20-%202010.pdf?sequence=1
http://tonysoftwares.com.br/attachments/article/5297/Sistema_de_banco_de_dados_Navathe.pdf 
http://tonysoftwares.com.br/attachments/article/5297/Sistema_de_banco_de_dados_Navathe.pdf 
https://www.ime.usp.br/~mfinger/home/papers/conf/MF98.pdf 
https://www.lume.ufrgs.br/bitstream/handle/10183/2474/000320304.pdf?sequence=1&local 
https://www.lume.ufrgs.br/bitstream/handle/10183/2474/000320304.pdf?sequence=1&local 
http://www.repositoriobc.unirio.br:8080/xmlui/bitstream/handle/unirio/12863/MI%2015%20-%202010.pdf?sequence=1 
http://www.repositoriobc.unirio.br:8080/xmlui/bitstream/handle/unirio/12863/MI%2015%20-%202010.pdf?sequence=1 
44UNIDADE I Escalonamento de Transações 44UNIDADE II Controle de Concorrência
MATERIAL COMPLEMENTAR
 
LIVRO 
Título: Sistemas de Gerenciamento de Banco de Dados
Autor: Raghu Ramakrishnan | Johannes Gehrke.
Editora: McGraw Hill Brasil.
Sinopse: Este livro apresenta uma abordagem clara e atualizada 
dos fundamentos dos sistemas de banco de dados. Os leitores 
podem optar por dar ênfase a aplicações de bancos de dados ou 
a sistemas. O livro traz muitos exemplos e aplicações, incluindo 
SQL e Oracle, e aplicações para a Internet. Além disso, são intro-
duzidos padrões atuais, como JDBC e XML, e desenvolvimento de 
aplicações em três camadas.
 
FILME/VÍDEO 
Título: Jobs
Ano: 2013.
Sinopse: Este filme mostra a história de vida de Steve Jobs, 
desde sua época na faculdade (e desistência da mesma) até seu 
sucesso como uma das pessoas mais famosas e reverenciadas no 
mundo da tecnologia. O filme conta como o fundador da Apple não 
entendia apenas de computadores, mas principalmente sempre se 
destacou pelo seu entendimento e visão de mercado e negócios.
45
Plano de Estudo:
● Conceitos, tipos de falhas e operações básicas;
● Técnica de Recuperação (Arquivo de log);
● Técnica de Recuperação (Checkpoints).
Objetivos da Aprendizagem:
● Conceituar e contextualizar os sistemas de recuperação de falhas;
● Compreender os tipos de técnicas utilizadas para recuperar
 o BD em caso de ocorrência de falhas;
● Estabelecer a importância da implementação das técnicas 
de recuperação de falhas em um SGBD.
UNIDADE III
Sistemas de Recuperação
Professora Doutora Gisele Alves Santana
46UNIDADE III Sistemas de Recuperação
INTRODUÇÃO
Os bancos de dados são essenciais para qualquer tipo de sistema de informação, 
devendo oferecer integridade, consistência e segurança dos dados armazenados. 
Porém, caso ocorra alguma falha, existe a possibilidade de um BD perder ou alterar 
seu desempenho. Dentre os tipos de falhas mais comuns tem-se: falta de manutenção, falhas 
de transação (erros lógicos), queda de energia elétrica e danos físicos aos equipamentos 
(hardware) de armazenamento dos dados. 
Na ocorrência de uma falha, os dados de um BD podem ser perdidos. Para que 
essa situação não aconteça, os SGBDs utilizam sistemas de recuperação de falhas, 
que sã responsáveis pela restauração do BD para um estado consistente, anterior da 
ocorrência da falha.
Geralmente, ossistemas de recuperação atuam antes e após a ocorrência de uma 
falha, ou seja, são implementadas ações durante o processamento de transações, a fim 
de assegurar que exista informações consistentes para permitir a recuperação correta dos 
dados. Além disso, são executadas ações após a ocorrência da falha, com o objetivo de 
recuperar o estado consistente do BD antes da falha.
Existem vários tipos de técnicas de recuperação de falhas e nesta aula você vai 
conhecer e aprender a aplicar as técnicas de recuperação baseadas em log e checkpoints.
Você está preparado (a)?
Então, vamos lá!
47UNIDADE III Sistemas de Recuperação
1. CONCEITOS, TIPOS DE FALHAS E OPERAÇÕES BÁSICAS
A transferência de dados entre memória e disco pode resultar em (ELMASRI e 
NAVATHE, 2011):
● Conclusão bem sucedida: o destino recebeu a informação;
● Falha parcial: o destino recebeu informação incorreta;
● Falha total: o destino permaneceu intacto.
Então, é interessante manter dois blocos físicos (destino) para cada bloco lógico 
(origem), considerando que um bloco contém diversos dados (MEDEIROS, 2013). Para 
melhor entendimento, vamos assumir que um dado não pertence a mais de um bloco.
Na Figura 1, os movimentos de blocos entre memória principal (MP) e disco 
envolvem duas operações básicas (ELMASRI e NAVATHE, 2011):
1.1 Input(B)
● Transfere o bloco físico B para a memória principal.
1.2 Output(B)
● Transfere o bloco de buffer B para o disco.
Analisando ainda mais a Figura 1, você pode perceber que cada transação possui uma 
área de trabalho privada, na qual mantém cópia de todos os itens de dados acessados por ela.
48UNIDADE III Sistemas de Recuperação
Essa área de trabalho é criada quando a transação é iniciada, sendo removida quando 
a transação é abortada ou efetivada. A interação da transação com o sistema acontece através 
da transferência de dados desta área de trabalho para o buffer do sistema e vice-versa.
FIGURA 1 – ESQUEMA DE TRANSFERÊNCIA DE BLOCOS ENTRE MP E DISCO
 
Fonte: Adaptado de: ELMASRI e NAVATHE (2011).
Como operações principais para a transferência de blocos entre a memória e o 
disco, temos (ELMASRI; NAVATHE, 2011):
1.3 read(X)
● É o valor do item de dado X para a variável de programa xi.
● Se o bloco Bx , no qual X reside não estiver na memória principal, então é 
emitido um input(Bx).
● O input(Bx) atribui a xi o valor de X a partir do bloco de buffer.
1.4 write(X)
● Realiza a atribuição do valor da variável de programa xi para o item de dado X 
no bloco de buffer.
● Se o bloco Bx no qual reside X não estiver na memória principal, então é 
executado o input(Bx).
● O input(Bx) atribui o valor de xi para X no buffer Bx.
Eventualmente, o bloco de buffer é escrito no disco por duas razões: o buffer está 
cheio e é preciso liberar espaço, ou o sistema deseja refletir a mudança em B sobre o disco. 
Para a saída de um dado, o sistema utiliza a operação output(B). Nem sempre o output(B) 
ocorre imediatamente depois de um write(B). Então, se o sistema falhar, o valor escrito em 
B por uma transação pode se perder.
49UNIDADE III Sistemas de Recuperação
1.5 Tipos de Falhas 
Os principais tipos de falhas que podem ocorrer um SGBD são: falhas de transação, 
erros de sistema, queda do sistema e falha de disco (ELMASRI e NAVATHE, 2011).
As falhas de transação podem ser causadas por erros lógicos (MEDEIROS, 2013). 
Nesse caso, a transação não pode continuar sua execução normal devido a uma falha interna 
do sistema, como por exemplo, dados não encontrados, overflow (estouro de memória) e 
programação incorreta. Mesmo que a transação seja reexecutada, o problema irá persistir.
Já nos erros de sistema, o sistema entra em um estado inadequado (deadlock, por 
exemplo), e com isso, a transação não consegue continuar sua execução normal, mas a 
mesma pode ser reexecutada posteriormente (MEDEIROS, 2013).
Por outro lado, uma falha relacionada à queda do sistema pode ocasionar algum 
mal funcionamento no hardware ou software, causando a perda do conteúdo armazenado 
em meio volátil e, assim, parando a execução de uma transação (MEDEIROS, 2013). Vale 
ressaltar que o conteúdo armazenado em meio não-volátil permanece intacto.
Já quando um bloco de disco perde seu conteúdo em função da quebra do cabeçote ou 
de falha durante uma transferência de dados, diz-se que o sistema sofreu uma falha de disco.
Considere a Figura 2, que ilustra a ocorrência de uma falha (queda no sistema) 
durante a execução da Transação T1, e suponha que os valores iniciais de A e B são iguais 
a 1000 e 2000, respectivamente.
FIGURA 2 – EXEMPLO DE OCORRÊNCIA DE FALHAS
 
Fonte: Adaptado de: ELMASRI e NAVATHE (2011).
Vamos imaginar dois procedimentos possíveis para a recuperação: reexecutar ou 
não reexecutar T1. 
50UNIDADE III Sistemas de Recuperação
Qual desses procedimentos seria o mais adequado? Primeiro, vamos analisar a 
reexecução de T1. Nesse caso, com a transação T1 executando novamente, tem-se o valor 
de A igual a 900 ao invés de 950. Dessa maneira, o sistema entra em estado inconsistente.
Agora, vamos verificar o que acontece se o sistema não reexecutar a transação T1. 
Nesse caso, o valor de A permanece igual a 950 e o valor de B permanece igual a 2000. 
Então, mais uma vez, o sistema fica em estado inconsistente.
Esse problema ocorreu porque modificou-se o banco de dados antes de se ter certeza 
de que a transação foi efetivada de fato. Assim, para evitar esse tipo de problema, todas ou 
nenhuma das modificações da transação deveriam ser realizadas (ELMASRI e NAVATHE, 2011). 
Nesse contexto, para garantir a atomicidade é necessário primeiramente enviar as 
informações sobre as modificações para um meio estável, sem modificar efetivamente o 
banco de dados (MEDEIROS, 2013). Aqui entram os sistemas de recuperação de falhas, 
que são rresponsáveis pela restauração do banco de dados para um determinado estado 
(o estado antes da ocorrência de uma falha).
Mas, quais são os meios disponíveis para o armazenamento dos dados? 
No armazenamento volátil, as informações não resistem à quedas do sistema. Por 
outro lado, no meio de armazenamento não volátil as informações não são perdidas quando 
se tem quedas do sistema, mas estão sujeitas a se perderem em falhas mais drásticas. 
Então, o melhor meio de armazenamento é o estável, no qual a informação nunca é perdida. 
Teoricamente, é impossível de se obter um meio estável, mas pode-se utilizar técnicas para 
tornar improvável a perda definitiva de dados de um BD.
1.6 Ações Básicas
Qualquer técnica de recuperação utiliza alguma ação básica, como (ELMASRI e 
NAVATHE, 2011):
1.6.1 Transaction UNDO 
● Uma transação não concluiu suas operações.
● As modificações realizadas por esta transação no BD são desfeitas.
1.6.2 Global UNDO
● Uma ou mais transações não concluíram as suas operações.
● As modificações realizadas por todas essas transações no BD são desfeitas.
51UNIDADE III Sistemas de Recuperação
1.6.3 Partial REDO
● Na ocorrência de uma falha, algumas transações podem ter concluído suas 
operações (committed), mas suas ações podem não ter se refletido no BD.
● As modificações realizadas por essas transações são refeitas no BD.
1.6.4 Global REDO
● No caso de um comprometimento do BD, todas as transações committed no 
BD são perdidas.
● As modificações realizadas por todas essas transações no BD são refeitas.
Vamos ver alguns exemplos de aplicação dessas ações na ocorrência de algumas 
falhas. Suponha que o sistema sofre uma falha de transação, na qual uma transação 
ativa terminou de forma anormal. Como possíveis causas dessa falha, tem-se: lógica da 
transação mal definida, deadlock ou cancelamento pelo usuário. Esse tipo de falha não 
compromete a memória principal e a memória secundária (disco), sendo a falha que possui 
a maior probabilidade de ocorrência em um sistema. 
Porém, seu tempo de recuperação é pequeno. Então, para essa falha, deve-se 
adotar comoação Transaction UNDO e, assim, as modificações provocadas por esta 
transação são desfeitas. 
Considere agora que o SGBD encerrou a sua execução de forma anormal, que teve 
como possíveis causas: interrupção de energia, falha no Sistema Operacional ou falha de 
algum equipamento de hardware. Esse tipo de falha pode comprometer a memória principal, 
mas não compromete o disco. Essa falha possui probabilidade média de ocorrência, assim 
como o tempo de recuperação (médio). Assim, as ações apropriadas para esse caso são: 
Global UNDO ou Partial REDO.
Por último, suponha que o BD tornou-se total ou parcialmente inacessível, tendo 
como possíveis causas: setores corrompidos no disco ou falha no cabeçote de leitura/gra-
vação. Esse tipo de falha não compromete a memória principal, mas compromete o disco. É 
uma falha com baixa probabilidade de ocorrência, porém seu tempo de recuperação é alto. 
Para esse caso, a ação implementada deverá ser Global REDO.
Como você pode perceber, para qualquer tipo de falha as operações são desfeitas 
ou refeitas. Mas, como garantir que o BD fique consistente após uma nova execução ou 
após as operações de uma transação terem sido desfeitas? Para isso, são usados sistemas 
de recuperação, alguns deles apresentados a seguir.
52UNIDADE III Sistemas de Recuperação
2. TÉCNICA DE RECUPERAÇÃO (ARQUVOS DE LOG)
O arquivo de log pode ser definido como uma sequência de registros que mantém 
um arquivo atualizado das atividades executadas em um Banco de Dados (ELMASRI e 
NAVATHE, 2011). O log pode ser gravado em dois momentos: 
● Antes da execução da transação;
● Depois da execução da transação.
 
Sempre que uma operação de escrita é realizada, é fundamental que o registro de 
log equivalente seja criado antes que o BD seja modificado (ELMASRI e NAVATHE, 2011). 
Dessa maneira, o log deve residir em armazenamento estável. 
Como o log contém o registro completo de todas as atividades realizadas no banco 
de dados, seu tamanho pode se tornar relativamente grande, mas eventualmente, pode-se 
apagar o seu conteúdo.
O formato de cada entrada do arquivo de log é formado da seguinte maneira 
(ELMASRI e NAVATHE, 2011):
<Ti,Tj,V1,V2>
Onde:
Ti – identificador da transação;
Xj – identificador do item de dado;
V1 – valor antigo;
V2 – novo valor.
53UNIDADE III Sistemas de Recuperação
Outros registros de um arquivo de log podem ter os seguintes formatos (ELMASRI 
e NAVATHE, 2011):
2.1 [start,T]
● Registra que a transação T começou a executar.
2.2 [write,T,X,valor_antigo,valor_novo]
● Registra que a transação T trocou o valor_antigo de X pelo valor_novo.
2.3 [write,T,X, valor_novo]
● Registra que a transação T alterou X para o valor_novo.
2.4 [read,T,X]
● Registra que a transação T leu o valor do item X.
2.5 [commit,T]
● Registra que a transação T completou com sucesso e seus “efeitos” podem ser 
registrados no BD.
2.6 [abort,T]
● Registro de que a transação T foi abortada.
A Figura 3 ilustra um exemplo de duas transações T1 e T2 e seu escalonamento S. 
As letras R, W e C significam leitura, escrita e commit, respectivamente.
FIGURA 3 – ESCALONAMENTO S
 
Fonte: A autora (2021).
Como ficaria o arquivo de log para esse escalonamento? 
54UNIDADE III Sistemas de Recuperação
Primeiramente, vamos demarcar o início do arquivo de log com [start, T2], já que a 
Transação T2, de acordo com o escalonamento é a primeira a iniciar sua execução. Depois, 
a próxima entrada deverá ser de leitura do item de dado C, da seguinte maneira: [read, T2, 
C]. Após, a transação T1 é iniciada, sendo feita a leitura do item de dado A, então no arquivo 
de log deverão constar as entradas: [start, T1] e [read, T1, A]. Então, T2 é retomada com a 
execução do comando de escrita ou atualização do item de dado B. Suponha que B tinha 
o valor 10 que será atualizado para 20, então a entrada no arquivo de log fica da seguinte 
maneira: [write, T2, B, 10, 20]. 
E assim por diante, até a finalização das duas transações. O arquivo final resultante 
do escalonamento é mostrado na Figura 4.
FIGURA 4 – ARQUIVO DE LOG DO ESCALONAMENTO S
 
Fonte: A autora (2021).
Vale saber que o SGBD gera um identificador único para cada transação (ELMASRI e 
NAVATHE, 2011). Para a recuperação de falhas, as operações de leitura (read) não precisam 
necessariamente serem gravadas no arquivo de log, mas para fins didáticos, adotaremos que 
essas operações são incluídas como entradas no arquivo, conforme feito na Figura 4.
Em caso de falha no sistema, se uma transação T tiver a entrada [start,T] no arquivo 
de log, é realizada uma das seguintes operações (ELMASRI e NAVATHE, 2011):
55UNIDADE III Sistemas de Recuperação
2.7 Undo (desfazer)
● Aplicada às transações do arquivo de log que não possuem a entrada [commit, 
T] ou [abort, T].
2.8 Redo (refazer)
● Aplicada às transações do log que possuem a entrada [commit, T]
O arquivo de log de um SGBD pode ser gravado em dois momentos: antes ou 
depois da execução da transação. A seguir, veremos cada uma dessas técnicas.
2.9 Modificação Adiada no Banco de Dados
Na técnica de modificação adiada, como o próprio nome diz, adia-se a execução 
de todas as operações de escrita (write) de uma transação até que ela seja parcialmente 
efetivada (tenha executado todas as suas ações) (ELMASRI; NAVATHE, 2011). 
No caso da ocorrência de alguma falha antes do término das operações de escrita 
ou se a transação for abortada, as informações no arquivo log serão ignoradas, e somente 
o novo valor do item de dado que sofreu alteração deve ser registrado log.
Na modificação adiada, um registro <start Ti> é escrito no log antes da transação 
Ti iniciar sua execução (ELMASRI; NAVATHE, 2011). 
Todas as operações write(x) de Ti, resultam em um novo registro no arquivo log. 
Quando Ti é parcialmente efetivada, um registro <Ti commit> deve ser escrito no log. 
Assim que a transação é parcialmente efetivada, os registros no log podem ser usados 
para atualizar o banco de dados e a transação entra em seu estado de efetivação. Neste 
momento, deve-se garantir que o log esteja armazenado em meio estável.
Como exemplo, considere a Figura 5, que ilustra a execução de duas transações 
T1 e T2, com os valores iniciais dos itens de dados A = 30, B = 10 e C = 80, assim como 
seu respectivo arquivo de log.
FIGURA 5 – EXEMPLO 1 DE MODIFICAÇÃO ADIADA
 
Fonte: A autora (2021).
56UNIDADE III Sistemas de Recuperação
Como o Banco de Dados nunca é atualizado efetivamente (em disco) até que as 
transações sejam efetivadas, nunca será necessária qualquer operação UNDO (desfazer) 
(ELMASRI e NAVATHE, 2011).
 Já no caso do sistema falhar depois que as transações forem efetivadas, será 
necessário realizar a ação de REDO (refazer), mas antes de todas as suas alterações 
serem gravadas em disco.
Vamos supor o exemplo ilustrado na Figura 6, com três situações. As ações 
executadas serão:
● Para o arquivo de log 1: nenhuma ação REDO é necessária, pois não se tem 
nenhuma entrada no arquivo de log com commit.
● Para o arquivo de log 2: é necessário realizar REDO(T1), pois existe uma entrada 
[commit, T1] registrada no arquivo de log.
● Para o arquivo de log 3: é necessário realizar REDO(T1) seguido de REDO(21), uma 
vez que as entradas [commit, T1] e [commit, T2] estão presentes no arquivo de log.
FIGURA 6 – EXEMPLO 2 DE MODIFICAÇÃO ADIADA
Fonte: A autora (2021).
Como outro exemplo, considere as transações da Figura 7, e tente determinar quais 
operações devem ser executadas pelo sistema de recuperação de falhas, tendo como base 
a técnica de modificação adiada.
57UNIDADE III Sistemas de Recuperação
FIGURA 7 – EXEMPLO 3 DE MODIFICAÇÃO ADIADA
Fonte: A autora (2021).
Para esse caso, como só existe uma linha de entrada no arquivo de log com commit 
([commit, T2]), será necessário apenas a ação REDO da transação T2.
Agora que você já aprendeu a técnica de modificação adiada, vamos conhecer 
o outro tipo de modificação