ADMINISTRAÇÃO DE BANCOS DE DADOS MÓDULO 13

Transcrição

1 ADMINISTRAÇÃO DE BANCOS DE DADOS MÓDULO 13

2 Índice 1. Administração de SGBDs - Continuação Recuperação (Recovery) Recuperação de sistema... Erro! Indicador não definido Recuperação da mídia Erro! Indicador não definido. 2

3 1. ADMINISTRAÇÃO DE SGBDS - CONTINUAÇÃO 1.1. REPLICAÇÃO DE DADOS Replicação de banco de dados é a cópia dos dados de um banco de dados original para outro banco. Muitos bancos de dados comerciais hoje permitem replicação, que pode assumir uma das várias formas. Com a replicação mestre-escravo (master-slave), o banco de dados permite atualizações em um site primário e propaga automaticamente as atualizações para as réplicas em outros sites. As transações podem ler as réplicas em outros sites, mas não têm permissão para atualizá-las (Fig. 4.3 e 4.4) (DATE, 2003). Um recurso importante de tal replicação é que as transações não têm bloqueios em sites remotos. Para garantir que as transações executadas nos sites de réplica tenham uma visão consistente (mas talvez desatualizada) do banco de dados, a réplica deverá refletir um snapshot consistente com a transação dos dados no site primário; ou seja, a réplica deverá refletir todas as atualizações das transações até alguma transação na ordem de seriação, e não deverá refletir quaisquer atualizações de outras transações na ordem de seriação. O banco de dados pode ser configurado para propagar as atualizações imediatamente após elas ocorrerem no site primário, ou propagar as atualizações apenas periodicamente. A replicação mestre-escravo é particularmente útil para distribuir informações, por exemplo, de um escritório central para os escritórios das filiais de uma organização. Outro uso para essa forma de replicação é na criação de uma cópia do banco de dados para executar grandes consultas, de modo que as consultas não interfiram com as transações. As atualizações devem ser propagadas periodicamente a cada noite, por exemplo de modo que a propagação da atualização não interfira com o processamento da consulta. Fig Servidores mestre estão ambos sincronizados transmitindo escrita atualizações e transações em tempo real. Fig Servidores mestre-escravo estão ambos sincronizados transmitindo em tempo real. 3

4 O sistema de banco de dados Oracle admite uma instrução create snapshot, que pode criar uma cópia snapshot de uma relação consistente com a transação, ou de um conjunto de relações em um site remoto. Ele também admite o refresh do snapshot, que pode ser feito recalculando o snapshot ou atualizando-o de modo incremental. O Oracle admite refresh automático, seja de forma contínua ou em intervalos periódicos. Com a replicação multimestre (também chamada replicação de atualização em qualquer lugar) as atualizações são permitidas em qualquer réplica de um item de dados e são propagadas automaticamente a todas as réplicas. Esse é o modelo básico usado para gerenciar os bancos de dados distribuídos. As transações atualizam a cópia local e o sistema atualiza outras réplicas de forma transparente. Muitos sistemas de banco de dados oferecem uma forma alternativa de atualização: eles atualizam em um site, com a propagação lenta das atualizações para outros sites, em vez de aplicar imediatamente as atualizações a todas as réplicas, como parte de uma transação que realiza atualização. Os esquemas baseados na propagação lenta permitem que o processamento da transação (incluindo atualizações) prossiga mesmo que um site esteja desconectado da rede, melhorando assim a disponibilidade, mas, infelizmente, fazem isso a custo da consistência. Uma de duas técnicas normalmente é seguida quando a propagação lenta é usada: As atualizações nas réplicas são traduzidas para as atualizações em um site primário, que são propagadas lentamente a todas as réplicas. Esta técnica garante que as atualizações em um item sejam ordenadas em série, embora os problemas de seriação possam ocorrer, visto que as transações podem ler um valor antigo de algum outro item de dados e usá-lo para realizar uma atualização; As atualizações são realizadas em qualquer réplica e propagadas a todas as outras réplicas. Essa técnica pode causar ainda mais problemas, pois o mesmo item de dados pode ser atualizado simultaneamente em vários sites. Alguns conflitos devido à falta de controle de concorrência podem ser detectados quando atualizações são propagadas para outros sites, mas resolver o conflito envolve reverter as transações confirmadas e a durabilidade das mesmas, portanto, não é nenhuma garantia. Além do mais, a intervenção humana pode ter de lidar com conflitos. Esses esquemas, portanto, deverão ser evitados ou usados com cuidado FORMAS DE MELHORIA DE DESEMPENHO Simulação de desempenho Para testar o desempenho de um sistema de banco de dados, mesmo antes que este seja instalado, podemos criar um modelo de simulação de desempenho. Cada serviço como CPU, disco, buffer e controle de concorrência, é modelado na simulação. Em vez de modelar detalhes de um serviço, o modelo de simulação só pode capturar alguns aspectos de cada serviço, como o tempo de serviço, ou seja, o tempo gasto para terminar de 4

5 processar uma solicitação, uma vez que o processamento tenha se iniciado. Assim, a simulação pode modelar um acesso ao disco a partir apenas do tempo médio de acesso ao mesmo (DATE, 2003). Como as solicitações para um serviço geralmente precisam esperar sua vez, cada serviço possui uma fila associada no modelo de simulação. Uma transação consiste em uma série de solicitações. As solicitações são enfileiradas à medida que chegam, e são atendidas de acordo com a política para esse serviço, na qual o primeiro a chegar, é o primeiro a ser atendido. Os modelos para serviços como CPU e discos conceitualmente operam em paralelo, levemos em conta o fato de que esses subsistemas operam em paralelo em um sistema real. Quando o modelo de simulação para processamento de transação é criado, o administrador do sistema pode executar diversas experiências sobre ele. Ele pode usar experiências com transações simuladas chegando em diferentes taxas para descobrir como o sistema se comportaria sob diversas condições de carga. O administrador poderia executar outras experiências que variam os tempos de serviço para cada serviço, a fim de descobrir a sensibilidade do desempenho de cada um deles. Os parâmetros do sistema podem ser variados, de modo que o ajuste do desempenho pode ser feito no modelo de simulação. 5