Informática - Universidade de Lisboa

UNIVERSIDADE DE LISBOA
Faculdade de Ciências
Departamento de Informática
DESENVOLVIMENTO DE UMA APLICAÇÃO
PARA MONITORIZAÇÃO DA ACTIVIDADE
FUNCIONAL EM BASES DE DADOS ORACLE
Ricardo Manuel Batalha Vilhena
MESTRADO EM ENGENHARIA INFORMÁTICA
Arquitectura, Sistemas e Redes de Computadores
2010
UNIVERSIDADE DE LISBOA
Faculdade de Ciências
Departamento de Informática
DESENVOLVIMENTO DE UMA APLICAÇÃO
PARA MONITORIZAÇÃO DA ACTIVIDADE
FUNCIONAL EM BASES DE DADOS ORACLE
Ricardo Manuel Batalha Vilhena
ESTÁGIO
Projecto orientado pelo Prof. Dr. Pedro Antunes
e co-orientado por Nuno Miguel de Sousa Maria
MESTRADO EM ENGENHARIA INFORMÁTICA
Arquitectura, Sistemas e Rede de Computadores
2010
Resumo
Este documento descreve o projecto realizado no âmbito da disciplina de Projecto em
Engenharia Informática, do Mestrado em Engenharia Informática da Faculdade de Ciências
da Universidade de Lisboa e desenvolvido na empresa Truewind – Tecnologias de
Informação SA.
A detecção das causas da degradação do desempenho nos sistemas de informação é
complexa. Muitas vezes esta actividade não obtém respostas válidas e relevantes para os
problemas encontrados. Prever o impacto e determinar de forma incisiva que operação do
processo e que instruções foram responsáveis pelo fraco desempenho de uma funcionalidade,
continua a ser uma tarefa muito pouco trivial.
Este projecto endereça este problema e teve como objectivo criar uma ferramenta –
BAM, que permita recolher dados de operações de negócio e relacionar a execução destas
operações com o consumo de recursos de hardware. Pretende-se com esta ferramenta estimar
e prever os recursos de hardware necessários em cenários de projecção da actividade
funcional.
O trabalho desenvolvido permitiu identificar conceitos de negócio na base de dados de
uma instalação do ERP Oracle e recolher indicadores da sua actividade. Para recolher dados,
foram desenvolvidas várias sondas que obtêm os indicadores e os introduzem na base de
dados de repositório da BAM. Estas sondas, além dos indicadores das operações de negócio
realizadas, recolhem também métricas de utilização e consumo de recursos de hardware.
Através da interface Web desenvolvida, a BAM permite a visualização de gráficos e de
tabelas que resumem e relacionam os dados recolhidos.
Num cliente da Truewind onde foi instalada a BAM, foi recolhida uma amostra de
dados significativa. Com base nos indicadores recolhidos, foi possível identificar na base de
dados do ERP Oracle, os diferentes tipos de projectos que este cliente desenvolve e qual o
impacto que cada tipo de projecto tem na utilização e consumo de recursos de hardware. Esta
informação auxilia o gestor da infra-estrutura a planear, em função dos objectivos de negócio,
os recursos necessários para garantir níveis de desempenho satisfatórios.
PALAVRAS-CHAVE: monitorização de sistemas, indicadores de negócio, consumo de
recursos
i
ii
Abstract
This document describes the project implemented for the Project in Computer Sciences
course of the Master’s Degree in Computer Sciences at the Faculty of Sciences of the
University of Lisbon developed in Truewind – Tecnologias de Informação SA.
Today’s business applications need to guarantee high performance levels. However,
through the years, with the change of business processes, it is common to watch overall
systems performance deteriorate. In most cases it is not always clear what triggered the
performance decline. It is difficult to identify correctly the process responsible for such
behavior, since several conditions may contribute. Not knowing in most cases the cause for
poor system performance, it is difficult to foresee the impact of each business operation and
plan hardware resources needed.
This project addresses this problem. The main goal is to develop an analysis tool –
BAM, which can collect execution data from business operations and relate this data with
resource usage metrics also collected.
Major tasks involved the identification of business entities, the development of multiple
probes to collect information about business activity and hardware resource usage and a Web
interface used to analyze retrieved data with dynamic graphics.
BAM was used in a support and maintenance project of Truewind and collected an
interesting sample of usage data. First, one of the main business operations was identified in
the database. Information about its execution and impact on different structures was retrieved.
Second, hardware resource usage metrics were collected in the production environment.
BAM provided an interface with graphical elements which allowed the analysis of these two
sets of data and the impact that business activity did on the hardware resource usage. This
analysis can help IT management to predict future needs according to the company’s business
plans.
KEYWORDS: databases, systems monitoring, business kpi, resource usage
iii
iv
Conteúdo
Conteúdo .................................................................................................................................... v
Lista de Figuras ...................................................................................................................... viii
Lista de Tabelas ........................................................................................................................ xi
Capítulo 1
Introdução ............................................................................................................ 1
1.1
Motivação .................................................................................................................... 1
1.2
Objectivos Gerais ........................................................................................................ 2
1.3
Resumo do trabalho desenvolvido .............................................................................. 3
1.4
Enquadramento institucional ....................................................................................... 4
1.5
Estrutura do relatório ................................................................................................... 5
Capítulo 2
Contextualização do Projecto .............................................................................. 7
2.1
Contexto ...................................................................................................................... 7
2.2
Objectivos Específicos .............................................................................................. 10
2.3
Metodologia Adoptada .............................................................................................. 11
2.4
Plano de Execução .................................................................................................... 13
Capítulo 3
3.1
Tecnologia e Arquitectura.................................................................................. 17
Plataforma de Base .................................................................................................... 17
3.1.1
Base de dados Oracle ......................................................................................... 17
3.1.2
Oracle EBS (E-Business Suite) .......................................................................... 20
3.1.3
SNMP................................................................................................................. 22
3.1.4
CMOS ................................................................................................................ 23
v
3.2
Tecnologias Utilizadas no Desenvolvimento ............................................................ 25
3.2.1
PHP .................................................................................................................... 25
3.2.2
JavaScript ........................................................................................................... 25
3.2.3
SQL .................................................................................................................... 26
3.2.4
XML................................................................................................................... 26
3.2.5
Shell Scripts ....................................................................................................... 27
3.2.6
Fusion Charts ..................................................................................................... 27
3.3
Arquitectura da BAM ................................................................................................ 28
3.3.1
Motor de Recolha de Dados ............................................................................... 29
3.3.2
Motor de Análise................................................................................................ 29
3.3.3
Integração de Sistemas ....................................................................................... 30
3.4
Tecnologia Relacionada ............................................................................................ 31
3.4.1
Oracle Enterprise Manager – OEM ................................................................... 31
3.4.2
Monitor Magic – Database Monitoring ............................................................. 32
3.4.3
Quest Database Management ............................................................................. 33
3.4.4
Primos Database Monitoring ............................................................................. 34
3.4.5
Ignite for Oracle Performance ........................................................................... 35
3.4.6
Oracle Business Activity Monitoring ................................................................ 36
3.4.7
Análise Comparativa .......................................................................................... 37
Capítulo 4
Trabalho Realizado ............................................................................................ 41
4.1
Preparação do Projecto .............................................................................................. 41
4.2
Definição dos Requisitos da BAM ............................................................................ 42
4.3
Desenho da Solução .................................................................................................. 43
4.4
Implementação da BAM ........................................................................................... 45
4.4.1
Instalação do Ambiente...................................................................................... 45
4.4.2
Repositório de dados .......................................................................................... 46
4.4.3
Motores de Análise e Recolha ........................................................................... 48
vi
4.4.4
4.5
Criação da interface gráfica ............................................................................... 55
Testes......................................................................................................................... 62
4.5.1
Testes realizados aos componentes nucleares da BAM ..................................... 62
4.5.2
Testes realizados à interface utilizador .............................................................. 63
4.6
Resultados Obtidos.................................................................................................... 64
Capítulo 5
5.1
Conclusões ......................................................................................................... 71
Trabalho futuro .......................................................................................................... 72
Bibliografia .............................................................................................................................. 75
vii
Lista de Figuras
Figura 1. Metodologia de desenvolvimento em Espiral .......................................................... 11
Figura 2. Mapa de Gantt com o planeamento executado no projecto ...................................... 13
Figura 3. Plano inicial do projecto ........................................................................................... 15
Figura 4. Arquitectura da base de dados Oracle versão 10g [13] ............................................ 18
Figura 5. Arquitectura da Oracle E-Business Suite ................................................................. 21
Figura 6. Mensagem do protocolo SNMP [18] ........................................................................ 23
Figura 7. Arquitectura da Consola de Monitorização com os vários componentes [6] ........... 23
Figura 8. Método de impressão de mensagens de depuração desenvolvido em PHP.............. 25
Figura 9. Método desenvolvido em Javascript para geração de gráficos ................................ 26
Figura 10. Interrogação em SQL para obtenção da média diária de consumo de memória
virtual sobre o modelo de dados da BAM ............................................................................... 26
Figura 11. Conteúdo de um ficheiro XML representativo de um gráfico ............................... 27
Figura 12. Arquitectura do Sistema ......................................................................................... 28
Figura 13. Vista de Administração do OEM [2] ...................................................................... 32
Figura 14. Monitor Magic Database Monitoring [3] ............................................................... 33
Figura 15. Spotlight - Quest Software [5] ................................................................................ 34
Figura 16. Primos Database Monitoring [28] .......................................................................... 35
Figura 17. Ignite for Oracle Performance [29] ........................................................................ 36
Figura 18. Interface gráfica Oracle BAM [24] ........................................................................ 37
Figura 19. Modelo de Dados .................................................................................................... 44
viii
Figura 20. Sonda da BAM para recolha de dados de carga de processador ............................ 49
Figura 21. Fluxo de funcionamento do motor de recolha de dados ......................................... 50
Figura 22. eTRM da Oracle com os meta-dados do modelo de dados do E-Business Suite ... 52
Figura 23. Excerto do resultado da pesquisa pela tabela PA_PROJECTS_ALL no eTRM .... 53
Figura 24. Quadro consumo de recursos.................................................................................. 56
Figura 25. Caixas de selecção para escolha de gráficos .......................................................... 57
Figura 26. Vista Horária .......................................................................................................... 58
Figura 27. Vista Diária ............................................................................................................. 59
Figura 28. Antes da operação de aumento ............................................................................... 60
Figura 29. Depois da operação de aumento ............................................................................. 60
Figura 30. Consumo de processador, memória e espaço ocupado pela base de dados em
função do número de linhas da tabela PA_PROJECTS_ALL ................................................. 67
Figura 31. Consumo de Processador ........................................................................................ 68
Figura 32. Evolução do número de linhas da tabela PA_RESOURCE_ASSIGNMENTS ..... 68
ix
x
Lista de Tabelas
Tabela 1. Comparativo de soluções ............................................................................. 39
Tabela 2. Tabelas da base de dados e respectiva descrição ......................................... 47
Tabela 3. Descrição das colunas existentes em cada tabela da base de dados............. 48
Tabela 4. Descrição das sondas ................................................................................... 50
Tabela 5. Número de registos por tabela ..................................................................... 64
Tabela 6. Número de linhas e espaço ocupado em média por tipo de projecto em três
tabelas .......................................................................................................................... 65
xi
Lista de Tabelas
xii
xii
Capítulo 1
Introdução
Este documento apresenta o projecto de desenvolvimento de uma aplicação para
a monitorização da actividade funcional numa base de dados Oracle, Este projecto foi
realizado no âmbito do Mestrado em Engenharia Informática (MEI), da Faculdade de
Ciências da Universidade de Lisboa, e foi desenvolvido na Truewind – Tecnologias
de Informação S.A.[1].
1.1 Motivação
Actualmente exigem-se níveis de desempenho elevados e constantes aos
sistemas de informação. A responsabilidade pelo desempenho destes sistemas recai,
em grande parte, sobre as bases de dados e as aplicações que as utilizam.
Logo após a entrada em utilização dos sistemas de informação, por vezes com
bases de dados vazias, não são evidentes os problemas de desempenho. Estes surgem
após alguns meses de operação. Nessa altura, interessa dispor das ferramentas
adequadas para analisar o funcionamento e o desempenho das aplicações no sentido
de corrigir situações ineficientes e recuperar os níveis de desempenho exigidos. No
entanto, devido à dificuldade de prever convenientemente o impacto da actividade
funcional que varia em cada organização (numa empresa de retalho será por exemplo
o registo de vendas, já numa empresa industrial será por exemplo o registo e a
produção de produtos) nos recursos de hardware disponíveis, adoptamos muitas vezes
1
Introdução
2
comportamentos reactivos na resolução do problema. Esta atitude, desprovida muitas
vezes, de um plano de acção, é extremamente ineficiente pois implica uma grande
perda de tempo e consequentes perdas financeiras.
A oferta de soluções comerciais ou directamente pelos fabricantes das bases de
dados para a monitorização do desempenho de uma base de dados é vasta. Temos
como exemplo o Oracle Enterprise Manager [2], o MonitorMagic Database
Monitoring[3] da Tools4ever[4] ou várias aplicações da Quest Software[5]. Contudo,
o funcionamento destas aplicações limita-se a avaliar o desempenho das bases de
dados ou dos sistemas, não explorando a relação entre as funcionalidades e conceitos
de negócio de uma aplicação, com os indicadores do desempenho físico da base de
dados. Por outro lado, baseiam-se em rácios tradicionais (rácio de utilização de dados
em memória rápida, métricas de velocidade de leitura de dados, entre outros) que
apenas nos fornecem informações sobre o estado global do sistema.
Prever o impacto e determinar de forma incisiva o processo e as instruções
responsáveis pelo fraco desempenho de uma funcionalidade, continua a ser uma tarefa
muito pouco trivial.
Foi com base neste contexto, que decorreu o projecto aqui descrito e através da
sua realização, foi possível criar uma aplicação de monitorização do desempenho
funcional de uma base de dados Oracle.
1.2 Objectivos Gerais
Este projecto teve como objectivos gerais a formação na tecnologia de base de
dados Oracle e o desenvolvimento de uma aplicação para análise e monitorização da
actividade funcional numa base de dados Oracle, doravante designada por BAM, que
permita:

Apresentar através de tabelas e gráficos e resultados obtidos na
inspecção ao funcionamento aplicacional de uma base de dados Oracle;

Identificar e analisar processos e eventos responsáveis pela degradação
de desempenho e obter e relacionar indicadores de negócio com
indicadores gerais dos recursos do sistema;
Introdução

3
Estimar o impacto da utilização de recursos baseados nos indicadores de
negócio;

Validar o funcionamento da BAM nos sistemas de informação cuja
manutenção é assegurada pela Truewind
1.3 Resumo do trabalho desenvolvido
O projecto arrancou com uma fase de aprendizagem na tecnologia Oracle. De
seguida foi-me introduzida a CMOS (Consola de Monitorização Operativa de
Sistemas) [6], uma aplicação interna do universo de ferramentas utilizada pela
Truewind nos projectos de monitorização de recursos. Nesta primeira fase ganhei
competências em bases de dados Oracle e nas técnicas de suporte utilizadas pela
Truewind nos projectos de administração e suporte de sistemas de informação.
Numa segunda fase, iniciou-se o desenvolvimento da BAM com um conjunto de
novas funcionalidades para a CMOS, nomeadamente com a resolução de problemas e
limitações que a CMOS possuía na apresentação dos indicadores, e na forma como os
obtinha, assim, foi alterado o motor interno da CMOS bem como a interface gráfica.
A BAM foi dotada de capacidade de apresentação de indicadores normais de
desempenho e carga, possibilitando ao mesmo tempo recolher e representar novos
indicadores que reflectem actividade em conceitos de negócio.
Depois desta fase de desenvolvimento a BAM foi colocada em funcionamento
num projecto de administração e suporte a bases de dados Oracle de um cliente da
Truewind. Aí foram detectados problemas ao nível da recolha de dados e indicadores
que levaram à execução de diversas correcções e melhoramentos.
Finalmente, depois de estabilizado o funcionamento da BAM, foram recolhidos
dados que permitiram detectar relações de causa-efeito interessantes que foram
apresentadas e que poderão auxiliar no planeamento de recursos em futuros projectos
de migração.
Introdução
4
1.4 Enquadramento institucional
Este projecto iniciou-se em Setembro de 2008 com uma fase de integração na
empresa Truewind – Tecnologias de Informação, S.A., que teve como objectivos dar a
conhecer a estrutura da empresa, as competências de cada unidade orgânica, bem
como os seus métodos de trabalho, as normas internas, a política de qualidade e toda a
documentação a ser produzida e utilizada no desenvolvimento de projectos.
A Truewind é uma empresa de Sistemas de Informação com fortes competências
nas áreas de desenvolvimento de software, formação, administração e suporte de
sistemas de informação, planeamento, gestão, acompanhamento e validação da
qualidade de projectos de informática.
A equipa de Consultores da Truewind é constituída por técnicos qualificados
com grande experiência, capazes de analisar a realidade e escolher as melhores opções
para as necessidades de cada projecto. O negócio da empresa está organizado em
quatro áreas de competência: desenvolvimento e suporte em tecnologia Java,
desenvolvimento em tecnologia Microsoft, suporte a tecnologia Oracle e
desenvolvimento e suporte em tecnologia OutSystems. De acordo com as políticas de
polivalência e relação aberta entre os responsáveis de projecto e os consultores, esta
divisão é informal e muitas vezes cruzada para poder oferecer aos clientes uma
verdadeira oferta global para as suas necessidades. Actualmente colaboram com a
Truewind cerca de 30 consultores nestas diferentes áreas.
O desenvolvimento do projecto ocorreu nas instalações da Truewind e nos seus
clientes, onde estive inserido numa equipa que presta serviços de suporte a múltiplos
ambientes e aplicações em tecnologia Oracle, que incluem: Bases de Dados, o ERP E-Business Suite, descrito mais adiante, bem como outras aplicações periféricas. O
número elevado de aplicações, com várias instâncias, distribuídas por múltiplos
servidores e ambientes, forneceu a contextualização ideal à concretização do projecto.
Introdução
5
1.5 Estrutura do relatório
O documento, após esta parte introdutória está organizado em quatro grandes
capítulos:

Capítulo 2: aprofunda o contexto subjacente ao projecto e apresenta o
planeamento do projecto e a metodologia empregue na sua concretização. É
também comparado o plano inicial de projecto (apresentado no relatório
preliminar) e o plano de execução real obtido, com uma análise aos desvios
ocorridos e às suas causas;

Capítulo 3: introduz as ferramentas e tecnologias utilizadas e apresenta a
arquitectura desenhada para a BAM;

Capítulo 4: descreve o trabalho que foi realizado face aos objectivos a nível
das funcionalidades, bem como os resultados alcançados com a BAM;

Capítulo 5: apresenta as conclusões do trabalho, com um resumo do trabalho
realizado, uma análise crítica e uma apresentação de possíveis trabalhos
futuros.
Introdução
6
Capítulo 2
Contextualização do Projecto
Neste segundo capítulo é feito um aprofundamento do contexto de execução do
projecto e dos objectivos a atingir com a sua execução. É também apresentada a
metodologia utilizada no seu desenvolvimento e realizada uma confrontação entre o
plano inicial do projecto e o plano real.
2.1 Contexto
O projecto iniciou-se com a integração na empresa. Ingressei desde logo na
equipa de administração e suporte a sistemas Oracle a qual é responsável por vários
projectos em diversas áreas de negócio: retalho alimentar, indústria, administração
pública e financeiro.
Nesta primeira fase, ganhei competência em operações de gestão e manutenção
da tecnologia Oracle e nas técnicas de suporte utilizadas pela Truewind nos projectos
de administração e suporte e que incluíram:

Instalação e configuração de software Oracle (base de dados e servidor
aplicacional);

Correcção de erros do software (através da instalação de patches);

Monitorização dos sistemas.
7
Contextualização do Projecto
8
O projecto onde fui inicialmente inserido desenvolveu uma plataforma de
compras electrónicas para a administração pública. Neste projecto e como parte da
minha formação inicial, desempenhei tarefas de manutenção, instalação e
configuração da infra-estrutura aplicacional e das bases de dados Oracle que lhe dão
suporte.
Numa segunda fase participei também num outro projecto na área do retalho
alimentar, com acções de migração e instalação de software para a solução de suporte
ao retalho, baseada no ERP [7] – Oracle E-Business Suite [8]. Nesta fase iniciei os
trabalhos de instalação e configuração da CMOS [6] para o ambiente tecnológico
deste cliente.
Com o início dos trabalhos de desenvolvimento da BAM fui integrado num
outro projecto num cliente da área da indústria aeronáutica. Aqui, a Truewind é
responsável pela gestão das bases de dados que dão suporte ao negócio desta empresa
e pelo sistema de salvaguardas. Trata-se de um ambiente tecnológico com oito bases
de dados que fazem parte de três ambientes distintos:

Ambiente de produção – composto por quatro bases de dados;

Ambiente de desenvolvimento – composto por duas bases de dados;

Ambiente de teste – composto por duas bases de dados
Além das tarefas regulares de manutenção das bases de dados, como são por
exemplo as tarefas de:

Monitorização do funcionamento;

Correcção de erros;

Gestão do espaço disponível;

Controlo de desempenho;

Configuração, gestão e recuperação de salvaguardas;

Reposições ou clonagens de bases de dados entre ambientes;
Realizei ainda múltiplas actualizações do software base da solução, para versões mais
actualizadas.
Contextualização do Projecto
9
Nas actividades em que participei, a definição dos recursos de hardware a
aplicar é normalmente baseada em dados imediatos que são obtidos a partir do estado
actual do sistema, não havendo na maior parte dos casos uma análise ou estudo acerca
da natureza dos dados e sua relação com o negócio da organização. Desta forma
dificilmente são obtidos dados que suportem a estimação ou a previsão da evolução
do desempenho do sistema de uma forma mais precisa e fiável. Um reflexo desta
realidade, é o facto de ser habitual o desconhecimento para a equipa de suporte, da
causa, em termos de negócio, que explica uma variação ou alteração evidente do
padrão de consumo médio dos recursos.
Esta ausência de conhecimento e suporte em dados do negócio para os valores
de dimensionamento dos recursos de infra-estrutura dos sistemas de informação, pode
provocar situações de desequilíbrio, com prejuízos evidentes para a organização. Se
por um lado, um dimensionamento superior ao necessário representa um custo
adicional muitas vezes pago para garantir a ausência de problemas, por outro lado, o
dimensionamento de recursos demasiado curto para a carga imposta pelo sistema,
pode dar origem a situações problemáticas de indisponibilidade ou manutenção
dispendiosa, com elevados custos para a organização.
Justifica-se assim, a criação de uma ferramenta que possibilite relacionar o
consumo de recursos da infra-estrutura física de suporte aos sistemas de informação,
com os conceitos de negócio.
Pretende-se adoptar uma postura preventiva, no sentido de ser possível prever o
estado para o qual o sistema avança ou os recursos por ele consumidos, tendo em vista
a sua optimização e uma antecipação relativamente a alterações que possam interferir
com os níveis de desempenho.
Contextualização do Projecto
10
2.2 Objectivos Específicos
Com base no contexto, requisitos e limitações já referidos, foi concebida a
BAM, uma ferramenta de monitorização da actividade funcional de uma base de
dados Oracle. A BAM tem por objectivo recolher e disponibilizar dados que permitam
relacionar a actividade e o negócio de organização no consumo de recursos e no
desempenho das bases de dados dos sistemas de informação.
Assumimos que, de facto, existe essa relação de causalidade e pretende-se
encontrar relações que permitam evidenciar que, por exemplo, o arranque de um
projecto ou aplicação numa empresa tem um impacto mensurável nos recursos que
são consumidos pelo sistema. A existência desta relação vai permitir estimar o custo,
em termos de recursos, de uma operação de negócio e desta forma prever os requisitos
necessários de uma configuração no arranque e na operação do sistema, de forma a
manter os níveis de desempenho pretendidos.
Assim, os objectivos delineados para o desenvolvimento do projecto foram:

Identificar e analisar processos e eventos responsáveis pela degradação
de desempenho e consumo de recursos de hardware;

Recolher indicadores gerais dos recursos do sistema, utilizando para tal
sempre que possível a CMOS e se necessário estender o seu
funcionamento;

Recolher indicadores de negócio, desenvolvendo estruturas que
permitam detectar e recolher o seu volume, crescimento e variação ao
longo de tempo;

Relacionar estes dois tipos de indicadores, para possibilitar a detecção de
correlações entre indicadores;

Apresentar de forma fácil e rápida os indicadores recolhidos;

Estimar o impacto na utilização de recursos de hardware com variações
nos indicadores de negócio;

Validar o funcionamento da BAM nos sistemas de informação cuja
manutenção é assegurada pela Truewind.
Contextualização do Projecto
11
2.3 Metodologia Adoptada
Para o desenvolvimento da BAM, foi adoptada a metodologia de
desenvolvimento em espiral [9] com várias iterações, incluindo um conjunto de
actividades que são executadas em ciclo até se atingir o objectivo definido.
Esta metodologia foi aplicada no desenvolvimento da BAM para reduzir os
riscos inerentes à realização de um projecto com requisitos e obstáculos incertos,
através da construção incremental do produto em desenvolvimento. Esta metodologia
promove a avaliação do protótipo alcançado, numa fase inicial do ciclo de vida do
projecto podendo assim, se necessário, tomarem-se as atitudes adequadas para alterar
o rumo do projecto, de forma a evitar o seu fracasso.
Cada ciclo desta metodologia é composto por uma fase de Análise, Desenho,
Implementação e Teste. A Figura 1 ilustra as fases da metodologia utilizada.
Figura 1. Metodologia de desenvolvimento em Espiral
Contextualização do Projecto
12
Na fase de especificação de requisitos foi realizada a análise das funcionalidades
a implementar na BAM, de forma a identificar os objectivos de cada ciclo de
desenvolvimento.
Na fase seguinte, e em diferentes iterações, foi efectuado o desenho da aplicação
e do modelo de dados que serve de estrutura de suporte à aplicação e que estendeu o
modelo de dados da CMOS.
Segue-se a fase de codificação onde, em cada iteração, é concretizado o desenho
realizado na fase anterior e todos os planos até então projectados. Esta fase
correspondeu ainda à concretização do modelo de dados e da implementação concreta
das alterações da CMOS para acomodar a BAM, através da criação de novas
estruturas de dados, e Scripts. A interface gráfica da CMOS foi remodelada (foram
adicionados novos elementos, e reestruturados elementos existentes). Foram criados
novos métodos e redesenhado o motor que permite à CMOS obter os dados para os
apresentar. Nesta fase foi também realizada a integração da BAM na CMOS.
O ciclo termina com uma fase de testes e avaliação de todos os componentes da
aplicação desenvolvidos, onde se desenrolaram um conjunto de demonstrações e
testes de usabilidade realizados a utilizadores alvo seleccionados.
De acordo com a metodologia adoptada pela empresa de acolhimento para o
desenvolvimento do projecto, que privilegiava a criação de um protótipo para
posterior refinamento, foram feitas duas iterações completas durante o período de
desenvolvimento do projecto cujo conteúdo e objectivos definidos são descritos na
secção que se segue.
Contextualização do Projecto
13
2.4 Plano de Execução
A execução do projecto decorreu em 4 fases. A Figura 2 apresenta o plano de
execução final do projecto, identificando as tarefas e sua duração.
Figura 2. Mapa de Gantt com o planeamento executado no projecto
De seguida é descrita em detalhe cada uma das fases de execução do projecto
identificadas na figura:
1ª Fase: Integração – Decorreu entre Setembro de 2008 e o final de Dezembro
de 2008 e compreende as actividades realizadas durante a fase inicial
do projecto. Teve início logo após a entrada na Truewind, com uma
tarefa de integração na empresa onde, para além da adaptação à
empresa e aos seus métodos de trabalho, foram definidos os objectivos
a atingir com a realização deste projecto. De seguida foram realizadas
duas tarefas onde foi realizado um estudo das ferramentas e tecnologias
a utilizar na implementação da BAM. Entre estas foi realizado o
relatório preliminar do projecto;
2ª Fase: 1ª Iteração de Desenvolvimento da Aplicação – Decorreu entre
Fevereiro de 2009 e Março de 2009 e compreendeu o desenvolvimento
da BAM com a primeira iteração realizada no desenvolvimento num
cliente. Incluiu as actividades de análise, desenho, implementação,
integração e teste do protótipo desenvolvido; Nesta fase foram criadas
as primeiras estruturas dados de recolha e repositório da BAM e feita a
primeira integração da BAM na CMOS.
Contextualização do Projecto
14
3ª Fase: 2ª Iteração de desenvolvimento da Aplicação – Decorreu desde Junho
de 2009 até ao final de Agosto de 2009 – Esta iteração, já envolvida
noutro projecto da Truewind, também envolveu o desenvolvimento da
BAM. Tal como a anterior, foi também constituída pelas cinco fases
referidas no subcapítulo anterior; Nesta fase foi ajustada a primeira
versão do modelo de dados e componentes da arquitectura do
protótipo. Foram ainda configuradas mais recolhas de dados. Também
foi melhorada a interface gráfica da BAM.
4ª Fase: Conclusão do projecto – Decorreu durante o mês de Setembro de 2009
onde foi elaborado o relatório final do projecto.
Relativamente à duração e ao conteúdo das duas iterações de desenvolvimento
da BAM realizadas, importa aprofundar aspectos que determinaram a configuração
temporal obtida.
A 2ª fase que correspondeu à 1ª iteração do desenvolvimento da BAM, iniciouse com a definição das funcionalidades a serem suportadas pela BAM, feita com base
na análise realizada na 1ª fase do projecto. Seguidamente e entrando nas actividades
de desenho e implementação, foram criadas as estruturas de dados que dão suporte à
BAM e desenvolvido um conjunto de funcionalidades que permitiram a criação de um
protótipo, que forneceu os primeiros resultados. Previamente foi necessário um
período de estudo e análise da arquitectura da CMOS, bem como a realização de
testes, de forma a concretizar as alterações necessárias quer a nível de interface, quer
a nível de funcionamento interno, com o objectivo de integrar a BAM na CMOS. Esta
versão da BAM integrada na CMOS foi instalada num cliente da Truewind do ramo
do retalho alimentar.
A 3ª fase que correspondeu à 2ª iteração do desenvolvimento da BAM surge
após um período de interrupção nos trabalhos e teve o seu início com a instalação da
BAM num outro cliente, para que, desde logo, fosse possível colocar em marcha os
processos de recolha de dados. Após a preparação deste novo ambiente de
desenvolvimento, foi então possível dar início à 2ª iteração.
Nesta 2ª iteração, a fase de implementação iniciou-se com a criação de novas
funcionalidades e melhoramento de outras existentes, adição de novas tabelas à base
de dados e criação de mais sondas para recolha de dados.
Contextualização do Projecto
15
A interface da CMOS foi alvo de uma reestruturação de modo a apresentar mais
informação, mais legível e organizada. O próprio funcionamento interno da CMOS foi
igualmente reestruturado.
Esta fase termina com os testes do protótipo desenvolvido e com a análise crítica
dos resultados obtidos.
Relativamente ao planeamento inicial, apresentado na Figura 3, e comparando
com o plano executado na Figura 2, há duas situações de desfasamento significativo
entre os dois que são evidentes.
Figura 3. Plano inicial do projecto
Estas duas situações foram em grande parte responsáveis pelo desfasamento
relativamente ao planeamento inicial ocorrido.
O período de integração e auto-formação foi mais demorado devido ao carácter
inovador e não familiar das tecnologias com as quais tive contacto inicialmente.
Nesta fase tive a oportunidade de participar num projecto no qual partilhei
responsabilidades na construção de uma infra-estrutura para uma plataforma de
compras electrónicas para a administração pública. Neste projecto foi adoptada a nova
versão do ERP Oracle E-Business Suite, a versão 12 [10], com a qual nenhum dos
elementos da equipa de projecto tinha ainda tido contacto. Para a construção desta
plataforma foi definida uma arquitectura assente em ambientes virtualizados [11]. Foi
um processo bastante demorado, não só, pelo carácter inovador, mas também pela
ausência de informação disponível relativamente às tecnologias usadas que obrigou a
a várias actividades de pesquisa para a resolução de problemas encontrados.
Estas condições e a integração na equipa, conduziram ao atraso do arranque da
primeira iteração do desenvolvimento da BAM, implicando que esta tivesse o seu
início não em Outubro, como estava previsto, mas apenas em Fevereiro.
Contextualização do Projecto
16
A segunda situação ocorre após a conclusão da 1ª iteração, onde por motivos
profissionais e de acordo com as responsabilidades assumidas perante a empresa de
acolhimento, trabalhei durante cerca de 2 meses num projecto, onde não me foi
possível prosseguir o desenvolvimento da BAM fazendo com que o inicio da 2ª
iteração apenas fosse concretizado em meados de Junho.
Capítulo 3
Tecnologia e Arquitectura
Este capítulo apresenta e descreve os sistemas base do projecto, as ferramentas e
tecnologias utilizadas durante a sua execução. É também apresentada a arquitectura da
solução implementada e uma secção sobre tecnologia relacionada.
3.1 Plataforma de Base
3.1.1 Base de dados Oracle
A BAM incidiu na recolha de indicadores de funcionamento de sistemas com
bases de dados Oracle. Interessa pois, apresentar em maior detalhe este componente
base dos sistemas de informação abordados no âmbito da BAM e que esta utiliza
também como repositório.
A base de dados Oracle [12] consiste num Sistema de Gestão de Base de Dados
(SGBD) baseado no modelo relacional. Na Figura 4 é apresentada a arquitectura de
uma base de dados Oracle, versão 10g Release 2 (versão utilizada no âmbito deste
projecto):
17
Tecnologia e Arquitectura
18
Figura 4. Arquitectura da base de dados Oracle versão 10g [13]
Uma base de dados Oracle é representada por uma instância - Oracle Instance,
composta por um conjunto processos e estruturas que são carregadas em memória
quando a base de dados é iniciada. O conjunto destas estruturas denomina-se por
System Global Area (SGA). Esta contém um conjunto de dados e informação de
controlo acerca de uma instância.
A informação armazenada na SGA divide-se em três estruturas de memória
[14]:

Database buffer cache: Esta componente armazena os blocos de dados que
foram utilizados mais recentemente, de forma a optimizar o desempenho
através de uma redução nos processos de Input/Output para o disco, onde os
dados estão armazenados;

Redo log buffer: Esta estrutura regista um conjunto de entradas descritivas
das alterações efectuadas na base de dados. Estas entradas são
posteriormente escritas num online redo log para, no caso de ser necessário,
recuperar informação relativa aos dados armazenados na base de dados;
Tecnologia e Arquitectura

19
Shared pool: Esta componente contém conjuntos de memória partilhada,
como por exemplo uma área para processar comandos SQL submetidos para
a base de dados. Esta área é partilhada por múltiplas aplicações que utilizam
funcionalidades idênticas, de forma a optimizar recursos.
Outro componente da Oracle Instance são os Oracle background processes
[14]. Estes consistem em processos de sistema operativo que operam também ao nível
da memória e visam suportar o acesso concorrente de vários utilizadores e aplicações
a uma única base de dados. Realizam ainda, operações de Input/Output de forma
assíncrona e monitorizam outros processos para um aumento do paralelismo, gerando
assim um melhor desempenho e fiabilidade da base de dados.
A instância Oracle é responsável por abrir e gerir uma base de dados – Oracle
Database [15]. Esta possui um conjunto de estruturas físicas que armazenam dados e
um conjunto de informação relativa às suas configurações. Entre estas estruturas
temos:

Datafiles: ficheiros físicos que contêm estruturas de dados, como por
exemplo tabelas e índices;

Control Files: ficheiros que armazenam um conjunto de informação relativa
à configuração de uma instância de base de dados, como por exemplo: o
nome da base de dados, localização dos datafiles e redo logs, timestamp de
criação da base de dados, números de alteração, entre outros;

Redo Log Files: conjunto de ficheiros que protege a informação da base de
dados alterada em memória e que ainda não foi escrita nos datafiles;

Archive Log Files: ficheiros armazenados em disco, que arquivam a
informação contida nos redo logs e que podem ser usados para recuperação
de uma base de dados;

Password File: ficheiro que permite a um utilizador com privilégios de
administrador de base de dados conectar-se remotamente à instância que
administra;
Tecnologia e Arquitectura

20
Parameter File: ficheiro que contém o conjunto de parâmetros de
configuração da instância e base de dados. Estes parâmetros incluem,
identificação da base de dados, dimensão em memóra das principais
estruturas e configurações específicas que condicionam o funcionamento dos
vários componentes da base de dados (dos processos de escrita da base de
dados em disco ou do optimizador de interrogações em SQL por exemplo).
Numa configuração típica, uma base de dados Oracle terá os seguintes ficheiros:

Um Parameter File e um Password File que definem os parâmetros da
base de dados;

Dois Control Files para garantir a redundância;

Três grupos de Redo Log cada um com dois membros para garantir a
redundância que quando são preenchidos são copiados para arquivo
(Archive Log Files);

Múltiplos Datafiles onde são armazenados os dados dos esquemas da
base de dados (tipicamente aos pares: dados e índices em separado)
Para além destas estruturas físicas, uma base de dados Oracle possui também um
conjunto de estruturas lógicas [14]. A separação destas estruturas permite que o
armazenamento físico dos dados (nos datafiles) possa ser gerido sem que isto afecte o
acesso às estruturas lógicas, representadas pelos objectos de base de dados contidos
num tablespace (unidade de armazenamento que agrupa estruturas lógicas
relacionadas). É sobre esta unidade lógica que são criados os objectos das aplicações
(tabelas, índices, etc.)
3.1.2 Oracle EBS (E-Business Suite)
O Oracle E-Business Suite [8] consiste numa colecção de aplicações de
Planeamento de Recursos Empresariais, Gestão de Relacionamento com Clientes e
Gestão de Cadeia de Fornecimento, que proporcionam processos de gestão da
informação permitindo conectar e informatizar as organizações.
Tecnologia e Arquitectura
21
A arquitectura geral do OEBS (Figura 5) inclui uma base de dados Oracle, um
conjunto de funções de negócio implementadas em PL/SQL, uma interface WEB que
poderá ser um navegador de internet e uma camada aplicacional constituída por três
grandes componentes:

Formulários (Forms) que invocam a lógica de negócio no PL/SQL e
implementam também lógica aplicacional de controlo;

Relatórios (Reports) e programas concorrentes (Concurrent Programs) que,
directamente sobre a base de dados ou através da lógica de negócio em
PL/SQL, recolhem, apresentam e manipulam informação;

Motor de processamento concorrente (Concurrent Processing) que gere as
prioridades e execução de relatórios e programas.
Figura 5. Arquitectura da Oracle E-Business Suite
A base de dados sobre a qual assentam estas aplicações materializa, armazena e
gere todos os conceitos de negócio envolvidos nas suas operações. Estes conceitos de
negócio envolvem, entre outras, operações de compra, venda, classificação, entrega,
contabilização, gestão de inventário entre muitos outros.
A interface é a camada que permite a apresentação de informação e através da
qual o utilizador interage com o sistema.
Tecnologia e Arquitectura
22
Por se tratar de um sistema plenamente integrado, a manipulação de cada
conceito de negócio não se resume à alteração de apenas uma ou duas tabelas, existe
todo um conjunto de tabelas e estruturas agregadas que são acedidas e alteradas no
decorrer de cada operação.
3.1.3 SNMP
O SNMP (Simple Network Management Protocol) [16] é um protocolo, que
define um mecanismo de recolha de informação sobre o estado e funcionamento de
dispositivos (hardware/software) ligados em rede.
Hoje em dia, muitos periféricos e peças de software base de suporte a sistemas
de informação (como sistemas operativos ou sistemas de gestão de base de dados)
permitem a recolha de indicadores através deste protocolo.
Os indicadores suportados estão listados, sob a forma de objectos com um
identificador numérico único, em várias MIB (Management Information Base). A
MIB pode ser considerada como uma base de dados que lista os indicadores
suportados por um determinado dispositivo, seja ele físico (hardware) ou lógico
(software), existindo várias MIB, algumas genéricas e outras específicas de um
determinado dispositivo ou fabricante.
No âmbito deste projecto, a utilização do SNMP é determinante para obter
indicadores do funcionamento e consumo de recursos de hardware da infra-estrutura
física, como por exemplo o nome de um servidor, ou o nível de carga do processador.
A versão inicial deste protocolo é definida no RFC 1157 [17] onde é introduzido
o seu funcionamento base que envolve a troca de mensagens entre entidades que
inclui um protocol data unit (PDU) e que constitui o próprio pedido e resposta tal
como ilustrado na Figura 6 [18]. Novas versões deste protocolo têm sido
disponibilizadas, onde foram introduzidas as MIB e onde foram incluídas novas
funções de segurança como por exemplo autenticação e cifra de pacotes enviados.
Tecnologia e Arquitectura
23
Figura 6. Mensagem do protocolo SNMP [18]
3.1.4 CMOS
A CMOS [6] é uma consola de monitorização que permite o armazenamento de
informação sobre o estado dos sistemas e posterior análise dessa informação sobre a
forma de gráficos, possibilitando uma melhor análise do funcionamento dos sistemas
e a prevenção de eventuais problemas.
A CMOS possui três componentes principais tal como ilustrado pela Figura 7:
Figura 7. Arquitectura da Consola de Monitorização com os vários componentes [6]

Recolha e Processamento de Dados: a recolha é suportada pelo protocolo
SNMP que fornece a informação básica sobre o estado da máquina e por
interrogações SQL que permitem obter informação sobre os aspectos de
funcionamento de uma base de dados;

Armazenamento de Dados: o armazenamento de dados para posterior análise é
Tecnologia e Arquitectura
24
conseguido através de uma base de dados na qual é guardada a informação
recolhida pelo componente descrito em cima;

Interface com o Utilizador: este componente permite aos utilizadores
consultarem a informação que está armazenada na base de dados através de
uma interface Web. O utilizador para realizar esta consulta selecciona um
indicador (utilização de CPU, memória, etc.) e o período no qual pretende
realizar a análise. O resultado é exibido através de um gráfico no qual é
possível verificar os valores do indicador correspondente à pesquisa realizada.
O funcionamento da CMOS baseia-se na recolha de indicadores e na
apresentação da sua variação através de gráficos, não sendo possível relacionar a
análise da informação dos indicadores facultados com outros indicadores.
Pretende-se com a BAM utilizar a CMOS para fornecer indicadores simples que
serão depois conjugados com indicadores provenientes de conceitos de negócio
preparados pela BAM. Assim será possível identificar e relacionar o motivo pelo qual
existem variações na utilização de recursos. A BAM tenta estender a CMOS ao
introduzir uma componente relacional, que irá permitir obter informação mais
relevante e detalhada sobre o estado do sistema através da análise do desempenho,
relacionando-a com operações de negócio realizadas.
Tecnologia e Arquitectura
25
3.2 Tecnologias Utilizadas no Desenvolvimento
3.2.1 PHP
A linguagem PHP [19] é uma linguagem de programação indicada para o
desenvolvimento em tecnologia Web para produzir páginas HTML dinâmicas.
No âmbito deste projecto é utilizada para realizar o processamento de ficheiros
XML, executar interrogações à base de dados e construir o ficheiro em XML que
representa um gráfico.
Na Figura 8 é apresentado um método desenvolvido em PHP para simplificar a
impressão de mensagens de depuração.
function print_debug($error_string){
$fh = fopen("/home/oracle/oms/debug/debug.txt",'a');
fwrite($fh,strftime('%c')." - ".$error_string."\n");
fclose($fh);
}
Figura 8. Método de impressão de mensagens de depuração desenvolvido em PHP
3.2.2 JavaScript
O Javascript [20] é uma linguagem de programação utilizada em páginas Web
principalmente para execução de código do lado do cliente. É utilizada na validação
de formulários e permite a construção de interfaces gráficas avançadas e Websites
dinâmicos.
Na BAM o Javascript desempenha um papel fulcral, pois é responsável pela
construção dinâmica do formulário de consulta, pela gestão e tratamento dos
parâmetros introduzidos pelo utilizador e pela apresentação dos resultados obtidos.
Na Figura 9 é apresentado um método desenvolvido em Javascript para geração
de gráficos.
Tecnologia e Arquitectura
26
function generateGraph(data,id,chartType) {
var chart = new FusionCharts("../libs/fusioncharts/"+chartType,
"chart1", "850", "600", "0", "0");
chart.setDataURL(data);
chart.render(id);
}
Figura 9. Método desenvolvido em Javascript para geração de gráficos
3.2.3 SQL
O SQL [21] é a linguagem estruturada de pesquisa utilizada para a obtenção e
gestão de dados numa base de dados relacional.
Esta linguagem está presente na codificação das interrogações desenhadas para
obter os indicadores da BAM, sobre o modelo de dados da aplicação. A Figura 10
apresenta uma interrogação em SQL cuja função é a obtenção da média diária de
consumo de memória virtual sobre o modelo de dados da BAM.
SELECT timestamp ,hostname, swap_used
FROM (SELECT dados.dia timestamp ,dados.hostname
hostname,round(avg(swap_used)) swap_used
FROM (SELECT to_date(timestamp,'dd-mm-rrrr') dia,
hostname,swap_used
FROM prx_ind_3
WHERE to_date(timestamp,'dd--mm-yyyy') =
to_date(sysdate,'dd-mm-yyyy')
) dados
GROUP BY dados.dia,dados.hostname
ORDER BY 1 DESC
Figura 10. Interrogação em SQL para obtenção da média diária de consumo de memória virtual
sobre o modelo de dados da BAM
3.2.4 XML
O XML [22] consiste numa recomendação da W3C para linguagem de marcação
livre, que permite aos seus utilizadores definirem as suas próprias estruturas. Estas
podem posteriormente ser lidas por software e integradas com outras linguagens [22].
No âmbito deste projecto o XML foi utilizado para armazenar as interrogações
base em SQL e também para a definição de gráficos com os resultados obtidos como é
exemplificado na Figura 11 que apresenta o conteúdo de um ficheiro XML utilizado
Tecnologia e Arquitectura
27
para a geração de um gráfico que exprime a variação da média diária do nível de
carga do processador.
<chart caption="Load (%)"
animation="0"
labeldisplay="rotate"
labelstep="4"
lineThickness="2"
showValues="0"
yAxisMinValue="0"
yAxisMaxValue="100">
<set label='03-SEP-2009 00:00' value='1'/>
<set label='04-SEP-2009 00:00' value='1'/>
<set label='05-SEP-2009 00:00' value='1'/>
</chart>
Figura 11. Conteúdo de um ficheiro XML representativo de um gráfico
3.2.5 Shell Scripts
A linha de comandos do Sistema Operativo Linux (Shell) [23] é uma ferramenta
poderosa para o utilizador, que pretende interagir directamente com o sistema para
executar comandos, recolher dados e processar de forma automática a informação
recolhida.
No contexto da BAM, conjuntos de instruções (Shell Scripts) executam
comandos para obter dados SNMP e interagir directamente com a base de dados
Oracle através de comandos SQL, tendo em vista a recolha e armazenamento de
dados de indicadores.
3.2.6 Fusion Charts
A Fusion Charts [26] é uma biblioteca open-source em tecnologia Flash [27]
que permite a geração de gráficos dinâmicos e interactivos a partir de uma
representação XML dos dados. Na BAM, os ficheiros de XML são construídos a
partir dos dados armazenados na base de dados, através de rotinas em PHP. A criação
do gráfico é também feita através da invocação de uma rotina PHP (que acompanha a
biblioteca de gráficos) com os dados dos ficheiros XML.
Tecnologia e Arquitectura
28
3.3 Arquitectura da BAM
A Figura 12 apresenta um diagrama com a arquitectura da BAM a qual é
constituída por dois grandes componentes:

Motor de Recolha de Dados

Motor de Análise
Estes dois componentes interagem com a CMOS para alcançar o objectivo de
fornecer uma aplicação de análise e monitorização avançada.
Figura 12. Arquitectura do Sistema
Tecnologia e Arquitectura
29
3.3.1 Motor de Recolha de Dados
Este componente é composto por outros dois sub-componentes, recolha de
dados das tabelas e monitorização de operações do negócio:

recolha de dados das tabelas, que será baseada em interrogações sucessivas
a vistas de dados estatísticos que fornecem informação sobre a actividade
das tabelas. O objectivo será determinar quais as tabelas que apresentam
maior actividade;

monitorização das operações de negócio, que consiste no registo e
relacionamento entre as operações de negócio que estão a ser realizadas
em cada momento. Os dados aqui recolhidos serão armazenados numa
base de dados.
O motor de recolha de dados apresenta ainda um conjunto de sondas que permite aos
dois sub-componentes concretizarem as operações de recolha através da execução de
sondas que realizam interrogações em SQL e pedidos de SNMP. Uma descrição mais
detalhada das sondas encontra-se na Figura 21 da página 50.
3.3.2 Motor de Análise
O componente de análise é responsável pelas operações relacionais sobre os
dados recolhidos pelo componente de recolha. Subdivide-se em dois subcomponentes:

um componente que trabalha directamente sobre os dados fornecidos pela
recolha, relacionando as tabelas que apresentam maior actividade com as
operações do negócio realizadas. Tornando assim possível determinar
quais as tabelas utilizadas numa operação do negócio. Os dados aqui
obtidos são guardados numa base de dados;

outro componente, que é responsável por relacionar os dados de
indicadores já recolhidos pela CMOS (utilização de processador, espaço
ocupado em disco, etc.) com as operações de negócio realizadas. O
cruzamento destes dados irá permitir quantificar o custo das operações de
Tecnologia e Arquitectura
30
negócio e elaborar relatórios com essa informação.
Os resultados aqui obtidos são disponibilizados para consulta através da
interface Web.
Procurou-se com esta arquitectura modular estender a sua aplicação focando-a
na análise de sistemas empresariais baseados em Oracle E-Business Suite. Por se
tratar de um sistema genérico, a identificação do conjunto das estruturas de dados que
são envolvidas numa operação do negócio da E-Business Suite será transversal a
múltiplos clientes da Truewind que utilizem os mesmos módulos. Desta forma, a
utilização desta aplicação poderá ser facilmente alargada, com a alteração mínima de
alguns parâmetros de configuração. Exemplos destas operações de negócio são, no
caso de uma empresa de retalho alimentar, as vendas de produto registadas por cada
vendedor. Já no caso de se tratar de uma empresa industrial, a actividade de criação ou
manutenção de um bem ou produto e dos registos de entrada e saída de material para a
manufactura.
No próximo capítulo, que descreve o trabalho realizado, são apresentados os
detalhes de implementação desta arquitectura.
3.3.3 Integração de Sistemas
Tal como indicado na Figura 12, a integração da BAM na CMOS é conseguida
de duas formas:

Através da base de dados da CMOS, preparada para armazenar a
informação recolhida directamente pela BAM;

Através da camada de acesso a dados, que consiste num conjunto de
métodos
em
Javascript
responsáveis
por
tratar
os
eventos
desencadeados na interface WEB, enviando-os para a CMOS ou para a
BAM (motor de análise), de acordo com o tipo de evento. O envio
destes pedidos desencadeia por sua vez uma execução de funções PHP
que extraem a informação necessária à geração de gráficos (ficheiros
XML). A camada de acesso a dados, ao receber as respostas aos
Tecnologia e Arquitectura
31
pedidos, encaminha-as para a interface WEB, que exibe os gráficos para
consulta.
3.4 Tecnologia Relacionada
No universo das aplicações de monitorização, administração e avaliação do
desempenho de bases de dados, existe um grande leque de soluções, criadas com o
objectivo de auxiliar o administrador da bases de dados na obtenção de configurações
cada vez mais adequadas e optimizadas para dotar os sistemas de capacidade para
fazer face aos requisitos de desempenho cada vez mais exigentes e determinantes no
sentido de garantir o bom funcionamento dos sistemas de informação. Nas próximas
secções são apresentadas algumas das soluções que foram avaliadas no âmbito do
projecto.
3.4.1 Oracle Enterprise Manager – OEM
Comercializado pela Oracle, o Oracle Enterprise Manager [2] é uma aplicação
para a gestão/administração/monitorização de bases de dados e respectivas infraestruturas aplicacionais desenvolvida pelo próprio fabricante do sistema gestor de
base de dados.
O OEM permite uma gestão completa das bases de dados, desde a criação de
modelos de dados à monitorização da actividade e dos serviços activos, detecção de
potenciais problemas, bem como a definição de tarefas de administração para a
resolução dos problemas encontrados.
A Figura 13 apresenta o aspecto do ecrã de administração da aplicação para
gestão e monitorização da instância de base de dados.
Tecnologia e Arquitectura
32
Figura 13. Vista de Administração do OEM [2]
3.4.2 Monitor Magic – Database Monitoring
A ferramenta Database Monitoring [3] é um módulo da ferramenta de gestão e
monitorização de sistemas denominada Monitor Magic. O Database Monitoring
dedica-se exclusivamente à monitorização e gestão de bases de dados e suporta a
criação de alarmes e eventos que são desencadeados com o aparecimento de
anomalias (através da análise dos registos), em situações definidas pelo utilizador ou
quando limites definidos são ultrapassados (tanto ao nível da base de dados como de
recursos de hardware). Através de comandos SNMP recolhe valores de objectos da
base de dados para depois exibi-los através de uma interface gráfica.
A Figura 14 apresenta a vista de alarmística desta aplicação.
Tecnologia e Arquitectura
33
Figura 14. Monitor Magic Database Monitoring [3]
3.4.3 Quest Database Management
A Quest Software [5], apresenta um vasto leque de opções no que diz respeito a
soluções de gestão e administração de bases de dados, com especial foco na gestão e
monitorização. Nesta área existem duas aplicações, o Spotlight, que se dedica
exclusivamente à detecção e resolução de congestionamentos na base de dados e o
Foglight, cujo foco é a monitorização e gestão do desempenho de uma base de dados.
A Figura 15 apresenta a vista geral da aplicação Spotlight, que permite
visualizar onde estão localizados os problemas de performance.
Tecnologia e Arquitectura
34
Figura 15. Spotlight - Quest Software [5]
3.4.4 Primos Database Monitoring
Apresenta-se como sendo “uma ferramenta desenhada para fornecer a
informação mais importante para controlar a base de dados” o Primos Database
Monitoring [28] é mais uma ferramenta para auxiliar o administrador da base de
dados nas suas rotinas diárias.
Criada por administradores de bases de dados, tenta reunir, numa única
ferramenta, as funcionalidades e informação que os seus criadores consideram ser as
fundamentais para que a administração das bases de dados possa ser realizada de
forma correcta e eficiente.
A figura 16 apresenta a interface que mostra as interrogações que foram
executadas em maior número.
Tecnologia e Arquitectura
35
Figura 16. Primos Database Monitoring [28]
3.4.5 Ignite for Oracle Performance
O fabricante Ignite direcciona a sua atenção para as questões relacionadas com o
desempenho das bases de dados tendo desenvolvido o Oracle Performance [29] cujo
objectivo é a procura e resolução, de forma célere dos problemas de desempenho de
uma base de dados. Através da análise das interrogações SQL realizadas na base de
dados e no tempo que estas levam a executar, esta ferramenta permite identificar e
analisar o fragmento de código responsável por uma perda de desempenho.
A Figura 17 apresenta a vista de análise de expressões em SQL, a qual permite
visualizar quais as expressões e o tempo que esteve envolvido durante a sua execução.
Tecnologia e Arquitectura
36
Figura 17. Ignite for Oracle Performance [29]
3.4.6 Oracle Business Activity Monitoring
De todas as tecnologias que tive oportunidade de observar, a que mais se
aproxima da BAM, seja em nomenclatura seja em funcionalidade é a aplicação Oracle
Business Activity Monitoring - BAM [24], que se apresenta como “uma solução
completa para a construção de painéis interactivos em tempo-real que fornecem
alertas pró-activas relativamente à monitorização de serviços e processos de negócio”
[24].
Apesar do nome semelhante e de uma definição que sugere funcionalidades
igualmente semelhantes, a Oracle BAM difere largamente dos objectivos deste
trabalho. Esta é uma aplicação de larga escala e de grande dimensão, preparada para
cálculos complexos com o objectivo de analisar e optimizar processos de negócio.
Não abrange contudo, questões como a degradação do desempenho do sistema nem a
relação desta com os processos de negócios. A aplicação desenvolvida no âmbito
deste projecto, por outro lado, foca o seu âmbito na monitorização e análise dessas
relações por forma a obter dados que possam permitir compreender e prever a
degradação do desempenho.
Tecnologia e Arquitectura
37
Na Figura 18 está representada uma imagem da interface da Oracle BAM.
Apresenta quatro painéis distintos, cada um deles com diferentes propósitos. Os
gráficos que podemos observar nesses painéis exprimem informação sobre a evolução
do negócio de um centro de contactos. A informação disponível diz respeito à
quantidade de chamadas num período de tempo, à quantidade de chamadas de por
região, etc., apesar de ser informação importante para a optimização do negócio, não é
explorada a forma como este afecta o desempenho do sistema.
Figura 18. Interface gráfica Oracle BAM [24]
Trata-se pois de um ambiente e enquadramento distintos pois a Oracle BAM,
devido à sua dimensão e complexidade é necessariamente muito exigente a nível de
recursos, físicos e também financeiros.
3.4.7 Análise Comparativa
Todas as soluções avaliadas, com a excepção da Oracle BAM, são ferramentas
típicas de gestão e administração de bases de dados ao nível técnico. Estas
ferramentas permitem uma gestão e administração das instâncias de bases de dados
Tecnologia e Arquitectura
38
que se exigem cada vez mais rigorosas e eficientes. No entanto, as funcionalidades e o
tipo de informação que disponibilizam, de uma forma geral, pouco difere de
ferramenta para ferramenta.
A BAM, por sua vez, além de recolher e apresentar indicadores comuns de
desempenho (consumo de processador, consumo de memória), recolhe dados
funcionais que quando conjugados permitem de forma limitada obter o impacto que as
operações de negócio têm no desempenho da base de dados. A Tabela 1 resume as
principais características das soluções avaliadas.
Solução
Pontos Fortes
Pontos Fracos
Oracle Enterprise
Manager – OEM
- Ferramenta plenamente
integrada na tecnologia
- Fornece apenas análises técnicas
- Vasto leque de análises
Monitor Magic –
Database
Monitoring
- Reduzida funcionalidade na previsão
de necessidades futuras de recursos
- Possibilidade de configurar
alarmes e acções automáticas
para problemas
- Interface pouco amigável nalguns
módulos
- Criação de alarmes e eventos de
acordo com limites prédefinidos ou definidos pelo
administrador
- Informação limitada sobre
funcionamento geral da base de
dados
- Notificação de erros críticos
- Reduzida funcionalidade na previsão
de necessidades futuras de recursos
- Interface pobre
Quest Database
Management
- Fornece informação detalhada
relativamente ao
congestionamento e ao
desempenho de bases de dados
- Interface bem construída
Primos Database
Monitoring
Ignite for Oracle
Performance
- Não relaciona os problemas que
encontra com o tipo de negócio do
sistema que monitoriza.
- Reduzida funcionalidade na previsão
de necessidades futuras de recursos
- Integração com vários sistemas
de gestão de bases de dados
(Oracle, SQLserver, etc)
- Licenças dispendiosas
- Identificação de situações
críticas
- Reduzida informação no consumo de
recursos Hardware
- Sugestão de resolução para
alguns problemas
- Suporte restrito a bases de dados
Oracle
- Análise integrada de várias
bases de dados
- Identificação de problemas de
desempenho limitado a análise de
expressões em SQL
- Informação detalhada sobre
constrangimentos no
desempenho da base de dados
- Foco da aplicação limitado ao
desempenho das bases de dados
- Interface simplista e atractiva
- Reduzida funcionalidade na previsão
de necessidades futuras de recursos
Tecnologia e Arquitectura
Oracle Business
Activity - BAM
39
- Monitorização de serviços e
processos de negócio
- Análise limitada à optimização de
processos de negócio
- Infra-estrutura de alarmística
avançada
- Exigente a nível de requisitos
Hardware
- Interface avançada, reunindo
informação necessária de forma
lógica e organizada
- Licenças dispendiosas
Tabela 1. Comparativo de soluções
Tecnologia e Arquitectura
40
Capítulo 4
Trabalho Realizado
Este capítulo descreve o trabalho realizado ao longo do projecto, as principais
dificuldades encontradas na sua execução bem como os resultados alcançados.
Inicialmente é feita uma descrição das tarefas realizadas na fase de preparação do
projecto. De seguida será feita uma descrição das tarefas mais relevantes realizadas a
nível da identificação dos requisitos, desenho, implementação e testes realizados à
BAM. Finalmente são apresentados os principais resultados alcançados.
4.1 Preparação do Projecto
O início do projecto teve lugar nos escritórios da Truewind onde ocorreu a
integração na equipa de administração de sistemas de informação e onde foram
definidas e atribuídas as primeiras tarefas de aprendizagem e a familiarização com a
tecnologia Oracle (base de dados, servidor aplicacional e ERP E-Business Suite).
Este foi um período de autoformação no qual tive oportunidade de ter contacto
com a tecnologia e de pôr em prática alguns conceitos e procedimentos aprendidos
através de tarefas de instalação e configuração de bases de dados Oracle e do ERP EBusiness Suite.
Paralelamente, e tendo em vista os objectivos delineados para a BAM, foi
realizado um trabalho de pesquisa de soluções existentes que de alguma forma
concretizassem as funcionalidades previstas para a BAM.
41
Trabalho Realizado
42
No decorrer desta etapa foi também realizado um estudo informal do
funcionamento da CMOS no qual foi possível perceber quais as funcionalidades desta
consola. Esta actividade iniciou-se com a passagem de conhecimento do autor da
CMOS e de toda a informação disponível acerca do trabalho. Como já existia um
ambiente de desenvolvimento preparado e estruturado, foi possível a transmissão
rápida e assistida dos desenvolvimentos ocorridos. A assimilação desta infra-estrutura
foi rápida o que permitiu realizar um conjunto de testes que consistiram na alteração
do código fonte da CMOS, quer a nível de interface gráfica, quer a nível do seu motor
interno, de forma a conseguir um melhor entendimento das suas características.
4.2 Definição dos Requisitos da BAM
Após a etapa de preparação, foi iniciado o desenvolvimento da BAM. Este
processo iniciou-se com uma fase de recolha e identificação dos requisitos estruturais
e funcionais da BAM. O conjunto de requisitos foi definido com base na análise
realizada inicialmente e com os responsáveis da empresa de acolhimento num
conjunto de reuniões, nas quais ficaram estabelecidos de forma informal os objectivos
detalhados da BAM. Depois desta análise seguiu-se a identificação dos requisitos
estruturais e funcionais:

Estruturais: definiram a estrutura de dados responsável por dar suporte e
armazenar a informação gerida e recolhida pela BAM; Optou-se por
suportar o repositório de dados da BAM numa base de dados Oracle e
utilizar o sistema operativo Linux como sistema base para a recolha de
indicadores de infra-estrutura física (servidores).

Funcionais: focaram-se na definição das funcionalidades a serem
suportadas pela BAM. Esta tarefa foi fundamental para clarificar
exactamente as funções a criar para atingir os objectivos estabelecidos
inicialmente; Pretendia-se com a BAM recolher indicadores com base
nos conceitos de negócio e relacioná-los com os indicadores recolhidos
da infra-estrutura.
Trabalho Realizado
43
O refinamento dos requisitos definidos inicialmente foi realizado em duas
iterações. Na primeira foi dada maior atenção à obtenção de uma estrutura de
armazenamento e aos requisitos gerais do modelo de dados com um conjunto limitado
de funcionalidades base. Na segunda iteração foi dada primazia à refinação dos
requisitos definidos na primeira iteração e à determinação dos restantes requisitos
necessários para ultrapassar problemas e preencher lacunas no funcionamento da
BAM após a primeira iteração.
4.3 Desenho da Solução
Depois de identificados os requisitos gerais da BAM, foi desenhado em
pormenor o modelo de dados, definida a forma como os componentes da aplicação se
relacionam e integram na CMOS e finalmente o fluxo de informação existente entre
eles.
É de extrema importância a existência deste modelo, pois funciona como um
mapa para a construção de aplicações. Permite uma forma rápida e eficiente de
identificação das estruturas e das relações subjacentes. Este modelo de dados foi
construído tendo por base os requisitos estruturais e funcionais, definidos na etapa
anterior.
Na Figura 19 é apresentado o diagrama que representa o modelo de dados
construído.
Trabalho Realizado
44
Figura 19. Modelo de Dados
Construído a partir do modelo de dados da CMOS (no canto superior esquerdo a
azul), o modelo de dados da BAM (a verde) apresenta o conjunto de entidades que
complementa o modelo da CMOS e introduz novas entidades fundamentais para o
funcionamento da BAM.
De acordo com o modelo criado temos o seguinte conjunto de estruturas:

entidades prx_ind_n: suportam a informação e valores relacionados com
o indicador em causa

entidades prx_ind_n_daily: suportam os valores recolhidos diariamente
relacionados com o indicador em causa

entidades prx_aux_<atributo> e outras: entidades que suportam dados
auxiliares para compor os indicadores dos conceitos de negócio e para o
cálculo de estimativas.
Estas estruturas permitem estender a CMOS para um novo conjunto de
indicadores, tal como foi realizado, é demonstrado na próxima secção.
Trabalho Realizado
45
4.4 Implementação da BAM
A implementação da BAM, que decorreu em duas iterações foi a tarefa que teve
o maior esforço empregue. Foi dividida em 4 fases as quais estão descritas em maior
detalhe nas próximas secções.
4.4.1 Instalação do Ambiente
O limitado conhecimento na programação em ambientes Web e a reduzida
experiência nas linguagens e tecnologias utilizadas, obrigaram a que uma fatia
relevante do tempo do projecto fosse consumida em formação nestas novas
tecnologias. Algumas destas actividades de formação foram concretizadas com a
instalação e configuração do ambiente de desenvolvimento e execução da BAM e no
qual tive o primeiro contacto com algumas das tecnologias a utilizar. Este processo
iniciou-se com a instalação da CMOS e com a realização de testes nesta consola.
Seguiram-se pequenas modificações à mesma, nas quais foi possível compreender o
seu funcionamento ao nível funcional e ao nível técnico das várias estruturas internas
e do motor da CMOS.
Foram instalados as seguintes ferramentas e sistemas:

Sistema Operativo Linux RHEL 5;

Processos residentes para recolha de indicadores via protocolo SNMP;

Base de Dados Oracle 10gR2;

Servidor Aplicacional Apache versão 2.0, configurado com módulos de
PHP e bibliotecas de auxílio à geração de interfaces Web.
Com esta tarefa foi possível obter uma visão mais pormenorizada da consola
CMOS, fornecendo dados relevantes para a tarefa de integração da BAM na CMOS.
Após esta fase, foi então possível dar início ao desenvolvimento da BAM.
Trabalho Realizado
46
4.4.2 Repositório de dados
O processo de desenvolvimento teve o seu início com a criação do modelo de
dados que serviu de suporte à BAM bem como ao conjunto de dados por ela gerido.
A possibilidade de uma mesma base de dados de repositório vir a recolher e
armazenar informação de várias bases de dados e servidores que as alojam,
conduziram à criação de duas colunas adicionais em todas as tabelas na base de dados
da BAM, que guardam o nome do servidor e respectiva(s) base(s) de dados. Desta
forma e numa mesma instalação, a BAM pode recolher e armazenar informação de
várias bases de dados e respectivos servidores.
De seguida encontra-se uma descrição das tabelas existentes bem como da
informação que suportam. A descrição das tabelas da base de dados da BAM
encontra-se na Tabela 2 e a estrutura das tabelas e significado das suas colunas
encontra-se na Tabela 3.
Tabela
Descrição
prx_ind_7
Armazena os valores da carga do Processador de 5 em 5 minutos
prx_ind_8
Usada para armazenar o tamanho (em MBytes) de várias tabelas.
O registo é feito 3 vezes por dia (frequência parametrizável, configuradas
recolhas às 8:00, 13:00 e 18:00)
prx_ind_9
Guarda o número de registos de cada tabela.
O registo é feito 3 vezes por dia (frequência parametrizável, configuradas
recolhas às 8:00, 13:00 e 18:00)
prx_ind_10
Esta tabela reúne dados das tabelas prx_ind_1,2,5 bem como o
número de registos da tabela PA_PROJECTS_ALL.
prx_ind_1_daily
Armazena a média diária da utilização de Processador
prx_ind_2_daily
Armazena a média diária do consumo de memória RAM
prx_ind_3_daily
Armazena a média diária do consumo de memória virtual(SWAP)
prx_ind_5_daily
Armazena a média diária do tamanho da(s) base(s) de dados
prx_ind_7_daily
Armazena a média diária dos valores da carga do CPU
prx_aux_mmt
Armazena o número de linhas da tabela MTL_MATERIAL_TRANSACTIONS
correspondente a cada projecto
prx_aux_pbl
Armazena o número de linhas da tabela PA_BUDGET_LINES
correspondente a cada projecto
Trabalho Realizado
47
Tabela
Descrição
prx_aux_pra
Armazena o número de linhas da tabela PA_RESOURCE_ASSIGNMENTS
correspondente a cada projecto
prx_project_statistics
Reúne o número de linhas por tipo de projecto das tabelas:
MTL_MATERIAL_TRANSACTION, PA_BUDGET_LINES,
PA_RESOURCE_ASSIGNMENTS
prx_avg_row_len
Guarda o tamanho, em média, de um registo das tabelas:
MTL_MATERIAL_TRANSACTION, PA_BUDGET_LINES,
PA_RESOURCE_ASSIGNMENTS
Tabela 2. Tabelas da base de dados e respectiva descrição
Na primeira iteração foram criadas apenas estruturas para armazenar os valores
de recolha diária (prx_ind_*_daily) e a tabela prx_ind_8.
As restantes, foram criadas na segunda iteração do desenvolvimento da BAM,
após o refinamento dos requisitos funcionais.
Tabela
Coluna
Significado
prx_ind_7
load
carga do processador (consumida de 5 em 5 minutos)
prx_ind_8
table_name
nome da tabela
current_size
tamanho da tabela em MBytes
table_name
nome da tabela
current_size
numero de registos da tabela
cpu_used
percentagem de processador utilizada diariamente
mem_used
percentagem de memória utilizada diariamente
total_size
percentagem de espaço em disco ocupado pela
base de dados diariamente
ppa_lines
número de linhas da tabela PA_PROJECT_ALL
prx_ind_1_daily
cpu_used
percentagem de processador utilizada diariamente
prx_ind_2_daily
mem_used
quantidade de memória consumida diariamente (em
GBytes)
prx_ind_3_daily
swap_used
quantidade de swap consumida diariamente (em MBytes)
prx_ind_5_daily
total_size
tamanho total diário da base de dados (em GBytes)
prx_ind_7_daily
load
carga diária consumida pelo processador
prx_aux_mmt
project_type
tipo de projecto
lines
número de registos
prx_ind_9
prx_ind_10
Trabalho Realizado
48
Tabela
Coluna
Significado
prx_aux_pbl
project_type
tipo de projecto
lines
número de registos
project_type
tipo de projecto
lines
número de registos
project_type
tipo de projecto
mmt_lines
número de registos da tabela
MTL_MATERIAL_TRANSACTIONS
pbl_lines
número de registos da tabela
PA_BUDGET_LINES
pra_lines
número de registos da tabela
PA_RESOURCE_ASSIGNMENTS
table_name
nome da tabela
length
média do tamanho ocupado por um registo (em Bytes)
prx_aux_pra
prx_project_statistics
prx_avg_row_len
Tabela 3. Descrição das colunas existentes em cada tabela da base de dados
Para obter o alinhamento dos vários eventos as tabelas prx_ind_7…10,
prx_ind_[1,2,3,5,7]_daily recolhem ainda uma estampilha temporal na coluna
“timestamp”. Esta estampilha temporal permite estabelecer relações na ocorrência de
variações entre os vários indicadores recolhidos.
4.4.3 Motores de Análise e Recolha
A BAM tem como objectivo principal analisar a forma como a execução de
operações do negócio se manifesta no consumo de recursos. Esta análise é
concretizada com a procura de relações em dados com características comuns (mesma
escala temporal por exemplo). Neste sentido os motores da BAM, que são o seu
núcleo, são os responsáveis por permitir a recolha dos dados dos indicadores para a
sua posterior análise.
Foram assim desenvolvidos dois componentes com características e propósitos
diferentes: o Motor de Recolha e o Motor de Análise.
Trabalho Realizado
49
Motor de recolha
O motor de recolha possui um conjunto de sondas. Estas sondas são
concretizadas em shell scripts que recolhem indicadores do SNMP e informação a
obter de bases de dados através de interrogações em SQL.
Estas sondas permitem assim a execução automatizada de comandos e
interrogações, filtrando e pré-processando a informação que daí resulta. O resultado
deste processo consiste em dados que são inseridos na base de dados da BAM através
de novos comandos em SQL. Um exemplo de uma destas sondas é apresentado na
Figura 20.
#!/bin/bash
. $HOME/.bash_profile
HOSTNAME=`snmpget -Oqv -m all -v 1 -c public $1 sysName.0`
TMP_LOAD=`snmpget -Oqv -m all -v 1 -c public $1 extOutput.2`
$ORACLE_HOME/bin/sqlplus -s /nolog << EOF
connect sys/password@TSH1 as sysdba
INSERT INTO SYS.PRX_IND_7 (timestamp, hostname, load)
SELECT sysdate,'$HOSTNAME','$LOAD' FROM DUAL;
exit
EOF
Figura 20. Sonda da BAM para recolha de dados de carga de processador
Os dados recolhidos através do serviço de SNMP incluem indicadores de
desempenho e consumo de recursos dos servidores que alojam as bases de dados
monitorizadas. As interrogações executadas em SQL obtêm dados sobre volume e
outras propriedades de tabelas bem como informação armazenada na própria tabela.
Foram criadas cinco sondas que estão descritas na Tabela 4.
Sonda
Descrição
prx_ind_1.sh
Recolhe dados de consumo de processador realizando uma média diária.
prx_ind_2.sh
Recolhe dados de consumo de memória realizando uma média diária.
prx_ind_3.sh
Recolhe dados de consumos de memória virtual realizando uma média diária.
prx_ind_5.sh
Recolhe valores de espaço ocupado na base de dados realizando uma
média diária.
prx_ind_7.sh
Recolhe valores de carga do processador realizando uma média diária.
Trabalho Realizado
50
Sonda
Descrição
prx_ind_7.sh
Recolhe dados relativos ao consumos de processador e
realiza a inserção destes na tabela prx_ind_7.
prx_ind_8.sh
Recolhe dados relativos ao tamanho das tabelas e realiza
a inserção destes na tabela prx_ind_8.
prx_ind_9.sh
Recolhe dados relativos ao número de registos das tabelas e
realiza a inserção destes na tabela prx_ind_9.
prx_ind_10.sh
Recolhe dados relativos ao consumo de processador, memória,
espaço ocupado pela base de dados e número de registos da
tabela PA_PROJECTS_ALL. Esta sonda obtém a informação através das
tabelas locais da BAM (que foram previamente preenchidas).
update_daily.sh
Responsável por recolher dados para preencher as tabelas que
guardam valores diários. Obtém a informação através das tabelas
locais da BAM (previamente preenchidas).
Tabela 4. Descrição das sondas
O fluxo de funcionamento do motor de recolha de dados está esquematizado na
Figura 21.
Sondas
SNMP
Shell Script
Base de dados
monitorada
Parse Shell
Script
Dados
SQL plus
Base de dados
local
SQLplus
Figura 21. Fluxo de funcionamento do motor de recolha de dados
A recolha de dados e indicadores é realizada em duas fases:
1. Numa primeira fase pretende-se determinar as tabelas envolvidas em
operações de negócio que devem ser monitorizadas. Para tal, a BAM
recolhe dados sobre o tamanho, número de registos e actividade das
tabelas que fazem parte da E-Business Suite. Os dados aqui recolhidos
Trabalho Realizado
51
são disponibilizados ao motor de análise que realiza uma filtragem
indicando quais as tabelas que interessa monitorizar.
2. Numa segunda fase, é monitorizado o crescimento e actividade das
tabelas previamente seleccionadas pelo motor de análise.
Motor de análise
Os dados recolhidos, por si só, não permitem distinguir informação relevante de
informação insignificante. É por isso importante, submeter os dados e indicadores
recolhidos acerca das estruturas de uma base de dados a um processo de análise e
tratamento para que estes dados possam ser verdadeiramente indicadores relevantes.
O motor de análise é responsável pelo processamento e normalização dos dados
recolhidos e também pela preparação dos dados para serem apresentados através de
gráficos e assim poderem ser analisados.
O processo de análise, à imagem do processo de recolha, é também realizado em
duas etapas:
1. Numa primeira etapa o motor de recolha fornece dados relativamente ao
tamanho das tabelas, número de registos e a sua actividade. Interessa,
nesta etapa, reconhecer conceitos de negócio a serem monitorizados.
Estes conceitos materializam-se normalmente em registos de uma ou
mais tabelas. Nesse sentido, torna-se necessário identificar as tabelas
cujas alterações sejam potenciais conceitos de negócio. A forma de
definir as candidatas mais prováveis passou por estabelecer filtros que,
baseados nalguns critérios objectivos, pretendem seleccionar as tabelas
mais relevantes para monitorização.
Os critérios escolhidos são:

Tabelas que ocupam mais espaço em disco;

Tabelas com maior número de registos;

Tabelas que apresentam maior actividade;
Além destes critérios, e como o universo de tabelas e estruturas é muito
extenso no ERP Oracle E-Business Suite (24022 tabelas no total), foi
Trabalho Realizado
52
necessário investigar e validar junto das equipas da Truewind o conjunto
de dados recolhido. Como complemento a esta validação socorri-me
ainda de um repositório de informação, o eTRM (Electronic Technical
Reference Manual) [25].
O eTRM é um repositório de meta-dados técnicos de referência para
explorar a estrutura de dados do E-Business Suite. Através do eTRM é
possível conhecer a estrutura das tabelas, índices, suas dependências,
atributos e tipos de dados (Figura 23). Esta informação é disponibilizada
através de um Website como é apresentado na Figura 22 e Figura 23.
Figura 22. eTRM da Oracle com os meta-dados do modelo de dados do E-Business Suite
Trabalho Realizado
Figura 23. Excerto do resultado da pesquisa pela tabela PA_PROJECTS_ALL no eTRM
53
Trabalho Realizado
54
Dada a inexistência de meta-dados no ERP que permitam determinar por
si só quais os conceitos de negócio armazenados em cada tabela, o
eTRM assume um papel determinante na identificação, contextualização
e validação dos dados recolhidos.
Na instalação da BAM os registos obtidos pelo motor de recolha foram
ordenados por ordem crescente, aplicando os três critérios indicados,
assim, foram seleccionadas 10 tabelas para serem monitorizadas. Destas
10 tabelas as mais relevantes são as seguintes:

PA_BUDGET_LINES
Guarda informação detalhada acerca do orçamento de um
projecto ou tarefa, incluindo os recursos associados, período de
tempo e quantidade do orçamento utilizado.

WIP_TRANSACTION_ACCOUNTS
Tabela que armazena informação acerca de transacções de
recursos, sendo que cada linha corresponde a um débito ou um
crédito.

PA_RESOURCE_ASSIGNMENTS
Guarda informação detalhada sobre os recursos que são
atribuídos a um projecto/tarefa.

QP_PRICING_ATTRIBUTES
Guarda informação sobre os produtos e atributos dos preços
respectivos.

MTL_TRANSACTION_ACCOUNTS
Guarda informação sobre contabilidade no que diz respeito a
cada transacção de material que ocorre. Cada linha representa
um débito ou um crédito.

MTL_MATERIAL_TRANSACTIONS
Armazena informação detalhada sobre as transacções e sobre o
material envolvido nessas transacções.
Trabalho Realizado
55
Estas tabelas, conjuntamente com a tabela PA_PROJECTS_ALL, no
contexto do cliente e do sistema que a BAM monitorizou, representam os
conceitos de negócio mais relevantes. Esta tabela contém informação
sobre todos os projectos e tipos de projectos que são executados na
empresa, e são precisamente estes conceitos de negócio que importa
obter, monitorar e analisar.
2. Numa segunda etapa, o motor de análise foca-se em processos de
relacionamento de dados e na exploração dessas relações. A
representação gráfica na dimensão temporal permite obter resultados
relevantes no objectivo de encontrar casualidade entre execução de
operações de negócio e variação no consumo de recursos.
Para serem averiguadas estas premissas o motor de análise permite a
visualização de vários gráficos que apresentam o crescimento das tabelas
ao longo do tempo e relacionam a variação do consumo de recursos com
esse crescimento das tabelas.
O motor de análise proporciona assim, ferramentas visuais para
relacionar o crescimento das tabelas quer em tamanho quer em número
de registos, com a variação do consumo de recursos da infra-estrutura
física. Na Figura 24 da próxima página é possível visualizar um quadro
que apresenta a forma como se manifesta o espaço e linhas ocupadas por
um tipo de projecto em três tabelas distintas.
4.4.4 Criação da interface gráfica
Nos requisitos delineados para a BAM, a apresentação fácil e rápida dos
resultados obtidos na inspecção ao funcionamento aplicacional de uma base de dados
Oracle era um dos mais importantes. O desenvolvimento da interface gráfica foi
direccionado precisamente nesse sentido. A interface da CMOS já dispunha de
algumas destas características, no entanto a forma como os resultados eram
apresentados e a localização dos elementos na interface não eram adequados para que
a integração da BAM nesta estrutura fosse bem sucedida.
Trabalho Realizado
56
Foi por isso decidido em sede de projecto não criar uma interface nova de raiz,
mas sim, tirar partido de alguns elementos já existentes, sendo redesenhados uns e
criados outros, que foram necessários, para que fossem mantidas as funcionalidades
da CMOS e facilmente integradas as da BAM.
A interface gráfica da BAM possui três componentes principais:

Quadro de consumo de recursos;

Caixas de selecção para a escolha de gráficos;

Gráficos;
Quadro de consumo de recursos
É o primeiro elemento a ser visualizado e é uma tabela que representa o volume
estimado (em número de linhas e espaço em disco de três tabelas) para cada tipo de
projecto. Apesar de se tratarem de valores relativamente estáveis (e alcançados por
medidas estatísticas que absorvem variações) está disponível no ecrã um botão que
permite actualizar os valores desta tabela. A Figura 24 apresenta este primeiro
elemento da interface gráfica.
Figura 24. Quadro consumo de recursos
Trabalho Realizado
57
Parâmetros de visualização
Os gráficos produzidos podem ser parametrizados pelo utilizador/administrador,
preenchendo para tal as caixas de selecção correspondentes aos gráficos que pretende
visualizar para facilitar desde logo a comparação entre diferentes gráficos, como é
apresentado na Figura 25.
Nesta figura é também possível visualizar dois parâmetros de data, que
permitem definir as datas entre as quais se pretende observar a evolução dos
indicadores.
Figura 25. Caixas de selecção para escolha de gráficos
Gráficos
Os gráficos são uma componente fundamental da interface, pois é através deles
que é possível analisar de forma efectiva os dados fornecidos. A interface está criada
para que seja possível apresentar na mesma página os gráficos dos vários indicadores,
permitindo assim a comparação de vários gráficos simultaneamente.
Trabalho Realizado
58
Os gráficos que apresentam dados de indicadores cuja recolha é efectuada com
uma frequência mais elevada, dispõem de dois tipos de vista: uma diária e outra
horária. A primeira permite uma análise mais detalhada e a outra disponibiliza uma
análise agregada. A selecção dos diferentes tipos de vista é concretizada por um
selector disponibilizado na interface junto ao gráfico. A Figura 26, evidencia a vista
horária de um gráfico. A Figura 27 mostra o mesmo gráfico após ter sido seleccionada
a vista diária.
Figura 26. Vista Horária
Trabalho Realizado
59
Figura 27. Vista Diária
É também possível obter uma visualização mais pormenorizada dos gráficos,
sendo necessário, para tal, clicar nos pontos que unem as linhas existentes. O
resultado desta operação resulta numa nova janela na qual é possível visualizar o
gráfico aumentado. É uma funcionalidade particularmente interessante quando
existem múltiplas linhas aparentemente sobrepostas, ou em situações em que não seja
possível perceber a evolução do gráfico.
Na Figura 28 pode ser observado o gráfico que mostra o número de registos de
tabelas. A linha que representa a tabela PA_PROJECTS_ALL (a verde) na escala
definida não tem aparente variação sugerindo a inexistência de alterações no período
representado. No entanto ao ser realizada a operação de visualização mais
pormenorizada, verifica-se que de facto existem alterações significativas, como está
representado na Figura 29.
Trabalho Realizado
60
Figura 28. Antes da operação de aumento
Figura 29. Depois da operação de aumento
Trabalho Realizado
61
Obstáculos
A pouca experiência em desenvolvimento para Web contribuiu para que todo o
processo de desenvolvimento sofresse com alguns contratempos, particularmente na
construção da interface, na qual me deparei com dificuldades na manipulação e
disposição dos elementos gráficos. Senti aqui a existência de uma lacuna que foi um
obstáculo no desenho e construção de uma interface como a que tinha sido projectada
inicialmente.
Relativamente à biblioteca de gráficos utilizada, surgiram na sua utilização
algumas restrições. Por limitação deste componente e ao contrário do que tinha sido
inicialmente planeado, não foi possível disponibilizar funcionalidades para permitir ao
utilizador interagir directamente com os gráficos, como por exemplo, realizar
operações de visualização ao pormenor localizadas. A visualização ao pormenor dos
gráficos é possível, no entanto, esta funcionalidade (fornecida nativamente pela
biblioteca utilizada) é apenas concretizada na disponibilização de uma ligação para
uma página na qual é fornecido um outro gráfico com um maior detalhe.
Trabalho Realizado
62
4.5 Testes
A execução de testes à aplicação é uma etapa fundamental no processo de
desenvolvimento que, em múltiplos ciclos, permite a avaliação e a validação das
funcionalidades implementadas, revelando assim o que tem de ser corrigido e/ou
melhorado. Neste projecto e tendo em conta que o objectivo passava pela
prototipagem de uma aplicação para posterior refinamento, apenas foi executado um
ciclo de testes em cada iteração do desenvolvimento.
A metodologia de execução dos testes consistiu na apresentação do protótipo
aos responsáveis da empresa de acolhimento e a outros membros da equipa de suporte
e administração de sistemas que, nestas sessões, testaram a aplicação e apresentaram
sugestões. O conjunto de situações reportadas foi registado e tratando-se de situações
anómalas (como a perca de funcionalidade de botões ou dados incorrectos recolhidos
por falha das sondas) foram prontamente corrigidas. As sugestões de melhoria foram
prioritizadas e na sua maioria acabaram por não ser executadas por falta de tempo.
Os testes à BAM foram assim realizados principalmente após as duas iterações,
do desenvolvimento sendo testados primeiramente os vários componentes nucleares
da aplicação e posteriormente a interacção com os componentes da interface.
4.5.1 Testes realizados aos componentes nucleares da BAM

Motor de Recolha
Os testes neste componente incidiram na validação dos dados recolhidos.
As principais incorrecções que aqui foram detectadas foram geradas pelo
comportamento anómalo das sondas quando eram realizadas execuções
sucessivas das diferentes sondas. Aqui foi detectado que o componente
de Shell Script das sondas, que trata e filtra a informação recolhida da
base de dados monitorizada, exibia mais dados do que seria suposto,
sendo, por isso, necessárias as afinações adequadas de forma a atingir o
funcionamento pretendido. Estas alterações foram executadas de forma
imediata após a detecção de dados incorrectos numa das sessões de
demonstração da aplicação.
Trabalho Realizado

63
Motor de Análise
Os testes neste componente incidiram no processo de geração de
gráficos e na validação e consistência dos dados por estes apresentada.
Numa primeira fase verificou-se que a geração de gráficos apresentava,
erros intermitentes (falhando de forma sistemática nalgumas situações de
análise),
Quando este problema foi ultrapassado, os gráficos gerados permitiram
validar os valores recolhidos pelas sondas e validar os valores
apresentados.
Foram
ainda
corrigidas
situações
anómalas
que
provocavam a apresentação de valores incorrectos ao nível da geração
das estruturas XML para alimentação dos gráficos.
4.5.2 Testes realizados à interface utilizador
Nesta iteração os testes incidiram nos componentes e nas interfaces
desenvolvidas para a BAM. Os testes consistiram na execução de determinadas
operações de forma a permitir avaliar por um lado, o comportamento da interface de
acordo com as operações realizadas, e por outro, evidenciar problemas na construção
da interface sendo este parâmetro baseado na facilidade ou dificuldade com que os
utilizadores realizavam as tarefas que lhes foram propostas.
Nas sessões de demonstração, foram sugeridas várias melhorias à interface e
novas formas de navegação para facilitar a comparação dos valores recolhidos. No
entanto e devido a limitações de tempo algumas destas sugestões e propostas de
alteração não foram executadas, tendo as correcções e outras acções decorrentes dos
testes incidido na correcção de funcionalidades e acções quebradas ao nível da
interface. As situações consideradas impeditivas da utilização da BAM foram todas
ultrapassadas.
Trabalho Realizado
64
4.6 Resultados Obtidos
Obtivemos assim uma plataforma que permite não só a recolha e identificação
de indicadores de negócio como também os relaciona com indicadores de consumo de
recursos hardware. Ao relacionar esta informação, novos dados são criados e
disponibilizados aos gestores e administradores de sistemas que, ao realizarem tarefas
de previsão de crescimento das bases de dados, dispõem agora de mais uma fonte de
dados para os auxiliar no fornecimento das respostas mais adequadas e na manutenção
dos níveis de desempenho dos sistemas.
Para o concretizar e para garantir um nível de fiabilidade razoável na
identificação das relações e projecções é necessário recolher dados de uma amostra
que seja minimamente representativa dos dados a analisar. Dada a duração e execução
do projecto a amostra de dados recolhida é limitada e iniciou-se no mês de Junho de
2009. Os resultados aqui apresentados resultam da análise a esse conjunto de dados e
que são concretizados no número de amostras apresentada na Tabela 4.
Tabela
prx_ind_1
prx_ind_1_daily
prx_ind_2
prx_ind_2_daily
Número de Registos
38407
125
38409
125
prx_ind_3
33465
prx_ind_4
5504
prx_ind_5
2789
prx_ind_5_daily
prx_ind_7
prx_ind_7_daily
124
33392
113
prx_ind_8
2500
prx_ind_9
1848
prx_ind_10
1311
Tabela 5. Número de registos por tabela
A Tabela 5 indica o número de registos recolhido em cada tabela de indicadores.
Trabalho Realizado
65
Com base no conjunto de dados recolhido, foi obtida uma estimativa do
consumo de recursos de hardware para cada tipo de projecto desenvolvido pela
organização em análise apresentada na Tabela 6. Esta tabela permite visualizar o
número de linhas e correspondente tamanho ocupado por cada tipo de projecto num
conjunto de três tabelas diferentes que armazenam os principais dados de planeamento
de um projecto. Assim, podemos observar, por exemplo, que a criação de um projecto
do tipo “Gastos Gerais” irá ocupar em média um total de 220 KBytes em termos de
espaço na tabela da base de dados monitorada. Este é, obviamente, um valor pouco
significativo, no entanto e como prova de conceito, demonstra a utilidade da
ferramenta e a possível extrapolação quando foram monitorizadas um conjunto mais
alargado de tabelas. Os valores recolhidos conjugados com o plano de negócio da
organização tornam-se num indicador de extrema importância para o gestor do
sistema quando é chamado a estimar o consumo de recursos do sistema aplicacional a
médio prazo.
Tipo de Projecto
MTL_MATERIAL_
TRANSACTIONS
PA_RESOURCE_
ASSIGNMENTS
PA_BUDGET_LINES
Linhas
KBytes
Linhas
KBytes
Linhas
KBytes
Apoio a Projectos
4
1.18
211
19.32
211
22.2
Cedencias - Cliente
0
0
255
23.4
255
26.89
Cedencias Internas
0
0
339
31.1
339
35.73
Concep e Desenv Ind
0
0
21
1.95
21
2.24
Concep e Desenvolvim
0
0
200
18.33
200
21.06
conv - AP CLIENTE
3
0.88
14
1.29
14
1.48
conv - CONTRATOS
9
2.62
95
8.75
95
10.06
conv - FABRICO
0
0
9
0.79
9
0.9
32
9.42
32
2.94
32
3.38
DFB - Cli. (Indir.)
0
0
25
2.32
25
2.67
Fabricos
0
0
11
0.97
11
1.11
Gastos Gerais
50
14.73
1.041
95.53
1.042
109.9
Imobiliz Incorporeo
0
0
34
3.12
34
3.59
Imobilizado
8
2.43
27
2.48
27
2.85
Imobilizado Corporeo
0
0
14
1.27
14
1.45
231
68.11
4.001
367.26
4.001
421.95
Reabastecimento
0
0
111
10.19
111
11.71
Reclamac?o
0
0
42
3.82
42
4.39
Suporte Frota
291
85.82
437
40.13
440
46.42
DFB-Fact. Cli.
0
0
598
54.93
598
63.11
conv - IMOBILIZADO
Manutenc?o
Tabela 6. Número de linhas e espaço ocupado em média por tipo de projecto em três tabelas
Trabalho Realizado
66
Um dos objectivos a que a BAM se propôs a atingir, foi conseguir demonstrar
que a execução de operações de negócio condiciona o consumo de recursos de
hardware. Na Figura 30 está representado um gráfico que demonstra uma evidência
desta situação. O gráfico obtido através da BAM, representa a variação do consumo
de processador, memória e espaço ocupado pela base de dados em função do aumento
do número de registos da tabela PA_PROJECTS_ALL ao longo do tempo. Os
círculos realçam as variações mais significativas. Podemos assim observar que, tanto
o consumo de processador como o consumo de memória e espaço ocupado, aumentam
com o aumento do número de registos da tabela PA_PROJECTS_ALL. Poderá existir
ruído que provoque alguma variação destes parâmetros coincidentemente com esta
situação. Contudo e neste caso é inequívoca a relação entre o aumento pontual de
volume da tabela e o consumo de recursos.
Como se pode observar nas setas (Figura 30), no dia 10-09-2009 a base de dados
tem 91.3% do espaço ocupado e no dia 18-09-2009 apresenta 91.91% de espaço
ocupado, ou seja, um aumento de 3GBytes tendo sido parte consumido por novos
segmentos das tabelas envolvidas no armazenamento de dados dos projectos. Este
resultado sugere que, naturalmente, o aumento do número de projectos, implica um
aumento de espaço ocupado.
Trabalho Realizado
67
Figura 30. Consumo de processador, memória e espaço ocupado pela base de dados em função do
número de linhas da tabela PA_PROJECTS_ALL
A BAM estima ainda que esse incremento é de 1.1 MBytes para os projectos do
tipo “Gastos Gerais”, 18.7 MBytes para os projectos do tipo “Manutenção” e 8
MBytes para os projectos do tipo “Suporte Frota”.
A Figura 31 apresenta um gráfico que ilustra o consumo de processador durante
o período compreendido entre as datas 22-07-2009 e 23-09-2009 e a Figura 32 mostra
um gráfico no qual está apresentado a evolução do número de registos da tabela
PA_RESOURCE_ASSIGNMENTS no mesmo período (as restantes tabelas
analisadas, apesar de não estarem no gráfico, apresentam um crescimento semelhante
a esta).
Trabalho Realizado
68
Figura 31. Consumo de Processador
Figura 32. Evolução do número de linhas da tabela PA_RESOURCE_ASSIGNMENTS
Analisando estas figuras, e de acordo com a premissa que a actividade nas
tabelas influencia o consumo de recursos, seria expectável que o consumo de
processador neste período fosse aumentando de uma forma gradual, pois o
crescimento de todas as tabelas é constante durante este período. Contudo, tal
Trabalho Realizado
69
variação não é inferida directamente. De facto o consumo de processador mantém-se
irregular com várias oscilações não sendo perceptível um aumento.
Esta situação poderá dever-se à reduzida quantidade da amostra que não permite
para já obter médias pesadas de consumo de Processador mensais comparáveis com o
crescimento das tabelas. Com este indicador seria possível uma análise mais rica que
permitisse uma distinção entre as situações que efectivamente têm impacto, com as
situações em que a afinação do sistema permite que o aumento do número de registos
não afecte directamente o consumo de processador e o desempenho do sistema.
Trabalho Realizado
70
Capítulo 5
Conclusões
Este projecto teve como principal objectivo o desenvolvimento de uma
aplicação que permitisse uma análise e monitorização avançada de bases de dados
Oracle. A BAM propôs-se, desta forma, a ser uma aplicação para analisar e
monitorizar não os rácios de actividade tradicionais de uma base de dados mas sim a
actividade funcional (em termos de operações do negócio) duma base de dados
Oracle, na qual seria possível obter dados que permitissem evidenciar o impacto desta
actividade funcional no consumo de recursos de hardware do sistema. Após nove
meses de trabalho e a sua concretização num dos clientes da Truewind, consideramos
o principal objectivo atingido.
No que diz respeito ao objectivo de trabalho para permitir a identificação dos
processos responsáveis pela degradação da performance da base de dados, apesar do
trabalho desenvolvido, não é ainda possível obter e analisar esta informação de forma
directa pela BAM. Derivado do impacto causado pelo arrastar de algumas tarefas e da
limitação de tempo disponível os objectivos mais estruturantes foram prioritizados.
Como obstáculos relevantes encontrados no desenvolvimento da BAM, há a
destacar a dificuldade no mapeamento dos conceitos de negócio no modelo de dados
das aplicações e o desenvolvimento do núcleo da aplicação. A dimensão do ERP
Oracle E- Business Suite, o vasto conjunto de estruturas de dados que inclui e a
reduzida informação da relação funcional e técnica, dificultou a identificação do
conjunto de estruturas relevantes. Apesar disso foi indiscutivelmente proveitoso o
tempo dispendido na investigação e aprendizagem destes conceitos.
71
Conclusões
72
Com a BAM, é agora possível analisar a evolução do consumo de recursos de
hardware e da sua relação com a execução de operações de negócio do cliente. No
cliente onde a BAM foi concretizada, foi possível determinar, por exemplo, que a
execução de um projecto de “Manutenção” é uma operação de negócio que envolve
registos em pelo menos 3 tabelas (as mais significativas), sendo que cada operação
deste tipo consome aproximadamente 856 KBytes e no que diz respeito ao impacto
deste tipo de projecto no consumo de processador, memória e memória virtual, não
foram detectadas alterações significativas com os dados disponíveis.
O estágio na Truewind promoveu o primeiro contacto que tive com o mundo da
das tecnologias de informação ao nível empresarial que foi extremamente positivo.
Além de ser uma empresa onde o incentivo à aprendizagem e às novas tecnologias é
constante, a nível de relações interpessoais é muito saudável. Sente-se um ambiente
familiar e o espírito de apoio e entreajuda entre os colaboradores é algo que gostaria
de destacar.
Os locais onde desempenhei tarefas contribuíram de forma determinante para a
minha formação como técnico e profissional na gestão e administração de tecnologia
Oracle. Considero importante ter-me sido dada a oportunidade de exercer tarefas em
diferentes clientes pois o contacto estabelecido com estes, permitiu o enriquecimento
do meu conhecimento relativamente a diferentes áreas de negócio.
5.1 Trabalho futuro
Tendo em vista a manutenção da BAM, foram identificadas algumas
funcionalidades que interessa desenvolver para complementar o seu funcionamento
actual.
A automatização de todo o processo de identificação de tabelas relevantes para
as operações de negócio é uma tarefa complexa e que dificilmente poderá ser
executada de forma totalmente automática. Contudo, a BAM carece de estruturas que
auxiliem esta identificação de forma mais simples e célere.
Conclusões
73
O processo de análise de impacto está ainda directamente dependente do
utilizador da BAM, que ao observar os gráficos retira conclusões. Idealmente a
automatização deste processo, também não poderá ser total, mas permanecem lacunas
que um motor de análise mais robusto poderia conseguir nomeadamente no
relacionamento dos indicadores mais básicos (por exemplo espaço ocupado)
É ainda um vector de desenvolvimento futuro a promoção de uma maior
interactividade do utilizador com os gráficos (adopção de uma nova biblioteca de
gráficos que ofereça funcionalidades mais poderosas), como por exemplo, operações
de aumento localizadas.
Conclusões
74
Bibliografia
1. Truewind. Truewind - Sistemas de Informação, S.A. [Online] 2009.
www.truewind.pt.
2. Oracle. Enterprise Manager. [Online] 2009.
http://www.oracle.com/enterprise_manager/index.html.
3. tools4ever. MonitorMagic Database Monitoring. [Online] 2009.
http://www.tools4ever.com/products/monitormagic/features/applicationmonitoring/database-monitoring/.
4. Oracle. Identity and Access Management Solutions. [Online] 2009.
http://www.tools4ever.com/.
5. Software, Quest. Systems Management. [Online] 2009. http://www.quest.com/.
6. Truewind. CMOS - Consola de Monitorização Operativa de Sistemas. 2007.
7. Wikipedia. ERP - Enterprise Resource Planning - Wikipedia, the free
encyclopedia. [Online] 2009.
http://en.wikipedia.org/wiki/Enterprise_resource_planning.
8. Oracle. Oracle E-Business Suite. [Online] 2009.
http://www.oracle.com/us/products/applications/ebusiness/index.htm.
9. Braude, Eric J. Software Enginnering, An object-Oriented Perspective. s.l. : John
Wiley & Sons, Inc., 2001.
10. Oracle. E-Business Suite 12i. [Online] 2009.
http://www.oracle.com/applications/e-business-suite-release.html.
11. Oracle. Oracle VM. [Online] 2009.
http://www.oracle.com/technology/products/vm/index.html.
75
Bibliografia
76
12. Oracle. Oracle Database. [Online] 2009.
http://www.oracle.com/database/index.html.
13. Oracle. Oracle Database Platform Guide 10g Release 2 (10.2) for Microsoft
Windows (32-ibit). Part Number B14304-02. 2005.
14. Oracle. Oracle Database Concepts 10g Release 2 (10.2). Part Number B1422002. 2005.
15. Oracle. Database Administrator´s Guide 10g Release 2 (10.2) Part Number
B14231-02. 2006.
16. Sourceforge. SNMPLink.org SNMP Portal. [Online] 2007. http://netsnmp.sourceforge.net/.
17. Archives, Internet FAQ. RFC 1157 - Simple Network Management Protocol
(SNMP). [Online] 2008. http://www.faqs.org/rfcs/rfc1157.html.
18. ChapNet. SNMP Network Management Protocols. [Online] 1999.
http://www.chapo.co.il/articles/snmp.
19. PHP. PHP: Hypertext Processor. [Online] 2009. http://www.php.net/.
20. w3schools. Javascript. [Online] http://www.w3schools.com/js/default.asp.
21. Oracle. Database SQL Reference 10g Release 2 (10.2). Part Number B14200-02.
2005.
22. Standards, World Wide Web Consortium - Web. Extensive Markup
Language(XML). [Online] 2009. http://www.w3.org/XML/.
23. Wikipedia. Linux Shell Scripting. [Online] 2009.
http://en.wikipedia.org/wiki/Shell_script.
24. Oracle. Business Activity Monitoring. [Online] 2009.
http://www.oracle.com/appserver/business-activity-monitoring.html.
25. Oracle. Oracle eTRM. [Online] 2005. http://etrm.oracle.com.
26. Fusion Charts. Fusion Charts Free. [Online] 2009.
http://www.fusioncharts.com/free/.
27. Flash. Adobe Flash Player. [Online] 2009.
http://www.adobe.com/products/flashplayer/.
Bibliografia
28. Primos. Oracle Databse Monitoring Software. [Online] 2007.
http://www.primos.nl/.
29. Confio. Database Monitoring & Performance Studio. [Online] 2010.
http://www.confio.com/English/Products/Ignite_for_Oracle.php.
77