banco de dados distribuídos - facomilmerio/sbd20132/sbd9... · as operações básicas de acesso...

GBC043 – Sistemas de Banco de DadosTransações, Controle de Concorrência e

Recuperação de Dados

Ilmério Reis da [email protected]/~ilmerio/sbdUFU/FACOM

FACOM/UFU Página:2

Introdução – Sistemas multiusuário

Def. em um sistemas multiusuário vários usuários podem utilizar o sistema ao mesmo tempo e, portanto, muitos usuários podem acessar o banco de dados simultaneamente.

FACOM/UFU Página:3

Introdução - Arquitetura de um SGBD

FACOM/UFU Página:4

Introdução - Estado Consistente de um BD

Def Estado Consistente de um BD é o estado do BD que atende a todas as restrições definidas sobre ele

Obs: deve refletir a realidade que representa.

FACOM/UFU Página:5

Definição de TransaçãoDef. Transação é a execução de um programa(conjunto de

ações) que acessa o BD formando uma unidade lógica de processamento. Pode incluir operações de inserção, exclusão, modificação ou recuperação de dados.

FACOM/UFU Página:6

Execução intercalada x paralelaProcessos A e B: intercaladosProcessos C e D: paralelos

FACOM/UFU Página:7

Operações de leitura e gravaçãoAs operações básicas de acesso ao banco de dados que uma transação pode incluir são as seguintes:

read_item(X) ou r(x). Lê um item do banco de dados chamado X para uma variável do programa também chamada X.

write_item(X) ou w(x). Grava o valor da variável de programa X no item de banco de dados chamado X.

FACOM/UFU Página:8

Exemplos de transações

FACOM/UFU Página:9

Problemas em execuções concorrente

O problema da atualização perdida. O problema da atualização temporária (ou leitura suja). O problema do resumo incorreto. O problema da leitura não repetitiva.

FACOM/UFU Página:10

Exemplos de problemas em execuções concorrente


Definição de consistência de transação

Def. Consistência da Transação é a garantia de consistência do BD mesmo havendo concorrência e/ou falhas

Obs.:- A recuperação ao estado inicial é necessária em caso de

falha

- Falhas podem ser de transação, sistema ou mídia


Controle de transação


Diagrama de estados de uma transação


Propriedades de Transações


Atomicidade em Transações

• Tudo ou nada• Se for interrompida, resultados parciais devem ser

desfeitos(undo) • A preservação de atomicidade em abort devido a

erros de entrada, sobrecarga do sistema ou deadlock, é controlado por processo chamado transaction recovery

• A preservação de atomicidade na presença de falhas do sistema(crash) é chamada crash recovery


Consistência em Transações

• Interna Execução sem concorrência ou falhas sempre

leva a estados consistentes Obs: os programas são corretos

• Def Dirty DataÉ um dado atualizado por uma transação que

ainda não foi consolidada


Consistência de transação – Grau 0

Grau 0

T não sobrescreve(dirty data) de outra transação T’


T não sobrescreve dirty data de outra transação T’

T não consolida qualquer gravação até concluir todas suas tarefas (EOT)



T não sobrescreve dirty data de outra transação

T’ T não consolida qualquer gravação até concluir

todas suas tarefas (EOT) T não lê dirty data de outra transação T’




T não sobrescreve dirty data de outra transação T’

T não consolida qualquer gravação até concluir todas suas tarefas (EOT)

T não lê dirty data de outra transação T’ Outras transações T’ não escrevem(dirty) dados

lidos por T, antes de T terminar(EOT).


Isolamento de Transações- Schedule

Def Um schedule (ou histórico) S de n transações T1, T2, ..., Tn é uma ordenação das operações das transações. As operações das diferentes transações podem ser intercaladas no schedule S.


Isolamento de Transações- Representação de Schedules

* somente operações read e write, identificando o número da transação no schedule e o item de dado;

Exemplo: Sa: r1(x); r2(x); w1(x); r1(y); w2(x); w2(y);


Isolamento - Schedule seriais e intercalados


Isolamento de Transações- Representação de Schedules seriais e intercalados Seriais:

Sa: r1(x); w1(x); r1(y); w1(y); r2(x); w2(x);

Sb: r2(x); w2(x); r1(x); w1(x); r1(y); w1(y);

Intercalados Sc: r1(x); r2(x); w1(x); r1(y); w2(x); w1(y);

Sd: r1(x); w1(x); r2(x); w2(x); r1(y); w1(y);


Isolamento de Transações- Conflito

Def. Operações conflitantes: duas operações incompatíveis, por exemplo read e write, são conflitantes se acessam o mesmo dado

Def. Transações conflitantes: duas transações são conflitantes se possuem operações conflitantes


Isolamento de Transações- Schedule CompletoDef. Um schedule completo S sobre um conjunto de

transações T={T1, ..., Tn} é uma ordem parcial onde

- as operações em S são exatamente as de T, incluindo uma última operação de cancelamento ou confirmação para cada transação

- a ordem de qualquer oi(x) em Ti é a mesma em S

- duas operações conflitantes oi(x), oj(x), devem ocorrem uma antes da outra, ou seja, oi(x) < oj(x) ou oj(x) < oi(x)

Obs.: em um sistema em operação geralmente trabalhamos com projeção confirmada de schedules


Isolamento de Transações- Classificação de Schedules quanto à facilidade de recuperação


Isolamento de Transações- Schedule RecuperávelDef. Um schedule S é recuperável se nenhuma transação Ti em S for confirmada até que todas as transações Tj em S que tiverem gravado algum item X que Ti lê sejam confirmadas

Exemplos:Recuperável:

Não recuperável:


Isolamento Transações-Schedule sem cascata (evita rollback em cascata)Uma transação Ti não pode revelar seus resultados a

qualquer outra transação Tj antes de se consolidar, pois, caso isso aconteça, se Ti for cancelada Tj também terá que ser cancelada.

Def. Um schedule S evita rollback em cascata se cada tansação nele ler apenas itens que foram gravados por transações confirmadas


Isolamento Transações-Schedule estrito

Def. Um schedule S é estrito se nenhuma transação le ou grava X até que a última transação que gravou X seja consolidada.


Isolamento Transações- Relação entre tipos de Schedule

Estritos

Recuperáveis

Sem_Cascata


Isolamento de Transações – Classificação de Schedule quanto à facilidade de Serialização


Isolamento de Transações- Serializabilidade

Def Serializabilidade: se várias transações são executadas concorrentemente, o resultado final deve ser igual a alguma execução serial das mesmas transações.

Obs.: isso define a equivalência de resultado.


Equivalência de Conflito

Def Equivalência de Conflito: dois schedules são considerados equivalentes de conflito se a ordem de quaisquer duas operações em conflito for a mesma nos dois schedules


Serializabilidade de Conflito

Def um schedule é serializável de conflito se ele for equivalente de conflito a algum schedule serial


Teste de Serializabilidade de Conflito


Teste de Serializabilidade de Conflito-Exemplo


Equivalência de visão (menos restritiva)

Def Equivalência de visão: dois schedules são considerados equivalentes de visão se:


Serializabilidade de Visão

Def um schedule é serializável de visão se ele for equivalente de visão a algum schedule serial


Serializabilidade de Visão x de Conflito

Um schedule serializável de visão mas não serializável de conflito:


Níveis de Isolamento do Padrão SQL92


Isolamento no Padrão SQL92- Fenômenos a serem evitados

• Dirty data: itens alterados de transações não encerradas

• Leitura não repetível: T le x; T’ modifica x e termina; T le x atualizado por T’

• Fantasma: T le usando predicado p; T’ insere dados que satisfazem p; T le novamente incluindo dados inseridos po T’


Níveis de Isolamento do Padrão SQL92


Durabilidade em Transações

Assegura permanência de dados alterados por transações consolidadas

Recuperação de banco de dados (forward recovery)


Transações - Exercícios

GBC043 – Sistemas de Banco de DadosControle de Concorrência


Inrodução - Arquitetura de um SGBD


Introdução – Protocolos

O objetivo das técnicas ou protocolos de controle de concorrência é garantir o isolamento de transações ou a serialização e recuperabilidade de schedules

Um recurso importante para alguns protocolos é o bloqueio de itens de dado, por exemplo o bloqueio binário que caracteriza o item como bloqueado ou desbloqueado.


Introdução – Bloqueio binário


Introdução – Regras de bloqueio binário


Regras de bloqueio compartilhado -(read_lock e write_lock)


Protocolo de Bloqueio em duas fases (2PL)

Todas as operações de bloqueio (read_lock, write_lock) precedem a primeira operação de desbloqueio na transação.

As duas fases: fase de expansão: novos bloqueios, mas nenhum desbloqueio

fase de encolhimento: bloqueios liberados, mas nenhum novo bloqueio


Garantindo a serialização pelo 2PLO bloqueio em duas fases pode limitar a quantidade de concorrência passível de ocorrer em um schedule, 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; OU– T precisa bloquear um item adicional Y antes que precise dele, de modo que pode liberar X.

MAS,o uso de bloqueios, combinado com o protocolo 2PL, garante a serialização de schedulesENTRETANTO, podem ocorrer deadlocks


Deadlock em 2PL


Tratamento de Deadlock

Espera cuidadosa: Ti tenta bloquear X que está bloqueado por Tj ENTÃO se Tj estiver bloqueada aborte Ti caso contrário bloqueie Ti;

Detecção de deadlock: ciclo em grafo de espera;

Timeouts: limita o tempo de espera independente de haver deadlock;


Inanição em 2PL

Def. a inanição ocorre quando uma transação espera por longo período e outras prosseguem normalmente.

Obs.: Geralmente ocorre em protocolos com prioridades de liberação. A solução é não haver prioridade.


2PL e schedule equivalente

- O uso de bloqueios, combinado com o protocolo 2PL, garante a serialização de schedules.

- Os schedules serializáveis produzidos pelo 2PL têm seus schedules seriais equivalentes com base na ordem em que as transações em execução bloqueiam os itens que elas adquirem.


Rótulo de tempo (timestamp)

Def. rótulo de tempo(timestamp) é um identificador exclusivo criado pelo SGBD para identificar uma transação.

O algoritmo de ordenação de rótulo de tempo ordena as transações com base em seus rótulos de tempo conforme mostrado a seguir


Rótulos de tempo em read e write


Controle de concorrência baseado na ordenação de rótulo de tempo (timestamp)


Técnicas de controle de concorrência multiversão

- No controle de concorrência baseado em multiversão versões de um item são mantidas

- Quando uma transação requer acesso a um item, uma versão apropriada é escolhida para manter a serialização do schedule em execução, se possível.


Técnicas de controle de concorrência multiversão baseada na ordenação de rótulo

Sejam X1, X2, ..., Xk as versões mantidas para XPara cada versão mantêm-se um valor Xi e dois rótulos de tempo, a saber:


Técnicas de controle de concorrência multiversão baseada na ordenação de rótulo


Controle de concorrência - Exercícios

GBC043 – Sistemas de Banco de DadosRecuperação de Dados


Introdução – Recuperação - Objetivo

O objetivo das técnicas de recuperação de falha é restaurar o BD para o estado consistente mais recente antes da falha.

O sistema precisa manter dados sobre as mudanças realizadas por várias transações


Introdução - Arquitetura de um SGBD


Backup e Forward Recovery

Se houver falha catastrófica no disco restaura-se a cópia mais recente do BD

Então, refaz-se as transações confirmadas até o momento da falha com base nos dados existentes no log (forward recovery)


Falhas específicas

Se houver falha específica, identifique mudanças que causaram inconsistência e aplique uma das seguintes técnicas

– Atualização adiada – nada a desfazer (NO-UNDO/REDO);

– Atualização imediata – desfazer (UNDO/NO-REDO);

Operações de UNDO e REDO devem ser idempotentes, ou seja, executá-las várias vezes é equivalente a executá-las uma vez.


Buffering de blocos de discoO sistema operacional mantêm um bufferpoll(cache)com

itens de dados que são atualizados em memória volátil antes de persistidos em disco.

- o bufferpool é uma estrutura com vários dados, por exemplo:- Dirty-bit: indica se a versão no buffer foi modificada- Bit preso-solto: indica se o dado pode ser gravado em

disco


Atualização de blocos de disco e o LogVersões do dado:

– BFIM(before image) - usada para UNDO– AFIM(after image) – usada para REDO

Atualização no local grava o buffer modificado no mesmo local da versão anterior – exige armazenamento de BFIM e AFIM em log que registra as alterações em memória durável;

Atualização por sombreamento grava o buffer modificado em outros local e não será necessário uso de log, pois BFIM e AFIM estarão no BD


Log e write-ahead

write-ahead: BFIM é gravada no log antes da modificação do BD (recuperação com UNDO)


Log, write-ahead com UNDO e REDO


Técnicas steal/no-steal e force/no-force

Quando uma página do buffer pode ser escrita no disco?

No-steal: uma página atualizada por uma transação não pode ser escrita no disco antes que a transação se efetive (NO-UNDO)

No-force: uma página atualizada por uma transação efetivada não é imediatamente escrita no disco (REDO)


Log, steal/no-steal e force/no-force


Steal/No-force

Steal/No-force é a técnica tipicamente empregada por SGBDs atuais.

– Steal: diminui a necessidade de buffer

– No-force: páginas atualizadas no buffer podem ser reutilizadas, diminuindo operações de I/O


Check-point (o que é)

Um registro [checkpoint, lista de transações ativas] no log, indica um ponto em que todos os buffers do SGBD que foram modificados estão gravados no banco de dados em disco

Um check point é gravado periodicamente em intervalos de tempo em minutos (m) ou de número de transações confirmadas (t) desde o último check point

m ou t são parâmetros do sistema


Check-point (como fazer)


Recuperação em Cascata pois T2 le de T3


Recuperação com atualização adiada (NO-UNDO/REDO)


RDU_M(NO-UNDO/REDO - Checkpoint)


Recuperação baseada em atualização imediata

UNDO/NO-REDO

ou

UNDO/REDO


Recuperação baseada em atualização imediata

A Figura 23.4 ilustra os conceitos de diretórios de sombra e atual. Para as páginas atualizadas pela transação, duas versões são mantidas. A versão antiga é referenciada pelo diretório de sombra e a nova versão, pelo diretório atual.


Recuperação baseada em atualização imediata cont..


FIM- Transações, Controle de Concorrência e Recuperação de Dados

FIM- Transações, Controle de Concorrência e Recuperação de Dados

banco de dados distribuídos - facomilmerio/sbd20132/sbd9... · as operações básicas de acesso...

Documents