UNIVERSIDADE ESTADUAL DO SUDOESTE DA BAHIA

DISCENTE: JOSIMAR

DOCENTES: EUDES

DISCIPLINA: BANCO DE DADOS II

Protocolos de serialização

• Planos Restauráveis

Os planos restauráveis são uma característica importante dos Sistemas de

Gerenciamento de Banco de Dados (SGBD), pois permitem a recuperação de dados
em caso de falhas ou erros que possam afetar o banco de dados. A função desses
planos é garantir a disponibilidade, integridade e confiabilidade dos dados
armazenados. Eles são compostos por pontos de restauração, que registram o estado
atual do banco de dados em um determinado momento.

Quando um ponto de restauração é criado, uma cópia dos dados, objetos e

informações de configuração relevantes para o estado atual do banco de dados é
armazenada em um local seguro, como um arquivo de backup ou dispositivo externo
de armazenamento. Caso ocorra uma falha ou erro que afete os dados, os
administradores do banco de dados podem usar esses pontos de restauração para
restaurar o banco de dados para um estado anterior à ocorrência do problema. Para
fazer isso, é utilizado o recurso de restauração de banco de dados do SGBD.

Além disso, os planos de restauração também são úteis para testar mudanças
em um banco de dados sem o risco de perda de dados importantes. Ao criar um ponto
de restauração antes de fazer alterações no banco de dados, os administradores do
banco de dados podem restaurar o banco de dados para esse ponto, se necessário,
revertendo as alterações feitas e mantendo a integridade dos dados.
 • Reversão em Cascata

A reversão em cascata é uma funcionalidade de gerenciamento de banco de

dados que possibilita a reversão de uma transação que afeta vários objetos do banco
de dados simultaneamente. Quando uma transação é revertida em cascata, todas as
outras transações que dependem dela também são desfeitas, evitando assim
inconsistências nos dados. Caso uma transação falhe, o banco de dados pode ficar
em um estado inconsistente, com alguns dados já atualizados e outros não. A
reversão em cascata é usada para evitar essa situação, desfazendo todas as
atualizações de dados realizadas durante a transação.

Por exemplo, suponha que uma transação é iniciada para atualizar diversos
registros em tabelas distintas de um banco de dados. Se ocorrer um erro durante a
transação, a reversão em cascata será utilizada para desfazer todas as atualizações
realizadas em todas as tabelas envolvidas na transação. Isso garante que o banco de
dados permaneça consistente e evita a ocorrência de erros e inconsistências nos
dados.

• Evitar Planos com Reversão em Cascata

Em algumas situações, a reversão em cascata pode ser prejudicial, pois pode levar à
perda de alterações importantes nos dados. Para evitar esse problema, é fundamental
adotar boas práticas de gerenciamento de banco de dados, tais como:

• Planejar as transações com cuidado: Evite que uma única transação afete
muitas tabelas e objetos. É mais seguro realizar transações menores e mais
específicas, reduzindo assim a chance de ocorrência da reversão em cascata.

• Realizar backups periódicos: Fazer backups regulares do banco de dados pode

minimizar a perda de dados no caso de uma reversão em cascata ser
necessária. Dessa forma, se ocorrer uma reversão, os dados importantes
podem ser recuperados a partir de um backup recente.

• Monitorar o banco de dados: Monitorar regularmente o banco de dados pode

ajudar a identificar e corrigir problemas antes que eles se tornem graves o
suficiente para exigir uma reversão em cascata. Isso pode incluir monitoramento
de desempenho, integridade de dados e detecção de erros e problemas.

Seguindo boas práticas de gerenciamento de banco de dados, é possível minimizar

a necessidade de reversão em cascata e reduzir o risco de perda de dados cruciais.
 • Bloqueio em Duas Fases e Suas Variações

O protocolo de Bloqueio em duas fases (Two-phase locking - 2PL) é uma técnica

de controle de concorrência usada em sistemas de gerenciamento de banco de dados
para garantir a integridade dos dados durante a execução de transações concorrentes.
O protocolo consiste em duas fases: a fase de aquisição (ou crescimento) e a fase de
liberação (ou redução).

Na fase de aquisição, a transação adquire os bloqueios necessários para

acessar os recursos do banco de dados. Isso significa que a transação deve solicitar
um bloqueio exclusivo ou compartilhado antes de acessar qualquer recurso. Durante a
fase de liberação, a transação libera os bloqueios quando não precisar mais acessar
os recursos.

Existem três variações do protocolo 2PL: Conservadora, Estrita e Rigorosa.

• Conservadora: Nesta variação, os bloqueios são adquiridos em todos os

recursos necessários para a transação logo no início da fase de aquisição, antes de
fazer qualquer modificação nos dados. Os bloqueios são mantidos até o final da
transação, quando são liberados na fase de liberação. Essa variação é considerada a
mais segura, mas pode causar um alto grau de bloqueio de transações concorrentes,
o que pode prejudicar o desempenho do sistema.

• Estrita: Os bloqueios são adquiridos em todos os recursos necessários para a

transação antes de fazer qualquer modificação nos dados. No entanto, os bloqueios
são liberados assim que a transação não precisar mais acessar um recurso específico.
Essa variação é menos restritiva que a conservadora e permite uma maior concorrência
entre as transações, mas ainda pode causar bloqueios excessivos em algumas
situações.

• Rigorosa: Os bloqueios são adquiridos em todos os recursos necessários para

a transação antes de fazer qualquer modificação nos dados, assim como nas outras
variações. No entanto, os bloqueios são mantidos até o final da transação, assim como
na variação conservadora. Essa variação é considerada a mais restritiva e oferece um
alto grau de segurança, mas pode causar bloqueios excessivos e impactar
significativamente o desempenho do sistema.
 • Deadlock

Deadlock é um problema que pode ocorrer em um banco de dados quando duas

ou mais transações ficam bloqueadas, aguardando a liberação de recursos que foram
bloqueados por outra transação. Esse problema pode impedir que as transações
continuem a executar e levar a uma paralisação do sistema.

O deadlock ocorre quando duas transações solicitam acesso a recursos que

estão bloqueados por outra transação, e ambas as transações ficam aguardando a
liberação desses recursos, impedindo que qualquer uma delas possa continuar a
executar. Por exemplo, se a transação A bloqueou o recurso R1 e solicita acesso ao
recurso R2, e a transação B bloqueou o recurso R2 e solicita acesso ao recurso R1,
ambas as transações ficarão bloqueadas, aguardando a liberação do recurso
bloqueado pela outra transação.

Existem várias causas que podem levar a um deadlock, incluindo a alocação

inadequada de recursos, a falta de sincronização entre as transações e a concorrência
excessiva entre as transações.

• Abordagens para Evitar Deadlocks

Os SGBDs implementam técnicas de controle de concorrência, como o

protocolo de bloqueio em duas fases (2PL) e o escalonamento de transações, para
evitar deadlocks e garantir a execução segura e ordenada de transações. No entanto,
caso ocorra um deadlock, o SGBD pode utilizar técnicas de detecção e resolução de
deadlock para recuperar o sistema.

Uma técnica comum é a detecção de deadlock, onde o SGBD monitora o

sistema em busca de transações bloqueadas e procura por ciclos de bloqueio. Quando
um deadlock é detectado, o SGBD escolhe uma das transações envolvidas e a cancela,
liberando os recursos bloqueados para que as outras transações possam continuar a
executar. Outra técnica é a prevenção de deadlock, que impede a ocorrência de
deadlock, mas pode aumentar o tempo de espera para a execução das transações.
 • Protocolos Baseados em Timestamp

Os protocolos baseados em timestamp são usados para controlar a

concorrência em bancos de dados. Esses protocolos atribuem um timestamp a cada
transação que acessa o banco de dados e usam esses timestamps para determinar a
ordem de acesso aos recursos compartilhados.

Existem dois tipos principais de protocolos baseados em timestamp: o protocolo

de timestamp de ordenação e o protocolo de timestamp multiversão. O protocolo de
timestamp de ordenação é um protocolo pessimista que impõe regras rígidas de
preempção para garantir a serialização das transações. Por outro lado, o protocolo de
timestamp multiversão é um protocolo otimista que permite que várias versões de um
objeto sejam mantidas no banco de dados e usa o timestamp para determinar qual
versão é a mais recente.

Além disso, existem variações dos protocolos baseados em timestamp, como o

protocolo de timestamp de conservação e o protocolo de timestamp de rigor. O
protocolo de timestamp de conservação permite que uma transação seja adiada se sua
execução não afetar a serialização das transações. Por outro lado, o protocolo de
timestamp de rigor permite que uma transação seja interrompida e revertida se houver
qualquer possibilidade de violação da serialização.

Em resumo, os protocolos baseados em timestamp são uma abordagem eficaz

para controlar a concorrência em bancos de dados e garantir a serialização das
transações. Cada protocolo tem suas próprias vantagens e desvantagens e deve ser
escolhido com base nos requisitos do sistema.

• Inanição

Inanição é um problema que pode ocorrer quando uma transação é impedida de

acessar um recurso compartilhado por um longo período de tempo, tornando
impossível a sua execução. Esse problema pode surgir quando várias transações estão
competindo por recursos limitados e um conjunto específico de transações está sempre
perdendo a disputa por esses recursos. Isso leva a uma espera prolongada e bloqueia
a execução da transação, levando a um atraso significativo na operação do sistema.

Por exemplo, se uma transação está bloqueando um recurso compartilhado que

outras transações também precisam acessar, essas outras transações ficarão em
espera, aguardando o recurso ficar disponível. Se a transação original não for
concluída ou liberar o recurso, as outras transações permanecerão em espera
indefinidamente, o que pode levar a uma situação de inanição. É importante que os
SGBDs implementem técnicas de controle de concorrência adequadas para prevenir a
ocorrência de inanição e garantir que todas as transações tenham a oportunidade de
acessar os recursos compartilhados.

• Abordagem para Evitar Inanição

Para evitar a ocorrência de inanição, existem diversas abordagens que podem

ser adotadas, como:

• Implementação de timeouts: essa é uma forma simples e eficaz de evitar a

inanição. Consiste em cancelar uma transação que esteja esperando por um recurso
por um determinado período de tempo configurado pelo administrador do SGBD. Isso
libera os recursos para que outras transações possam acessá-los.

• Priorização de transações em espera: outra abordagem é priorizar as

transações que estão esperando por recursos por um longo período de tempo, dando
a elas prioridade no acesso a esses recursos em relação a outras transações que
chegam posteriormente.

• Implementação de algoritmos de escalonamento de transações: é possível

evitar a inanição adotando algoritmos de escalonamento de transações que
considerem o tempo de espera das transações por recursos. Esses algoritmos podem
ser implementados de diversas formas, utilizando o tempo de chegada da transação,
o tempo de espera, ou uma combinação desses fatores.

• Aumento da capacidade de recursos: outra abordagem é aumentar a

capacidade de recursos disponíveis para o SGBD, como adicionar mais servidores ao
sistema ou expandir a capacidade de armazenamento do banco de dados. Isso reduz
o tempo de espera das transações por recursos e evita a inanição.