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 Silvailmerio@facom.ufu.brwww.facom.ufu.br/~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

- 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

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

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

Banco de Dados Distribuídos - FACOMilmerio/sbd20132/sbd9... · As operações básicas de acesso...

Documents

Banco de Dados Distribuídos - facom.ufu.brilmerio/sbd20132/sbd9_funcoesEgatilhos.pdf · Plpgsql– FUNÇÕES – Exemplo 2 - Problema Considere que um conjunto de comandos contendo

Banco de-dados

Seminário de Banco de Dados II Banco de Dados Espaciais · Seminário de Banco de Dados II Banco de Dados Espaciais Alunos: Bráulio Miranda Veloso Vítor Mangaravite Professor:

Banco de Dados - Tipos de Dados

Acesso Banco Dados

CURSO BANCO DADOS

Banco de Dados - Introdução - Projeto de Banco de Dados - DER

Banco Dados

Md7 banco dados

Banco de Dados

Banco de Dados Distribuídos - facom.ufu.brilmerio/sbd20132/sbd5sqlDDLparte1.pdf · Página 3 Prgrama Teórico/Prático - SQL • Linguagem SQL – Comandos de criação e eliminação

Banco de Dados - Sistemas de Gerenciamento de Banco de Dados

Banco de Dados Revisão de Banco de Dados Banco de Dados Adilson Silva adilson.silva@fsm.com.br

Conceitos Banco Dados

Banco Dados Completa

BANCO DE DADOS INTRODUÇÃO (MODELAGEM DE BANCO DE DADOS · BANCO DE DADOS INTRODUÇÃO (MODELAGEM DE BANCO DE DADOS) Definição de modelo 3 z .com “Dados são os fatos em sua

Sistemas de Banco de Dados - facom.ufu.brilmerio/sbd20132/sbd8algebraEcalculo.pdf · FACOM/UFU Página:2 Álgebra e Cálculo Relacional e o Modelo R • São as linguagens formais

Banco de Dados - tiagodemelo.infotiagodemelo.info/aulas/uea/2008/banco-dados/aula-bd-2008.pdf · Livros de Banco de Dados em Português Sistemas de banco de Dados Korth, H. F.; Silberschatz,

Apostila Banco Dados

Sistemas de Banco de Dados - Faculdade de Computaçãoilmerio/sbd20132/sbd9Anormalizacao.pdf · GBC043 – Sistemas de Banco de Dados Normalização de Relações em Projeto de BD