BDII SQL TRANSAÇÃO Revisão 2

Transcrição

1 exatasfepi.com.br BDII SQL TRANSAÇÃO Revisão 2 André Luís Duarte Honra a teu pai e a tua mãe (que é o primeiro mandamento com promessa), para que te vá bem, e sejas de longa vida sobre a terra.(ef 6:2,3)

2 SQL Transações Introdução ACID Deadlocks 2

3 Transações Conjunto sequencial de instruções SQL projetado em uma única unidade de trabalho que A partir de um estado inicial, Age na transformação os dados Gerando um resultado Que pode alterar ou não o estado atual do banco 3

4 Transações Diagrama de estado durante uma transação Fonte: 4

5 Transações São a base para a criação de banco de dados transacionais Além das propriedades ACID, podemos usar bloqueio de tabelas e linhas (LOCK) Devemos tomar cuidado com DEADLOCKS, que é um problema comum em banco de dados transacionais 5

6 Transações Implícita Todo comando DML ou DDL é considerado uma transação implícita Logo depois de cada comando executado no SGBD, esse se encarrega de enviar um COMMIT Explicita Deve ser explicitada através do comando START TRANSACTION 6

7 Exemplo Suponha que desejamos transferir R$ 1000,00 da conta número 1 para a conta número 2 Ações: 1. Gerar uma transação de débito (subtrair R$ 1000,00) para a conta nº 1 2. Gerar uma transação de crédito (adicionar R$ 1000,00) para a conta nº 2 Quais os problemas que podemos encontrar? 7

8 Exemplo Para simplificar o exemplo vamos considerar as seguintes ações: Ações: 1. Subtrair R$ 1000,00 da transação nº 1 2. Adicionar R$ 1000,00 na transação nº 2 Quais os problemas que podemos encontrar? 8

9 Problemas Quais os problemas podemos identificar? A transação nº 1 não ter a possibilidade de subtrair R$ 1000,00 À transação nº 2 não poder ser adicionado R$ 1000,00 Após a ação 1, ocorrer algum problema físico ou lógico no sistema Após a ação 2, ocorrer algum problema físico ou lógico no sistema 9

10 Exemplo DELIMITER // DROP PROCEDURE IF EXISTS sp_atualizacao; CREATE PROCEDURE sp_atualizacao() BEGIN DECLARE vt DECIMAL; SET vt = 1000; UPDATE transacao SET valor = valor - vt WHERE numero = 1; UPDATE transacao SET valor = valor + vt WHERE numero = 2; END // DELIMITER ; 10

11 Problema DELIMITER // DROP PROCEDURE IF EXISTS sp_atualizacao_fail; CREATE PROCEDURE sp_atualizacao_fail() BEGIN DECLARE vt DECIMAL; SET vt = 1000; UPDATE transacao SET valor = valor - vt WHERE numero = 1; UPDATE transacao SET valor = valor + vt WHERE numero = 0; END // DELIMITER ; 11

12 Retornando os valores UPDATE transacao SET valor = 1500 WHERE numero = 1; UPDATE transacao SET valor = 200 WHERE numero = 2; 12

13 Exemplo DELIMITER // DROP PROCEDURE IF EXISTS sp_atualizacao_trans_param; CREATE PROCEDURE sp_atualizacao_trans_param(in conta1 INT, IN conta2 INT) BEGIN DECLARE vt DECIMAL; DECLARE cnt1 INT; DECLARE cnt2 INT; SET vt = 1000; END // DELIMITER ; START TRANSACTION; UPDATE transacao SET valor = valor - vt WHERE numero = conta1; SET cnt1 = ROW_COUNT(); UPDATE transacao SET valor = valor + vt WHERE numero = conta2; SET cnt2 = ROW_COUNT(); IF (cnt1 = 0 OR cnt2 = 0) THEN ROLLBACK; ELSE COMMIT; END IF; 13

14 ACID Modelo de transação que deve prover as características: Atomicidade Consistência Isolamento Durabilidade 14

15 Atomicidade Requer que a transação seja tudo ou nada Todos os comandos funcionam de forma atômica, indivisível Previne que atualizações parciais no banco de dados seja executadas 15

16 Consistência Deve garantir que a partir de um estado válido, após uma transação, o banco estará em um estado válido também Erros de construção não podem violar a integridade do banco Integridade de chave Integridade referencial Regras de negócio Etc 16

17 Isolamento Permite que a execução de transações concorrentes levem o banco à um estado que seria obtido se fossem executadas transações seriais Previne que uma leitura em um campo de uma tabela só possa ser realizado se nenhuma atualização não confirmada (commited) esteja em execução 17

18 Isolamento Possui níveis: Read uncommited Read commited Repeatable read Serializable Podem ocorrer fenômenos indesejados Dirt read 18

19 Fenômenos indesejados Dirty read (leitura suja) Transação lê dados escritos por uma transação simultânea não efetivada (uncommited) A T1 grava B A B T2 Lê B A B Banco Inicial T1 faz rollback A 19

20 Fenômenos indesejados Nonrepeatable read (leitura que não pode ser repetida) Também conhecida como snapshot ocorre quando um select repetido não consegue obter o mesmo resultado da execução anterior A B T2 Lê B A B T1 apaga B A B Banco Inicial T1 faz commit A 20

21 Fenômenos indesejados Phantom read (leitura fantasma) O resultado do fenômeno Nonrepeatable read que faz com que uma transação esteja com dados que podem ter sido alterados por outra transação A B T2 Lê B A B T1 apaga B A B Banco Inicial T1 faz commit A 21

22 Isolamento Read uncommited Nível de isolamento menos proibitivo, não possui lock nenhum Nele podem ocorrer todos os fenômenos indesejados (leitura suja, leitura que não pode ser repetida e leitura fantasma) em uma transação 22

23 Isolamento Read commited Este nível é o usado por padrão no Oracle e no SQL Server Neste nível são usados locks partilhado que asseguram que nenhuma informação que ainda não tenha sido confirmada seja lida Leitura suja não ocorre, mas pode ocorrer leituras que não podem ser repetidas 23

24 Isolamento Repeatable read Neste nível são adquiridos locks de leitura, prevenindo a ocorrência de leitura suja e leituras que não podem ser repetidas Permite a ocorrência de leituras fantasmas 24

25 Isolamento Serializable Nesse nível todas as transações ocorrem num meio fechado Todas são executadas de modo sequencial Transações concorrentemente podem ser executadas apenas se a ilusão de serialização for mantida, ou seja, se uma transação partilha dados com a outra Não ocorrem fenômenos indesejados 25

26 Isolamento Nível de isolamento / Fenômeno indesejado Dirty Read Nonrepeatable Read Phantom Read Read uncommitted Possível Possível Possível Read committed Impossível Possível Possível Repeatable read Impossível Impossível Possível Serializable Impossível Impossível Impossível 26

27 Durabilidade A propriedade garante que uma transação enviada, deve ser mantida em memória não volátil Previne que uma transação enviada para o banco de dados fique armazenada, por exemplo, em um buffer de disco e em caso de queda de energia ela seja perdida Obs.: Perceba que no sistema, o usuário já recebeu uma mensagem de transação realizada com sucesso 27

28 Deadlocks Geralmente não são perigosos desde que não impossibilitem a execução de uma transação Transações devem estar preparadas para serem reexecutadas caso ocorra um ROLLBACK por causa de um DEADLOCK Geralmente os SGBD modernos conseguem detectar DEADLOCKS 28

29 Deadlocks Exemplo de DEADLOCKS Transação T1 Aguarda pelo recurso R1 Para gerar o recurso R2 Transação T2 Aguarda pelo recurso R2 Para gerar o recurso R1 29

30 Exercício Crie uma uma transferência entre contas de forma correta, ou seja, criando transações de débito e crédito para as contas envolvidas Deve possui três parâmetros: Número da conta debitada Numero da conta creditada Valor transferido Restrição: a conta não pode ficar negativa na transferência 30