CONCORRÊNCIA. 1. Introdução. Recursos exclusivos. Não necessita controle. Abundância de recursos compartilhados. Controle necessário mas mínimo

Transcrição

1 CONCORRÊNCIA 1. Introdução Recursos exclusivos Não necessita controle Abundância de recursos compartilhados Controle necessário mas mínimo Harmonia, provavelmente não haverá conflito Recursos disputados e escassos Espera Controle seria necessário Provável conflito

2 2. Concorrência em BD A concorrência (por dados) existe quando temos: Múltiplos Usuários Múltiplas Operações Operações que buscam os mesmos recursos (dados) Operações Simultâneas O termo concorrência refere-se ao fato de que os SGBDs em geral permitem que muitos usuários/muitas transações tenham acesso ao mesmo banco de dados (mesmo dado) ao mesmo tempo. Em um sistema desse tipo, é necessário algum tipo de mecanismo de controle (bloqueio) para assegurar que transações concorrentes não interfiram umas nas outras ou não causem inconsistência. Em uma situação ideal, cada um destes usuários deveria executar os seus comandos como se ele fosse o único. Este seria o maior nível de isolamento. Entretanto, é muito baixo o nível de concorrência correspondente a tal nível de isolamento e usuários poderão ficar aguardando por informações durante tempos relativamente longos, à espera do término de outras transações. Buscando aumentar os níveis de concorrência redução da espera em detrimento do isolamento total, a SQL definiu alguns níveis de isolamento. SGBD BD/Dado (recurso) Transação T1 concorre com T2 pelo recurso (principalmente dado), (pode haver interferência em T2). Transação T2 concorre com T1 pelo recurso (principalmente dado), (pode haver interferência em T1).

3 3. Transações x Concorrência (Efeitos da Concorrência) Em um ambiente onde não existe isolamento total entre as transações, a intercalação entre os comandos das transações pode produzir os efeitos (problemas) que serão apresentados a seguir. Efeitos que podem ser produzidos pela concorrência: Leitura Suja (ou Dependência sem commit) 1. Transações T1 e T2 são iniciadas. 2. A transação T1 modifica a linha L1. 3. A transação T2 lê a linha L1 antes que T1 termine. 4. T1 termina com fracasso e suas operações são desfeitas. Assim: T2 terá lido uma informação que nunca foi confirmada. Viu algo que não existe. Problema comum na maioria dos SGBD s. Leitura Não Repetida (ou Análise inconsistente) 1. Transações T1 e T2 são iniciadas. 2. A transação T1 lê a linha L1. 3. A transação T2 modifica a linha L1, atualizando seus dados ou apagando a linha. 4. A transação T2 é concluída com sucesso e as suas operações são confirmadas. 5. A transação T1 lê (ou tenta ler) a linha L1. Assim: T1 nunca modificou os dados da linha L1, mas não obteve a mesma leitura dentro da mesma transação. Pense, por exemplo, em T1 fazendo duas operações de soma (totalização de uma determinada coluna). Este efeito fará com que o valor na coluna que está sendo totalizada seja alterado em uma das linhas antes da segunda totalização, produzindo uma soma (sum) diferente da primeira.

4 Leitura Fantasma (ou Leitura dupla) 1. Transações T1 e T2 são iniciadas. 2. A transação T1 lê um conjunto de linhas que atendem a uma condição C1; 3. A transação T2 executa uma operação de atualização que cria uma ou mais linhas que atendem à condição C1; 4. A transação T1 lê, novamente, um conjunto de linhas que atendem a uma condição C1. Assim: Embora T1 não tenha criado linhas que atendem à condição C1, novas linhas participarão do resultado da mesma consulta na transação. Pense no exemplo apresentado no item anterior. A diferença é que, na leitura fantasma, aparece um novo registro e na Leitura Não Repetida houve uma alteração em um registro já lido. Perda de Atualização 1. Transações T1 e T2 são iniciadas. 2. A transação T1 lê o dado D1 e armazena seu valor na variável X. 3. A transação T2 lê o dado D1 e armazena seu valor na variável Y. 4. A transação T1 atualiza D1 com o valor A transação T2 atualiza D1 com o valor A transação T1 termina com sucesso. 7. A transação T2 termina com sucesso. Assim: Para a transação T1 o valor de D1 deveria ser 10, mas efetivamente, o valor é 11 (último valor gravado no BD).

5 4. Níveis de Isolamento Em razão da influência existente entre as transações, o padrão SQL criou vários Níveis de Isolamento, eles definem a relação adotada pela transação com os efeitos da concorrência (problemas) listados no item 3. Os níveis de isolamento definem: Quando eu ler vou bloquear? O bloqueio será durante toda a transação ou durante minha leitura? As leituras devem ler a última versão comitada? As leituras podem ler dados não comitados (leitura suja)? Níveis de isolamento definidos no padrão SQL: Serializable Read Uncommitted Read Committed Repeatable Read O nível de isolamento a ser utilizado pode ser definido: - Através do comando de início de uma transação: Padrão SQL: START TRANSACTION [nível-de-isolamento] SQL Server: BEGIN TRANSACTION [nível-de-isolamento] - Pelo comando de alteração das propriedades da transação: SET TRANSACTION ISOLATION LEVEL [nível-de-isolamento] Níveis de Isolamento x Concorrência CONCORRÊNCIA CONSISTÊNCIA Read Committed Read Uncommitted Serializable MÍN ISOLAMENTO MÁX (pode resultados errados) (sem interferência, com espera)

6 Detalhamento dos Níveis de Isolamento Para cada nível de isolamento, demonstraremos, através de exemplos práticos, alguns dos efeitos da concorrência que se aplicam a ele. Assim, será necessário criar o BD do modelo apresentado abaixo (Sistema de Leilão). Faça-o agora, utilizando os scripts que serão fornecidos. Obs.: para simplificar os exemplos este modelo não segue regras rígidas de normalização. Read Uncommitted - Permite a leitura de dados não comitados. Ao não impor bloqueio de leitura (lê como está), se o dado estiver sendo atualizado, é possível que se leia algo que não vai ser confirmado posteriormente. - Grande nível de concorrência mas sujeito a todos os problemas de concorrência vistos no item 3 (leitura suja, leitura não repetida, leitura fantasma, perda de atualização). Exemplo prático (LEITURA SUJA): Situação do Produto cujo IdProduto é 10: IdProduto NomeProduto PrecoInicial MelhorOferta 10 Adaptador PCI Express Wireless 150Mbps 42,00 NULL Atenção: para fazer a simulação da LEITURA SUJA, copie todo o código do usuário 1 e cole em uma nova sessão (janela de query). Faça o mesmo com o código do usuário 2. No SQL SERVER, selecione todo o código do usuário 1 menos as linhas do ROLLBACK (inclusive) em diante. Clique no botão EXECUTAR.

7 A seguir, execute todo o código do usuário 2 e observe o resultado do select deste usuário. Qual o valor da MELHOR OFERTA para o usuário 2? Retorne para o código do usuário 1 e execute as linhas do ROLLBACK em diante que estavam pendentes. Qual o valor da MELHOR OFERTA? Qual o problema gerado para o usuário 2 considerando que a transação dele já terminou ou mesmo que houvesse outros comandos nela? USUÁRIO 1\SESSÃO 1 -- Mudar o contexto de banco de dados -- Recupera os dados do produto 10 SELECT IdProduto, NomeProduto, PrecoInicial, MelhorOferta FROM Produtos WHERE IdProduto = Abre uma transação BEGIN TRAN -- Cria e grava dados em variáveis dentro da transação SMALLMONEY = = ' ' = André = Adaptador PCI Express Wireless 150Mbps = = NEWID() -- Insere uma nova oferta para o produto 10 INSERT INTO Ofertas ( IdOferta, DataOferta, IdUsuario, IdProduto, ValorOferta, HashOferta) -- Recupera a melhor oferta para o produto 10 = (SELECT MelhorOferta FROM Produtos WHERE IdProduto = 10) -- Verifica se o valor da oferta é a melhor oferta para esse produto IS NULL

8 -- Atualiza o produto 10 se for a melhor oferta UPDATE Produtos SET MelhorOferta WHERE IdProduto = Recupera os dados do produto 10 SELECT IdProduto, NomeProduto, PrecoInicial, MelhorOferta FROM Produtos WHERE IdProduto = 10 ROLLBACK -- Recupera os dados do produto 10 SELECT IdProduto, NomeProduto, PrecoInicial, MelhorOferta FROM Produtos WHERE IdProduto = 10 USUÁRIO 2\SESSÃO 2 -- Mudar o contexto de banco de dados ATENÇÃO! -- Muda o nível de isolamento SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED -- Recupera os dados do produto 10 SELECT IdProduto, NomeProduto, PrecoInicial, MelhorOferta FROM Produtos WHERE IdProduto = 10

9 Read Committed - O padrão para o ANSI. - Só é possível ler dados comitados (não permite leitura suja). - Diminui um pouco o nível de concorrência em relação ao read uncommitted. - Sujeito aos outros problemas de concorrência (leitura não repetida, leitura fantasma, perda de atualização). Exemplo prático (ATUALIZAÇÃO PERDIDA): Situação do Produto cujo IdProduto é 10: IdProduto NomeProduto PrecoInicial MelhorOferta 10 Adaptador PCI Express Wireless 150Mbps 42,00 NULL Atenção: para fazer a simulação da ATUALIZAÇÃO PERDIDA, copie todo o código do usuário 1 e cole em uma nova sessão (janela de query). Faça o mesmo com o código do usuário 2. A seguir, execute a transação (completa) do usuário 1 e em seguida a transação (completa) do usuário 2. USUÁRIO 1\SESSÃO 1 (pretende fazer uma oferta de 50,40): -- Mudar o contexto de banco de dados -- Recupera os dados do produto 10 SELECT IdProduto, NomeProduto, PrecoInicial, MelhorOferta FROM Produtos WHERE IdProduto = Abre uma transação BEGIN TRAN -- Cria e grava dados em variáveis dentro da transação SMALLMONEY = = ' ' = André = Adaptador PCI Express Wireless 150Mbps = = NEWID()

10 -- Insere uma nova oferta para o produto 10 INSERT INTO Ofertas ( IdOferta, DataOferta, IdUsuario, IdProduto, ValorOferta, HashOferta) -- Recupera a melhor oferta para o produto 10 = (SELECT MelhorOferta FROM Produtos WHERE IdProduto = 10) -- Espera 15 segundos propositalmente WAITFOR DELAY '00:00:15' Retornou null -- Verifica se o valor da oferta é a melhor oferta para esse produto IS NULL -- Atualiza o produto 10 UPDATE Produtos SET MelhorOferta WHERE IdProduto = 10 COMMIT -- Recupera os dados do produto 10 SELECT IdProduto, NomeProduto, PrecoInicial, MelhorOferta FROM Produtos WHERE IdProduto = 10 Resultado esperado da transação do usuário 1: como a melhor oferta estava NULL, ela será substituída por 50,40 (oferta do usuário 1). Mas atenção, a linha WAITFOR DELAY '00:00:15' fará a transação parar neste ponto por 15 segundos antes de atualizar o valor da melhor oferta para 50,40 (o comando update está em uma linha posterior à linha do delay). Enquanto os 15 segundos correm, o usuário 2 inicia a sua transação. USUÁRIO 2\SESSÃO 2 (pretende fazer uma oferta de 49,20): -- Mudar o contexto de banco de dados -- Recupera os dados do produto 10 SELECT IdProduto, NomeProduto, PrecoInicial, MelhorOferta FROM Produtos WHERE IdProduto = Abre uma transação BEGIN TRAN

11 -- Cria e grava dados em variáveis dentro da transação SMALLMONEY = = ' ' = Davi = Adaptador PCI Express Wireless 150Mbps = = NEWID() -- Insere uma nova oferta para o produto 10 INSERT INTO Ofertas ( IdOferta, DataOferta, IdUsuario, IdProduto, ValorOferta, HashOferta) Retornou null -- Recupera a melhor oferta para o produto 10 = (SELECT MelhorOferta FROM Produtos WHERE IdProduto = 10) -- Espera 15 segundos propositalmente WAITFOR DELAY '00:00:15' -- Verifica se o valor da oferta é a melhor oferta para esse produto IS NULL -- Atualiza o produto 10 UPDATE Produtos SET MelhorOferta WHERE IdProduto = 10 COMMIT -- Recupera os dados do produto 10 SELECT IdProduto, NomeProduto, PrecoInicial, MelhorOferta FROM Produtos WHERE IdProduto = 10 Resultado esperado da transação do usuário 2: como o usuário 1 fez uma oferta maior, a oferta de 49,20 do usuário 2, não será gravada como a melhor oferta (que deve ficar com o usuário 1, cuja oferta é de 50,40). Mas atenção, a linha WAITFOR DELAY '00:00:15', existente nas duas transações, fará com que a transação do usuário 1 termine (commit) ANTES da transação do usuário 2 (pois a transação do usuário 2 iniciou o processamento depois da transação do usuário 1). Responda: Qual o valor gravado na coluna MelhorOferta quando as duas transações encerrarem?

12 Atenção: execute os comandos abaixo para que os dados do produto 10 retornem ao estado anterior -- Mudar o contexto de banco de dados -- Volta a situação do produto UPDATE Produtos SET MelhorOferta = NULL WHERE IdProduto = Elimina as duas ofertas DELETE FROM Ofertas WHERE IdOferta >= Complete a frase: O exemplo acima mostra que o nível de isolamento READ COMMITED permite o efeito/problema de concorrência (entre outros), embora proteja a transação quanto ao problema.

13 Repeatable Read - Os bloqueios de leitura duram até o fim da transação (quando uma transação faz uma leitura, os registros lidos ficam bloqueados até que tal transação finalize, mesmo que a leitura já tenha terminado). - Leituras sempre consistentes. - Há redução da concorrência em razão da duração dos bloqueios (se alguém quiser atualizar vai ter que esperar). - Apenas um problema de concorrência pode ocorrer: Registros Fantasmas. Exemplo prático 1: funcionamento do Repeatable Read: Atualmente, as 10 melhores ofertas são: IdOferta DataOferta IdUsuário IdProduto ValorOferta :00: , :00: , :00: , :00: , :00: , :00: , :00: , :00: , :00: , :00: ,02 Atenção: para fazer a simulação do funcionamento do nível Repeatable Read, copie todo o código do usuário 1 e cole em uma nova sessão (janela de query). Faça o mesmo com o código do usuário 2. Não os execute ainda. USUÁRIO 1\SESSÃO 1 (seleciona as 10 melhores ofertas): -- Mudar o contexto de banco de dados -- Muda o nível de isolamento SET TRANSACTION ISOLATION LEVEL REPEATABLE READ -- Abre uma transação BEGIN TRAN -- Mostra as dez melhores ofertas SELECT TOP(10) * FROM Ofertas ORDER BY ValorOferta DESC COMPUTE SUM(ValorOferta), MAX(ValorOferta)

14 COMMIT -- Mostra as dez melhores ofertas novamente SELECT TOP(10) * FROM Ofertas ORDER BY ValorOferta DESC COMPUTE SUM(ValorOferta), MAX(ValorOferta) USUÁRIO 2\SESSÃO 2 (altera o valor da oferta ): -- Atualiza a melhor oferta UPDATE Ofertas SET ValorOferta = WHERE IdOferta = Instruções: No SQL SERVER, selecione todo o código do usuário 1 menos a linha do COMMIT. Clique no botão EXECUTAR. Note que os resultados dos dois comandos select são os mesmos (como esperado), sendo também iguais ao apresentado no início deste exemplo prático (note o valor da oferta : 2.808,02). Obs.: a transação não foi completada (sem commit). A seguir, execute todo o código do usuário 2 e observe na parte inferior da janela que o comando update está aguardando (mensagem Executing query... não termina) a liberação dos registros lidos pelo usuário 1 (especificamente a oferta cujo valor se deseja alterar para ,00). Retorne para a sessão do usuário 1, selecione e execute apenas o comando select acima do commit. O valor da oferta foi alterado? Justifique. Selecione e execute apenas o commit que estava pendente. Retorne para a sessão do usuário 2. Observe que o comando update foi completado ( 1 row(s) affected ). Retorne para a sessão do usuário 1, selecione e execute apenas o comando select acima do commit. O valor da oferta foi alterado? Justifique. Qual a outra mudança que podemos notar em relação ao registro da oferta ? Justique.

15 Atenção: agora copie e execute os comandos abaixo para que os dados retornem ao estado anterior. -- Mudar o contexto de banco de dados -- Desfaz o UPDATE UPDATE Ofertas SET ValorOferta = WHERE IdOferta = Exemplo prático 2 (REGISTROS FANTASMAS (ANSI / SQL SERVER) ou LEITURA NÃO REPETIDA (DB2)): No momento, as 10 melhores ofertas permanecem as mesmas: IdOferta DataOferta IdUsuário IdProduto ValorOferta :00: , :00: , :00: , :00: , :00: , :00: , :00: , :00: , :00: , :00: ,02 Atenção: para fazer a simulação do problema Registros Fantasmas no nível de isolamento Repeatable Read, copie todo o código do usuário 1 e cole em uma nova sessão (janela de query). Faça o mesmo com o código do usuário 2. Não os execute ainda. USUÁRIO 1\SESSÃO 1 (seleciona as 10 melhores ofertas): -- Mudar o contexto de banco de dados -- Muda o nível de isolamento SET TRANSACTION ISOLATION LEVEL REPEATABLE READ -- Abre uma transação BEGIN TRAN -- Mostra as dez melhores ofertas SELECT TOP(10) * FROM Ofertas ORDER BY ValorOferta DESC COMPUTE SUM(ValorOferta), MAX(ValorOferta)

16 -- Mostra as dez melhores ofertas SELECT TOP(10) * FROM Ofertas ORDER BY ValorOferta DESC COMPUTE SUM(ValorOferta), MAX(ValorOferta) COMMIT USUÁRIO 2\SESSÃO 2 (insere uma nova oferta (valor de 4.000,00) para o produto 333): -- Mudar o contexto de banco de dados -- Nova oferta (valor 4.000) para o produto 333 INSERT INTO Ofertas ( IdOferta, DataOferta, IdUsuario, IdProduto, ValorOferta, HashOferta) VALUES (424075, ' ', 300, 333, 4000, NEWID()) O INSERT desta transação será executado ou ficará aguardando o encerramento da transação do usuário 1 (como o update do exemplo anterior)? Instruções e observações: No SQL SERVER, selecione todo o código do usuário 1 menos a linha do COMMIT. Clique no botão EXECUTAR. Note que os resultados dos dois comandos select são os mesmos (como esperado), sendo também iguais ao apresentado no início deste exemplo prático. Obs.: a transação não foi completada (sem commit). A seguir, execute todo o código do usuário 2. Note que o comando INSERT foi executado ( 1 row(s) affected ). Não houve espera. Por quê? Retorne para a sessão do usuário 1, selecione e execute o comando select acima do commit. Note a alteração no resultado desta execução do select em comparação à anterior. A justificativa é a presença de uma nova linha na tabela (gerada pelo insert do usuário 2, uma oferta de 4.000,00) que atende aos requisitos do select (está entre as 10 maiores ofertas, substituindo a oferta de 2.808,02 que era a menor entre as 10 maiores). Selecione e execute apenas o commit que estava pendente. Selecione e execute novamente o comando select acima do commit. Note que a leitura é a mesma (a nova oferta aparece).

17 Conclusão: A oferta número no valor de 4.000,00 apareceu para a transação do usuário 1 como um registro fantasma (apareceu no meio da transação 1 sem que esta tenha feito algo para isso). Este é o padrão ANSI. Alguns SGBD consideram que a leitura não foi exatamente a mesma (base alterada pelo insert), estes consideram como uma leitura não repetida. Atenção: agora copie e execute os comandos abaixo para que os dados retornem ao estado anterior. -- Exclui o registro DELETE FROM Ofertas WHERE IdOferta = Exercício: a) Execute a transação do usuário 1 menos o commit. b) Execute a transação do usuário 2. c) Execute o select do usuário 1. d) Execute o delete acima (DELETE FROM Ofertas WHERE IdOferta = ) O que aconteceu? O que fazer para completar o exercício?

18 Serializable - Isolamento puro (nível mais alto). Efeitos de uma transação não influenciam em outra transação. - Redução muito grande da concorrência. - Impede todos os problemas gerados pelos acessos concorrentes. - Bloqueia os dados acessados até o final da transação (como faz o nível Repeatable Read ) e impede a inserção de novas linhas (tuplas) nas tabelas em uso. Elimina Registros Fantasmas também. Obs.: Bloqueia inclusive insert s que mudem o resultado de um select (visualização). Exemplo prático 1 (FUNCIONAMENTO DO NÍVEL SERIALIZABLE): No momento, as 10 melhores ofertas permanecem as mesmas: IdOferta DataOferta IdUsuário IdProduto ValorOferta :00: , :00: , :00: , :00: , :00: , :00: , :00: , :00: , :00: , :00: ,02 Atenção: para fazer a simulação, copie todo o código do usuário 1 e cole em uma nova sessão (janela de query). Faça o mesmo com o código do usuário 2. Não os execute ainda. USUÁRIO 1\SESSÃO 1 (seleciona as 10 melhores ofertas): -- Mudar o contexto de banco de dados -- Muda o nível de isolamento SET TRANSACTION ISOLATION LEVEL SERIALIZABLE -- Abre uma transação BEGIN TRAN -- Mostra as dez melhores ofertas SELECT TOP(10) * FROM Ofertas ORDER BY ValorOferta DESC COMPUTE SUM(ValorOferta), MAX(ValorOferta) COMMIT

19 USUÁRIO 2\SESSÃO 2 (insere uma nova oferta (valor de 4.000,00) para o produto 333): -- Mudar o contexto de banco de dados -- Inclui uma oferta alta INSERT INTO Ofertas ( IdOferta, DataOferta, IdUsuario, IdProduto, ValorOferta, HashOferta) VALUES (424075, ' ', 300, 333, 4000, NEWID()) -- Inclui uma oferta baixa INSERT INTO Ofertas ( IdOferta, DataOferta, IdUsuario, IdProduto, ValorOferta, HashOferta) VALUES (424075, ' ', 300, 333, 2000, NEWID()) -- Exclui o registro DELETE FROM Ofertas WHERE IdOferta = Instruções e observações: No SQL SERVER, selecione todo o código do usuário 1 menos a linha do COMMIT. Clique no botão EXECUTAR. Note que, conforme esperado, o resultado do comando select é o mesmo da tabela apresentada no início deste exemplo prático (10 melhores ofertas). Obs.: a transação não foi completada (sem commit). Agora, vá para a sessão do usuário 2, selecione todas as linhas referentes ao comando use e ao comando insert (não selecione do delete em diante). Clique no botão EXECUTAR. Note que, a sessão 2 está tentando incluir uma oferta de R$4.000,00. Esta oferta, se confirmada, tornaria falso o resultado do select feito pelo usuário 1 (que está usando o nível serializable). Assim, a operação do usuário 2 será bloqueada e terá que aguardar o término da transação do usuário 1. Note na parte inferior da janela o Executing query que não termina. Agora selecione o commit existente na transação do usuário 1 e clique no botão EXECUTAR. Retorne à sessão do usuário 2 e veja que a inclusão da nova oferta foi realizada. Retorne à sessão do usuário 1, selecione e execute o último select. Note que, agora, o resultado é diferente do anterior (nova oferta de R$4.000,00 aparece).

20 IMPORTANTE: - Vá para a sessão 2 e exclua o novo registro: DELETE FROM Ofertas WHERE IdOferta = Vá para a sessão 1 e execute novamente todo o código, menos o commit. - Vá para a sessão 2, selecione e execute o segundo insert (inclusão de uma oferta pequena de R$2.000,00 que não interfere no resultado do select da sessão 1 serializable). INSERT INTO Ofertas ( IdOferta, DataOferta, IdUsuario, IdProduto, ValorOferta, HashOferta) VALUES (424075, ' ', 300, 333, 2000, NEWID()) Note, pela mensagem apresentada, que esta inclusão foi confirmada, ao contrário da anterior. Qual o motivo? - Exclua o registro. DELETE FROM Ofertas WHERE IdOferta = Fim dos Exemplos - Resumo Geral: Os quatro níveis de isolamento da SQL de acordo com a sua relação com os quatro fenômenos (problemas) da concorrência: NÍVEL DE ISOLAMENTO READ UNCOMMITTED READ COMMITTED REPEATABLE READ Perda de Atualização Leitura Suja PROBLEMA Leitura Não-repetida Leitura Fantasma Permite Permite Permite Permite Permite Não permite Permite Permite Não permite Não permite Não permite Permite SERIALIZABLE Não permite Não permite Não permite Não permite

21 Exercício 1: Simular uma situação de concorrência e bloqueio. Use a tabela TBCONTA do banco de dados DBBANCO (código de criação abaixo, exclua o banco antes, caso ele já exista). CREATE DATABASE DBBANCO ON PRIMARY (NAME=DBTESTE, FILENAME="D:\BANCOS\DBTESTE.MDF", SIZE=10MB); CREATE TABLE DBBANCO.DBO.TBCONTA ( CODI INT NOT NULL IDENTITY PRIMARY KEY, CONTA INT NOT NULL, SALDO INT NOT NULL, LIMITE INT NOT NULL); Agora copie e execute os comandos abaixo para incluir duas linhas na tabela. INSERT INTO DBBANCO.DBO.TBCONTA (CONTA,SALDO,LIMITE) VALUES (123,5000,10000) INSERT INTO DBBANCO.DBO.TBCONTA (CONTA,SALDO,LIMITE) VALUES (456,200,5000) Escreva duas transações em janelas (NEW QUERY) diferentes do Management Studio. A primeira transação deve alterar um dado da tabela (o saldo da conta 123, por exemplo código abaixo): Obs.: digite mas não execute a transação ainda. begin transaction update TBCONTA set saldo=saldo+1000 where conta=123 commit A segunda transação (em outra janela) deve ler este mesmo dado (o saldo da conta 123 código abaixo). Obs.: digite mas não execute a transação ainda. begin transaction select saldo from TBCONTA where conta=123 commit Selecione as duas primeiras linhas da primeira transação e clique no botão <EXECUTE>. Vá para a janela da segunda transação e clique no botão <EXECUTE>.

22 O que aconteceu com a segunda transação? Por quê? Retorne à janela da primeira transação, selecione apenas o comando COMMIT e clique no botão <EXECUTE>. Retorne à janela da segunda transação. O que aconteceu? Por quê? Exercício 2: Anote o saldo atual da conta 123: Altere o código na janela da primeira transação: begin transaction update TBCONTA set saldo=saldo+1000 where conta=123 rollback Altere o código na janela da segunda transação: set transaction isolation level read uncommitted begin transaction select saldo from TBCONTA where conta=123 commit Retorne à janela da primeira transação e execute as duas primeiras linhas. Retorne à janela da segunda transação e clique no botão <EXECUTE>. Qual o valor do saldo? Retorne à janela da primeira transação e execute apenas a última linha (rollback). Retorne à janela da segunda transação, selecione e execute apenas o comando abaixo. select saldo from TBCONTA where conta=123 Qual o saldo da conta 123? Que fenômeno que ocorreu na execução da segunda transação?