universidade de lisboa - informática | faculdade …paa/reports/t25.pdf · arquitectura, sistemas...

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

i

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

iii

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

v

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 Tecnologia e Arquitectura .................................................................................. 17

3.1 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

vi

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

vii

4.4.4 Criação da interface gráfica ............................................................................... 55

4.5 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 Conclusões ......................................................................................................... 71

5.1 Trabalho futuro .......................................................................................................... 72

Bibliografia .............................................................................................................................. 75

viii

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

ix

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

xi

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

Lista de Tabelas xii

xii

1

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

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

7

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.

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.


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.


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.


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


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.


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.


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, iniciou-

se 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.


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.


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.

17

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):

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;


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;


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.


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.


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.


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 é


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.


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.

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.

function print_debug($error_string){

$fh = fopen("/home/oracle/oms/debug/debug.txt",'a');

fwrite($fh,strftime('%c')." - ".$error_string."\n");

fclose($fh);

}


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.

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

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

function generateGraph(data,id,chartType) {

var chart = new FusionCharts("../libs/fusioncharts/"+chartType,

"chart1", "850", "600", "0", "0");

chart.setDataURL(data);

chart.render(id);

}


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.

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.

<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'/>



</chart>


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


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 sub-

componentes:

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


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


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 infra-

estruturas 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.


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.


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.


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.


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.


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.


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


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

- Vasto leque de análises

- Possibilidade de configurar alarmes e acções automáticas para problemas

- Fornece apenas análises técnicas

- Reduzida funcionalidade na previsão de necessidades futuras de recursos

- Interface pouco amigável nalguns módulos

Monitor Magic – Database Monitoring

- Criação de alarmes e eventos de acordo com limites pré-definidos ou definidos pelo administrador

- Notificação de erros críticos

- Informação limitada sobre funcionamento geral da base de dados


- Interface pobre

Quest Database Management

- Fornece informação detalhada relativamente ao congestionamento e ao desempenho de bases de dados

- Interface bem construída

- Integração com vários sistemas de gestão de bases de dados (Oracle, SQLserver, etc)

- Não relaciona os problemas que encontra com o tipo de negócio do sistema que monitoriza.


- Licenças dispendiosas

Primos Database Monitoring

- Identificação de situações críticas

- Sugestão de resolução para alguns problemas

- Análise integrada de várias bases de dados

- Reduzida informação no consumo de recursos Hardware

- Suporte restrito a bases de dados Oracle

- Identificação de problemas de desempenho limitado a análise de expressões em SQL

Ignite for Oracle Performance

- Informação detalhada sobre constrangimentos no desempenho da base de dados

- Interface simplista e atractiva

- Foco da aplicação limitado ao desempenho das bases de dados



Oracle Business Activity - BAM

- Monitorização de serviços e processos de negócio

- Infra-estrutura de alarmística avançada

- Interface avançada, reunindo informação necessária de forma lógica e organizada

- Análise limitada à optimização de processos de negócio

- Exigente a nível de requisitos Hardware

- Licenças dispendiosas

Tabela 1. Comparativo de soluções

41

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 E-

Business 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.

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.


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.


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.


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.


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


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

prx_ind_9 table_name nome da tabela

current_size numero de registos da tabela

prx_ind_10 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


Tabela Coluna Significado

prx_aux_pbl project_type tipo de projecto


prx_aux_pra project_type tipo de projecto


prx_project_statistics 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

prx_avg_row_len table_name nome da tabela

length média do tamanho ocupado por um registo (em Bytes)

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.


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.

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.

#!/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


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.

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

Base de dados monitorada

Base de dados localSQL plus

Parse Shell Script

Dados

SNMP

SQLplus

Shell Script

Sondas


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


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


Figura 23. Excerto do resultado da pesquisa pela tabela PA_PROJECTS_ALL no eTRM


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.


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.


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


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.


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


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.


Figura 28. Antes da operação de aumento

Figura 29. Depois da operação de aumento


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.


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.


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.


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 Número de Registos

prx_ind_1 38407

prx_ind_1_daily 125

prx_ind_2 38409

prx_ind_2_daily 125

prx_ind_3 33465

prx_ind_4 5504

prx_ind_5 2789

prx_ind_5_daily 124

prx_ind_7 33392

prx_ind_7_daily 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.


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

conv - IMOBILIZADO 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

Manutenc?o 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

Tabela 6. Número de linhas e espaço ocupado em média por tipo de projecto em três tabelas


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.


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).


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


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.

71

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.

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

75

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/application-

monitoring/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.

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 B14220-

02. 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://net-

snmp.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/.

http://www.adobe.com/products/flashplayer/

Bibliografia 77

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.

http://www.primos.nl/

universidade de lisboa - informática | faculdade …paa/reports/t25.pdf · arquitectura, sistemas...

Documents