Monitoração de Sistemas de Banco de Dados

Monitoração de Sistemas de Banco de Dados

Por Ricardo Lima Caratti

A disponibilidade do banco é um fator crítico para aplicações que manipulam bases de dados. Sistemas fora do ar por alguns minutos podem causar o descontentamento de milhares de usuários. Além da infra-estrutura de hardware e software projetada para garantir tal disponibilidade, é necessária a observação atenta e contínua do estado do SGBD. Neste artigo conheceremos algumas ferramentas de monitoração de banco de dados.

Métodos de Monitoração de Banco de Dados

Atividades de monitoramento podem ser efetuadas de duas formas: contínua ou sob demanda. Quando contínuas (ou pró-ativas), as atividades buscam prever e evitar o surgimento de problemas. Já as atividades por demanda (ou reativa) agem após a identificação de um problema já ocorrido. Um exemplo de utilização do monitoramento por demanda está relacionado a questões de desempenho. Imaginemos que um novo módulo de um aplicativo entrou em produção e em um dado momento o tempo de resposta do sistema aumentou de forma não esperada. Nesse caso, poderia ser detectado que uma determinada consulta foi construída de forma não otimizada.

O monitoramento pró-ativo consiste em fazer previsões baseadas em informações estatísticas extraídas do próprio SGBD e do sistema operacional. De posse desses dados, ele deve decidir se há necessidade de executar uma ação que previna a parada parcial ou total do sistema. Por exemplo, um monitor pró-ativo pode detectar que uma tabela irá alcançar sua alocação máxima e automaticamente estender essa alocação para que o sistema continue funcionado.

Embora o método reativo tenha seu espaço nas atividades de monitoração, o método pró-ativo é, sem dúvida, a forma mais eficaz de monitoramento no que tange a disponibilidade do SGBD. No entanto, é preciso ter cuidado com a utilização indiscriminada desses monitores, pois a verificação contínua do sistema pode causar impacto negativo no desempenho do SGBD. Nesse contexto, a monitoração pode ser classificada em intrusiva e não intrusiva, dependendo da interferência que ela causa no sistema.

Monitoração Intrusiva

Em muitos casos, é necessário obter informações internas do SGBD, como a quantidade de blocos ocupados por uma tabela ou como esses blocos estão distribuídos. Essas informações são importantes e necessitam de um acompanhamento periódico. No entanto, sua obtenção consome recursos do SGDB sendo necessário o cuidado para não sobrecarregá-lo. Fica claro que uma definição sensata da periodicidade em que as checagens serão feitas é fundamental. Outros exemplos comuns de monitoração intrusiva são: fazer o acompanhamento das atividades de um usuário ou grupo de usuários em particular para fins de depuração ou auditoria; fazer o acompanhamento em intervalos de tempo da taxa de crescimento de uma tabela e a avaliação do estado de fragmentação dos grupos de arquivos do SGBD.

Monitoração não Intrusiva

Como vimos, é muito importante que o monitoramento não afete negativamente o desempenho do SGBD. Para isto, as ferramentas de monitoração devem aproveitar ao máximo os recursos nativos de cada SGDB.
Diversos “fabricantes” de bancos de dados disponibilizam interfaces de programação para o desenvolvimento de mecanismos de monitoração para seu produto. Através dessas interfaces é possível obter informações diretamente da estrutura de memória do SGBD com impacto mínimo de performance. A ORACLE, por exemplo, oferece a visão V$SESSION para verificar as sessões de usuário conectados no SGBD. De forma similar, o MS SQL Server oferece a storade procedure sp_who.

O que Esperar de um Sistema de Monitoramento?

Considerando o que foi apresentado até o momento, já é possível fazer uma projeção de um sistema de monitoramento. Porém, surgem algumas questões:
Quais dados serão coletados?
Como fazer a coleta?
Como será criado um repositório centralizado para guardar informações?
Como o SGBD será acessado?
Como essas informações serão apresentadas?

Na maioria dos livros e manuais de SGBD, monitoração é um tema intimamente ligado a refinamento, ou seja, monitorar para otimizar performance. No entanto, sabe-se que o refinamento tende a ser muito mais eficiente na fase de Projeto e Desenvolvimento de um sistema do que durante a produção. Ou seja, quando um sistema entra em produção, é desejável que ele já esteja otimizado, restando para a monitoração o papel de identificar fatores que venham a comprometer sua disponibilidade.
Pensando assim, um bom monitor pró-ativo tem como componente fundamental o repositório de dados. O principal objetivo desse repositório é indicar tendências comportamentais do SGBD, como taxa de crescimento de usuários simultâneos, taxa de crescimento de dados, consumo de recursos do sistema e horários de pico. Dessa forma, uma análise temporal das informações do repositório poderá apoiar as tomadas de decisão do DBA.

Considerando que um DBA não está 24h no ambiente de trabalho, um bom monitor deverá tomar ações para impedir a parada do sistema sem a intervenção imediata do DBA. Por exemplo, ao coletar a informação de espaço disponível no disco, caso o valor atual não esteja dentro do limite considerado crítico, o monitor poderia efetuar determinadas ações como enviar uma mensagem de alerta para o DBA ou remover arquivos temporários para liberar mais espaço. A seguir são apresentadas algumas informações importantes a serem coletadas pelo monitor:

SGBD: Sessão de usuário, utilização de memória, utilização de espaço de armazenamento, performance geral do sistema, atividades de backup e recovery, contenção de bloqueios (locks) e transações por minuto.
NO-BREAK: Os NO-BREAKs modernos possuem uma interface de comunicação com o computador, sendo possível monitorar as condições das baterias, temperatura interna, oscilação e falta de energia elétrica.
SISTEMA OPERACIONAL: CPU, memória, espaço em disco, processos de usuário e rede.

O monitoramento do sistema operacional é importante, pois em muitos casos um problema pode estar mais relacionado aos recursos gerenciados por ele do que pelo SGDB. Considere, por exemplo, um processo “pesado” sendo executado pelo usuário em horário de pico (um antivírus, por exemplo).
A ampla gama de sensores de monitoração disponíveis atualmente permite que fatores externos ao SGBD sejam também monitorados, como:

Temperatura do ambiente: Caso exista alguma falha no sistema de refrigeração, a temperatura poderá subir de forma que possa comprometer o funcionamento dos computadores.
Umidade do ambiente: Ambientes muito úmidos podem prejudicar o funcionamento do computador.
Temperatura interna da CPU: Por mau funcionamento ou condições extremas, a temperatura da CPU poderá subir para valores críticos.
Temperatura dos Arrays de Discos: O uso intenso de I/O poderá superaquecer os discos.
Falha em algum disco do Array: Os atuais sistemas de array de discos possibilitam realizar manutenções sem necessidade de parar o sistema. Assim, monitorar as condições dos discos é importante e desejável.
Fontes de alimentação: Computadores projetados para alta disponibilidade vêm com duas ou mais fontes de alimentação permitindo que uma entre em funcionamento caso a outra falhe.

Onde Encontrar Ferramentas de Monitoração

Alguns SGBDs já trazem ferramentas de monitoração em seu pacote. Existem também fabricantes de softwares especializados nessa tarefa, como por exemplo a BMC Software (http://www.patrol.com/), Quest Software (http://www.quest.com/) e Veritas (http://www.veritas.com). Essas ferramentas estão disponíveis para os principais SGBD comerciais e podem ser consultadas nos sites apresentados. Algumas características dessas ferramentas são mostradas a seguir.
Ferramenta da Quest Software
A Quest Software possui um conjunto de ferramentas que possibilitam ao DBA monitorar e diagnosticar, em tempo real, várias condições de estado do SGBD. As principais características dessas ferramentas são:

Representação visual dos fluxos das atividades do SGBD;
Suporte a monitoração de múltiplos serviços de banco de dados ao mesmo tempo;
Suporte a monitoração de sistema operacional;
Suporte a identificação de gargalos;
Visualização imediata de áreas e situações problemáticas;
Alerta de contenção de recursos de SGBD;
Assistente que ajuda em reparos e refinamentos on-line;
Integração com outras ferramentas para suporte a monitoração pró-ativa em SGBD 24/7. Isso inclui envio de mensagens ao DBA via celular, page ou e-mail;
Apresentação detalhada de consultas em SQL ineficientes, utilização de memória, utilização de I/O, transações e bloqueios (locks).

Ferramenta da Patrol (BMC Software)

A Patrol também possui um conjunto de ferramentas que, na mesma linha da Quest Software, possibilitam a monitoração do SGBD e sistema operacional. Suas principais características são:

Condição de performance em tempo real dos servidores de banco de dados;
Visualização imediata de áreas e situações problemáticas;
Isolamento da causa do problema;
Análise de performance;
Dados estatísticos acumulados em repositório;
Alerta de contenção de recursos de SGBD;
Alerta de falta de espaço;
Condição e utilização de memória.


Conclusão

Vimos neste artigo uma introdução a algumas ferramentas para monitoração de banco de dados. Infelizmente não tive oportunidade de avaliar a ferramenta da Precise (Indepth). Porém, pelo que pude ver no site (http:/veritas.com/), ela possui funcionalidades equivalentes às apresentadas pela Quest e Patrol. Gostaria de complementar dizendo que as observações sobre as ferramentas apresentadas aqui são superficiais e servem apenas para dar uma idéia ao leitor das facilidades presentes nelas.

Referências

ARONOFF, Eyal, LONEY, Kevin, SANAWALLA, Noorali, ORACLE 8 Advanced Tuning & Administration, Berkeley, California, Oracle Press, 1998
CYRAN, Michele, Desinginig 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.
MOLINA, Hector Garcia, ULMAN Jeffrey D., WIDON, Jennifer, Implementação de Sistemas de Banco de Dados, 1ª ed. [Tradução: Vandenberg D. de Souza], Rio de Janeiro, CAMPUS, 2001.
SHAPIRO, Jeffrey R., SQL Server 2000, 1ª ed. [Tradução: Aldair José Coelho Corrêa da Silva], São Paulo, MAKRON Books, 2002.
Quest Software (www.quest.co)
Patrol (www.patrol.com)
Veritas (www.veritas.com)

Linux - Programação C _ Bibliotecas Compartilhadas

PROGRAMAÇÃO

DESENVOLVENDO BIBLIOTECAS COMPARTILHADAS EM LINUX.

Por Ricardo Lima Caratti

Em programação, entende-se por bibliotecas, arquivos que contêm um conjunto de módulos ou membros de códigos pré-compilados reutilizáveis. Esses códigos podem ser usados por vários programas sem a necessidade de detalhes de sua implementação. A grande vantagem de usar uma biblioteca, é que uma vez fabricada, não será mais preciso compilar, bastando simplesmente liga-la ao programa desejado. Dessa forma, existe uma grande vantagem em usar bibliotecas, pois uma vez implementada ou adquirida de terceiros, o desenvolvedor pode se abstrair dos detalhes e concentrar-se somente no problema principal.

A figura abaixo esboça o uso de uma biblioteca

Note que “Meu Programa” necessitou usar uma função X e um procedimento Y. Entende-se por função, um procedimento ou uma rotina que retorna um valor. Sabendo que essas rotinas existem na biblioteca “Biblioteca”, para usa-las, basta fazer referência à biblioteca durante a compilação do programa principal.

Em Linux, pode-se desenvolver dois tipos de bibliotecas. A biblioteca de ligação estática e biblioteca de ligação dinâmica. As bibliotecas estáticas são ligadas ao programa e fazem parte do arquivo executável. Já as bibliotecas dinâmicas são ligadas em tempo de execução, ou seja, a ligação ocorre por demanda. Portanto, não fazem parte do programa principal, reduzindo assim, o tamanho do arquivo executável.

Optar pelo uso de bibliotecas estáticas ou dinâmicas depende muito do que se pretende. Em geral, pode-se obter o mesmo resultado usando uma ou outra técnica. Bibliotecas estáticas deixam o código executável mais livre da configuração do ambiente, ou seja, todo o código que o programa precisa para ser executado já se encontra no próprio executável. Ao contrário, quando se faz uso de bibliotecas compartilhadas, o programa é dividido em um módulo principal e em um ou mais módulos que serão ligados dinamicamente. Considerando que bibliotecas compartilhadas podem ser usadas por mais de um programa ao mesmo tempo, elas ocupam menos memória RAM, menos espaço em disco, menos recurso do sistema e finalmente fica mais simples fazer manutenção.

Resumindo, bibliotecas são arquivos que contêm módulos reutilizáveis pré-compilados que serão usados por desenvolvedores de aplicações. Elas podem ser classificadas em estáticas e compartilhadas. Ao optar por bibliotecas estáticas, ela passará a fazer parte do corpo do programa principal, liberando-o assim do ambiente de configuração do sistema. Ao contrário, bibliotecas compartilhadas ligam-se ao programa principal dinamicamente, ou seja, um módulo só será ligado ao programa principal se for solicitado. Com isso, bibliotecas compartilhadas consomem menos recursos do sistema operacional além de facilitarem a substituição de módulos defeituosos sem a necessidade de compilar novamente todos os outros módulos ou sistemas envolvidos.

Para ilustrar o desenvolvimento de bibliotecas compartilhadas, será utilizado o ambiente de desenvolvimento na linguagem C que vem com a própria distribuição Linux.

Será criado um procedimento que mostrará o resultado da soma de dois valores e uma função que dirá qual o maior valor.

Note pelo fonte a seguir, que não existe nada incomum no desenvolvimento das rotinas.

Fonte: MinhaLib.c

#include
#include
#include

/*

Dados dois argumentos inteiros, a e b, imprime a soma.

*/

void MinhaProcSoma( int a, int b)
{

int c;

c = a + b;

printf("\n a + b = %d \n", c);
}

/*

Dado dois argumentos inteiros, a e b, retorna o maior valor

*/

int MinhaFuncMaiorValor( int a, int b)

{

if ( a >= b)

return a;

else

return b;

}

É preciso agora tornar a função e o procedimento disponíveis para qualquer programa. Para tanto, é preciso compila-lo utilizando a seguinte linha de comando:

gcc -fPIC -c MinhaLib.c

Para obter mais detalhes sobre as opções de compilação do C da GNU utilize o comando man gcc. Um manual completo das opções do compilador será mostrado.

Após a compilação, um arquivo MinhaLib.o será gerado.

Até agora, tudo que se tem é um módulo compilado com um procedimento e uma função. Nessa forma, é possível utilizar MinhaLib.o como uma biblioteca estática. Bastando para isso, liga-la ao programa principal da seguinte forma:

gcc –o ProgPrincipal ProgPrincipal.c MinhaLib.o

Para fazer uso dos benefícios de bibliotecas compartilhadas, é preciso ir um pouco mais além. Para tanto, é preciso usar a seguinte linha de comando:

gcc -shared -Wl,-soname,libMinhaLib.so.1 -o libMinhaLib.so.1.0 MinhaLib.o

Apesar de não ser obrigatório iniciar o nome de uma biblioteca compartilhada com lib, é muito desejável, já que é o padrão de algumas ferramentas do Linux como veremos mais adiante. Pelo comando acima, será criada uma biblioteca com o nome de libMinhaLib.so.1.0. O sistema operacional irá reconhecê-la pelo nome de libMinhaLib.so.1. Isso também não é obrigatório, mas é bom usar esse padrão para ficar de acordo com as normas de desenvolvimento do Linux.

Na realidade o Linux usa o seguinte padrão para bibliotecas compartilhadas:

libaaa.so.b.c.ddd

onde:

libaaa.so é o nome da biblioteca;

b é um número que indicará a maior versão;

c é um número que indicará a menor versão;

ddd é um número que informa a “release”.

Uma vez desenvolvida as rotinas e criada a biblioteca compartilhada, é preciso publicá-la. Para tanto será preciso escolher um diretório onde suas bibliotecas ficarão. De preferência utilize /usr/local/lib. Utilizando um editor de texto de sua preferência, altere o arquivo /etc/ld.so.conf adicionando na última linha o diretório /usr/local/lib.

Mova a biblioteca compartilhada libMinhaLib.so.1.o para /usr/local/lib

mv libMinhaLib.so.1.o /usr/local/lib

em seguida execute o comando:

/sbin/ldconfig

o utilitário ldconf irá a todos os diretórios existentes referenciados em ld.so.conf e carregará todas as bibliotecas compartilhadas que iniciarem com lib, criando também um link que de acordo com o exemplo será libMinhaLib.so.1. Também será criada uma referência para cada biblioteca compartilhada em /etc/ld.so.cache. Isso permitirá que ela seja carregada toda vez que o sistema iniciar.

Após executar ldconfig, verifique no diretório /usr/local/lib os sequintes arquivos:

libMinhaLib.so.1 (Link criado pelo ldconfig);
libMinhaLib.so.1.o a biblioteca criada por você.

Testando a biblioteca:

Programa de Teste (TestaProc.c):

#include

#include

int main()
{
void *descritor;
void (*PonteiroParaMinhaProcSoma)( int a, int b);

int (*PonteiroParaMinhaFuncMaiorValor( int a, int b);

int x, y, MaiorValor;

x = 10; /* Somente para exemplo */
y = 11; /* Somente para exemplo */

/* Abre a biblioteca compartilhada */
if ( descritor = dlopen("MinhaLib.so.1.0",RTLD_LAZY))
{
PonteiroParaMinhaProcSoma = dlsym(descritor,"MinhaProcSomal");

PonteiroParaMinhaFuncMaiorValor = dlsym(descritor,”MinhaFuncMaiorValor”);

/* Chamada a MinhaProcSoma */

(*PonteiroParaMinhaProcSoma)( 2, 4 );
(*PonteiroParaMinhaProcSoma)( x, y );

/* Chamada a MinhaFuncMaiorValor */

MaiorValor = (*PonteiroParaMinhaFuncMaiorValor)(x,y);

printf(“\nO Maior valor é: %d”, MaiorValor);

}
else

{
printf("\nErro ao tentar usar a biblioteca dinâmica\n");

printf(“\n%s\n”,dlerror() );

return 0;
}

Observações:

#include	Declarações das funções para manipulação de bibliotecas dinâmicas
dlopen(const char*filename, int flag)	Carrega uma biblioteca Compartilhada
void * dlsym(void *handle, char *symbol)	Obtem o endereço do procedimento dentro da biblioteca compartilhada
const char *dlerror()	Retorna uma string contendo o erro ou NULL se tudo OK
int dlclose(void *handle)	Fecha a biblioteca

Compile esse programa com:

gcc -o TesteProc TesteProc.c -ldl

Para executar faça:

./TestaProc

O exemplo mostrará o seguinte resultado:

a + b = 6
a + b = 21

O Maior valor é: 11

Para efeito prático, altere o procedimento MinhaProcSoma em MinhaLib.c da seguinte forma:

c = b - a;

printf("\n b - a = %d \n", c);

Execute os passos a seguir:

gcc -fPIC -c MinhaLib.c

gcc -shared -Wl,-soname,libMinhaLib.so.1 -o libMinhaLib.so.1.0 MinhaLib.o

mv libMinhaLib.so.1.o /usr/local/lib

Execute novamente o programa TestaProc da seguinte forma:

./TestaProc

Resultado:

b - a = 2
b - a = 1

O Maior valor é: 11

Note que não foi preciso compilar novamente o programa TestaProc. Nesse caso, a ligação à biblioteca alterada MinhaLib, foi efetuada em tempo de execução.

Concluindo, o Linux bem como outros ambientes Unix facilitam o uso e o desenvolvimento de bibliotecas compartilhadas. Dentre as vantagens em usar essas bibliotecas, destaca-se a facilidade de manutenção de sistemas, considerando é claro, que para tanto, basta trocar o módulo defeituoso sem a necessidade de re-compilar todos os outros módulos que o compõe.

Referências Bibliograficas:

WALL, WATSON, AND WHITIS. Linux Programming. SAMS, 1999

BARKAKATI, NABA. Red Hat Linux Secrets, Info World – IDG Books, 2^nd Edition, 1999

Atividades de DBA Introdução Atividades de DBA

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

Normalização vs Desnormalização de Banco de Dados

Quantidade de Colunas em uma Tabela

NORMALIZAÇÃO vs DESNORMALIZAÇÃO

Por Ricardo Lima Caratti

Este texto é o resultado da compilação de trechos dos livros e links abaixo:

• NAVATHE, Sistemas de Banco de Dados – Fundamentos e Aplicações, LTC, Terceira Edição, 2002;

• DATE, Introdução a Sistemas de BANCOS de DADOS, CAMPUS, Sétima Edição, 2000;

• TEOREY, Projeto de Modelagem de Banco de Dados, CAMPUS, 2007

• COUGO, Modelagem Conceitual e Projeto de Banco de Dados, CAMPUS, Décima Tiragem, 1997.

• ORACLE: http://download.oracle.com/docs/cd/B12037_01/server.101/b10752/data_acc.htm#17777

• http://www.dizwell.com/prod/node/58

A objetivo deste texto é buscar uma forma menos rígida de modelagem física de banco de dados, sem com isso, fugir de conceitos acadêmicos sobre o assunto.

Alguns Administradores de Banco de Dados, sobretudo os iniciantes, buscam em seus modelos, uma pureza "acadêmica" cujos benefícios em muitos dos casos são questionáveis.

Primeiro de tudo, desnormalizar um modelo físico de banco de dados não deveria ser considerado uma ação anti-acadêmico. A julgar pelo NAVATHE e o DATE, dois papas no assunto, é comum em um projeto de banco de dados, a desnormalização.

Abaixo tem-se alguns relatos desses autores sobre Desnormalização.

No capítulo 12 do DATE e 16 do NAVATHE, são dedicados as técnicas de desnormalização. Nestas literaturas são discutidas as vantagens e desvantagens dessa abordagem.

[DATE Capitulo 12]:

Uma Observação sobre Desnormalização]:

A normalização até a 5FN é desejável. Porém, na prática, se afirma com freqüência que a “desnormalização” é necessária para se alcançar um bom desempenho.

[NAVATHE Capítulo 16]:

DESNORMALIZAÇÃO COMO UMA DECISÃO DE PROJETO PARA ACELERAR CONSULTAS

[NAVATHE Capítulo 16]:

O Tuning do Projeto de Banco de Dados:

Tabelas existentes podem ser juntadas (Desnormalizadas) porque determinados atributos de duas ou mais tabelas são freqüentemente necessárias ao mesmo tempo;

Mito da Quantidade de Colunas vs Desnormalização

Existe relação entre a Quantidade de Colunas e as Regras de Normalização?

Vejamos:

Primeira Forma Normal

1. Está Integrado por tabela;

2. As linhas da tabela devem ser únicas;

3. As linhas não devem conter itens repetidos;

4. Os atributos devem ser atômicos;

5. *Os atributos não devem ter valores NULOS*; [COUGO]

Comentários:

O item 1 é intrínseco ao conceito RELACIONAL, pois, se não conseguimos ver o modelo na forma de linhas e colunas, sequer podemos iniciar os trabalhos; Os itens 2, 3 e 4 dispensam comentários. O item 5 é de difícil aplicação na vida prática. Assim, será aceito o NULO quando a informação não for conhecida. Contudo, se o NULO significar algo INAPLICÁVEL (Não se Aplica), é possível que o modelo necessite de uma revisão.

Como chegar a Primeira Forma Normal:

1. Obter as chaves candidatas da tabela;

2. Selecionar a Chave Primária da Tabela (pode ser composta por um ou mais atributos);

3. Eliminar os itens repetidos criando novas linhas;

4. Verificar se todos os atributos são atômicos. Caso existe um item que seja composto por mais de um sub-item, este deve ser separado.

Segunda Forma Normal

1. Estar na Primeira Forma Normal;

2. Cada uma das colunas não pertencente a chave primária NÃO pode ser dependente parcialmente (de parte) dessa chave; [COUGO]

Como chegar a Segunda Forma Normal:

Para verificar se uma tabela está na Segunda Forma Normal podemos fazer a seguinte pergunta: A Chave Primária é Composta por mais de uma coluna? Caso afirmativo, Existe alguma coluna NÃO-CHAVE que dependa apenas de parte da chave primária?

Terceira Forma Normal

1. Estar na Primeira e na Segunda Forma Normal;

2. Se nenhuma coluna NÀO-CHAVE depender de qualquer outra coluna NÃO-CHAVE;

Como chegar a Segunda Forma Normal:

Identificar as colunas NÃO-CHAVE e, para cada uma dessas colunas, verificar se seu valor pode ser determinado por alguma outra coluna NÃO-CHAVE;

Analise cada coluna NÃO-CHAVE e faça as seguintes perguntas:

1. Qual outra coluna NÃO-CHAVE poderia determinar o valor dessa coluna?

2. O valor dessa coluna poderia ser determinado pelo conhecimento de algum outro valor dessa tabela?

Quarta e Quinta Forma Normal

As formas normais até a Terceira ou FNBC foram definidas unicamente sobre Dependências Funcionais (DFs).

Para a maioria das necessidades a 3FN ou FNBC atende sem muitos problemas.

Contudo, existem mais duas formas normais necessárias para eliminar o restante das anomalias. Quais sejam:

Quarta Forma Normal

Estudo das Dependências Multivaloradas (DMV) [TEOREY]

Uma tabela está na 4FN se, e somente se, estiver na FNBC e não existir DMV.

Exemplo:

Cadastro de Pesoas com nome do pai, mãe e endereço.

O nome do pai, mãe e endereço pode se repetir nos casos de irmãos.

Em geral, isso pode ser percebido quando a tabela for populada.

Quinta Forma Normal

Trata do Estudo da Dependência de Junção.

Uma tabela está na quinta forma normal (5FN) ou forma normal projeção-junção se, e somente se, cada dependência de junção na tabela for inferidas pelas chaves desta tabela. [TEOREY].

Conslusão:

A Desnormalização, se usada com propriedade pode favorecer a performance do Sistema. No que se refere a Normalização, não encontrei em nenhuma literatura, algo que relacionasse a quantidade de colunas com a quebra de regra de normalização.