PROCESSAMENTO DE TRANSAÇÕES

Transcrição

1 UNINGÁ UNIDADE DE ENSINO SUPERIOR INGÁ FACULDADE INGÁ CIÊNCIA DA COMPUTAÇÃO PROCESSAMENTO DE TRANSAÇÕES Profº Erinaldo Sanches Nascimento

2 Objetivos Discutir a necessidade de controle de concorrência e recuperaçã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. 2

3 Introdução Discutir os conceitos de execução concorrente de transações e recuperação de transações com falhas. 3

4 Classificação de um SGBD De acordo com o número de usuários que podem usar o sistema simultaneamente. Monousuário: no máximo um usuário de cada vez. Multiusuário: muito usuários podem acessá-lo simultaneamente. 4

5 SGBDs Monousuário Restrito a sistemas de computador pessoal. 5

6 SGBDs Multiusuário Sistema de reservas aéreas. Sistemas usados em bancos, agências de seguros, mercado de ações, supermercados. Centenas ou milhares de usuários normalmente estão operando no banco de dados ao submeter transações ao sistema ao mesmo tempo. 6

7 Multiprogramação: Multiprogramação permite que o sistema operacional do computador execute vários programas (processos) ao mesmo tempo. Intercalada Processamento paralelo 7

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. 8

9 Tipos de Transações Somente leitura: leitura não atualizam o banco de dados, apenas recuperam dados Leitura-gravação: Leitura-gravação faz o contrário. 9

10 Itens de Banco de Dados Um banco de dados é basicamente representado como uma coleção de itens de dados nomeados. Granularidade: Granularidade tamanho de um item de dados. Item de dados: dados um registro de banco de dados, um bloco de disco inteiro, um valor de campo. 10

11 O processamento de transação é independente 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. 11

12 Operações Básicas Leitura (read): read_item(x). Gravação (write): write_item(x). 12

13 Comando de Leitura 1. Ache o endereço do bloco de disco que conté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. 13

14 Comando de Gravação 1. Ache o endereço do bloco de disco que conté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 chamada X para o local correto no buffer. 4. Armazene o bloco atualizado do buffer de volta no disco. 14

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. 15

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. 16

17 Controle de Concorrência As transações podem ser executadas simultaneamente, 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 17

18 Tipos de Problemas Atualização perdida Atualização temporária (leitura suja) Resumo incorreto Leitura não repetitiva 18

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. 19

20 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 é acessado (lido) por outra transação, antes de ser alterado de volta para seu valor original. 21

22 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 outros, depois que foram atualizados. 23

24 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 leituras do mesmo item. 25

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 confirmada (committed), Ou que a transação não tenha qualquer efeito no banco de dados ou quaisquer outras transações abortada. abortada 26

27 A transação inteira é uma unidade lógica de processamento de banco de dados. Se a transação falhar depois de executar algumas de suas operações, as operações já executadas precisam ser desfeitas. 27

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 detectadas pela transação. 4. Imposição de controle de concorrência. 5. Falha de disco. 6. Problemas físicos e catástrofes 28

29 Falha do Computador Erro de hardware, software ou rede. Falhas de mídia memória principal. 29

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. 30

31 Erros Locais Dados da transação não podem ser encontrados. Saldo de conta insuficiente para um saque bancário. Execução que é programada na própria transação não é uma falha da transação. 31

32 Controle de Concorrência Aborta uma transação porque ela viola a serialização. Abortar uma ou mais transações para resolver um estado de deadlock entre várias transações. Essas transações são reiniciadas automaticamente em outro momento. 32

33 Falha de Disco Perda de dados devido a um defeito de leitura/gravação. Falha da cabeça de leitura/gravação. 33

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. 34

35 Estados de Transação Begin_transaction Read ou Write End_transaction Commit_transaction Rollback (ou Abort) 35

36 36

37 Log do Sistema Registra todas as operações de transação que afetam os valores dos itens de banco de dados. 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 contra falhas catastróficas. 37

38 Registro de log: log tipos de entradas que são gravadas para o arquivo de log e a ação correspondente para cada registro de log. 38

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] 39

40 Propriedades ACID Atomicidade Preservação da consistência Isolamento Durabilidade ou permanência 40

41 Atomicidade Uma transação é uma unidade de processamento atômica. É realizada na sua totalidade ou não é realizada de forma alguma. O SGBD deve garantir. 41

42 Consistência Se uma transação for completamente executada 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. 42

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 interferida por quaisquer outras transações que acontecem simultaneamente. Imposta pelo subsistema de controle de concorrência do SGBD. 43

44 Durabilidade As mudanças aplicadas ao banco de dados pela transação confirmada precisam persistir no banco de dados. É responsabilidade do subsistema de recuperação do SGBD. 44

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 operações de Ti em S precisam aparecer na mesma ordem de Ti. 45

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 gravado segue as operações r e w entre parênteses. 46

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

48 Sb: r1(x); w1(x); r2(x); c2; a1; 48

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 write_item(x). uma das operações é um 49

50 Operações de leitura não estão em conflito. Operações que operam em itens de dados distintos não estão em conflito. Operações de leitura e escrita sobre o mesmo item de dados que pertencem à mesma transação não estão em conflito. Duas operações estão em conflito se a mudança de sua ordem puder resultar em algo diferente. 50

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 alterado. 51

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 52

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 cancelamento 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. 53

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 pertencem a transações confirmadas. Transações Ti cuja operação de confirmação ci está em S. 54

55 Facilidade de Recuperação Schedules recuperáveis: quando uma transação T é confirmada, nunca deve ser necessário cancelar T (durabilidade). 55

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 primeiro 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 gravam X depois que T' o grave e antes que T o leia. 56

57 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 teoria da serialização. 57

58 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. 58

59 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; Abortar T2 é aceitável porque ainda não foi confirmado. 59

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 (propagação de cancelamento): uma transação não confirmada foi cancelada porque leu um item de uma transação que falhou. 60

61 Rollback em cascata pode ser muito demorado. É importante caracterizar os schedules nos quais esse fenômeno certamente não ocorrerá. 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á. 61

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. 62

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 serve apenas para restaurar a imagem anterior (valor antigo) do item de dados X. 63

64 Sf: w1(x, 5); w2(x, 8); a1; Suponha x valendo 9 (imagem anterior). Se T1 for cancelada, o procedimento de recuperação que restaura a imagem anterior de uma operação de gravação cancelada restaurará o valor de x para 9, embora T2 o tenha alterado 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 confirmada (cancelada) 64

65 Schedule estrito é sem cascata. Qualquer schedule sem cascata também é recuperável. 65

66 Schedules Serializáveis São sempre considerados corretos quando transações concorrentes estão sendo executadas. 66

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

68 Se nenhuma intercalação de operações for permitida 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. 68

69 69

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

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 outra transação. Limitam a concorrência Desperdiça tempo de processamento da CPU São considerados inaceitáveis na prática 71

72 Schedules Não Serial C e D são chamados de não seriais, pois cada sequência intercala operações das duas transações. 72

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. 73

74 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. 75