Lista de Exercícios 12 Transações

Transcrição

1 UNIVERSIDADE DE SÃO PAULO INSTITUTO DE CIÊNCIAS MATEMÁTICAS E DE COMPUTAÇÃO DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO SCC Bancos de Dados e Suas Aplicações Prof. José Fernando Rodrigues Júnior 2º semestre de 2011 Entrega 21/11/2011. Lista de Exercícios 12 Transações Nomes: Para esta lista use o esquema Futebol (Lista-06-Aula-DDL.txt e Lista-06-Aula-DML.txt). 1. Neste exercício, são necessárias duas conexões do mesmo usuário na base de dados, chamadas aqui de SESSÃO 1 e SESSÃO 2. Execute as instruções de i. a x. uma vez usando isolamento REPEATABLE READ, e outra vez usando isolamento READ COMMITTED. Para cada caso, analise e explique o que acontece em cada caso respondendo às perguntas propostas nos itens vi, viii e x. i. Abra uma conexão para SESSÃO 1 (janela1); ii. Abra outra conexão para SESSÃO 2 (janela2); iii. Na SESSÃO 1, inicie uma transação com um dos níveis de isolamento (OBS: inicie a transação executando o comando START TRANSACTION seguido de um comando SET TRANSACTION LEVEL execute os comandos nesta ordem, do contrário o PostgreSQL irá se comportar de maneira imprevisível); SET TRANSACTION ISOLATION LEVEL READ COMMITTED; iv. Na SESSÃO 1, faça a consulta1 abaixo (em SQL) (OBS: cuidado para não executar novamente o comando SET TRANSACTION execute apenas o comando de consulta); FROM JOGADOR J, EQUIPE E WHERE J.idequipe = e.idequipe; v. Na SESSÃO 2, inicie uma transação com um dos níveis de isolamento e faça o update da equipe de um dos jogadores, alterando assim os dados da resposta da consulta1;

2 UPDATE JOGADOR SET idequipe = 3 WHERE RG = ; SET TRANSACTION ISOLATION LEVEL READ COMMITTED; UPDATE JOGADOR SET idequipe = 1 WHERE RG = ; vi. Repita o passo iv o que aconteceu e por quê? Os dados da sessão 1 não refletem as alterações realizadas na sessão 2. Não houve nenhuma alteração em relação a 1ª consulta. Neste modo de isolamento, no início da transação, um snapshot dos dados do banco é armazenado e será usado como referência até o fim da transação. Os dados da sessão 1 não refletem as alterações realizadas na sessão 2. Não houve nenhuma alteração em relação à 1ª consulta. Isso ocorre porque neste nível de isolamento, apenas os dados das operações commited são lidos. vii. Na SESSÃO 2, execute commit para efetivar a transação; viii. Repita o passo iv o que aconteceu e por quê? Mesmo após o commit na sessão 2, os dados da sessão 1 não refletem o update da sessão 2. Só agora os dados da sessão 1 refletem o update da sessão 2. ix. Na SESSÃO 1, execute commit para efetivar a transação;

3 x. Repita o passo iv o que aconteceu e por quê? Somente agora, os dados da sessão 1 refletem as alterações da sessão 2. Nenhuma alteração. Consulta1: Faça a junção dos dados de Jogador e Equipe para o jogador cujo RG é Para este exercício: a) Usando duas sessões (de maneira semelhante ao exercício 1) e duas transações com nível de isolamento READ COMMITTED, use a tabela Equipe para exemplificar (, e ) a anomalia Phantom Read. Defina um predicado (conjunto de tuplas) para sua consulta na sessão 1; na sessão 2, insira/remova/altere tuplas; na sessão 1, repita a consulta para demonstrar o Phantom Read; WHERE idequipe = 5; WHERE idequipe = 6;

4 A sessão 1, lê dados diferentes do que havia lido anteriormente. b) Refaça o experimento usando o nível de isolamento adequado para que não ocorra a anomalia Phantom Read. WHERE idequipe = 5; WHERE idequipe = 6;

5 A sessão 1, lê os mesmos dados que havia lido anteriormente. 3. Usando duas sessões cada uma com sua transação: a) i. Inicie as duas transações com nível de isolamento READ COMMITTED; SET TRANSACTION ISOLATION LEVEL READ COMMITTED; ii. Defina uma tupla para ser atualizada com o comando UPDATE e execute o comando em ambas as transações; UPDATE EQUIPE SET SALDO_GOLS = 2 WHERE IDEQUIPE = 8; iii. O que acontece na transação 2? Porquê? A transação 2 entrou em espera aguardando o desbloqueio da tupla pela transação 1. iv. Faça commit na transação 1; agora o que aconteceu na transação 2? A transação 2 pode prosseguir. b) Repita o exercício a) usando nível de isolamento SERIALIZABLE. i. Inicie as duas transações com nível de isolamento SERIALIZABLE; ii. Defina uma tupla para ser atualizada com o comando UPDATE e execute o comando em ambas as transações; UPDATE EQUIPE SET SALDO_GOLS = 2 WHERE IDEQUIPE = 8; iii. O que acontece na transação 2? A transação 2 entrou em espera aguardando o desbloqueio da tupla pela transação 1. iv. Faça commit na transação 1; agora o que aconteceu na transação 2? A transação 2 reportou erro. ERRO: não pôde serializar acesso devido a uma atualização concorrente

6 SQL state: c) Repita o exercício b) usando nível de isolamento SERIALIZABLE, mas executando rollback no passo v. i. Inicie as duas transações com nível de isolamento SERIALIZABLE; ii. Defina uma tupla para ser atualizada com o comando UPDATE e execute o comando em ambas as transações; UPDATE EQUIPE SET SALDO_GOLS = 2 WHERE IDEQUIPE = 8; iii. O que acontece na transação 2? A transação 2 entrou em espera aguardando o desbloqueio da tupla pela transação 1. iv. Faça rollback na transação 1; agora o que aconteceu na transação 2? A transação 2 pode prosseguir. d) Considerando a teoria de serialização de transações (slide 13, aula 21), explique porque o erro é reportado no item iv do exercício b). Como as duas transações concorrem pela atualização do mesmo dado, não existe execução intercalada das duas transações capaz de produzir um resultado condizente com o caso em que elas fossem executadas em sequência. Isto, pois cada um das transações tenta atualizar o mesmo dado, assim, ao final da execução em sequência, uma delas não terá sua atualização efetivada, pois foi sobrescrita pela outra. A execução em paralelo supõe que ambas as transações sejam respeitadas. No caso de uma delas fazer rollback, então entende-se que aquela transação desistiu da atualização do dado.