slides -banco-de-dados

Prévia do material em texto

Tópicos Avançados 
em Banco de Dados
Professor: Juan Sebastian Toquica Arenas.
Aula 14
Sumário:
1. Revisão aula 13: Otimização de Consultas;
2. Aula 14: Conceitos de recuperação;
3. Dúvidas.
Sumário:
1. Revisão aula 13: Otimização de Consultas;
2. Aula 14: Conceitos de recuperação;
3. Dúvidas.
 Árvores de consulta e heurística;
 Escolha de plano de execução de consulta;
 Seletividade baseada em custo;
 Exemplo baseada em custo;
Otimização de Consultas:
Tomado de: https://thesearchendshere.wordpress.com/2012/05/15/sql-server-query-plans-introduction/
 Uma consulta expressada em uma linguagem de consulta de alto nível,
como o SQL, deve primeiro ser lida, analisada e validada.;
 O scanner identifica os tokens de consulta, nomes de atributos e nomes
de relação que aparecem no texto da consulta, enquanto o analisador
sintático (parser) verifica a sintaxe da consulta para determinar se está
formulada de acordo com as regras de sintaxe (regras da gramática) da
linguagem de consulta;
 A consulta também deve ser validada verificando se todos os nomes de
atributos e relação são válidos e semanticamente significativos no
esquema do BD consultado. Uma representação interna da consulta é
então criada, geralmente como uma estrutura de dados de árvore
chamada árvore de consulta.
 Também é possível representar a consulta usando uma estrutura de dados
de grafo, chamada grafo de consulta. O DBMS deve elaborar um plano de
consulta para recuperar os resultados da consulta do BD. Uma consulta
tem muitas estratégias de execução possíveis, e o processo de escolha de
uma adequada para o processamento é conhecido como otimização de
consulta.
Otimização de Consultas:
 O módulo otimizador de consulta
tem a tarefa de produzir um bom
plano de execução, e o gerador de
código gera o código para executar
esse plano. O processador em tempo
de execução do BD tem a tarefa de
executar o código de consulta, seja
no modo compilado ou interpretado,
para produzir o resultado da
consulta. Se um erro de tempo de
execução acontecer, uma mensagem
de erro será gerada pelo
processador em tempo de execução
do BD.
Otimização de Consultas:
 O termo otimização é, na verdade, um equívoco, porque em
alguns casos o plano de execução escolhido não é a estratégia
ideal, é apenas uma estratégia razoavelmente eficiente ou a
melhor avaliada para executar a consulta;
 Encontrar a estratégia ideal geralmente é muito demorado,
exceto pelas consultas mais simples. Aliás, tentar encontrar a
estratégia ideal de execução de consultas requer informações
precisas e detalhadas sobre o tamanho das tabelas e
distribuições de elementos como valores de coluna, que podem
nem sempre estar disponíveis no catálogo do DBMS;
 O planejamento de uma boa estratégia de execução pode ser
uma descrição mais precisa do que a otimização da consulta.
Otimização de Consultas:
 O objetivo principal é chegar ao plano mais eficiente e econômico usando as
informações disponíveis sobre o esquema e o conteúdo das relações envolvidas,
e fazê-lo em um período razoável de tempo;
 Uma maneira adequada de descrever a otimização de consultas seria: é uma
atividade conduzida por um otimizador de consulta em um DBMS para
selecionar a melhor estratégia disponível para executar a consulta.
Otimização de Consultas:
 O scanner e o analisador de uma consulta SQL primeiro geram uma
estrutura de dados que corresponde a uma representação inicial de
consulta, que é então otimizada de acordo com regras heurísticas;
 Isso leva a uma representação de consulta otimizada, que corresponde
à estratégia de execução de consulta. Depois disso, um plano de
execução de consulta é gerado para executar grupos de operações com
base nos caminhos de acesso disponíveis nos arquivos envolvidos na
consulta;
 Uma das principais regras heurísticas é aplicar operações SELECT e
PROJECT antes de aplicar o JOIN ou outras operações binárias, porque
o tamanho do arquivo resultante de uma operação binária, como o
JOIN, geralmente é uma função multiplicativa dos tamanhos dos
arquivos de entrada. As operações SELECT e PROJECT reduzem o
tamanho de um arquivo e, portanto, devem ser aplicadas antes de uma
operação binária.
Árvores de consulta:
 É uma estrutura de dados de árvore que corresponde a uma expressão de
álgebra relacional estendida. Representa as relações de entrada da
consulta como nós folha da árvore, e as operações de álgebra relacional
como nós internos;
 Uma execução da árvore de consulta consiste na execução de uma
operação de nó interno sempre que seus operandos estiverem
disponíveis e, em seguida, substituir esse nó interno pela relação
resultante da execução da operação;
 A ordem de execução das operações começa nos nós folha, que
representa as relações de BD de entrada para a consulta, e termina no
nó raiz, que representa a operação final da consulta;
 A execução termina quando a operação do nó raiz é executada e produz
a relação de resultado para a consulta.
Árvores de consulta (AC):
• SELECT P.Pnumber, P.Dnum, E.Lname, E.Address, E.Bdate
• FROM PROJECT P, DEPARTMENT D, EMPLOYEE E
• WHERE P.Dnum=D.Dnumber AND D.Mgr_ssn=E.Ssn
• AND P.Plocation= ‘Stafford’;
Árvores de consulta (AC):
 Em geral, várias expressões da álgebra relacional diferentes
podem ser semanticamente equivalentes, ou seja, podem
representar a mesma consulta e produzir os mesmos resultados;
 O analisador de consulta normalmente gerará uma árvore de
consulta inicial padrão para corresponder a uma consulta SQL,
sem fazer qualquer otimização;
 O otimizador deve incluir regras de equivalência entre
expressões da álgebra relacional estendidas que podem ser
aplicadas para transformar a árvore inicial na árvore de consulta
final e otimizada;
Otimização heurística das AC:
1. Quebre as seleção com condições conjuntivas em uma cascata de
operações de seleção;
2. Mova cada operação de seleção o mais baixo possível na árvore
de consulta;
3. Reordene os nós folhas de forma as seleções mais restritivas
sejam executas primeiro;
4. Combine as operações de produto cartesiano com seleções
subseqüentes (formando junções);
5. Quebre e mova as projeção o mais baixo possível na árvore e crie
novas projeção quando necessário;
6. Identifique subárvore que representam grupos de operações que
podem ser executadas em um único algoritmo.
Otimização heurística das AC:
 Encontre os sobrenomes de funcionários nascidos após 1957 que
trabalham em um projeto chamado 'Aquarius’:
• SELECT E.Lname
• FROM EMPLOYEE E, WORKS_ON W, PROJECT P
• WHERE P.Pname='Aquarius' AND P.Pnumber=W.Pno AND E.ssn=W.Essn
• AND E.Bdate > '1957-12-31';
Otimização heurística das AC:
Otimização heurística das AC:
• SELECT COUNT(*)
• FROM DEPARTMENT D
• WHERE D.Dnumber IN ( SELECT E.Dno
• FROM EMPLOYEE E
• WHERE E.Salary > 20000);
 Neste caso, novamente, há duas opções para o otimizador:
1. Avaliar a subconsulta aninhada para cada tupla exterior, mas é ineficiente;
2. Desaninhar a sub-consulta usando semi-junção, que é muito mais eficiente do que a
opção 1. Desaninhar se refere a expressá-lo como um único bloco, a junção interna
não pode ser usada, uma tupla de DEPARTAMENTO pode corresponder a mais de
uma tupla de EMPLOYEE e, portanto, produzir resultados errados. É fácil ver que
um sub-consulta aninhada age como um filtro e, portanto, não pode, ao contrário
da junção interna, produzir mais linhas que há na tabela DEPARTMENT. A semi-
junção simula esse comportamento.
Otimização Consulta Aninhada:
 Um otimizador de consulta não depende apenas de regras
heurísticas ou transformações de consulta; também estima e
compara os custos de execução de uma consulta usando
diferentes estratégias de execução e algoritmos, e então
escolhe a estratégia com a menor estimativa de custo;
 Para essa abordagem, são necessárias estimativas precisas de
custos para que diferentes estratégias possam ser comparadas
de forma justa e realista.Além disso, o otimizador deve limitar
o número de estratégias de execução a serem consideradas;
caso contrário, muito tempo será gasto fazendo estimativas de
custos para as muitas estratégias de execução possíveis;
Otimização Consulta baseada em custo:
 Essa abordagem é geralmente referida como otimização de
consulta baseada em custos;
 Utiliza técnicas tradicionais de otimização que buscam o espaço
da solução para um problema para uma solução que minimize
uma função objetiva (custo);
 As funções de custo utilizadas na otimização da consulta são
estimativas e não funções de custo exatas, de modo que a
otimização pode selecionar uma estratégia de execução de
consulta que não seja a ideal (melhor absoluta).
Otimização Consulta baseada em custo:
1. Custo de acesso ao armazenamento secundário: Este é o
custo de transferir blocos de dados (leitura e escrita) entre o
armazenamento de disco secundário e os principais buffers de
memória. Isso também é conhecido como custo de I/O de disco
(entrada/saída). O custo de consulta de registros em um
arquivo de disco depende do tipo de estruturas de acesso nesse
arquivo, como pedidos, hashing e índices primários ou
secundários. Além disso, fatores como blocos de arquivos são
alocados contiguamente no mesmo cilindro de disco ou
espalhados no disco afetam o custo de acesso;
2. Custo de armazenamento em disco: custo de armazenar em
disco quaisquer arquivos intermediários que são gerados por
uma estratégia de execução para a consulta;
Otimização Consulta baseada em custo:
3. Custo da computação: custo de realizar operações na memória nos
registros dentro dos buffers de dados durante a execução da
consulta. Tais operações incluem a busca e classificação de
registros, a fusão de registros para uma adesão ou uma operação de
classificação e a realização de cálculos sobre valores de campo. Isso
também é conhecido como custo de CPU;
4. Custo de uso da memória: custo relativo ao número de buffers de
memória principais necessários durante a execução da consulta;
5. Custo de comunicação: custo do envio da consulta e seus
resultados do local do BD até o local ou terminal de onde a consulta
se originou. Em BD distribuídos, também incluiria o custo de
transferência de tabelas e resultados entre vários computadores
durante a avaliação de consulta.
Otimização Consulta baseada em custo:
• SELECT Pnumber, Dnum, Lname, Address, Bdate
• FROM PROJECT, DEPARTMENT, EMPLOYEE
• WHERE Dnum=Dnumber AND Mgr_ssn=Ssn AND
• Plocation='Stafford';
Otimização Consulta baseada em custo:
Otimização Consulta baseada em custo:
 Essa técnica, que pode ser usada em combinação com as técnicas
discutidas anteriormente, utiliza restrições especificadas no banco
de dados, esquema, como atributos exclusivos e outras restrições
mais complexas, para modificar uma consulta em outra consulta
mais eficiente para ser executada.
• SELECT Lname, Salary
• FROM EMPLOYEE, DEPARTMENT
• WHERE EMPLOYEE.Dno = DEPARTMENT.Dnumber and
• EMPLOYEE.Salary>30000;
Otimização Consulta Semântica:
 Os atributos recuperados são apenas de uma relação: EMPLOYEE; a
condição de seleção também está nessa relação. No entanto, há
uma restrição de integridade referencial onde o Employee.Dno é
uma chave estrangeira que se refere ao departamento
Department.Dnumber. Portanto, essa consulta pode ser
transformada removendo a relação DEPARTAMENT da consulta e,
assim, evitando a junção interna:
• SELECT Lname, Salary
• FROM EMPLOYEE
• WHERE EMPLOYEE.Dno IS NOT NULL and EMPLOYEE.Salary>30000;
Otimização Consulta Semântica:
 Esse tipo de transformação se fundamenta na semântica de
relacionamento de chave primária/estrangeira, que são uma
restrição entre as duas relações;
 Com a inclusão de regras ativas e metadados adicionais nos
sistemas de BD, as técnicas de otimização de consulta
semântica estão sendo gradualmente incorporadas ao DBMS.
Otimização Consulta Semântica:
 Quais são as características e diferenças entre a otimização de
consultas em Oracle e SQL Server?
1. SQL Server Query Optimizer;
2. SQL Tuning.
 Existem outros otimizadores de consultas?
Atividade:
Sumário:
1. Revisão aula 13: Otimização de Consultas;
2. Aula 14: Conceitos de recuperação;
3. Dúvidas.
 Se apresentam a seguir alguns dos conceitos que podem ser
considerados para recuperação de BD em caso de falha no
sistema;
 A recuperação de falhas de transação geralmente significa
que o BD é restaurado para o estado consistente mais recente
antes do momento de falha;
 O sistema deve manter informações sobre as alterações que
foram aplicadas aos itens de dados pelas diversas transações.
Essas informações são normalmente mantidas no registro do
sistema (system log).
Conceitos de Recuperação de BD:
 Uma estratégia típica de recuperação pode ser resumida
informalmente em duas etapas:
1. Se houver danos extensivos a uma grande parte do BD devido
a uma falha catastrófica, como uma falha de disco, o método
de recuperação restaura uma cópia antiga do BD que teve
backup do armazenamento (armazenamento offline de grande
capacidade) e reconstrói um estado mais recente, refazendo
as operações de transações confirmadas do registro no
backup, até o momento da falha.
Conceitos de Recuperação de BD:
2. Quando o BD no disco não está fisicamente danificado, e ocorreu uma
falha não catastrófica, a estratégia de recuperação é identificar
alterações que possam causar uma inconsistência no BD.
• Por exemplo, uma transação que atualizou alguns itens do BD no disco,
mas não confirmou a necessidade de ter suas alterações revertidas
desfazendo suas operações de gravação;
• Também pode ser necessário refazer algumas operações para restaurar
um estado consistente do BD, por exemplo, se uma transação foi
confirmada, mas algumas de suas operações de gravação ainda não
foram gravadas em disco;
• Para uma falha não catastrófica, o protocolo de recuperação não
precisa de uma cópia completa do BD. Em vez disso, as entradas
mantidas no registro do sistema on-line são analisadas para determinar
as ações apropriadas para recuperação.
Conceitos de Recuperação de BD:
 É possível distinguir de forma conceitual duas técnicas para recuperação de
falhas de transações não catastróficas: atualização adiada e atualização
imediata:
 As técnicas de atualização adiada não atualizam fisicamente o BD no disco até
que uma transação atinja o ponto de confirmação, em seguida, as atualizações
são registradas no BD.
 Antes de atingir a confirmação (commit), todas as atualizações de transação são
registradas no espaço de trabalho de transação local ou nos buffers da memória
principal do DBMS. Antes da confirmação, as atualizações são gravadas
persistentemente no registro, após a confirmação, as atualizações são gravadas
no BD no disco, a partir dos buffers na memória principal. Se uma transação
falhar antes de atingir seu ponto de confirmação, ela não terá alterado o BD de
forma alguma, portanto, o UNDO não é necessário. Pode ser necessário um REDO
para desfazer o efeito das operações de uma transação confirmada com base no
registro, pois seu efeito pode ainda não ter sido registrado no BD em disco.
Assim, a atualização adiada também é conhecida como NO-UNDO/REDO.
Conceitos de Recuperação de BD:
 Nas técnicas de atualização imediata, o BD pode ser atualizado por algumas
operações de uma transação antes que a transação atinja seu ponto de
confirmação. No entanto, essas operações também devem ser escritas no
registro no disco ao forçar a gravação antes de serem aplicadas ao BD no disco,
tornando a recuperação ainda possível;
 Se uma transação falhar após gravar as alterações no disco, mas antes de atingir
seu ponto de confirmação, o efeito de suas operações no BD deve ser desfeito;
ou seja, a transação deve ser revertida.
 No caso geral de atualização imediata, tanto undo quanto redo podem ser
necessários durante a recuperação. Essa técnica, conhecidacomo algoritmo
UNDO/REDO, requer ambas operações durante a recuperação e é usada com
mais frequência na prática;
 Uma variação do algoritmo onde todas as atualizações são necessárias para
serem registradas no BD em disco antes da confirmação da transação, requer
apenas undo, por isso é conhecido como o algoritmo UNDO/NO-REDO.
Conceitos de Recuperação de BD:
 As operações UNDO e REDO precisam ser idempotentes, ou seja,
executar uma operação várias vezes equivale a executá-la
apenas uma vez;
Conceitos de Recuperação de BD:
Tomado de: https://www.mssqltips.com/sqlservertip/5971/accelerated-database-recovery-in-sql-server-2019/
 No geral, todo o processo de recuperação deve ser idempotente
porque se o sistema falhar durante o processo de recuperação, a
próxima tentativa de recuperação poderia fazer um UNDO e REDO de
certas operações já executadas durante o primeiro processo de
recuperação;
 O resultado da recuperação de uma falha no sistema durante a
recuperação deve ser o mesmo que o resultado da recuperação
quando não há falha durante o processo.
Conceitos de Recuperação de BD:
 O processo de recuperação é frequentemente entrelaçado com
as funções do sistema operacional (SO), em particular, o
buffering de páginas de disco de BD no cache de memória
principal do DBMS;
 Normalmente, várias páginas de disco que incluem os itens de
dados a serem atualizados são mantidas em cache nos buffers
de memória principal e, em seguida, atualizadas na memória
antes de serem gravadas de volta ao disco;
 O caching de páginas de disco é tradicionalmente uma função do
SO, mas devido à sua importância para a eficiência dos
procedimentos de recuperação, é tratado pelo DBMS chamando
rotinas de SO de baixo nível.
Caching (buffering) de blocos de disco:
 Em geral, é conveniente considerar a recuperação em
termos das páginas de disco (blocos) do BD;
 Normalmente, uma coleção de buffers na memória,
chamado de cache do DBMS, é mantida sob o controle
do DBMS com o propósito de manter esses buffers;
 Um diretório para o cache é usado para acompanhar
quais itens do BD estão nos buffers. Por exemplo, uma
tabela tipo:
✓ <Disk_page_address, Buffer_location, ... >
Caching (buffering) de blocos de disco:
 Quando o DBMS solicita ação em
algum item, primeiro verifica o
diretório de cache para determinar se
a página de disco contendo o item
está no cache DBMS;
 Se não estiver, o item deve ser
localizado no disco, e as páginas de
disco apropriadas são copiadas para o
cache;
 Pode ser necessário substituir, ou
esvaziar, alguns dos buffers de cache
para gerar espaço para o novo item.
Caching (buffering) de blocos de disco:
 As entradas no diretório de cache do DBMS têm informações
adicionais relevantes para o gerenciamento do buffer;
 Associado a cada buffer no cache está um bit sujo, que pode
ser incluído na entrada do diretório para indicar se o buffer foi
ou não modificado;
 Quando uma página é lida pela primeira vez do disco do BD em
um buffer no cache, uma nova entrada é inserida no diretório
de cache com o novo endereço de página do disco, e o bit sujo
é definido como 0 (zero);
 Quando o buffer for modificado, o bit sujo para a entrada do
diretório correspondente é definida como 1.
Caching (buffering) de blocos de disco:
 Informações adicionais, como os id das transações que
modificaram o buffer, também são mantidas no diretório;
 Quando o conteúdo do buffer for substituído (esvaziado) do
cache, o conteúdo deve ser primeiro gravado de volta para a
página de disco correspondente, somente se o bit sujo for 1.
 Outro bit, chamado de bit preso-solto (pin-unpin), também é
necessário:
✓ uma página no cache está presa (bit = 1) se ainda não puder ser
escrita de volta ao disco.
 O protocolo de recuperação pode restringir que certas páginas
de buffer sejam gravadas de volta ao disco até que as
transações que alteraram esse buffer tenham sido confirmadas.
Caching (buffering) de blocos de disco:
 Duas principais estratégias podem ser empregadas ao esvaziar
um buffer modificado de volta ao disco:
1. Atualização no local: grava o buffer no mesmo local do disco
original, substituindo assim o valor antigo de quaisquer itens
de dados alterados no disco. Portanto, uma única cópia de
cada bloco de disco do BD é mantida.
2. Sombreamento: grava um buffer atualizado em um local
diferente do disco, de modo que várias versões dos itens de
dados podem ser mantidas, mas essa abordagem não é usada
na prática com frequência .
Caching (buffering) de blocos de disco:
 De forma geral, o valor antigo do item de dados antes da
atualização é chamado de imagem anterior (BFIM), e o novo
valor após a atualização é chamado de imagem posterior
(AFIM);
 Se o sombreamento for usado, tanto o BFIM quanto o AFIM
podem ser mantidas em disco, portanto não é totalmente
necessário manter um registro (log) para recuperação.
Caching (buffering) de blocos de disco:
 Quando a atualização no local é utilizada, é necessário usar um
log para recuperação;
 O mecanismo de recuperação precisa garantir que a BFIM do
item de dados esteja registrada na entrada de log apropriada e
que a entrada de log seja esvaziada para o disco antes de a BFIM
ser modificada pela AFIM no banco de dados em disco;
 O processo geralmente é conhecido como logging write-ahead, e
é necessário poder desfazer (UNDO) a operação se isso for
exigido durante a recuperação.
Logging write-ahead:
 Existem dois tipos de informação de entrada de log incluída para
um comando de gravação: a informação necessária para UNDO e
a informação necessária para REDO;
 Uma entrada de log tipo REDO inclui um valor novo (AFIM) do
item gravado pela operação, pois isso é necessário para refazer
seu efeito com base no log (ao definir o valor do item no banco
de dados em disco para a AFIM);
 As entradas de log tipo UNDO incluem o valor antigo (BFIM) do
item, já que isso é necessário para desfazer o efeito da
operação baseada no log (ao definir o valor do item no BD de
volta para a BFIM);
 Em um algoritmo UNDO/REDO, os dois tipos de entradas de log
são combinados.
Logging write-ahead:
 Na recuperação de SGBD convencional inclui os termos steal/no-
steal e force/no-force, que especificam as regras para controlar
quando uma página do BD pode ser gravada do cache para o
disco:
 Se uma página do buffer em cache atualizada por uma transação
não pode ser gravada em disco antes da confirmação da
transação, o método de recuperação é chamado no-steal;
 O bit de preso-solto será usado para indicar se uma página não
pode ser gravada de volta ao disco. No entanto, se o protocolo de
recuperação permite gravar um buffer atualizado antes que a
transação confirme, o método é chamado de steal.
steal/no-steal e force/no-force:
 Se todas as páginas atualizadas por uma transação forem
imediatamente gravadas em disco antes que a transação
confirme, essa é chamada de técnica force, caso contrário é
chamada no-force;
 A regra do force significa que REDO nunca será necessário
durante a recuperação, pois qualquer transação confirmada terá
todas as suas atualizações em disco antes de ser confirmada.
steal/no-steal e force/no-force:
 Um tipo de entrada no log é chamado de checkpoint;
 No caso, um registro é gravado no logo periodicamente no ponto
que o sistema grava, no BD em disco, todos os buffers do DBMS
que foram modificados;
 O gerenciador de recuperação de um DBMS precisa definir em que
intervalos realizar um checkpoint;
 O intervalo pode ser medido em tempo (minutos), assim como
pelo número transações confirmadas desde o último checkpoint,
onde os valores são parâmetros do sistema. Realizar um check
point consiste nas seguintes ações:
Checkpoint:
 Realizar um checkpoint consiste nas seguintes etapas:
1. Suspender a execução de transações provisoriamente;
2. Forçar a gravação em disco de todos os buffers da memória
principal que foram modificados;3. Gravar um registro (checkpoint) no log e forçar a gravação do log
em disco;
4. Retomar a execução das transações.
 Devido à etapa 2, um registro de checkpoint no log também
pode incluir informações adicionais, como uma lista de id das
transações ativas e os locais do primeiro e último registro no log
para cada transação ativa. Facilitando o “desfazer” de
operações de transação caso uma transação precise ser
desfeita.
Checkpoint:
 O tempo necessário para forçar a gravação de todos os buffers de
memória modificados pode atrasar o processamento da transação
por causa da etapa 1.
 Para reduzir o atraso, é comum usar uma técnica chamada
checkpoint fuzzy;
 O sistema pode retomar o processamento da transação após um
registro ser gravado no log sem esperar que a etapa 2 termine;
 O sistema mantém um arquivo no disco que contém um ponteiro
para o checkpoint válido, que continua a apontar para o registro
do checkpoint anterior no log;
 Quando a etapa 2 termina, o ponteiro é mudado de modo a
apontar para o novo checkpoint no log.
Checkpoint:
 Se uma transação falhar por um algum motivo depois de atualizar o BD, mas
antes que a transação seja confirmada, pode ser necessário reverter (roll
back) a transação;
 Se algum valor de item de dados foi alterados pela transação e gravados no
BD, precisam ser restaurados para seus valores anteriores (BFIMs);
 As entradas de log do tipo UNDO são usadas para restaurar os valores antigos
dos itens de dados que precisam ser revertidos.
Rollback de transação:
 Se uma transação T é revertida, qualquer transação S que tenha
lido o valor de algum item de dados X gravado por T também
deve ser revertida;
 Quando S for revertida, qualquer transação R que tenha lido o
valor de algum item de dados Y gravado por S também precisa ser
revertida, e assim por diante;
 Esse fenômeno é chamado de rollback em cascata e pode ocorrer
quando o protocolo de recuperação garante schedules
recuperáveis, mas não garante schedules estritos ou sem
propagação.
 O rollback em cascata pode ser complexo e demorado, por isso a
maioria dos mecanismos de recuperação são projetados de modo
que o rollback em cascata não seja necessário.
Rollback em cascata:
Rollback em cascata:
Tomado de: Elmasri e Navathe (2006)
 De forma geral, uma transação terá ações que não afetam o BD,
como a geração e impressão de mensagens ou relatórios das
informações recuperadas/consultadas do BD;
 Se uma transação falhar antes de concluir, é necessário que o
usuário não receba esses relatórios, pois a transação não se
completo;
 Se relatórios com informação errada forem gerados, parte do
processo de recuperação deve informar ao usuário sobre os fatos,
já que o usuário pode tomar uma ação, com base nesses
relatórios, que afeta o BD;
Impacto no BD?
 Os relatórios só devem ser gerados depois que a transação atinge
seu ponto de confirmação;
 Um método comum de tratar essas ações é emitir os comandos
que geram os relatórios, mas mantê-las como tarefas em batch,
que são executadas somente depois que a transação atinge seu
ponto de confirmação. Se a transação falha, as tarefas em batch
são canceladas.
Impacto no BD?
Tomado de: https://datawhatnow.com/batch-processing-mapreduce/extract-data/
Sumário:
1. Revisão aula 13: Otimização de Consultas;
2. Aula 14: Conceitos de recuperação;
3. Dúvidas.
1. Lista de exercícios propositiva:
✓ X triggers;
✓ X Views;
✓ X procedimentos armazenados.
2. Estudo de caso:
▪ Conceitos da disciplina;
▪ Apresentação estudo de caso;
▪ Resultados lista.
Lista e Caso de Estudo (3 pessoas):
Dúvidas:
Referências
 DATE, C.J. Introdução a sistemas de banco de dados. Rio de
Janeiro: Campus, 2003;
 ELMASRI, R.; NAVATHE, S. B. Sistemas de Banco de Dados:
Fundamentos e Aplicações. LTC, 2006;
 DA SILVA OLIVEIRA, M. Desenvolvimento de aplicações de
Banco de Dados;
 Alzahrani, H. Evolution of object-oriented database systems.
Global Journal of Computer Science and Technology. 2016;
 Bartels, Dirk, et al. The object database standard: ODMG 2.0.
Eds. Roderic Geoffrey Galton Cattell, and Douglas K. Barry.
Vol. 38. Los Altos, CA: Morgan Kaufmann Publishers, 1997.
Obrigado!