Administração de Dados

ADMINISTRAÇÃO DE DADOS

PADRONIZAÇÃO PARA NOMES E IDENTIFICADORES

Por Ricardo Lima Caratti

Uma breve introdução sobre Administração de Dados


A Administração de Dados é um tema pouco abordado em livros e em periódicos. Em muitos dos casos ela é confundida com a Administração de Banco de Dados e, quando existente em uma corporação, é exercida de forma tácita e não institucional. Muitos acreditam que o papel do Administrador de Dados (AD) se limita a criar e impor padrões que deverão ser seguidos por toda a equipe de desenvolvimento. Embora a padronização seja umas das ferramentas de trabalho para o uso estratégico da informação, veremos que a Administração de Dados é algo muito mais abrangente e de extrema importância para uma corporação.


Objetivos Principais da Administração de Dados


A Administração de Dados tem como principal objetivo gerenciar as estruturas de dados da corporação, promovendo sua conceituação, segurança, integridade e compartilhamento. Poderíamos detalhar isso da seguinte forma:


Garantir o uso estratégico das informações, identificando suas necessidades e oportunidades;

Melhorar a qualidade, a precisão e integridade dos dados;

Melhorar o compartilhamento dos dados na corporação;

Manter os modelos de informações atualizados;

Retirar dos Analistas e Desenvolvedores a responsabilidade da organização e estruturação dos dados;

Fornecer suporte a equipe de desenvolvimento;

Refinar e reaproveitar as informações da corporação.


Atividades da Administração de Dados

As principais atividades de um AD são:


Participar dos levantamentos de dados, eventos/funções e regras de negócio junto às áreas funcionais da corporação;

Elaborar e acompanhar a confecção dos modelos Conceituais de Dados.

Participar da integração do planejamento de sistemas com os modelos de Dados.

Responsabilizar-se pela qualidade e compatibilidade dos modelos de dados com os modelos de implementação;

Planejar e coordenar a evolução do Banco de Dados da corporação;

Definir, manter e auditar o Dicionário de Dados;

Desenvolver os mecanismos necessários para a adaptação dos sistemas legados.


Instrumentos de apóio a Administração de Dados


Dicionário de Termos;

Dicionário de Dados;

Dicionário de Acrônimos e Abreviações;

Documentação dos Projetos;


Perfil do Administrador de Dados


Análise de Sistema, sobretudo no que se refere a levantamentos de requisitos;

Boa capacidade de abstração;

Habilidade de mensurar a qualidade dos dados, segurança e facilidade de acesso;

Bom relacionamento com os envolvidos em cada projeto da corporação;

Boa noção sobre a metodologia aplicada para o desenvolvimento de sistema;

Conhecimento em Modelagem de Dados;

Conhecimento em ferramentas de apóio a modelagem de dados;

Conhecimento desejável:

Experiência em desenvolvimento de Sistemas;

Sistemas de Gerenciamento de Banco de Dados;

Linguagem SQL ou correlata;

UML;


PADRONIZAÇÃO DE NOMES DE ENTIDADES E ATRIBUTOS


Os “Nomes” são utilizados para identificar fatos sobre objetos, conceitos e eventos. Eles são de extrema relevância para a disseminação do conhecimento existente sobre os dados de uma corporação. Um bom padrão deve ser construído de tal forma a ser fácil de ser seguido por todos os envolvidos, desde o mais alto escalão da corporação até os gerentes de projeto, analistas, programadores e, em alguns casos, os usuários finais. Assim, a padronização de nomes deve estar presente tanto no modelo lógico quanto no modelo físico de dados. Nesse contexto, definimos “Nome” como uma palavra ou combinação de palavras no qual um elemento de dado pode ser conhecido. Assim, cada nome deve ser identificado dentro de um contexto, cada elemento de dado deve ter pelo menos uma palavra que o identifique.


Para abordar aspectos referentes a padronização de “Nomes” alguns conceitos podem ajudar na compreensão.


“Metadados"


Em sistemas de informações, entende-se por metadados informações sobre os dados. Ele é, sem sombra de dúvida, a ferramenta mais utilizada no gerenciamento de dados. Por isso, a padronização é um elemento necessário para assegurar que usuários e desenvolvedores entendam as informações que serão acessadas.


“Metadados” pode ser classificado em “metadado de negócio” e “metadados técnico”. “Metadados” de negócio são usados por analistas e usuários e provêem descrição sobre os elementos de informação. Eles estão mais associados aos modelos lógicos de dados. Os meta dados técnico são utilizados por administradores de sistema, desenvolvedores e ferramentas de software. Eles provêem descrições sobre os dados e as operações relacionadas a eles.


A utilização de um repositório de “Metadados” possibilita um meio para gerenciar informações sobre dados, aumentando assim, a produtividade no desenvolvimento de sistema de informação além de orientar usuários finais na localização e compreensão dos dados;


Modelo lógico de dados


O modelo lógico de dados serve para mostrar os dados que as aplicações devem armazenar satisfazendo os requisitos de negócios. Ele também mostra como esses dados estão relacionados. Em geral ele pode ser criado sem nenhum ambiente computacional em mente, ou seja, sem nenhuma consideração a questão de performance, armazenamento de dados, ambiente de desenvolvimento e hardware.


Modelo físico de dados


O modelo físico de dados serve para mostrar como os elementos de dados serão armazenados no banco de dados. As entidades e atributos do modelo lógico são mapeados para tabelas e colunas do modelo físico. O modelo físico muitas vezes pode introduzir objetos que não contribuem diretamente com os requisitos de negócios. Esses objetos podem ser criados por motivos de performance, redução de necessidade de armazenamento ou até mesmo para simplificar o desenvolvimento da aplicação.


PRINCÍPIOS DE CONVENÇÃO DE “NOMES” E IDENTIFICADORES


Nomes ou identificador podem ser definidos como palavras ou combinação de palavras dos quais os elementos de dados são conhecidos. Nomes podem ser combinados de tal forma a seguir uma regra de formação. Em muitos dos casos essas regras são construídas e utilizadas de acordos com as necessidades de uma corporação. No entanto a idéia de uma regra de formação permanece constante.


As regras ou conjunto de regras para formação de nomes devem ser seguidas e utilizadas em qualquer nível de desenvolvimento de uma corporação, ou seja, não deve ser restrita ao desenvolvimento de aplicação computacionais. Dado a importância do tema, a ISO desenvolveu um padrão para formação de nomes. Ele é baseado nas regras de composição de nome descritas acima. Trata-se da ISO/IEC -11179, que consiste das seguintes partes: 1-Cuida da especificação e padronização de elementos de dados; 2 – Classificação de elementos de dados; 3 - Atributos Básicos e Registro de “metamodelos”; 4 – Regras e guias para definição de formulação de dados; 5 – Princípios de formação de Nomes e Identificadores; 6 – Registro de elementos de dados. Falaremos aqui sobre a parte 5 do ISO/IEC – 11179.


O Padrão ISO/IEC 11179-5


Principais Características


Possibilita acesso e busca por conteúdo semântico em coleções de “metadados”;

Promove o uso de padrões para maior interoperabilidade;

Descreve a padronização e registro de elementos dados para fazer com que eles sejam compreensíveis e compartilhados;

Fornece um guia para regra de formação de nomes e definição de elementos de dados;

Nome de tags em XML seguem a convenção W3C que é baseada na ISO11179;

Dentre várias vantagens em utilizar o padrão ISSO/IEC 11179 destacam-se: É um padrão internacional estabelecido, é amplamente utilizado pelas agências governamentais; é facilmente integrável em esquemas de banco de dados e pode ser facilmente implementado em um LDAP (serviço de diretório);


As três regras principais para a composição de um nome são:


Regras semânticas, que são baseadas combinação de nomes, ou seja, utiliza qualificadores para enquadrar elementos de dados em um contexto;

Regras sintáticas, que descrevem como serão arranjados os elementos dentro de um nome;

Regras Léxicas, que diz respeito aos aspectos de um idioma ou linguagem, ou seja, termos preferidos e não preferidos, Sinônimos, Abreviações, Tamanhos, Conjunto de caracteres permitidos, utilização de maiúsculos e minúsculos;


Sugestões para formação de nomes


Como dito anteriormente, modelos lógicos de dados são gerados, além de outras coisas, para identificação de cada entidade e de seus atributos. Uma entidade ou objeto pode ser uma pessoa, uma coisa ou ainda um evento. O nome para definir cada objeto deve ser único dentro da corporação. A mesma idéia deve ser entendida para nomes de atributos, ou seja, ele deve ser único dentro de uma entidade. Assim, nomes para entidades e atributos devem ser o mais próximos do mundo real. Isso facilitará a leitura e compreensão dos modelos de dados.


Regra geral


Cada nome deve consistir de uma ou mais palavras que defina precisamente o propósito ou uso do elemento de dado;

O nome deve refletir o significado do negócio muito mais que o meio onde ele será armazenado ou processado;

Nome para elemento de dado deve estar no singular (Exemplo: Para entidade Funcionário, utilize “Funcionario” e não “Funcionarios”);

A palavra principal que compõe um elemento de dado não deve ser abreviada;

Utilize abreviações somente se for de aceitação e conhecimento geral da corporação;

Use todos os modificadores necessários para completa identificação do elemento de dados (Exemplo: Para “Nome do Empregado”, utilize NomeEmpregado no lugar de Nome);

Coloque os modificadores em uma seqüência lógica de tal forma que dê um significado preciso em Português (Exemplo: Para “Data de Nascimento”, utilize DataNascimento e não NascimentoData);

Se uma das palavras que compõe um Nome for um verbo, utilize-a no presente;

Usar a forma no substantivo sempre que possível (Exemplo: FUNCIONARIO, ORGAO, etc);

Se oportuno, para tornar mais claro, usar substantivo + adjetivo da seguinte forma: substantivo_adjetivo ou SubstantivoAdjetivo. Exemplo: HISTORICO_FUNCIONAL ou HistoricoFuncional. Lembrando que algumas implementações de SGBD não fazem distinção de maiúsculas e minúsculas. Assim, HistoricoFuncional poderia se tornar HISTORICOFUNCIONAL, podendo dificultar a compreensão.

Acrônimos ou siglas são bem vindos quanto estes são universalmente aceito. Exemplo: RG para registro geral, CEP para código de endereçamento postal, etc. Siglas podem ser oportunas para compor o nome de um esquema de banco de dados. Exemplo: Sistema de Recursos Humanos poderia ficar SRH. Entende-se por esquema de banco de dados como uma descrição de um banco de dados e não o banco de dados em si.

Evite tamanho de nomes muito longos. Sabe-se que algumas plataformas de banco de dados não suportam tamanhos maiores que 18 caracteres;

Utilize os Caracteres de A-Z e a-z para a identificação. Evite caracteres acentuados, espaços e outros que possam causar problemas quando incorporados a um SGBD. Leve sempre em consideração a portabilidade;



Exemplos de “Nomes” utilizados para Entidades e Atributos


A tabela abaixo mostra um pequeno exemplo de adoção de nomes para Entidades e Atributos.


Entidade


Atributo


Descrição








Funcionario


Matricula


Identificação do Funcionário




NomeFuncionario


Nome do Funcionário




DataNascimento


Data de Nascimento do Funcionário




NomePai


Nome do Pai do Funcionário




NomeMae


Nome da Mãe do Funcionário




CodigoEscolaridade


Código da Escolaridade do Funcionário




CodigoGrupoSanguineo


Código do Grupo Sangüíneo do Funcionário




.....



Escolaridade


Código Escolaridade


Código da Escolaridade




Descrição


Descrição da Escolaridade




....



GrupoSanguineo


CodigoGrupoSanguineo


Código do Grupo Sangüíneo




Descrição


Descrição do Grupo Sangüíneo




....



Tabela 1 – Exemplo de Nomes de Entidades e Atributos




Conclusão


A precisão e a integridade dos dados bem como a garantia do uso estratégico das informações de uma corporação são, dentre outros, os principais desafios da Administração de Dados. A utilização de um padrão de regra de formação de “Nomes” pode servir de ferramenta de trabalho para o Administrador de Dados. Nesse sentido, o padrão ISO/IEC 11179 poderá ajudar na utilização de um bom padrão.

Referências


Padrão ISO/IEC 11179-5, ISSO/IEC JTC1 SC36 N0555;

UC Davis Information Naming Standards, Data Administration Plan & Budget Office, Universidade da California, Versão 1.2, 22/07/1999;

University of Pennsylvania, http://www.upenn.edu/computing/da/;

Southwest Oregon Province, http://ims.reo.gov/website/swop/html/swop_slide_show/swop_sdm_whitepaper/sdm.htm#IV.

The University of Arizona, http://w3fp.arizona.edu/dataadmn/

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