PROCESSAMENTO DE TRANSAÇÕES

UNINGÁ – UNIDADE DE ENSINO SUPERIOR INGÁFACULDADE INGÁCIÊNCIA DA COMPUTAÇÃO

Profº Erinaldo Sanches Nascimento

2

Objetivos

● Discutir a necessidade de controle de concorrência e recu-peração em SGBDs.

● Definir transação e os conceitos adicionais relacionados ao processamento de transação nos SGBDs.

● Apresentar as propriedades ACID.● Apresentar o conceito de schedules (históricos) de execu-

ção.● Definir as sequências de execução corretas de transações

simultâneas.● Apresentar comandos que dão suporte ao conceito de

transação em SQL.

3

Introdução

Discutir os conceitos de execução concorrente de transações e recuperação de transações com fa-lhas.

4

Classificação de um SGBD

● De acordo com o número de usuários que po-dem usar o sistema simultaneamente.

● Monousuário: no máximo um usuário de cada vez.

● Multiusuário: muito usuários podem acessá-lo simultaneamente.

5

SGBDs Monousuário

● Restrito a sistemas de computador pessoal.

6

SGBDs Multiusuário

● Sistema de reservas aéreas.● Sistemas usados em bancos, agências de se-

guros, mercado de ações, supermercados.

Centenas ou milhares de usuários normalmente Centenas ou milhares de usuários normalmente estão operando no banco de dados ao submeter estão operando no banco de dados ao submeter

transações ao sistema ao mesmo tempo.transações ao sistema ao mesmo tempo.

7

MultiprogramaçãoMultiprogramação: permite que o sistema ope-racional do computador execute vários progra-mas (processos) ao mesmo tempo.● Intercalada● Processamento paralelo

8

Transação

● É um programa em execução que forma uma unidade lógica de processamento de banco de dados.

● Incluir uma ou mais operações de acesso ao banco de dados.

● As operações podem ser embutidas em um programa de aplicação ou SQL.

9

Tipos de Transações

● Somente leituraSomente leitura: não atualizam o banco de da-dos, apenas recuperam dados

● Leitura-gravaçãoLeitura-gravação: faz o contrário.

10

Itens de Banco de Dados

● Um banco de dados é basicamente represen-tado como uma coleção de itens de dados no-meados.

● GranularidadeGranularidade: tamanho de um item de dados.● Item de dadosItem de dados: um registro de banco de dados,

um bloco de disco inteiro, um valor de campo.

11

● O processamento de transação é independen-te da granularidade.

● Se aplicam a itens de dados em geral.● Cada item de dados tem um nome único; um

meio para identificar exclusivamente cada item de dados.

12

Operações Básicas

● Leitura (read): read_item(X).● Gravação (write): write_item(X).

13

Comando de Leitura

1. Ache o endereço do bloco de disco que con-tém o item X.

2. Copie esse bloco de disco para um buffer na memória principal.

3. Copie o item X do buffer para a variável de programa chamada X.

14

Comando de Gravação

1. Ache o endereço do bloco de disco que con-tém o item X.

2. Copie esse bloco do disco para um buffer na memória.

3. Copie o item X da variável de programa cha-mada X para o local correto no buffer.

4. Armazene o bloco atualizado do buffer de vol-ta no disco.

15

Gerenciador de Recuperação

Em cooperação com o sistema operacional é quem decide quando armazenar um bloco de disco modificado● O SGBD manterá na cache do banco de dados

uma série de buffers de dados na memória principal.

● Utiliza uma política de substituição de buffer que devem ser substituídos.

16

● Conjunto de leitura: é o conjunto de todos os itens que a transação lê.

● Conjunto de gravação: é o conjunto de todos os item que a transação grava.

17

Controle de Concorrência

● As transações podem ser executadas simulta-neamente, acessar e atualizar os mesmos itens de banco de dados.

● Se a execução simultânea for descontrolada pode tornar o banco de dados inconsistente.

● Para fins de controle de concorrência, uma transação é uma execução em particular de um programa

18

Tipos de Problemas

● Atualização perdida● Atualização temporária (leitura suja)● Resumo incorreto● Leitura não repetitiva

19

Atualização Perdida

● Duas transações que acessam os mesmos itens do banco de dados têm suas operações intercaladas.

● Isso torna o valor de alguns itens do banco de dados incorreto.

20

21

Atualização Temporária

● Uma transação atualiza um item do banco de dados e depois a transação falha por algum motivo.

● Nesse meio-tempo, o item atualizado é aces-sado (lido) por outra transação, antes de ser al-terado de volta para seu valor original.

22

23

Resumo Incorreto

● Uma transação está calculando uma função de resumo de agregação em uma série de itens de banco de dados;

● Outras transações estão atualizando alguns desses itens;

● A função de agregação podem calcular alguns valores antes que eles sejam atualizados e ou-tros, depois que foram atualizados.

24

25

Leitura Não Repetitiva

● Uma transação T lê o mesmo item duas vezes e o item é alterado por outra transação T entre as duas leituras.

● T recebe valores diferentes para suas duas lei-turas do mesmo item.

26

Recuperação

● O SGBD é responsável por garantir que todas as operações na transação sejam concluídas com sucesso.

● Seu efeito é registrado permanentemente no banco de dados – confirmadaconfirmada (committed),

● Ou que a transação não tenha qualquer efeito no banco de dados ou quaisquer outras tran-sações – abortadaabortada.

27

● A transação inteira é uma unidade lógica de processamento de banco de dados.

● Se a transação falharfalhar depois de executar al-gumas de suas operações, as operações já executadas precisam ser desfeitas.

28

Tipos de Falhas

1. Falha do sistema (computador).

2. Erro de transação ou do sistema.

3. Erros locais ou condições de execução detec-tadas pela transação.

4. Imposição de controle de concorrência.

5. Falha de disco.

6. Problemas físicos e catástrofes

29

Falha do Computador

● Erro de hardware, software ou rede.● Falhas de mídia – memória principal.

30

Erro de Transação

● Estouro de inteiro.● Divisão por zero.● Valores de parâmetro errôneos.● Erro lógico de programação.● Usuário interrompe a transação durante sua

execução.

31

Erros Locais

● Dados da transação não podem ser encontra-dos.

● Saldo de conta insuficiente para um saque bancário.

● Execução que é programada na própria tran-sação – não é uma falha da transação.

32

Controle de Concorrência

● Aborta uma transação porque ela viola a seria-lização.

● Abortar uma ou mais transações para resolver um estado de deadlock entre várias transa-ções.

● Essas transações são reiniciadas automatica-mente em outro momento.

33

Falha de Disco

● Perda de dados devido a um defeito de leitura/gravação.

● Falha da cabeça de leitura/gravação.

34

Problemas Físicos

● Falha de energia.● Incêndio.● Roubo.● Sabotagem.● Regravação de discos ou fitas por engano.● Montagem da fita errada pelo operador.

35

Estados de Transação

● Begin_transaction● Read ou Write● End_transaction● Commit_transaction● Rollback (ou Abort)

36

37

Log do Sistema

● Registra todas as operações de transação que afetam os valores dos itens de banco de da-dos.

● Arquivo sequencial mantido no disco que não é afetado por qualquer tipo de falha.

● O arquivo de log do disco é periodicamente copiado para arquivamento, para proteger con-tra falhas catastróficas.

38

● Registro de logRegistro de log: tipos de entradas que são gra-vadas para o arquivo de log e a ação corres-pondente para cada registro de log.

39

Registros de Log

1. [start_transaction, T]

2. [write_item, T, X, valor_antigo, valor_novo]

3. [read_item, T, X]

4. [commit, T]

5. [abort, T]

40

Propriedades ACID

● Atomicidade● Preservação da consistência● Isolamento● Durabilidade ou permanência

41

Atomicidade

● Uma transação é uma unidade de processa-mento atômica.

● É realizada na sua totalidade ou não é realiza-da de forma alguma.

● O SGBD deve garantir.

42

Consistência

● Se uma transação for completamente executa-da deve levar o banco de dados de um estado consistente para outro.

● Responsabilidade do programador ou do SGBD que impõe restrições de integridade.

43

Isolamento

● Uma transação deve parecer como se fosse executada isoladamente de outras

● A execução de uma transação não deve ser in-terferida por quaisquer outras transações que acontecem simultaneamente.

● Imposta pelo subsistema de controle de con-corrência do SGBD.

44

Durabilidade

● As mudanças aplicadas ao banco de dados pela transação confirmada precisam persistir no banco de dados.

● É responsabilidade do subsistema de recupe-ração do SGBD.

45

Schedules

● Ordem da execução das operações de todas as diversas transações simultâneas.

● Operações de diferentes transações podem ser intercaladas no schedule (histórico) S.

● Para cada transação Ti do schedule S, as ope-rações de Ti em S precisam aparecer na mes-ma ordem de Ti.

46

● Um schedule utiliza os símbolos b, r, w, e, c e a para as operações begin_transaction, read_item, write_item, end_transaction, commit e abort, respectivamente.

● Acrescenta a id da transação a cada operação no schedule.

● O item X de bando de dados que é lido ou gra-vado segue as operações r e w entre parênte-ses.

47

Sa: r1(X); r2(X); w1(X); r1(Y); w2(X), w1(Y);

48

Sb: r1(X); w1(X); r2(X); c2; a1;

49

Conflito

● Duas operações são consideradas entrando em conflito se satisfizerem as três condições a seguir:

(1) Pertencem a diferentes transações;

(2) Acessam o mesmo item X;

(3) Pelo menos uma das operações é um write_item(X).

50

● Operações de leitura não estão em conflito.● Operações que operam em itens de dados dis-

tintos não estão em conflito.● Operações de leitura e escrita sobre o mesmo

item de dados que pertencem à mesma tran-sação não estão em conflito.

● Duas operações estão em conflito se a mu-dança de sua ordem puder resultar em algo di-ferente.

51

Conflito de Leitura

● Mudar a ordem das duas operações r1(X); w2(X) para w2(X); r1(X)– O valor de X que é lido pela transação T1 muda

– Na segunda ordem o valor de X é mudado por w2(X) antes que seja lido por r1(X)

– Na primeira ordem o valor é lido antes de ser alte-rado.

52

Conflito de Gravação-Gravação

● Muda a ordem das duas operações w1(X); w2(X) para w2(X); w1(X)– O último valor de X será diferente.

– Em um caso ele é gravado por T2

– No outro ele é gravado por T1

53

Schedule Completo

1. As operações em S são exatamente aquelas em T1, T2, …, Tn, incluindo uma operação de confirmação ou cance-lamento como última operação em cada transação no schedule.

2. Para qualquer par de operações da mesma transação Ti, a ordem de aparecimento relativa em S é a mesma que sua ordem de aparecimento em Ti.

3. Para duas operações quaisquer em conflito, uma das duas precisa ocorrer antes da outra no schedule.

54

Projeção Confirmada

● É difícil encontrar schedules completos em um sistema de processamento de transação.

● Projeção confirmada C(S) de um schedule S, inclui apenas as operações em S que perten-cem a transações confirmadas.

● Transações Ti cuja operação de confirmação ci está em S.

55

Facilidade de Recuperação

● Schedules recuperáveis:Schedules recuperáveis: quando uma tran-sação T é confirmada, nunca deve ser neces-sário cancelar T (durabilidade).

56

● Um schedule S é recuperável se nenhuma transação T em S for confirmada até que todas as transações T', que tiverem gravado algum item X que T lê, sejam confirmadas.

● Uma transação T lê da transação T' em um schedule S se algum item X for gravado primei-ro por T' e depois lido por T.

● T' não deve ser cancelado antes que T leia o item X, e não deve haver transações que gra-vam X depois que T' o grave e antes que T o leia.

57

Sa': r1(X); r2(X); w1(X); r1(Y); w2(X); c2; w1(Y); c1;Sa': r1(X); r2(X); w1(X); r1(Y); w2(X); c2; w1(Y); c1;

● Sa' é recuperável.● O problema da atualização é tratado pela teo-

ria da serialização.

58

Sc: r1(X); w1(X); r2(X); r1(Y); w2(X); c2; a1;Sc: r1(X); w1(X); r2(X); r1(Y); w2(X); c2; a1;● Não é recuperável porque T2 lê o item X de T1,

mas T2 confirma antes que T1 confirme.● Se T1 abortar depois da operação c2, então o

valor de X que T2 lê não é mais válido e T2 precisa ser abortado depois de ser confirmado.

● Para o schedule ser recuperável, a operação c2 em Sc precisa ser adiada até depois de T1 confirmar.

59

Sd: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); c1; c2;Sd: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); c1; c2;

● Se T1 abortar em vez de confirmar, então T2 também deve abortar, conforme mostrado em Se.

Se: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); a1; a2;Se: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); a1; a2;

● Abortar T2 é aceitável porque ainda não foi confirmado.

60

Rollback em Cascata

● Em um schedule recuperável nenhuma transa-ção confirmada precisa ser cancelada.

● A transação confirmada como durável não é violada.

● Rollback em cascata Rollback em cascata (propagação de cance-lamento): uma transação não confirmada foi cancelada porque leu um item de uma transa-ção que falhou.

61

● Rollback em cascata pode ser muito demora-do.

● É importante caracterizar os schedules nos quais esse fenômeno certamente não ocorrerá.

● Schecule sem cascata:Schecule sem cascata: se cada transação nele ler apenas itens que foram gravados por transações confirmadas.– Todos os itens lidos não serão descartados.

– Nenhum rollback em cascata ocorrerá.

62

● Os schedules Sd e Se precisam ser adiados até depois que T1 tiver sido confirmada (ou cancelada)

● Adia T2, mas garante que não haja rollback em cascata se T1 for cancelada.

63

Schedule Estrito

● As transações não podem ler nem gravar um item X até que a última transação que gravou X tenha sido confirmada (cancelada).

● Simplificam o processo de recuperação.● O processo de desfazer uma operação

write_item(X) de uma transação abortada ser-ve apenas para restaurar a imagem anterior (valor antigo) do item de dados X.

64

Sf: w1(x, 5); w2(x, 8); a1;Sf: w1(x, 5); w2(x, 8); a1;● Suponha x valendo 9 (imagem anterior).● Se T1 for cancelada, o procedimento de recu-

peração que restaura a imagem anterior de uma operação de gravação cancelada restaura-rá o valor de x para 9, embora T2 o tenha alte-rado para 8.

● Sf não é um schedule estrito, pois permite que T2 grave o item X embora a transação T1, que gravou X por último, ainda não tenha sido con-firmada (cancelada)

65

● Schedule estrito é sem cascata.● Qualquer schedule sem cascata também é re-

cuperável.

66

Schedules Serializáveis

São sempre considerados corretos quando tran-sações concorrentes estão sendo executadas.

67

Exemplo:Exemplo: suponha dois agentes de reservas aé-reas que submetem às transações do SGBD T1 e T2 aproximadamente ao mesmo tempo.

68

Se nenhuma intercalação de operações for per-mitida existem apenas dois resultados possíveis:

1. Executar todas as operações da transação T1 seguidas de todas as operações da transação T2.

2. Executar todas as operações da transação T2 seguidas por todas as operações da transação de T1.

69

70

Se a intercalação for permitida haverá muitas or-dens possíveis em que o sistema pode executar as operações individuais das transações.

71

Schedules Seriais

● A e B são seriais porque as operações de cada transação são executadas consecutivamente, sem quaisquer operações intercaladas da ou-tra transação.– Limitam a concorrência

– Desperdiça tempo de processamento da CPU

– São considerados inaceitáveis na prática

72

Schedules Não Serial

● C e D são chamados de não seriais, pois cada sequência intercala operações das duas tran-sações.

73

Testando a Serialização em Conflito

1. Crie um nó Ti no grafo de precedência para cada transa-ção Ti do schedule S.

2. Tj executa uma leitura no item X depois que Ti executar uma escrita no item X.

3. Tj executa uma escrita no item X depois que Ti executar uma leitura no item X.

4. Tj executa uma escrita no item X após Ti executar uma escrita no item X.

5. O schedule é serializável se, e somente se, o grafo de precedência não tiver ciclos.

74

75

● Testando na prática: faça a aplicação do teste de serialização nos schedules A, B, C e D.

● Use os valores de X = 90, Y = 90, N = 3 e M = 2.