Controle de concorrência de transações
Propaganda
BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING Asterio K. Tanaka http://www.uniriotec.br/~tanaka/tin0036 [email protected] Bancos de Dados Distribuídos Processamento de Transações Asterio K. Tanaka Ambiente com SGBD Distribuído Asterio K. Tanaka Asterio K. Tanaka Asterio K. Tanaka Asterio K. Tanaka Transações em BDs • • • • Uma transação é uma unidade lógica de processamento com uma ou mais operações de acesso a BD (inserção, exclusão, atualização ou recuperação) As operações de BD que formam uma transação podem estar embutidas num programa de aplicação ou podem ser especificadas interativamente via uma linguagem de manipulação de dados de alto nível como a SQL. Uma forma de especificar as fronteiras de uma transação é através de comandos explícitos BEGIN TRANSACTION e END TRANSACTION num programa de aplicação; neste caso, todos as operações de acesso a BD entre os dois comandos são considerados como formando uma transação. Outra forma de delimitar transações é considerar como início implícito de uma transação qualquer comando de modificação do BD e o término da transação como os comandos de controle em SQL (COMMIT, ROLLBACK). Asterio K. Tanaka Transações em BDs Asterio K. Tanaka Propriedades das Transações Atomicidade: Uma transação é uma unidade atômica de processamento; ela é ou executada inteiramente ou não é nada executado. Consistência: A completa execução de uma transação deve levar o BD de um estado consistente para outro estado consistente, isto é, sem violação de restrições de integridade Isolação: Uma transação deve parecer como se estivesse sendo executada isoladamente, isto é, sua execução não deve sofrer interferência de outras transações sendo executadas concorrentemente Durabilidade: As mudanças aplicadas a um BD por uma transação efetivada (committed) deve persistir no BD. Asterio K. Tanaka Atomicidade • Tudo ou nada. • Atomicidade requer que se uma transação for interrompida por uma falha, seus resultados parciais sejam desfeitos. • A atividade de preservar a atomicidade das transações na presença de aborto de transações devido a erros de entrada, excesso de carga do sistema, ou deadlocks é chamada de recuperação (recovery) de transações. No caso de crash de sistema é chamado também de crash recovery. Asterio K. Tanaka Consistência Problemas da Concorrência de Transações • Atualização perdida (“lost update”) – • Ocorre quando duas transações que acessam os mesmos itens do BD têm as suas operações intercaladas de uma forma que torna os valores de algum item incorreto. Leitura suja (“dirty read”) – ou atualização temporária – • Ocorre quando uma transação atualiza um item do BD e então a transação falha por alguma razão. O item atualizado é acessado por uma outra transação antes que seja mudado de volta para o seu valor original, isto é, antes do rollback. Leitura não repetitível (“unrepeatable read”) – • Ocorre quando uma transação T lê um item duas vezes e o item é alterado por uma outra transação T’ entre as duas leituras. Em conseqüência, T recebe dois valores diferentes para suas duas leituras do mesmo item. Fantasmas (“Phantoms”) – Uma transação T1 pode ler um algumas tuplas de uma tabela, baseado em alguma condição especificada na cláusula WHERE. Supondo que outra transação T2 insira uma nova linha na mesma tabela, que também satisfaça a mesma cláusula WHERE usada na transação T1. Se T1 for repetida, lerá uma fantasma, isto é, uma linha que antes não existia. Asterio K. Tanaka Lost Update Dirty Read Asterio K. Tanaka Graus de Consistência • Grau 0 – uma transação não sobrescreve dados sujos lidos por outras transações. • Grau 1 – as transações não tem atualizações perdidas • Grau 2 – as transações não tem leituras sujas nem atualizações perdidas • Grau 3 – além do grau 2, as transações possuem a propriedade de leituras repetidas Asterio K. Tanaka Isolação Serializabilidade • Se várias transações forem executadas concorrentemente, os resultados devem ser os mesmos como se elas fossem executada serialmente em alguma order. Resultados incompletos • Uma transação incompleta não pode revelar seus resultados a outras transações antes da sua efetivação (commitment) • Isto é necessário para prevenir abortos em cascata. Asterio K. Tanaka Níveis de isolação em SQL • SQL delimita transações com início implícito em qualquer comando de modificação do BD e o término da transação explicitamente com COMMIT ou ROLLBACK. • Transações são configuradas pelo comando SET TRANSACTION [READ ONLY | READ WRITE] ISOLATION LEVEL <nível de isolação> <nível de isolação> : [READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE] Asterio K. Tanaka Níveis de isolação em SQL Tipo de violação Dirty Read Nonrepeatable Read Phantom READ UNCOMMITTTED Sim Sim Sim READ COMMITTTED Não Sim Sim REPEATABLE READ Não Não Sim SERIALIZABLE Não Não Não Nível Asterio K. Tanaka Exemplo EXEC SQL WHENEVER SQLERROR GOTO UNDO; EXEC SQL SET TRANSACTION READ WRITE DIAGNOSTICS SIZE 5 ISOLATION LEVEL SERIALIZABLE; EXEC SQL INSERT INTO EMPLOYEE (FNAME, LNAME, SSN, DNO, SALARY) VALUES (‘Robert’, ‘Smith’, ‘991004321’, 2, 35000); EXEC SQL UPDATE EMPLOYEE SET SALARY = SALARY * 1.1 WHERE DNO = 2; EXEC SQL COMMIT; GOTO THE_END; UNDO: EXEC SQL ROLLBACK; THE_END: ...; Asterio K. Tanaka Durabilidade • Uma vez que a transação é efetivada (commit), o sistema deve garantir que os resultados de suas operações nunca serão perdidos, a despeito de falhas subseqüentes. • Recuperação de BD (database recovery) – Para garantir atomicidade e durabilidade em presença de falhas. • Falhas – Transações incorretas (quebram consistência). – Falhas em transações: aborts explícitos, underflow, overflow ... – Erros de sistema: quedas de força, falhas no SO, no SGBD ... => Conteúdos da memória principal e do buffer pool são perdidos. O conteúdo do BD não. – Falhas de meio magnético: corrupção no armazenamento estável => tratados via back-up. Asterio K. Tanaka Controle de concorrência de transações • Para garantir a propriedade da isolação de transações concorrentes (e consistência, como conseqüência). • A maioria das técnicas utiliza protocolos para assegurar a serializabilidade das execuções (escalonamentos ou históricos) de transações concorrentes (chamadas de schedules). • A execução serial evita os problemas da concorrência – Se uma transação é executada sozinha por um SGBD, desde que seja consistente em si mesma e o estado inicial do BD seja consistente, o estado final também será consistente. • Sempre que duas ou mais transações executadas concorrentemente efetuam operações sobre o mesmo item de dado, pode ocorrer conflito. Um conflito ocorre se pelo menos uma das operações for uma operação de escrita. Asterio K. Tanaka Controle de concorrência de transações Protocolos (conjuntos de regras) de dois tipos – Baseados em bloqueios (locks) – Baseados em tempo (timestamps) Duas classes de mecanismos • Métodos pessimistas – Partem da premissa de que as transações conflitam entre si na maioria das execuções e estabelecem protocolos para acesso exclusivo aos dados pelas operações, assegurando o isolamento das ações da transação e a correção das suas execuções • Métodos otimistas – Baseiam-se na premissa de que a maioria das transações não possui operações conflitantes entre si, possibilitando livre acesso aos valores dos itens de dados. Ao final da execução de uma transação – ao receberem o comando de efetivação para processamento – fazem a avaliação da história produzida. Caso o SGBD constate a violação do isolamento, a transação é desfeita. Asterio K. Tanaka Controle de concorrência (CC) e Recuperação (Rec) em BDs distribuídos • Múltiplas cópias de itens de dados – CC responsável por manter a consistência entre as cópias – REC responsável por fazer uma cópia consistente com outras cópias se o site em que a cópia está armazenada falha e recupera mais tarde. • Falha de sites individuais – O SGBD-D continua a operar com seus sites ativos, se possível, quando um ou mais sites falham. Quando um site recupera, seus BD local deve ser atualizado com o resto dos sites antes de ser juntado ao sistema novamente. • Falha de links de comunicação – O sistema deve ser capaz de tratar falhas de um ou mais links que conectam os sites. Um caso extremo deste problema é o particionamento de rede, que divide os sites em duas ou mais partições, em que os sites em cada partição podem se comunicar apenas com os sites dentro da sua própria partição. Asterio K. Tanaka Controle de concorrência (CC) e Recuperação (Rec) em BDs distribuídos Outros problemas adicionais • Commit distribuído – Problemas podem ocorrer ao efetivar uma transação que está acessando BDs armazenados em múltiplos sites, se alguns sites falharem durante o processo de efetivação. O protocolo two-phase commit (2PC) é usado para tratar desse problema. • Deadlock distribuído – Pode ocorrer deadlock envolvendo vários sites, assim as técnicas para tratar de deadlocks devem ser estendidas para levar isto em consideração Asterio K. Tanaka Controle de Concorrência com “Cópia Distinta” A idéia é designar uma cópia em particular de cada item de dado como uma ”cópia distinta”. Os bloqueios (locks) para esse item de dados são associados à tal “cópia distinta” e todas as requisições de bloqueio e desbloqueio são enviadas para o site que contém aquela cópia. Vários métodos de controle de concorrência são baseados nessa idéia, diferenciados pela forma de escolher a ”cópia distinta”. – Técnica do Site Primário – Técnica do Site Primário com Site Backup – Técnica da Cópia Primária Asterio K. Tanaka Técnica do Site Primário Um único site primário é escolhido como o site coordenador de todos os itens do BD. Em conseqüência, todos os locks são guardados nesse site, e todas as requisições de bloqueio/desbloqueio são enviadas para esse site. Vantagem – Simplicidade, pois é uma mera extensão da abordagem centralizada Desvantagens – Sobrecarga no site primário causa um gargalo na rede. – Falha no site primária paralisa o sistema, prejudicando a confiabilidade e disponibilidade. Asterio K. Tanaka Técnica do Site Primário com Site Backup Um segundo site é designado como backup do site primário, aumentando a confiabilidade e disponibilidade. Todas as informações de bloqueio são mantidas em ambos os sites. Simplifica o processo de recuperação de falha do site primário, pois o site backup assume a coordenação e o processamento continua depois de um novo site backup ser escolhido e os dados de bloqueio serem copiados. O processo de bloqueio/desbloqueio fica mais lento, porque todas as requisições devem ser gravadas tanto no site primário como no backup antes que uma resposta seja enviada para a transação requisitante. O problema de sobrecarga nos sites primário e backup e conseqüente gargalo na rede permanece como desvantagem. Asterio K. Tanaka Técnica da Cópia Primária Este método tenta distribuir a carga de coordenação de bloqueio entre vários sites, designando cópias distintas de diferentes itens de dados armazenados em diferentes sites. A falha de um site afeta quaisquer transações que estão acessando locks sobre itens cujas cópias primárias residem naquele site, mas as outras transações não são afetadas. Este método também pode usar sites backup para melhorar a confiabilidade e disponibilidade. Asterio K. Tanaka Asterio K. Tanaka Asterio K. Tanaka Asterio K. Tanaka Asterio K. Tanaka Asterio K. Tanaka Administração de BDs Distribuídos • Nos SBDs distribuídos homogêneos, as funções de DBA podem ser vistas, em essência, como as mesmas dos SBDs centralizados. As ferramentas de suporte são mais sofisticadas. • Facilidades para DBA: servidores de replicação, monitores de eventos, mecanismo de agendamento de execução de procedimentos. Podem ser fornecidas pelo fabricante do SGBD ou por terceiros ou desenvolvidas na própria organização. • Com a proliferação das redes e dos servidores de BDs locais, é clara a necessidade de ferramentas que possibilitem a administração centralizada (não faria sentido ter um DBA em cada servidor). • Tendência de estender as funções de ferramentas de administração centralizada de redes, adequando-as para apoio a parte das funções de administração de banco de dados. Asterio K. Tanaka
