Unidade III 4 ADMINISTRAÇÃO DE SGBDs As pessoas que trabalham com um banco de dados podem ser categorizadas como usuários de banco de dados ou administradores de banco de dados. 1 Entre os usuários, existem quatro tipos diferentes, distinguidos pela maneira como esperam interagir com o sistema. Diversos tipos de interfaces com o usuário foram projetados (SILBERSCHATZ, 1999:16): usuários leigos: são usuários não avançados que interagem com o sistema chamando um dos programas de aplicação previamente escritos. A interface típica para usuários leigos é composta de formulários, na qual o usuário pode preencher campos apropriados no formulário. Também podem simplesmente ler relatórios gerados pelo banco de dados; programadores de aplicação: são profissionais de computação que escrevem programas de aplicação. Os programadores de aplicação podem escolher entre muitas ferramentas para desenvolver interfaces com o usuário. As ferramentas de RAD (Rapid Aplication Development) permitem que um programador de aplicação construa formulários e relatórios com um mínimo de esforço de programação; usuários avançados: interagem com o sistema sem escrever programas. Em vez disso, eles formam suas 24
ADMINISTRAÇÃO DE BANCO DE DADOS 1 requisições em uma linguagem de consulta de banco de dados, Eles submetem cada uma dessas consultas a um processador de consulta, cuja função é desmembrar as instruções DML em instruções que o gerenciador de armazenamento entenda. Estão nesta categoria os analistas que submetem consultas para explorar dados no banco de dados; usuários especializados: são usuários avançados que escrevem aplicações de banco de dados especializadas, que não se encaixam na estrutura de processamento de dados tradicional. Entre essas aplicações estão os sistemas de projeto auxiliados por computador, sistemas de base de conhecimentos e sistemas especialistas, sistemas que armazenam dados com tipos de dados complexos (por exemplo, dados gráficos e dados de áudio) e sistemas de modelagem de ambiente. A pessoa que tem controle central sobre o sistema é chamada de administrador de banco de dados (DBA). As funções de um DBA incluem: definição de esquema: o DBA cria o esquema de banco de dados original executando um conjunto de instruções de dados na DDL; estrutura de armazenamento e definição de método de acesso; 2 modificação de esquema e de organização física: o DBA realiza mudanças no esquema e na organização física para refletir as alterações das necessidades da empresa, ou modificar a organização física de modo a melhorar o desempenho; concessão de autorização para acesso a dados: concedendo diferentes tipos de autorização, o DBA pode controlar partes do banco de dados em que os vários usuários podem 2
acessar. As informações de autorização são mantidas em uma estrutura de sistema especial, a qual o sistema de banco de dados consulta toda vez em que alguém tenta acessar os dados no sistema; manutenção de rotina: exemplos da manutenção de rotina do DBA são: - realizar backups periódicos do banco de dados, sejam em fitas ou em servidores remotos, para prevenir perda de dados no caso de acidentes, como incêndio, inundação, etc.; - garantir que haja espaço livre suficiente em disco para operações normais e aumentar o espaço em disco de acordo com o necessário; 1 - monitorar tarefas sendo executadas no banco de dados e assegurar que o desempenho não seja comprometido por tarefas muito onerosas submetidas por alguns usuários. 4.1 Segurança e administração - controle de acesso Através do SGBD, o DBA pode implementar mecanismos de segurança baseados em garantias ou restrições de acesso com preenchimento de login e senha, permitindo o registro de acessos e operações a partir do período em que o usuário acessa o banco de dados até o momento em que ele encerra suas atividades (Fig. 4.1). Fig. 4.1 - Conexão com SGBD cliente/servidor 26
ADMINISTRAÇÃO DE BANCO DE DADOS O DBA pode atribuir a um usuário formas de autorização sobre partes do banco de dados. Por exemplo: autorização para ler dados; autorização para inserir novos dados; autorização para atualizar dados; autorização para excluir dados. Cada um desses tipos de autorização é chamado de um privilégio (DATE, 03). O DBA pode autorizar um usuário a todos, a nenhum ou a uma combinação de privilégios sobre partes específicas de um banco de dados. Assim como também pode restringir o acesso a determinado banco de dados. Uma vez definido qual banco de dados poderá ser acessado, também define quais tipos de operações poderão ser realizadas pelos usuários. 1 Os mecanismos de configuração de privilégios são conhecidos como REVOKE e GRANT (revogação e garantia dos níveis), e podem ser implementados em grande parte de sistemas gerenciadores de banco de dados (Fig. 4.2). Fig. 4.2 - Definindo privilégios no SQL Server 6. 27
4.2 Recuperação (recovery) 1 2 O Recovery (recuperação), segundo DATE (03:381) em um sistema de banco de dados significa basicamente a recuperação do próprio banco de dados: ou seja, restaurar o banco de dados a um estado que se sabe ser correto depois que alguma falha o leva a um estado incorreto ou, pelo menos, suspeito. E os princípios fundamentais em que se baseia essa recuperação são muito simples, e podem ser resumidos em uma palavra: redundância. Em outras palavras, o modo de garantir que o banco de dados de fato é recuperável é garantir que toda informação que ele contém possa ser reconstruída a partir de alguma outra informação armazenada de modo redundante em outro lugar do sistema. O sistema deve estar preparado para se recuperar não apenas de falhas puramente locais, como a ocorrência de uma condição de estouro (overflow) dentro de uma transação individual, mas também de falhas globais, como uma queda de energia. Por definição, uma falha local só afeta a transação em que a falha realmente ocorreu. Ao contrário, uma falha global afeta todas as transações em andamento no instante da falha e, portanto, tem implicações significativas em todo o sistema. Essas falhas se enquadram em duas grandes categorias (DATE, 03): Falhas do sistema (por exemplo, queda de energia), que afetam todas as transações em curso no momento, mas não danificam fisicamente o banco de dados. Às vezes, uma falha do sistema é chamada de soft crash; Falhas da mídia (por exemplo, queda da cabeça de gravação sobre o disco), que causam danos ao banco de dados ou a uma parte dele, e afetam pelo menos todas as transações que, no momento, estão usando essa parte. Às vezes, uma falha da mídia é chamada de hard crash. 28
ADMINISTRAÇÃO DE BANCO DE DADOS 4.2.1 Recuperação de sistema 1 2 O ponto crítico com relação a falhas do sistema é o fato de que o conteúdo da memória principal é perdido (em particular, os buffers do banco de dados se perdem). Então, o estado exato de qualquer transação em curso no momento da falha deixa de ser conhecido; desse modo, tal transação não poderá nunca mais ser concluída com sucesso e deverá ser desfeita isto é, retomada quando o sistema for reinicializado. Além disso, também pode ser necessário refazer no momento da reinicialização certas transações concluídas com êxito antes da queda, mas que não conseguiram ter suas atualizações transferidas dos buffers do banco de dados para o banco de dados físico (DATE, 03). Segundo DATE, o sistema mantém um log ou diário em fita ou (mais comumente) em disco, no qual são registrados detalhes de todas as operações de atualização em particular, valores do objeto atualizado antes e depois de cada atualização, às vezes chamados de imagens antes e depois (03:383). Surge aqui a questão óbvia: de que maneira o sistema saberá, no momento da reinicialização, quais transações devem ser desfeitas e quais devem ser refeitas? A resposta é a seguinte: em certos intervalos predeterminados em geral, sempre que algum número preestabelecido de entradas é gravado no log o sistema automaticamente marca um checkpoint (ponto de verificação). Marcar um checkpoint envolve: a) gravar fisicamente o conteúdo dos buffers do banco de dados físico; b) gravar fisicamente um registro de checkpoint especial no log físico. O registro de checkpoint fornece uma lista de todas as transações que estavam em andamento no momento em que o 29
checkpoint foi marcado. O sistema percorre o log do fim para o início, desfazendo as transações; em seguida, ele percorre o log de novo para a frente, refazendo as transações. A restauração do banco de dados a um estado correto refazendo o trabalho é chamada de recuperação direta. De modo semelhante, a restauração do banco de dados a um estado correto desfazendo o trabalho às vezes é chamada de recuperação inversa. Observe que a recuperação direta refaz as atualizações na ordem em que foram feitas originalmente, enquanto a recuperação inversa desfaz as atualizações na ordem inversa. Finalmente, quando toda essa atividade de recuperação for concluída, então o sistema estará pronto para aceitar um novo trabalho. 4.2.2 Recuperação da mídia 1 A recuperação de uma falha desse tipo envolve basicamente a recarga ou a restauração do banco de dados a partir de uma cópia de backup. Em seguida, usa-se o log em geral, tanto a parte ativa quanto a parte arquivada para refazer todas as transações que se completaram desde que foi feita a última cópia de backup. Não há necessidade de desfazer as transações que ainda estavam em curso no momento da falha, pois, por definição, todas as atualizações dessas transações de qualquer modo foram desfeitas perdidas (DATE, 03). 2 A necessidade de ser capaz de efetuar a recuperação da mídia implica a necessidade de um utilitário de dump/restore (ou de descarga/recarga). A parte de dump desse utilitário é usada para criar cópias de backup do banco de dados por solicitação. Essas cópias podem ser mantidas em fita ou em outro meio de armazenamento de arquivos; não é necessário que estejam na mídia de acesso direto. Depois de uma falha
ADMINISTRAÇÃO DE BANCO DE DADOS de mídia, a parte de restauração do utilitário é usada para recriar o banco de dados a partir de uma cópia de backup especificada. 4.3 Replicação de dados 1 2 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, 03). 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 31
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. Master Master Fig. 4.3 - Servidores mestre estão ambos sincronizados transmitindo escrita, atualizações e transações em tempo real. Master Slave Fig. 4.4 - Servidores mestre-escravo estão ambos sincronizados transmitindo em tempo real. 1 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, 32
ADMINISTRAÇÃO DE BANCO DE DADOS 1 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. 2 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. 4.4 Formas de melhoria de desempenho 4.4.1 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 33
1 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 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, 03). 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. 2 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. 34