ADMINISTRAÇÃO DE BANCO DE DADOS
Por Ricardo Lima Caratti
Introdução
A administração de banco de dados é uma área de muita importância dentro de uma corporação. A forma como os dados são manipulados podem definir o sucesso ou fracasso de um projeto. Muitas vezes um sistema de banco de dados pode crescer rapidamente, tanto no que tange ao volume de dados bem como o número de usuários. Assim, é desejável pelo menos uma pessoa para executar as tarefas de Administração. O Administrador de Banco de Dados (DBA) e a pessoa encarregada de manter o sistema de banco de dados e a ele é atribuída as seguintes responsabilidades:
1.1 Planejar a infra-estrutura adequada que contemple as necessidades da empresa
Antes mesmo da instalação de um SGBD, é muito importante o DBA conhecer a demanda da corporação com a finalidade de definir uma infra-estrutura que a contemple. Isso irá assegurar um ambiente computacional compatível com o esperado, evitando assim, surpresas desagradáveis. Por exemplo: O investimento de Hardware e Software não suportar as demandas de recursos de informática. Também é muito importante que o DBA conheça e configure o sistema operacional de acordo com as características pedidas pelo SGBD. Isso inclui, principalmente, configuração de I/O, memória e processos.
1.2 Instalar e atualizar o Aplicativo SGBD bem como suas ferramentas de suporte
Além de definir o produto de Software e a plataforma de Hardware, o DBA deve cuidar da instalação e atualização do SGBD. No caso da atualização, é de bom alvitre analisar antes, o impacto que a nova versão irá causar nos sistemas que utilizam o banco, caso contrário, isso poderá causar prejuízos a corporação. Por exemplo: Uma determinada característica do SGBD ter sido descontinuada e, no entanto, os aplicativos a utilizam. Na mesma direção, as ferramentas de suporte poderão ser um diferencial na qualidade dos serviços prestados pelo DBA. É muito importante escolher um conjunto de ferramentas que aliviem o DBA das atividades rotineiras e sujeitas a erros.
1.3 Configurar os componentes físicos e lógicos do Banco de Dados de forma que contemplem as aplicações desenvolvidas
A forma como serão distribuídos os arquivos de sistema operacional vinculado ao SGBD poderão refletir no desempenho dos sistemas que utilizam o banco. O DBA tem um papel importante nessa atividade evitando o quanto possível, por exemplo, a contenção de Input e Output (I/O), ou seja, Entrada e Saída de dados, já que é uma área critica no desempenho do sistema. Outro exemplo seria, pôr os dois sistemas mais pesados em termos de fluxo de informação concorrendo por um único sistema de arquivo. Além dos componentes físicos, os componentes lógicos do sistema também devem ser definidos segundo critérios que venha a não prejudicar o desempenho do sistema no futuro. Por exemplo, definir corretamente tipos de dados, estruturas de tabelas, índices etc.
1.4 Modificar os componentes físicos e lógicos de acordo com as modificações propostas pelo desenvolvedores.
Na maioria dos casos, há a necessidade de alteração em uma estrutura física ou lógica do banco de dados está relacionado com a falta de planejamento adequado durante a fase de configuração, sendo, portanto, muito mais uma medida reativa que pró-ativa. No entanto, uma vez identificado o problema a alteração deverá ser feita de tal forma a evitar futuras alterações. Como medida pró-ativa, o DBA, antes de efetuar qualquer alteração, deverá fazer uma análise de impacto, caso contrário, poderá introduzir outros problemas ao sistema.
1.5 Criar Usuário, definir seus perfis de acesso e utilização.
Definir a forma como os usuários irão acessar o Banco de Dados poderá garantir a sua disponibilidade, isto é, acessos não autorizados poderão causar grandes prejuízos para a corporação. É função do DBA está de acordo com a política de segurança da corporação e definir padrões de acesso que permitam a integridade dos dados. Também é importante definir os recursos que cada usuário poderá utilizar com a finalidade de racionaliza-los. Por exemplo: Perceber, após estudos, que o consumo da Unidade Central de Processamento (CPU) de um determinado grupo de usuários não poderá ultrapassar 10% do total.
1.6 Controlar e monitorar acesso de usuários ao Banco de Dados
O monitoramento dos usuários é uma atividade muito importante na administração do banco de dados. É função do DBA acompanhar e controlar o acesso aos dados procurando situações atípicas. Por exemplo: Acesso a tabelas do sistema por meio de uma aplicação diferente da esperada.
1.7 Monitorar e otimizar a performance do Banco de Dados
A atividade de monitoramento, seja de usuário ou de performance, é uma atividade diária. Durante essa atividade, é função do DBA analisar comportamentos não esperados. Isso inclui redução de performance, consultas ineficientes, condições gerais do SGBD bem como do sistema operacional. Nessa atividade o DBA poderá detectar futuros problemas. Por exemplo: Consumo de I/O e memória, Observar que existe um crescente número de acessos simultâneos ao banco de dados. Nesse caso, o DBA poderá tomar medidas para evitar a degradação do sistema ao longo do tempo, evitando assim, a necessidade de sua parada.
1.8 Fazer auditoria das atividades executadas no banco de dados pelos usuários
Apesar do termo auditoria ser mais amplo, aqui, entende-se por auditoria a atividade de investigar ações efetuadas por usuários. É função do DBA configurar, se oportuno, mecanismos de auditoria no SGBD. Por exemplo: identificar qual usuário excluiu linhas de uma tabela, em que data, hora, por qual aplicação e em que máquina. Nesse caso, é importante manter essas informações registradas nos logs de banco e em unidades de fita por longo tempo. Isso porque problemas dessa natureza podem ser detectados muito depois do ocorrido.
1.9 Suporte a equipe de desenvolvimento de aplicação
Sendo o DBA, um bom conhecedor das características do SGBD, ele é um candidato a dá suporte a equipe de desenvolvimento no que tange a utilização dos recursos de forma racional. Por exemplo, o DBA pode atuar na codificação de consultas consideradas criticas para o sistema. Em uma visão pró-ativa, isso poderá evitar surpresa futura quanto ao tempo de resposta do sistema. Por exemplo: Atender uma funcionalidade do sistema que necessite efetuar milhares de transações por segundo.
1.10 Implementar a estratégia de Backup e Recovery de acordo com as necessidades da empresa
Dada às necessidades da corporação, o DBA deverá implementar a estratégia de backup e recovery. Informações como: A disponibilidade do banco durante essa atividade, tempo de recuperação de informação em caso de desastre, tecnologia disponível para sua execução e tempo em que as informações antigas devem ser mantidas são alguns entre vários parâmetros que o DBA deve analisar para implantar o sistema de Backup e Recovery do banco de dados. Testes também deverão ser efetuados para validar a implementação.
1.11. Executar o Backup e Recovery do Banco de Dados
É função do DBA verificar o sucesso ou não do Backup. Isso poderá evitar surpresa desagradável em caso de desastre.
2. MÉTODO DE REFINAMENTO DE PERFORMANCE
Todas as atividades descritas até o momento têm expressiva importância dentro do contexto da administração de um banco de dados. Porém, em geral, é necessário esforço e cuidado adicional para definir os métodos que serão utilizados para fazer refinamento de performance. Esses métodos serão abordados com mais detalhes a seguir.
Uma metodologia adequada é a chave para o sucesso do refinamento de performance. Algumas estratégias de refinamento podem não trazer o retorno esperado. Então é importante procurar estratégias que tragam o máximo de retorno. Além disso, sistemas com diferentes propósitos, como sistemas Processamento de Transações On-line(OLTP) e sistemas de Processamento de Analise On-line(OLAP) podem requerer abordagens diferenciadas. Nesse contexto, proceder de forma pró-ativa no refinamento do banco de dados pode ser o diferencial para o sucesso dos serviços disponibilizados pela corporação.
2.1. Refinamento pró-ativo durante o projeto e o desenvolvimento do sistema.
Segundo Cyran [1999], sem duvida, trabalhar de forma pró-ativa é a abordagem mais eficaz de refinamento. Para que isto seja possível, o pessoal executivo tem que colaborar com projetistas do sistema no sentido de estabelecer metas justificáveis de performance, fixando expectativas reais desde o inicio. Durante o projeto e o desenvolvimento, os projetistas podem determinar qual a combinação de recursos e disponibilidade de características do software irão melhor alcançar as necessidades. Construir um sistema eficiente pode minimizar custos de projeto, desenvolvimento e produção. A figura 2.1 ilustra o custo relativo ao refinamento durante o tempo de vida de uma aplicação
Figura 2.1 - Custo de refinamento durante o tempo de vida de uma aplicação.
Fonte: ORACLE (Oracle 8i Designing and Tuning for Performance)
Já a figura 2.2 mostra que o benefício em relação ao refinamento de uma aplicação no que tange ao seu tempo de vida é inversamente proporcional ao custo.
Figura 2.3 - Benefício do refinamento durante o tempo de vida de uma aplicação.
Fonte: ORACLE (Oracle 8i Designing and Tuning for Performance)
2.2 Refinamento reativo para melhorar um sistema em produção
Varias pessoas acreditam que o processo de refinamento começa com as reclamações dos usuários por tempo de resposta lento. Geralmente quando isto acontece já é muito tarde para aplicar algumas das estratégias de refinamento realmente eficaz. Nesta altura ficaria muito caro redesenhar completamente a sua aplicação, restando como única alternativa para melhorar a performance, a reconfiguração de memória e I/O. Na maioria das vezes o real problema não foi resolvido e sim adiado. Nesse caso uma reavaliação do desenho do sistema ou até mesmo alguma mudança na regra de negócio poderia ser uma solução mais definitiva. Para evitar problemas na fase de produção, Cyran[1999], sugere alguns passos a serem seguidos.
2.3 Passos prioritários do método de refinamento pró-ativo.
Na figura 2.4 estão classificados os passos necessários ao refinamento em ordem de prioridade e segundo seu impacto na performance:
Figura 2.4 -Método de Refinamento
Fonte: ORACLE (Designing and Tuning for Performance)
Cyran[1999] sugere ainda que pós completar os passos acima, deve-se avaliar o banco novamente para decidir se existe necessidade de refinamento adicional, ou seja, o refinamento deve ser um processo iterativo. Note também que a performance alcançada em passos posteriores pode abrir caminhos para passos anteriores adicionais, logo novas passadas pelo processo de refinamento podem ser necessárias e úteis.
Primeiro passo: Refinar regras do negócio
Para melhor performance, é importante adaptar as regras do negócio do sistema. Isso abrange um alto nível de analise e projeto completo do mesmo. Dessa forma, planejadores têm que assegurar que os requisitos do sistema correspondam diretamente às necessidades concretas. Regras do negócio tem que ser consistentes com uma expectativa realista. Por exemplo, alguns riscos tais como: número de usuários simultâneos, tempo de resposta por transação, consultas textuais, aplicações com multimídia etc. O DBA poderia participar nesse passo verificando se é possível o SGBD, juntamente com a plataforma de Hardware e Sistema Operacional, realmente suporta a demanda esperada.
Segundo passo: Refinar o projeto de dados
Na fase de projeto de dados, deve-se determinar quais dados são necessários para suas aplicações, quais relações são importantes e quais são seus atributos. Isso pode garantir que as estruturas das suas informações fiquem organizadas de tal forma que possibilite atingir melhor performance. Também nessa fase a normalização deverá estar pronta, porém, em alguns casos, poderá existir a necessidade de fazer o processo inverso, ou seja, desnormalizar, por razões de performance. O DBA poderá atuar aqui observando as chaves primárias e estrangeiras que serão utilizadas nas relações, observar se os tipos de dados são adequados para os tipos de informações utilizadas. Exemplo: Verificar que tipo de dados seria melhor para armazenar imagens.
Terceiro passo: Refinar o projeto de aplicações
Executivos do negócio e projetistas de aplicativos devem traduzir metas em um projeto de sistema eficaz. Por exemplo: Um sistema deve salvar, somente uma vez pela manha, um índice de correção diário, calculado a partir de vários outros índices, que é usado varias vezes durante o dia, evitando assim o mesmo calculo várias vezes. Agregar grupos de informações consultadas freqüentemente, em alguns casos, poderá ser bem vindo. Exemplo: Criar tabelas com totalizadores.
Quarto passo: Refinar a estrutura lógica do banco de dados.
Após os projetos de sistema e aplicações, você necessita planejar a estrutura lógica do banco de dados. A primeira preocupação é o refinamento do projeto de índices, para assegurar que os dados não estejam, nem sobre-indexados ou sub-indexados. Sabe-se que uma quantidade excessiva de índices em um tabela com muita alteração poderá ocasionar gargalos, pois, a alteração em uma coluna indexada resultará em trabalho adicional para atualizar também seus índices. Em contrapartida, um número reduzido de índices poderá resultar em tempo de resposta muito longo em consulta com alta seletividade. Também é importante considerar os recursos oferecidos pelo fabricante do SGBD tais como: “Tabelas organizadas em CLUSTER”, visões materializadas etc.
Quinto passo: Refinar operações do banco de dados.
Antes de otimizar o servidor de banco de dados, é fundamental que o aplicativo esteja obtendo o máximo de vantagem da linguagem SQL e das características disponíveis para aumento de performance. Assim, o entendimento do mecanismo de processamento de regras do banco também é importante quando forem escritas regras em SQL. Outro fator relevante é que independentemente se novas regras estão sendo codificadas em SQL ou regras problemáticas estão sendo rescritas, a metodologia de refinamento de operação de banco de dados deve enfocar recursos de CPU e I/O de disco. Vale lembrar que não existe refinamento de regras em SQL que possam compensar um projeto ineficiente na aplicação. Por exemplo, não considerar a indexação de campos utilizados com freqüência na cláusula WHERE de uma consulta SQL.
Sexto Passo: Refinar caminhos de acesso.
Assegure-se que existe um acesso de dados eficiente. Considere as soluções implementadas pelo fabricante do SGDB. Por exemplo, o SGBD ORACLE implementa tabelas com estruturas similares a índices (Index Table) com a finalidade diminuir o caminho de acesso a informações. Na pratica esse tipo de tabela é visto como se fosse uma tabela normal, no entanto, ela é recomendada somente para casos em que o caminho de acesso seja único, ou seja, acesso somente pela chave primária. Isso significa que se houver a necessidade de obter alguma informação nesse tipo de tabela por outro caminho, o tempo de resposta poderá não ser satisfatório.
Sétimo passo: Refinar a alocação de memória.
A alocação generosa de memória de acesso randômica (RAM) destinada ao SGBD poderá afetar positivamente na performance. Porém isso deve ser feito com cuidado, o sistema operacional também necessita de memória. Se uma quantidade excessiva de memória for destinada ao SGBD, em detrimento do Sistema Operacional, isso poderá força-lo a fazer muitas operações de disco, (paginação) resultando assim, em queda desempenho do sistema como um todo.
Oitavo passo: Refinar entrada e saída de dados (I/O) e estruturas físicas.
O I/O de disco rígido tende a reduzir a performance em algumas aplicações. Para refinar o I/O, dentre vários procedimentos dependente de plataforma de SGBD, destacam-se a distribuição dos dados em unidades de discos distintas para evitar contenção e a escolha do tamanho apropriado para unidade de alocação (blocos de dados). Fatores externos também devem ser levados em conta. Por exemplo, atividades paralelas aos serviços de banco de dados podem consumir muito I/O em detrimento do SGBD. Por exemplo, um processo responsável pela verificação de vírus executando em paralelo com os serviços de banco de dados.
Nono passo: Refinar a contenção de recursos.
Processamento concorrente para múltiplos usuários pode criar contenção de recursos. A contenção pode ocasionar a espera de processamento até que o recurso esteja disponível. Dentre várias destacam-se: contenção de I/O de disco, contenção de memória compartilhada e contenção de bloqueios (LOCK). Por exemplo, evitar que um usuário bloqueie uma tabela inteira enquanto na realidade ele só precisaria bloquear uma linha ou ainda evitar um bloqueio de linha por um tempo além do aceitável.
Décimo passo: Refinar as plataformas adjacentes.
Este refinamento deve ser feito de acordo com as plataformas que estão sendo usadas. Por exemplo, você pode querer refinar o tamanho destinado a memória compartilhada, gerenciadores de volumes lógicos de discos e quantidade de memória para cada processo. É possível também refinar características particulares do Sistema Operacional utilizado. Por exemplo, tamanho mínimo que deve ser utilizado para a unidade de alocação de disco.
2.4 Conclusão
Finalmente, no que se refere a Administração de Banco de Dados, é fundamental a utilização de métodos pró-ativos. Isso não só inclui as atividades exercidas pelo DBA, mas, também procedimentos que devem ser tomando antes mesmo de existir um banco de dados em produção. Assim, a participação do DBA deve está presente em todos os passos referidos acima. Ele deve dá apóio a equipe de arquitetos no que se refere aos riscos pertinentes ao banco de dados. Também é fundamental um ambiente de teste onde o DBA possa monitorar o desenvolvimento da aplicação. Ele deverá estar atento a qualquer anomalia que possa resultar em uma aplicação ineficiente em produção.
REFERÊNCIAS BIBLIOGRAFICAS
ARONOFF, Eyal, LONEY, Kevin, SANAWALLA, Noorali, ORACLE 8 Advanced Tuning & Administration, Berkeley, California, Oracle Press, 1998
BYLIS, Ruth, FEE, Joice, Administrator´s Guide, Release 2 (8.1.6), Oracle Corporation, 1999.
CYRAN, Michele, Designinig and Tuning for Performance, Release 2 (8.1.6), Oracle Corporation, 1999.
DATE, C. J., Introdução a Sistema de Banco de Dados, 7ª ed. [Tradução: Vandenberg D. de Souza], Rio de Janeiro, 2000.
KORTH, Henry F., SILBERSCHATZ Abrahan, System de Banco de Dados, 2ª ed. [Tradução: Maurício Heihachiro Galvan Abe], São Paulo, MAKRON Books, 1995
