Um SGBD pode ser classificado pela quantidade de usuários aptos a utilizar o sistema
Por: Alle Andrade • 4/5/2018 • Relatório de pesquisa • 1.106 Palavras (5 Páginas) • 204 Visualizações
Um SGBD pode ser classificado pela quantidade de usuários aptos a utilizar o sistema, dentro disto, temos:
SGBD Monousuário – se somente um usuário de cada vez possa utilizar o sistema.
Exemplo: sistemas de computação pessoal.
SGBD Multiusuário – vários usuários podem acessar o banco CONCORRENTEMENTE.
Exemplo: maioria dos sistemas de BD em geral.
Transação – é um programa em execução que forma uma unidade lógica de processamento no BD onde a mesma deve ser indivisível (garantir a atomicidade) no que se refere à recuperabilidade. Uma transação engloba uma ou mais operações que acessam o BD como, por exemplo, inserções, exclusões, alterações, select’s, etc. As transações também podem estar embutida em programas de aplicações ou especificadas em um bloco de código SQL.
Transações Concorrentes – em sistemas multiusuários, várias transações podem ser disparadas e executadas ao mesmo tempo. A CPU irá trabalhar com a ideia de Time-Sharing, ou seja, a CPU executará por um certo período de tempo (time slice) uma transação, interrompe-la, executará outra, interrompe-la, voltará executar a primeira e assim por diante. O SGBD que irá controlar a execução destas transações, principalmente quando elas requisitarem os mesmos recursos da máquina (como por exemplo, uma variável).
Lembrando que se não houver o controle destes acessos, uma série de erros podem vir a acontecer, entre eles temos:
- Problema da atualização perdida: Problema que ocorre quando duas transações acessam os mesmos dados de forma intercalada, de modo que torne esses dados compartilhados inválidos em uma ou ambas as transações.
- Problema da atualização temporária (ou leitura suja): Ocorre quando uma das transações realiza uma modificação em algum dado compartilhado e, antes de ser comitado, uma segunda transação utiliza este dado modificado e caso ocorra um erro na transação 1 e for preciso dar um rollback, a transação 2 ficará com um valor inválido, ou seja, uma leitura suja.
- Problema de agregação (soma, resumo) incorreta: Ocorre quando uma transação lê e realiza uma soma com algum valor compartilhado sendo que este mesmo pode ter sido modificado por outra transação fazendo com que o valor da soma da primeira transação seja inválido.
Sempre que uma transação for submetida, o SGBD terá somente duas opções válidas a serem seguidas:
- Todas as operações na transação se completam com sucesso e seus resultados são gravados no BD de forma permanente;
- A transação não terá efeito nenhum no BD ou qualquer outra transação, seja por erro ou por algum acidente (como por exemplo, uma queda de energia no meio da transação).
Caso o SGBD siga pelo segundo caso, ele irá recuperar o estado anterior ao começo da transação em questão, ou seja, deixando-o como estava antes do inicio da transação.
Obs.: A restauração do estado do BD é importante pois o SGBD não deve permitir que algumas das operações de uma certa transação tenham efeito no BD caso a transação não termine pois isto deixaria o BD inconsistente.
Tipos de falhas que podem exigir recuperação:
- Falha de computador;
- Erro de transação ou de sistema;
- Erros locais ou de condições de exceção detectados pelas transações;
- Imposição do controle de concorrência;
- Falha de disco;
- Problemas físicos e catástrofes;
Obs. 1: Falhas do tipo 1, 2, 3 ou 4 o BD deverá ser capaz de tratar da recuperação enquanto as falhas 5 e 6 não acontecem frequentemente e sua recuperação é uma tarefa mais especializada.
Obs. 2: Lembrando que uma transação é uma unidade atômica, ou seja, ou ela é completada por inteiro ou ela não é realizada.
O gerenciador de recuperação do BD acompanha as seguintes operações:
- Begin transaction;
- Read ou write;
- End transaction;
- Commit transaction;
- Rollback;
Lembrar desta estrutura:
[pic 1]
Log do sistema – o sistema guarda todas as informações das operações que afetem os valores de itens do BD realizadas em um arquivo de log pois, caso seja necessário por causa de algum erro, será possível a recuperação do BD. Esse arquivo de log é armazenado em disco para que não seja afetado por qualquer tipo de falha.
O arquivo de log (registro de ocorrências do sistema) irá registrar os seguintes tipos de entradas:
- Id_transação -> Identificador da transação, gerado automaticamente pelo sistema;
- [START_TRANSACTION, T] -> Sendo T o ID da transação;
- [ESCREVER_ITEM, T, X, valor_antigo, valor_novo] -> Sendo T o ID da transação, X a variável/dado onde irá ser escrito algum valor;
- [LER_ITEM, T, X] -> Sendo T o ID da transação e X a variável/dado lido;
- [COMMIT, T] -> Salvando as modificações no BD;
- [ABORT, T] -> Abortando a transação, não irá ser salvo no BD;
- [END_TRANSACTION, T] -> Terminando a transação;
...