Post on 10-Oct-2020
Anolan Yamilé MilanésBarrientos
Uma arquitetura paraauto-sintonia global deSGBDs usando agentes
DISSERTAÇÃO DE MESTRADO
DEPARTAMENTO DE INFORMÁTICA
Programa de Pós�graduação em Ciências
da Computação
Rio de Janeiroabril de 2004
Anolan Yamilé Milanés Barrientos
Uma arquitetura para auto-sintoniaglobal de SGBDs usando agentes
Dissertação de Mestrado
Dissertação apresentada como requisito parcial para obten-ção do grau de Mestre pelo Programa de Pós�graduaçãoem Ciências da Computação do Departamento de Informá-tica da PUC-Rio
Orientador: Prof. Sérgio Lifschitz
Rio de Janeiroabril de 2004
Anolan Yamilé Milanés Barrientos
Uma arquitetura para auto-sintoniaglobal de SGBDs usando agentes
Dissertação apresentada como requisito parcial para obten-ção do grau de Mestre pelo Programa de Pós�graduaçãoem Ciências da Computação do Departamento de Informá-tica do Centro Técnico Cientí�co da PUC-Rio.Aprovadapela Comissão Examinadora abaixo assinada.
Prof. Sérgio LifschitzOrientador
Departamento de Informática � PUC-Rio
Prof. Fabio André Machado PortoIME-RJ
Prof. Geraldo Bonorino XexéoDCC/IM UFRJ
Prof. José Eugênio LealCoordenador Setorial do Centro Técnico Cientí�co �
PUC-Rio
Rio de Janeiro, 14 de abril de 2004
Todos os direitos reservados. É proibida a reproduçãototal ou parcial do trabalho sem autorização da univer-sidade, do autor e do orientador.
Anolan Yamilé Milanés Barrientos
Ficha Catalográ�caBarrientos, Anolan Yamilé Milanés
Uma arquitetura para auto-sintonia global deSGBDs usando agentes/ Anolan Yamilé Milanés Bar-rientos; orientador: Sérgio Lifschitz. � Rio de Janeiro :PUC-Rio, Departamento de Informática, 2004.
v., 81 f: il. ; 29,7 cm
1. Dissertação (mestrado) - Pontifícia UniversidadeCatólica do Rio de Janeiro, Departamento de Informá-tica.
Inclui referências bibliográ�cas.
1. Informática � Teses. 2. Banco de dados. 3. Agen-tes de software. 4. Sintonia global. 5. Auto-sintonia. I.Lifschitz, Sérgio. II. Pontifícia Universidade Católica doRio de Janeiro. Departamento de Informática. III. Título.
CDD: 004
A Paula y Sebastian, por el tiempo perdido. Aos meus pais e irmã.
Agradecimentos
Chegada a página mais difícil por todos aqueles que irão �car injusta-
mente fora por causa do espaço e da minha memória, quero aproveitar de
qualquer jeito para agradecer a todas as pessoas que intervieram de alguma
forma com que este trabalho tenha sido �nalmente terminado.
A minha mãe, pela sua valiosa ajuda durante quase meio ano. A minha
irmã pela sua ajuda quase o tempo todo.
Aos amigos do Labpos, em especial a Silvana, Cláudio, Renato, Thiago
(e Sergina), Sebastián e Paula, pela ajuda e simpatia nas horas difíceis.
À Marcos V. Salles, que não economizou horas de ajuda e de quem
aprendi muito nesse tempo de trabalho em conjunto.
Ao pessoal da Secretaria pela ajuda e in�nita paciência.
A Carmen pela simpatia, a conversa e o lanchinho.
Aos amigos de Cuba, ao Pruza, à Danays e à professora Lucina Garcia
da Universidade da Havana e ao Msc. Hector Dache, sem a ajuda dos quais
teria sido impossível começar o mestrado.
Ao CNPq e à PUC�Rio, pelos auxílios concedidos, sem os quais este
trabalho não poderia ter sido realizado.
E �nalmente ao departamento de Informática pela oportunidade única
de estudar aqui e pelo ótimo ambiente que tem mantido todo esse tempo,
e em especial ao meu orientador o Professor Sérgio Lifschitz por me dar a
oportunidade de realizar um trabalho tão interessante e complexo. Obrigada
pela simpatia, ajuda e ensinamento durante o período de realização deste
trabalho.
Resumo
Barrientos, Anolan Yamilé Milanés; Lifschitz, Sérgio. Uma arqui-tetura para auto-sintonia global de SGBDs usando agentes.Rio de Janeiro, 2004. 81p. Dissertação de Mestrado � Departa-mento de Informática, Pontifícia Universidade Católica do Rio deJaneiro.
O aumento da complexidade dos SGBDs comerciais e a carga que supor-
tam, além da crescente utilização destes por pessoal pouco familiarizado
com a administração de bancos de dados, entre outras causas, sugerem a
introdução de técnicas que automatizem o processo de sintonia de bancos de
dados. A auto-sintonia (self-tuning) é uma característica que faz os sistemas
se adaptarem para manter um bom desempenho, reduzindo a interação do
administrador com o sistema. Este trabalho propõe uma abordagem para
o ajuste automático dos parâmetros em um SGBD usando agentes de soft-
ware. A tarefa de sintonia é tratada nesta pesquisa como um problema glo-
bal, dado que alterações de um parâmetro podem se re�etir em outros. Os
detalhes da arquitetura, sua implementação e avaliação de funcionamento
são também discutidos nesta dissertação.
Palavras�chave
Banco de Dados; Auto-sintonia; Sintonia Global; Agentes de Software
Abstract
Barrientos, Anolan Yamilé Milanés; Lifschitz, Sérgio. An agent-based architecture for DBMS Global Self-tuning. Rio deJaneiro, 2004. 81p. MSc. Dissertation � Departamento de Infor-mática, Pontifícia Universidade Católica do Rio de Janeiro.
The increasing complexity of the commercial DBMSs as well as the workload
they manage, besides the fact that many users do not have deep knowledge
about database administration, among other reasons, strongly suggests the
introduction of techniques that automates the database tuning process. Self-
Tuning, or auto-tuning, is a feature that makes systems adaptable in order
to keep a good overall performance, reducing as possible the interaction
between the administrator and the system. This work proposes an approach
for the automatic tuning of DBMSs parameters using an architecture based
on software agents. We consider tuning as a global issue, given that changes
of a single parameter can be re�ected in others. The architecture details,
its implementation and a practical evaluation are also discussed in this
dissertation.
Keywords
Databases; Self-Tuning; Global Tuning; Software Agents
Conteúdo
1 Introdução 11
2 Auto-sintonia de sistemas de bancos de dados 132.1 Agentes 132.2 A arte da sintonia de desempenho 162.3 Auto-Sintonia 192.4 Trabalhos relacionados 222.5 Operação do sistema de auto-sintonia 262.6 Motivação da pesquisa 342.7 Conclusões 35
3 Arquitetura 363.1 Requisitos 363.2 Propostas de Arquitetura 393.3 Abordagem centralizada 413.4 Abordagem distribuída 433.5 Agentes na arquitetura 483.6 Conclusões 48
4 Implementação 494.1 Infra-estrutura 494.2 Exemplo de aplicação 594.3 Ambiente de desenvolvimento 604.4 Aspectos de implementação 634.5 Conclusões 65
5 Conclusões e Contribuições 665.1 Resumo 665.2 Principais contribuições 665.3 Conclusões 675.4 Trabalhos futuros 68
Referências Bibliográ�cas 68
A Anexo 76A.1 Substituição de páginas em cache 76A.2 Nível de Multiprogramação 78
Lista de Figuras
2.1 Arquiteturas de integração de agentes em SGBDs [66]. 152.2 Desempenho da transação em função do MPL limite [66]. 172.3 Cadeia de Consumo em SGBDs [36] 312.4 Etapas de um processo de auto-sintonia [11] 34
3.1 Abordagem centralizada para auto-sintonia global 423.2 Arquitetura distribuída para auto-sintonia global 43
4.1 Framework para a construção de agentes [33] 504.2 Processo executado pelas camadas de Crença, Raciocínio e Ação
para o controle da estratégia de substituição de páginas em bu�er. 524.3 Envio de uma mensagem 544.4 Recebimento de uma mensagem (comunicação assíncrona) 554.5 Interações no sistema de auto-sintonia 574.6 Atividade do sistema em um evento de violação de razão de
con�itos 63
A.1 A estratégia LRU toma uma página limpa do extremo LRU dacache 77
A.2 O princípio de trabalho do controle de carga orientado a con�itos[66]. 79
Lista de Tabelas
3.1 Satisfação dos requisitos propostos para um sistema de auto-sintonia global de SGBDs na arquitetura. 47
1
Introdução
Os Sistemas de Gerência de Bancos de Dados (SGBDs) atuais oferecem
um grupo de parâmetros que permitem modi�car a alocação de recursos1 no
sistema. A modi�cação desses parâmetros de forma a satisfazer os objetivos
dos usuários em cada contexto é chamada de sintonia (tuning). A sintonia de
SGBDs é una tarefa rotineira que exige dos DBAs (Database Administrators
- Administradores de Bancos de Dados) uma alta dose de criatividade,
conhecimentos e dedicação. A situação ideal seria, entretanto, que os SGBDs
conseguissem se adaptar às mudanças no ambiente de forma que o DBA
pudesse se ocupar de tarefas relacionadas com a gerência dos dados.
Vários trabalhos têm sido realizados objetivando resolver o problema
da auto-sintonia (self-tuning) de sistemas de computação em geral e de
SGBDs em particular [34]. A grande maioria deles se concentra em compo-
nentes ou problemas isolados, sendo chamados na literatura de mecanismos
de auto-sintonia local. As interações que existem entre os componentes do
sistema podem provocar, no entanto, que ações executadas por um meca-
nismo de auto-sintonia local afetem outros componentes e, como conseqüên-
cia, se deteriore o desempenho do sistema. Isso leva à necessidade de adotar
uma visão global do problema da auto-sintonia de SGBDs. Essa abordagem
tem sido adotada em trabalhos como [8, 9, 28, 39, 68].
A presente proposta se concentra no estudo dos aspectos relacionados
ao tema da auto-sintonia global de SGBDs usando agentes de software.
Sua motivação está na elaboração do contexto global onde o mecanismo de
auto-sintonia de índices proposto em [11] seria inserido. Seguimos a linha de
trabalho do nosso grupo de pesquisa cujo interesse é a utilização de agentes
de software para aumentar as funcionalidades dos sistemas de bancos de
dados [40, 50].
Os trabalhos de auto-sintonia global podem dividir-se naqueles que
visam a criação de novos sistemas de bancos de dados orientados a desem-
penho, e naqueles que procuram melhorar a adaptabilidade dos sistemas
1Recursos são aqueles componentes de hardware e software que formam o sistema.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 12
atuais incluindo componentes de auto-sintonia [34]. O objetivo dessa pes-
quisa é criar um componente de auto-sintonia global baseado em agentes
que possa ser embutido dentro de um SGBD classi�cando-se, pois, dentro
da segunda vertente.
A principal contribuição desse trabalho é propor uma arquitetura de
auto-sintonia global baseada em agentes que atende aos principais requisitos
observados na literatura e enumerados aqui. Como contribuições adicionais
podemos mencionar a classi�cação e discussão de sistemas de auto-sintonia
locais e globais e a implementação de um protótipo para avaliação da
complexidade de desenvolvimento e e�cácia das idéias aqui propostas na
prática, utilizando o SGBD PostgreSQL.
Entre as vantagens que apresenta a introdução de agentes no projeto
e implementação dessas arquitetura está a facilidade de integração de novos
mecanismos de auto-sintonia. Estes podem ser acrescentados progressiva
e independentemente um do outro, sendo a sua inter-relação gerenciada
pelo sistema. Esta é uma grande diferença entre esse trabalho e propostas
anteriores, em que os sistemas de auto-sintonia têm sido sempre tratados
centralizadamente dentro do contexto do SGBD.
No próximo capítulo serão comentados brevemente alguns aspectos
relacionados com o tema de agentes de software e será apresentado um
panorama do problema da auto-sintonia em SGBDs, assim como algumas
abordagens de solução. No capítulo 3 são enumerados os requisitos que
devem ser satisfeitos por um sistema de auto-sintonia e discutidas as
possíveis arquiteturas para sua construção usando agentes. No capítulo 4
é detalhada a implementação de um protótipo do sistema proposto. O
capítulo 5 apresenta as conclusões dessa dissertação e possíveis extensões.
2
Auto-sintonia de sistemas de bancos de dados
Este capítulo apresenta os conceitos relacionados à auto-sintonia de
SGBDs abordadas nesta dissertação incluindo agentes de software e sintonia
de desempenho. Também discute os desa�os decorrentes do problema de
auto-sintonia e as abordagens propostas. Finalmente, as considerações
assumidas ao longo do trabalho e as motivações para a presente pesquisa
serão expostas.
Uma introdução aos termos relacionados com desempenho pode ser
consultada em [34], trabalho que contém um estado da arte em auto-sintonia
de SGBDs relacionais.
2.1Agentes
Embora o tema de agentes de software1 venha sendo estudado pela
área de Inteligência Arti�cial desde os anos 80 [48, 70] e pela área de Enge-
nharia de Software nos últimos anos [19, 33], ainda não existe um consenso
quanto às características que todo agente deve ter. Por enquanto, autono-
mia, reatividade, sociabilidade e pró-atividade são as mais aceitas [73]:
� Autonomia: capacidade de agir/reagir para atingir um objetivo sem a
intervenção de humanos, tendo algum controle sobre suas atitudes;
� Reatividade: a partir de percepções sobre o que ocorre no ambiente
possui a capacidade de responder a mudanças para que seus objetivos
sejam atingidos;
� Pró-atividade: agir para manter a possibilidade de atingir seus obje-
tivos, antecipando-se a mudanças no ambiente;
� Sociabilidade: capacidade de interagir com outros participantes do
ambiente.1Nesse trabalho serão chamados simplesmente de agentes
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 14
Os agentes podem ser classi�cados, entre outras formas, segundo a sua
característica de agência: fraca ou forte [73]. Agentes de agência fraca são
aqueles que possuem as características citadas acima. Os de agência forte,
também chamados agentes inteligentes, deverão possuir a mais a capacidade
de raciocínio (rationality), podendo ser atribuídas noções mentais como
conhecimento, intenção e compromisso.
No contexto de agência forte outro atributo importante é o apren-
dizado. O aprendizado é essencial quando o agente tem um conhecimento
incompleto do ambiente [48]. A idéia é aproveitar as experiências para me-
lhorar a habilidade do agente atuar no futuro. O agente aprende durante
sua interação com o ambiente e pela observação dos resultados do seu pró-
prio processo de tomada de decisões. Existe uma forte relação entre este
atributo e a autonomia: um sistema é autônomo na medida em que seu
comportamento está determinado por sua própria experiência [48].
Agentes são encontrados com freqüência formando uma organiza-
ção com outros agentes. Estas organizações são chamadas sistemas multi-
agentes (Multi-Agent Systems: MAS ) [73]. Um ponto crítico nos MAS é a
interação entre os agentes. Os propósitos dos agentes podem ser con�itantes
e devem, portanto, ser coordenados. A coordenação pode ser feita por um
agente coordenador dedicado ou por uma comunicação ponto a ponto, onde
os agentes interagem descentralizadamente. A cooperação é a coordenação
entre agentes não antagônicos enquanto a negociação é a coordenação entre
agentes competitivos ou "egoístas" [24]. Um MAS coerente é um sistema de
agentes que se comporta como uma unidade. O problema de como manter
a coerência do sistema sem um controle global explícito deve ser resolvido
através da coordenação, junto com a de�nição de "compromissos sociais"2,
de forma a resolver os con�itos entre os interesses locais e os objetivos da
sociedade. Existem várias soluções para esse problema, entre elas aquelas
baseadas em mecanismos de mercado [24].
O desenho de um MAS abrange não somente o desenho de cada
agente individual mas, também, os mecanismos de coordenação que lhes
permitem relacionar-se dentro da sociedade para atingir seus objetivos. As
características mais importantes destes sistemas são:
� cada agente tem informação incompleta e restrita das suas possibili-
dades;
� o controle do sistema é distribuído;
2compromissos de um agente com outro que permitem restringir o comportamentodos agentes dentro do sistema.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 15
� os dados estão descentralizados;
� a computação é assíncrona.
A abordagem de um sistema multi-agentes se justi�ca nos casos em que
a tarefa pode ser melhor resolvida por uma sociedade de múltiplos agentes
que por um agente só. Dado que o uso de agentes pode introduzir uma
sobrecarga desnecessária nas aplicações que não precisam desse paradigma,
seu uso deve ser bem analisado em cada caso.
2.1.1Agentes em SGBDs
A questão da construção de SGBDs baseados em agentes foi levantada
em [40], onde são propostas as três arquiteturas para agentes em SGBDs
apresentadas na �gura 2.1.
Figura 2.1: Arquiteturas de integração de agentes em SGBDs [66].
Estas são:
1. Arquitetura em camadas: Permite implementar agentes sobre SGBDs
existentes sem ter praticamente que modi�car o SGBD objetivo. A
ação dos agentes é limitada pois devem acessar os componentes do
SGBD via as interfaces oferecidas.
2. Arquitetura Embutida: Os agentes são embutidos dentro de SGBDs
já construídos para aumentar e estender suas funcionalidades. Esta
arquitetura tem limites impostos pelas funcionalidades oferecidas pelo
SGBD.
3. Arquitetura Integrada: Os componentes do SGBD são implementados
como subsistemas de agentes. A integração dos agentes no sistema
aporta mais �exibilidade e controle que nas outras arquiteturas, ao
mesmo tempo que traz mais di�culdades de implementação.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 16
Assim como os SGBDs baseados em agentes, os sistemas de bancos
de dados ativos conseguem reagir a mudanças de estado sem intervenção
humana [5]. Algumas vantagens podem ser citadas a favor da tecnologia de
agentes, como a quase ilimitada persistência das intenções, a possibilidade
de retornar o resultado das ações, a capacidade de controlar cenários
dinâmicos em tempo real e o fato de que algoritmos complexos de raciocínio
são mais facilmente implementados em arquiteturas de agentes. Estas razões
sugerem o uso de agentes em lugar de sistemas de bancos de dados ativos
para aplicações que exigem adaptabilidade, autonomia e inteligência como
a auto-sintonia de SGBDs.
2.2A arte da sintonia de desempenho
A sintonia de desempenho (performance tuning) consiste na realização
de ajustes em um sistema (seja um SGBD ou um sistema de computação
qualquer) para uma carga de trabalho especí�ca visando obter um melhor
desempenho das aplicações ao otimizar a utilização dos recursos computa-
cionais disponíveis.
O desempenho pode ser de�nido como a e�ciência com que um
sistema atinge seus objetivos. Os sistemas podem fornecer determinados
parâmetros de controle que permitam ajustar a alocação dos recursos e,
como conseqüência, mudar o desempenho. O desempenho de um sistema
pode ser caracterizado através da observação de três classes de métricas [7]:
1. Métricas de Con�guração: são características que não mudam ajus-
tando os parâmetros de controle, como a quantidade de memória e a
velocidade da CPU.
2. Medidas de Desempenho ou Métricas de Nível de Serviço: As medidas
mais usadas para avaliar o desempenho de um SGBD são a vazão
e o tempo de resposta. A vazão (throughput) é uma medida de
produtividade que corresponde à quantidade de trabalho executada
pelo sistema durante um dado período de tempo. O tempo de resposta
é o tempo de processamento das requisições submetidas ao sistema.
3. Métricas de carga de trabalho: designa todo o processamento de
requisições submetidas ao sistema pelo usuário durante um dado
intervalo de tempo. Em [64] é proposto um conjunto de parâmetros
para a caracterização da carga de trabalho em bancos de dados.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 17
Estes são: a localidade de acesso ou de referência, o comprimento
das transações, a proporção de operações de escrita das transações, o
nível de multiprogramação e a taxa de chegada das consultas.
A satisfação do usuário com o desempenho do sistema é que de�ne o
�m do processo de sintonia.
Chamada às vezes de arte, a sintonia de SGBDs ainda é uma tarefa
que tem muito de empírico e requer, com freqüência, as habilidades e
imaginação de administradores experimentados [49]. A di�culdade que essa
tarefa apresenta tem causas técnicas e subjetivas. Entre as causas técnicas
podemos mencionar o grande número de ajustes diferentes que podem
resolver um dado problema de desempenho, as fortes inter-relações que
existem entre os recursos, assim como entre os recursos e a carga de trabalho,
e o escasso conhecimento que existe ainda sobre essas inter-relações [56].
Um exemplo da complexidade que as interferências entre as diferentes
cargas de trabalho acrescentam à sintonia é descrito em [66]. É comparada
a complexidade do problema do controle do nível de multiprogramação
(MultiProgramming Level - MPL) para uma carga homogênea e para uma
mistura de cargas, conforme mostrado na �gura 2.2. Aqui é notável a
in�uência da carga no valor ótimo do parâmetro, cuja determinação se torna
mais complexa na mistura de cargas heterogêneas.
Figura 2.2: Desempenho da transação em função do MPL limite [66].
No primeiro caso, pode-se notar na �gura que o valor ótimo para o
parâmetro MPL é 20, pois é com esse valor que o tempo médio de resposta
do sistema é menor para essa carga de trabalho. No casso da mistura de
cargas é mais difícil a determinação do MPL ótimo. A escolha do valor
ótimo de uma carga como valor para o parâmetro MPL otimiza o tempo de
resposta para essa carga, mas piora para as outras.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 18
As causas subjetivas da complexidade da tarefa de sintonia se devem
fundamentalmente ao fato de que a tarefa habitual do SGBD é oferecer ser-
viços a seres humanos. Isso deriva, por exemplo, na di�culdade para de�nir
prioridades no processamento de consultas dado que muitas vezes os crité-
rios são basicamente empresariais, di�cilmente de�nidos automaticamente.
O fator subjetivo na tarefa de sintonia é um poderoso voto contra a
possibilidade da sua total automatização em sistemas de bancos de dados.
Dessa forma, a idéia de integrar componentes de auto-sintonia em SGBDs
é eliminar o máximo possível as tarefas rotineiras de modo que os DBAs
(DataBase Administrators) possam se concentrar na verdadeira gerência
dos dados.
O processo de sintonia depende fortemente do contexto da aplicação.
Este inclui o tipo de aplicação, a relevância da informação gerenciada e a
estabilidade do sistema. Aplicações de comércio eletrônico, por exemplo,
demandam respeitar limites nos tempos de resposta de forma a evitar a
desistência dos usuários.
A relevância da informação é determinante em cenários nos quais
decisões de sintonia podem melhorar notavelmente o desempenho do banco
colocando em risco, por outro lado, a integridade dos dados. Este é o
caso, por exemplo, da opção que permite desabilitar fsync (fsync-disabling)
no SGBD PostgreSQL, conforme descrito em [65]. Quando fsync está
habilitado, é o backend do PostgreSQL que decide quando serão salvos
(�ushed) os dados a disco. Por outro lado, com fsync desabilitado é o
sistema operacional que decide. As escritas em disco nesse caso serão menos
freqüentes aumentando o desempenho do sistema de banco de dados. Mas
poderá acontecer que dados já con�rmados (commited) que estiverem ainda
em memória sejam perdidos em caso de uma falha de hardware. O valor
pré-determinado de fsync é habilitado. Em ambientes onde as falhas de
hardware são improváveis e as informações não são críticas, desabilitar este
parâmetro é uma opção a se levar em conta.
A postura de tentar resolver os problemas de desempenho depois des-
tes terem se manifestado, também chamada de postura reativa, é cada vez
mais difícil de se manter por causa do aumento das exigências dos sistemas
atuais e das cargas a que estes são submetidos [55]. Vários trabalhos têm
discutido a necessidade de passar de posturas reativas a pró-ativas, que se
antecipem aos problemas de forma a tentar evitar que estes aconteçam. Em
[55] propõe-se uma metodologia chamada de Total Performance Manage-
ment - TPM em que, após concluído o processo de sintonia, se executa
uma etapa de detecção e alerta de problemas potenciais. Em [64] depois de
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 19
concluídas as etapas que são chamadas no trabalho de diagnóstico e terapia
(ou resolução de problemas) executa-se uma etapa de previsão de desempe-
nho que estima a evolução da carga e permite determinar quando o sistema
deverá ser ajustado novamente. A indústria de sistemas para gerência de sis-
temas de bancos de dados tem assumido em grande parte esta postura [34].
Por exemplo, a informação coletada pelas ferramentas da suíte de gerência
de desempenho da Veritas Software [63] é consolidada e armazenada em
um repositório chamado Performance DataWarehouse. Análises históricas
sobre os dados armazenados nesse repositório permitem antecipar alertas
ante problemas potenciais.
A complexidade que apresenta a tarefa de sintonia tem motivado o
desenvolvimento de várias ferramentas de ajuda ao DBA na tomada de
decisões de sintonia. Algumas delas, baseadas em Sistemas Especialistas
(Expert Systems), Raciocínio Baseado em Casos (Case Based Reasoning -
CBR) e Redes Neurais, são destacadas em [28]. O objetivo desses sistemas
é apenas sugerir ações: não inclui a execução dessas ações.
2.3Auto-Sintonia
Os sistemas com auto-sintonia devem ser capazes de escolher os valores
ótimos dos parâmetros de forma a satisfazer os requisitos de desempenho
previamente estabelecidos pelo administrador ou usuário do sistema. São
tarefas de um sistema com auto-sintonia executar tanto processos que
tenham por objetivo resolver problemas que prejudiquem ou que podem
prejudicar a perspectiva do cliente como processos que visem melhorar o
desempenho do sistema.
No caso particular de SGBDs, alguns administradores são contrários
à idéia da auto-sintonia, dado que consideram que a maioria dos problemas
desses sistemas se devem à implementação ine�ciente das aplicações3.
Certamente, um sistema de auto-sintonia pode não ser a melhor alternativa
em todos os casos. Entretanto, podemos identi�car algumas situações em
que o seu resultado pode ser vantajoso:
1. Dado que o desempenho do sistema depende intimamente da carga de
trabalho, assim que esta mudar o sistema pode precisar ser sintonizado
novamente. Por este motivo, a automatização do processo de sintonia
3The limits of self-tuning,http://www.computerworld.com/news/2002/story/0,11280,73890,00.html
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 20
é essencial se a freqüência com que a carga de trabalho do sistema
varia for alta [18].
2. Em instalações cujas dimensões não justi�quem o alto custo de um
DBA que gerencie a complexidade e requisitos de desempenho dos
sistemas atuais [2, 66].
3. Novos paradigmas como a computação ubíqua (Ubiquitous Compu-
ting) [71] procuram isolar o usuário das particularidades do sistema.
A auto-sintonia de SGBDs embutidos em dispositivos construídos se-
guindo esses paradigmas é uma necessidade.
Outro argumento contra a auto-sintonia é o fato de que a sua integra-
ção com o SGBD implica em uma carga adicional concorrendo pelos recursos
do sistema. Uma decisão errada pode piorar o problema de desempenho e
erros de programação ou concepção podem deixar um sistema, até então
considerado robusto, fora de uso. A qualidade da implementação do sistema
de auto-sintonia é crítica para o seu sucesso. Deve-se ter cuidado para não
prejudicar o desempenho do SGBD, assim como conseguir diagnosticar os
problemas mais signi�cativos de desempenho que o sistema possa sofrer. Os
requisitos que um sistema de auto-sintonia deve cumprir serão enumerados
na seção 3.1.
Nesse trabalho se considerará que o sistema oferece uma interface mí-
nima com o usuário. Na prática, no entanto, é desejável que o sistema de
auto-sintonia ofereça ao administrador a possibilidade de intervir no pro-
cesso de sintonia, monitorando-o ou decidindo quais ações serão executa-
das. Por este motivo, deveremos considerar como sistema com auto-sintonia
aquele que possua a capacidade de executar ações sem intervenção humana,
ainda quando essa possibilidade estiver disponível.
2.3.1Considerações
1. A sintonia envolve a otimização da utilização dos recursos pre-
existentes no sistema. Nesse trabalho não serão consideradas soluções
que impliquem acrescentar recursos de hardware.
2. Nesse trabalho será considerada como parte da atividade de sintonia
de desempenho a resolução de problemas de deterioração de desempe-
nho, bem como os processos que geram con�gurações iniciais ótimas
dos parâmetros do SGBD.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 21
3. Apesar de estarem muito relacionados, o conceito de sintonia é dife-
rente da tarefa de planejamento de capacidade, que consiste em de-
terminar a con�guração de um sistema ainda inexistente de forma a
suportar as cargas de trabalho estimadas.
4. A sintonia �m a �m4 de um sistema requer a análise de todos os
seus componentes, ou seja, tanto o sistema de banco de dados como
o sistema operacional e a aplicação. A proposta de [55] é executar
a sintonia procurando o gargalo em cada sub-sistema. Em seguida,
estudar as interações entre eles e estreitar o espaço de busca voltando a
atenção para o sub-sistema suspeito. Para os efeitos dessa dissertação,
entretanto, não serão considerados casos que requeiram a sintonia da
aplicação ou do sistema operacional, devido à elevada complexidade
desse problema. A integração de todas as camadas da aplicação para
uma completa gerência dos sistemas também é tratada em [29].
5. Para a de�nição dos valores esperados das métricas de desempenho
pode-se assumir duas alternativas: uma é calcular o melhor valor
possível para cada parâmetro com base nos recursos disponíveis.
Outra é permitir ao administrador do sistema especi�car níveis de
serviço ou objetivos (Service Level Agreements - SLAs) que serão
então mapeados pelo sistema para valores de parâmetros de controle.
Nesse trabalho estaremos considerando somente a primeira opção, pois
entendemos que a mesma abrange os problemas mais importantes
relativos à auto-sintonia de sistemas de banco de dados, e não requer
a construção de interfaces com o usuário, uma tarefa que está fora do
escopo da dissertação.
2.3.2Abordagem global à auto-sintonia
Uma abordagem freqüente ao problema da auto-sintonia consiste em
usar algoritmos isolados, como os apresentados em [34]. Porém, interações
tanto entre os componentes do sistema como entre as cargas de trabalho
podem gerar deterioração do desempenho como conseqüência das próprias
ações de auto-sintonia. Por outro lado, um problema de contenção em
um recurso pode-se re�etir em outro e ser erroneamente interpretado pelo
mecanismo de auto-sintonia local que o controla.
4Aquela que abrange todos os subsistemas envolvidos na execução da aplicação
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 22
Isto leva à idéia de um sistema de sintonia global [8, 11, 42, 66]
diferente da idéia da sintonia como a combinação não coordenada de ajustes
especí�cos para problemas ou componentes determinados. As interações
entre os componentes podem fazer com que mudanças em um parâmetro
afetem outros e devem por isso ser consideradas.
Por exemplo: colocando-se todas as páginas de índices em memória,
melhora-se o desempenho de buscas indexadas. Igualmente, aumentando-
se os bu�ers mantêm-se por mais tempo os dados na memória principal,
o que diminui os acessos e a contenção de disco. Mas estas ações podem
deixar pouca memória disponível para ordenação ou hash e em função
disso, o otimizador de consultas poderia escolher planos de execução menos
e�cientes para determinadas consultas, comprometendo o desempenho do
sistema.
2.4Trabalhos relacionados
Trabalhos anteriores têm proposto a implementação de sistemas de
auto-sintonia global para sistemas de computação em geral e de bancos de
dados em particular [34]. Em [8] sugere-se um processo em que um agente
único com visão global do sistema executa as funções de análise dos dados
coletados pelos sensores e armazenados em um repositório comum. Como
resultado dessa análise são acionados mecanismos para efetuar ações de
controle.
Em [28] descreve-se a tecnologia dos ATS (Automated Tuning Sys-
tems), cuja operação coincide em essência com a proposta de [8]. Além dos
comentários sobre os desa�os técnicos apresentados pela construção desses
sistemas, esse trabalho propõe resolver o problema da integração dos ATSs
para garantir determinados níveis de desempenho �m-a-�m. Essa integra-
ção seria atingida através de um ATS coordenador capaz de balancear os
requisitos de cada um dos ATSs do nível inferior dada sua visão global do
problema, o que sugere a colaboração entre os ATSs.
Em [7] descreve-se a implementação de um sistema baseado em agentes
para a auto-sintonia de sistemas genéricos. Esta generalidade é obtida
através de um modelo do sistema controlado que pode ser reconstruído
assim que mudam as características do sistema controlado. Este modelo
permite mapear os valores esperados de níveis de serviço em parâmetros de
controle.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 23
No domínio de aplicação de bancos de dados as propostas para a auto-
sintonia de sistemas podem ser classi�cadas em dois grupos: aquelas que
propõem sistemas auto-sintonizáveis por projeto e aquelas que objetivam
a integração de componentes de auto-sintonia em bancos de dados já
existentes [34]. Assim, a proposta descrita em [12] baseia-se na complexidade
dos sistemas de bancos de dados atuais para propor a construção de um novo
tipo de SGBD mais simples, baseado em componentes. Esta simplicidade
facilitaria a modelagem e os ajustes. Atualmente está sendo desenvolvido
um protótipo seguindo essa abordagem [23] mas ainda não constam na
bibliogra�a sistemas deste tipo já prontos.
Representante da segunda vertente há o sistema apresentado em [39],
chamado Quartermaster, para auto-sintonia global de SGBDs no âmbito
de um sistema de comércio eletrônico. A arquitetura do Quartermaster
segue a linha daquelas descritas em [8, 28]. Constitui-se de um grupo
de módulos que são: o Monitor, o Planejador e o Controlador, os quais
executam respectivamente as funções de monitoramento, diagnóstico e ação.
O Quartermaster possui também módulos de interação com o usuário.
Um repositório armazena os objetivos, as medições dos parâmetros de
desempenho, regras e características da carga de trabalho, entre outros.
Apesar da sua arquitetura lhe permitir executar ações independentes, o
Quartermaster ainda deixa boa parte das decisões a cargo do administrador.
O módulo do Planejador foi descrito em [9].
A partir da documentação do SGBD e o conhecimento dos especialis-
tas, são criados um modelo de recursos, um modelo de carga de trabalho,
regras de diagnóstico e �nalmente uma árvore de diagnóstico. O processo
de diagnóstico consiste em atravessar a árvore de diagnóstico. Ele produz
um conjunto de recursos cujo ajuste é uma possível solução do problema de
desempenho. A determinação do ajuste que oferecerá o maior desempenho
é feita por algoritmos de auto-sintonia. A diferença de outros trabalhos, o
diagnóstico leva em conta vários recursos do sistema a partir de um modelo
de recursos que contém informação sobre os recursos e as relações entre
eles. A partir desse modelo podem determinar-se quais serão os efeitos de
um ajuste sobre os outros recursos e quais são os recursos que podem ter
afetado o desempenho de um recurso dado.
Finalmente, em [11] aborda-se o tema da integração dos estudos
existentes em auto-sintonia local dentro do contexto da proposta de uma
arquitetura baseada em agentes para a auto-sintonia de índices. O modelo de
auto-sintonia global proposto inclui um repositório onde são armazenadas
as operações executadas pelo agente de forma a evitar a execução de ações
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 24
que no passado tivessem afetado o desempenho do sistema. O modelo
prevê também a comunicação dos agentes de forma a garantir uma ação
combinada em favor do sistema como um todo.
Todas estas propostas utilizam como mecanismo de controle o ciclo
de controle fechado ou de realimentação (feedback control loop). O ciclo
de realimentação permite controlar continuamente a saída do sistema em
virtude do desconhecimento da função que relaciona os parâmetros de
con�guração e carga de trabalho com o desempenho do sistema [45].
As etapas em que deve ser dividida a auto-sintonia, por outro lado,
variam ligeiramente de uma proposta para outra. Assim, em [28] considera-
se que os passos a executar durante o processo de auto-sintonia devem ser
detecção, diagnóstico, ação e avaliação. Por outro lado, em [8] é sugerido
que o processo seja formado pelas etapas de de�nição de expectativas,
monitoramento de desempenho, análise e ação. A proposta de [66] inclui
somente três etapas, que são observação, predição e reação, diferente de [11],
que identi�ca quatro etapas de um Processo de Auto-Sintonia Genérico:
1. Coleta de informações: Monitoramento da parte do sistema onde está
sendo realizado a auto-sintonia.
2. Avaliação do sistema: Avaliação do desempenho baseado nas métricas
relacionadas ao nível do sistema e detecção da necessidade de adap-
tações. A escolha da métrica é uma grande di�culdade dado que é
muito dependente do caso em questão e as possíveis alternativas são
ora numerosas ora muito complexas.
3. Enumeração de possíveis alterações: Listagem das possíveis altera-
ções a serem realizadas quando é detectado que um componente não
está respondendo adequadamente. É a etapa que gera a maior sobre-
carga no sistema. São elaboradas várias alternativas calculando seus
ganhos/custos. Trata-se de um processo geralmente bastante oneroso
ao sistema e nem sempre a alternativa escolhida será a ótima.
4. Realização das alterações: alteração dos componentes do SGBD me-
diante o mecanismo de auto-sintonia.
No ciclo descrito em [30] como parte da arquitetura de computação
autonômica são propostas quatro etapas que podem ser mapeadas dire-
tamente às etapas propostas em [11]. Estas são: monitoramento, análise,
planejamento e ação.
O sistema é controlado através dos sensores (que coletam métricas
de desempenho) e os efetuadores (que ajustam a alocação dos recursos).
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 25
A operação do ciclo de controle transcorre como segue: o monitor coleta,
�ltra e consolida a informação captada pelos sensores. O analisador então
executa algoritmos de correlação e modelagem para detectar ou predizer
problemas de sintonia. Posteriormente, na etapa de planejamento, elabora-
se um plano de ação objetivando atingir os níveis de desempenho esperados,
plano este que é executado durante a etapa de ação. As particularidades de
cada uma dessas etapas, assim como os desa�os que apresentam as suas
implementações, serão discutidos na seção 2.5.2.
2.4.1De�nição do problema da con�guração ótima
A tarefa de auto-sintonia pode ser caracterizada como a otimização da
utilização dos recursos presentes em um sistema para atingir um determi-
nado objetivo com intervenção mínima do ser humano. A con�guração de
recursos é modi�cada através de parâmetros de controle. Chamamos de so-
lução de um problema de sintonia de desempenho a escolha de um conjunto
desses parâmetros (não necessariamente a combinação que ofereça o melhor
desempenho, dado que existem limitações de tempo e consumo de recur-
sos) que aplicados ao sistema gerem os melhores valores de níveis de serviço
possíveis para uma carga de trabalho dada, ou valores que se aproximem a
estes.
Em trabalhos anteriores [9, 64] a possibilidade de solução deste pro-
blema usando técnicas de otimização tem sido descartada. Outras soluções,
como a geração de modelos matemáticos5 são difíceis de aplicar devido à
complexidade associada à geração do sistema de equações. Igualmente os
modelos analíticos usualmente não são considerados pelas di�culdades da
sua elaboração para um sistema tão complexo como é um SGBD.
Considerando o fato de que as métricas de nível de serviço não são
independentes [18](podem inclusive ser contraditórias, como é o caso da va-
zão e o tempo de resposta em algumas situações) e dado o grande número
de soluções possíveis (sendo que o espaço de busca corresponde a todos
os valores possíveis dos parâmetros de sintonia acessíveis do sistema), o
problema pode ser formulado como um problema de Otimização Combina-
tória Multi-Objetivo (Multi-Objective Combinatorial Optimization Problem
- MOCO [14]). A resolução do problema usando esta abordagem deve gerar
5Um modelo matemático é formado por um conjunto de equações que tentam modelaro comportamento dinâmico do sistema.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 26
um grupo de soluções e�cientes ou Pareto-ótimas6, as quais devem ser pos-
teriormente avaliadas por um "juiz", que nesse caso seria o próprio sistema.
Como resultado desta avaliação seria escolhida a solução mais conveniente,
considerando-se o valor de cada métrica de nível de serviço na solução pon-
derado pela relevância da métrica para o sistema em particular. Acreditamos
que essa abordagem oferece uma alternativa para a execução do processo
de con�guração inicial dos parâmetros de sintonia do SGBD.
2.5Operação do sistema de auto-sintonia
Nessa seção descreveremos a operação do sistema de auto-sintonia.
O sistema executa dois tipos de processos diferentes: estes são con-
�guração e ajuste. A seguir descrevemos em detalhes ambos os tipos de
processos.
2.5.1Con�guração
Este processo consiste na determinação dos valores iniciais dos parâ-
metros de con�guração que otimizem o desempenho do sistema e o ajuste
dos parâmetros de controle até atingir esses valores. A operação é similar
à do Con�guration Advisor do DB2 [32], que oferece recomendações para
a con�guração destes sistema. Ele deve ser executado no início da opera-
ção do sistema de auto-sintonia e toda vez que o sistema observado tivesse
mudado de tal forma que se justi�quem mudanças radicais. É altamente
recomendável que um processo desse gênero seja executado o�-line ou em
horários de pouca atividade, pois os modelos podem incluir imprecisões que
prejudiquem o desempenho.
A determinação dos parâmetros em [32] se baseia na modelagem ana-
lítica do sistema combinando informação relacionada com características do
ambiente que são especi�cadas pelo usuário, as características do sistema e
o conhecimento de especialistas em sintonia do DB2. Os resultados experi-
mentais indicam que as soluções obtidas não melhoram aqueles obtidos por
especialistas em sintonia, mas ultrapassam de forma considerável o desem-
penho do sistema com os valores de con�guração pré-determinados.
6Não existe uma outra solução viável que melhore pelo menos um e não piore nenhumdos objetivos.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 27
Após terminado o processo de con�guração e com o sistema já servindo
a cargas de trabalho reais, é possível iniciar o processo de auto-sintonia
(comentado a seguir) que objetiva ajustar parâmetros de controle do SGBD
de forma a melhorar o seu desempenho.
2.5.2Processo de auto-sintonia genérico
Nessa seção são analisados brevemente os desa�os para a implemen-
tação das distintas etapas do processo de auto-sintonia. Assumiremos aqui
como etapas do processo a observação, a análise, o planejamento e a ação.
Observação
O monitoramento ou observação é a primeira e mais importante etapa
do ciclo de controle [66]. Trata-se da captura de uma imagem do estado do
sistema em intervalos que dependem da dinâmica de cada parâmetro.
Vários problemas comprometem esta etapa:
� Existe um compromisso entre o fato de que a observação deve ser
pouco intrusiva para não interferir nos resultados nem sobrecarregar
o sistema e que a freqüência de execução deva ser su�cientemente alta
para garantir a acurácia da medição e a reação imediata em caso de
problemas de sintonia.
� A escolha das métricas que caracterizam o desempenho do sistema é
um dos problemas fundamentais a resolver nesta etapa [66]. Devem ser
preferivelmente independentes de outras variáveis como, por exemplo,
o tempo de observação.
� Normalmente as informações coletadas são armazenadas para poste-
rior análise em um repositório de histórico. Dependendo da freqüência
de amostragem, do tipo e da quantidade de métricas observadas, o vo-
lume deste repositório pode tornar-se consideravelmente grande.
A coleta de dados pode efetuar-se usando uma das seguintes técnicas:
� Por eventos: A informação se coleta quando acontecem determinados
eventos. Usualmente a instrumentação deste tipo de medição consiste
em inserir código em lugares especí�cos do programa controlado.
Quando esses eventos acontecem com freqüência, pode ser introduzida
uma grande sobrecarga no processo de medição. Dado que a freqüência
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 28
dos eventos não pode ser controlada, a sobrecarga da medição se torna
imprevisível, o que é uma das maiores desvantagens desse método.
� Por amostragem: Nesse modo, a informação é coletada em intervalos
prede�nidos especi�cados no inicio da sessão de monitoramento. A
sobrecarga nesse caso depende de dois fatores: número de variáveis
observadas e tamanho do intervalo de amostragem. Longos intervalos
de amostragem geram baixas sobrecargas, mas a diminuição das
amostras provoca por outro lado a redução da acurácia da medição.
Comparado com o modo de eventos, fornece uma observação menos
detalhada.
Devido ao fato de que os sensores usam os mesmos recursos que
estão medindo, dependendo do nível de sobrecarga introduzido, podem
ser obtidos dados errôneos. Detalhes de implementação podem provocar
também leituras errôneas. Em [46] se reportam problemas de precisão dos
dados causados pela inexatidão das ferramentas de linha de comandos do
sistema operacional, que levaram os desenvolvedores do sistema a coletar os
dados acessando diretamente o núcleo do sistema.
Os sistemas comerciais de gerência de desempenho oferecem soluções
interessantes ao problema do monitoramento. Por exemplo, o Veritas In-
depth para Oracle [63] coleta as informações diretamente da área de memó-
ria compartilhada (SGA). Estas informações são armazenadas em arquivos
locais que são carregados em intervalos regulares em um repositório (Per-
formance Warehouse) que pode estar situado em outro servidor. A idéia
deste repositório é comum entre os trabalhos que propõem sistemas de auto-
sintonia [11, 39] e entre as ferramentas de análise de desempenho [34], pois
fornece dados históricos que permitem analisar situações passadas.
Análise
Um sistema de auto-sintonia deve procurar continuamente a existência
de métricas cujos valores não satisfaçam as expectativas especi�cadas, indi-
cando problemas de desempenho. A detecção de problemas de desempenho
potenciais, que corresponde à abordagem pró-ativa, requer a implementação
de algoritmos que, baseados em análises do repositório de dados históricos,
consigam extrair informações que indiquem a necessidade da execução de
ações corretivas. A escolha da técnica depende da disponibilidade e exatidão
dos dados históricos nos quais se baseia a análise, o horizonte da predição
e dos padrões contidos nos dados [26]. Entre os padrões possíveis estão os
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 29
de tendência, cíclico, sazonal e estacionário. O padrão de tendência re�ete
uma função que tende a crescer ou a decrescer em função do tempo, en-
quanto o estacionário exibe uma média constante. Tanto o padrão sazonal
como o cíclico apresentam �utuações, a diferença entre um e outro está na
periodicidade dessas �utuações.
Idealmente a detecção pró-ativa seria su�ciente. No entanto, na prá-
tica é possível que alguns problemas sejam detectados somente depois de
manifestarem-se.
Fatores decisivos para a efetividade desta etapa são, entre outros:
� a de�nição do intervalo admissível para cada parâmetro -dependendo
dos limites, problemas podem não ser detectados ou, pelo contrário,
gerar falsos alarmes-;
� a técnica escolhida para executar a análise -comumente a análise de li-
mite. É muito importante que esta técnica seja capaz de detectar todos
os problemas a partir de determinada severidade, ou a con�abilidade
do sistema comprometeria a sua utilidade.
É possível que em um determinado SGBD o sistema de auto-sintonia
não consiga resolver um problema de desempenho dado por causa das
limitações de recursos ou por falta de mecanismos que permitam ajustar
a con�guração. Entretanto, a detecção destes problemas é crítica para o
sucesso do sistema.
Um problema a resolver nessa etapa é saber distinguir se as mudanças
na resposta do sistema se devem à mudanças no padrão de carga de trabalho
ou à reação do SGBD a ajustes de sintonia. Esse problema se torna ainda
mais crítico devido à demora da realimentação, pois dependendo do caso
em particular a reação do sistema pode demorar um tempo indeterminado
em manifestar-se. Esta é uma das causas pelas quais é preferível executar
os ajustes o�-line ou em horários de pouca carga de trabalho. No entanto,
modelos de carga de trabalho podem ajudar nesse sentido, conforme pro-
posto em [7]. Uma outra opção possível é utilizar SGBD teste. Nesse caso as
modi�cações seriam testadas em réplicas do SGBD operacional submetidas
à carga de trabalho real de forma a não afetar o trabalho do sistema.
Após a detecção de um problema de desempenho, providências deverão
ser tomadas para a sua resolução. Segundo [18], os métodos baseados
na remoção sucessiva de gargalos se demostraram úteis para melhorar o
desempenho. Isso sugere que, ainda que sejam detectados vários problemas
de desempenho de uma vez, a resolução deve ser seqüencial pois a reação
do sistema pode não eliminar os problemas restantes como também criar
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 30
novos problemas. Os métodos para detectar e resolver esses problemas serão
comentados a seguir.
Planejamento
Nessa etapa o problema é diagnosticado de forma a determinar suas
verdadeiras causas. Em seguida são enumeradas as ações que podem corrigir
o problema detectado.
O objetivo do algoritmo de diagnóstico é localizar a causa do problema
em tempo mínimo. Existem inúmeras publicações e produtos comerciais
relacionados com o diagnóstico de problemas de desempenho em sistemas
de computação em geral e de SGBDs em particular. Em [34] são estudadas
algumas ferramentas de gerência de desempenho de SGBDs. A respeito
do diagnóstico, estas ferramentas conseguem sugerir recomendações para
resolver problemas de desempenho baseadas em sistemas especialistas. De
novo nessa etapa é importante a utilização do repositório, pois nele é
mantido um registro de dados temporais que permitem correlacionar eventos
gerados por diferentes módulos do sistema para detectar a verdadeira causa
do problema. Em qualquer caso, o diagnóstico de desempenho em um SGBD
é uma atividade inerentemente global, por causa das interações já discutidas.
A grande quantidade de métricas usualmente disponíveis nos SGBDs
leva à sugestão de métodos que permitam estreitar o espaço de busca das
variáveis relacionadas com a verdadeira causa do problema de desempenho.
Em linha com esta abordagem é proposta em [36] uma hierarquia de
produtores e consumidores que representam os componentes do SGBD,
como mostra a �gura 2.3. Os recursos primários ocupam o nível mais baixo
da hierarquia como produtores e os processos ou usuários o mais alto, como
consumidores. No nível intermediário encontram-se os subsistemas do SGBD
que consomem recursos para servir aos consumidores do nível superior. Em
cada ponto da hierarquia são feitas amostragens para checar o estado do
sistema.
Esta representação facilita a compreensão das relações causa-efeito,
dado que os efeitos do problema de sintonia podem manifestar-se em um
componente diferente daquele que o está causando. Desta forma problemas
surgidos nas leituras das amostragens podem ser relacionados com as causas.
Enquanto um processo de sintonia nesta etapa retornaria a causa do
problema e, em alguns casos, possíveis soluções para resolvê-lo, a auto-
sintonia precisa determinar os ajustes que podem solucionar o problema de
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 31
Figura 2.3: Cadeia de Consumo em SGBDs [36]
desempenho, assim como os novos valores que deverão ser atribuídos aos
parâmetros de sintonia.
Qualquer que seja o método escolhido para a geração das possíveis so-
luções, após a enumeração de possíveis alterações deve haver uma avaliação
para quanti�car o desempenho que será obtido recon�gurando o sistema a
partir de cada uma das possíveis soluções com a carga de trabalho atual.
Testar as possíveis soluções diretamente sobre o sistema pode levar a insta-
bilidade dado que a reação não é totalmente conhecida. Nesse caso os testes
somente poderão ser executados em momentos de pouca carga de trabalho
ou durante o processo de instalação. Ou então efetuando os ajustes progres-
sivamente em intervalos pequenos como sugere o método de Ajuste Incre-
mental [25]. De outra forma, uma representação ou modelo do sistema será
necessária para poder avaliar o impacto das mudanças no sistema. Alguns
problemas que podem apresentar as soluções propostas são enumerados em
[64]:
� Relação custo-benefício inviável.
� Con�ito: ações contraditórias de�nidas para um mesmo recurso que
se anulariam mutuamente.
� Restrição: características do componente, carga ou ambiente em exe-
cução limitam a aplicação da ação (exemplo: limitações em tempo de
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 32
reação ou memória disponível).
Ação
A etapa de ação é a última do ciclo de auto-sintonia. Embora a lista de
ajustes já tenha sido de�nida na etapa anterior, algumas decisões deverão
ainda ser tomadas.
Tomemos por exemplo o algoritmo proposto em [66] para o controle
de carga orientado a con�itos de bloqueio. Nesse trabalho foi identi�cada
uma métrica para a detecção de problemas de bloqueio, denominada razão
de con�itos (con�ict ratio), que mede a razão entre o número total de
bloqueios obtidos e a quantidade deles possuídos por transações ativas. O
valor crítico da razão de con�itos em que o sistema começa a sofrer thrashing
de contenção de dados foi determinado experimentalmente (coincidindo com
a determinação teórica desenvolvida em [59]). Este valor está em torno de
1.3, quase independentemente da carga de trabalho. Esta independência da
carga, e o fato de ser um valor limite constante, são as características mais
importantes dessa métrica pois não é necessário qualquer ajuste. Por outro
lado, o caso do algoritmo para a execução das ações de controle é diferente.
Ele se divide em dois processos: um processo de controle de admissão de
novas transações e um de cancelamento de transações em execução. Várias
opções podem ser assumidas na implementação destes métodos. Assim, uma
solução ingênua pode ser colocar em uma �la todas as novas transações que
chegarem ao sistema durante o tempo em que a variável razão de con�ito
permanecer em valores maiores de 1.3. Porém, tal decisão pode afetar
desnecessariamente o desempenho do sistema no caso de reter transações
que não precisem dos objetos bloqueados que estão provocando contenção
de dados.
Outras abordagens para este problema requerem conhecimento dos
objetos que serão afetados durante o processamento da transação. Da mesma
forma, no processo de cancelamento existem vários critérios possíveis a
assumir na escolha das transações vítimas. Estas podem ser escolhidas por
número de bloqueios requisitados, por tempo de processamento, por custo,
entre outras, sendo que algumas decisões podem ser boas para alguns casos
e ruins para outros. Embora a métrica do problema seja independente da
carga, o processo de sintonia acaba não o sendo por causa da relação da
etapa de ação com a carga de trabalho.
Novos problemas de desempenho decorrentes da reação do sistema à
execução de ações de auto-sintonia deverão ser detectados pelos mecanismos
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 33
anteriormente discutidos, fechando-se assim o ciclo de realimentação. O
fato de que a concorrência de vários processos de auto-sintonia di�culta
esta detecção sugere a implementação de um mecanismo de escalonamento,
que execute em nível de sistema um processo de cada vez, sendo que
um processo de sintonia pode estar composto por uma ou várias ações.
Algumas alternativas podem ser avaliadas, como por exemplo, a introdução
de prioridades e o cancelamento de atividades que não sejam mais válidas
quando é chegado o momento da execução.
A implementação desses processos é complexa e precisa de uma
abstração que ofereça adaptabilidade e reatividade. Os agentes de software
possuem características como pró-atividade e aprendizado [7, 33, 73] que
podem ser úteis na implementação de sistemas de auto-sintonia. Estudos
de agentes de software formando parte de SGBDs para aumentar sua
�exibilidade e adaptabilidade foram realizados em [11, 40, 62].
2.5.3Agentes para auto-sintonia
A construção de sistemas de auto-sintonia usando agentes foi abordada
em [7, 11]. Em [11] foi usada a arquitetura proposta em [33], que apresenta
um framework para o projeto e implementação de agentes de software. A
arquitetura está organizada em camadas verticais e permite, com relativa
simplicidade, a construção de agentes com capacidades pró-ativa e reativa.
É possível mapear as etapas do processo de auto-sintonia proposto em [11]
às camadas deste modelo, como mostra a �gura 2.4. Por sua vez, essas
etapas podem ser mapeadas diretamente com as quatro etapas propostas
do processo de auto-sintonia nesse trabalho, que são observação, análise,
planejamento e ação.
A arquitetura apresentada tem duas passagens: ocorre um �uxo da
camada inferior à superior e outro em sentido contrário. A camada inferior
monitora o estado do ambiente e atualiza as crenças, que ativam um
procedimento na camada de raciocínio. Este procedimento pode gerar tanto
planos a serem executados na camada de Ação como mensagens a serem
preparadas e enviadas pela camada de Colaboração. As outras camadas
tratam os problemas da tradução de mensagens e mobilidade do agente. Já
no agente receptor o processo percorre o sentido contrário. Assim, a camada
superior recebe as mensagens que são repassadas à camada de Raciocínio.
Esta pode ou não atualizar as crenças e/ou executar modi�cações na camada
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 34
Figura 2.4: Etapas de um processo de auto-sintonia [11]
Sensor, assim como gerar novos planos. Nesta con�guração, a percepção e
a ação estarão envolvidas cada uma com uma camada no máximo.
Este trabalho se baseará nessa arquitetura de agentes. Outras arqui-
teturas podem ser revisadas em [73].
2.6Motivação da pesquisa
O foco desta dissertação está na sintonia global de SGBDs, dado que
existem situações em que ajustes independentes não são su�cientes para
garantir um bom desempenho. Acreditamos que a implementação de tais
sistemas é factível, mesmo que não existam ainda SGBDs comerciais com
auto-sintonia global [34]. O objetivo do trabalho é a automatização da tarefa
dentro do possível e não a substituição total dos DBAs, o que de qualquer
forma deve redundar em uma diminuição dos custos de manutenção dos
SGBDs e no aumento da sua disponibilidade.
Seguimos a linha de trabalho do nosso grupo de pesquisa cujo interesse
é a utilização de agentes de software para aumentar as funcionalidades dos
sistemas de bancos de dados. Este trabalho em particular está aprofundando
uma idéia colocada em [11] no contexto de uma proposta para um sistema de
auto-sintonia de índices baseado em agentes, em que se menciona a forma
em que o componente de auto-sintonia poderia inserir-se em um sistema
formado por outros agentes de auto-sintonia.
O objetivo dessa pesquisa é criar um componente de auto-sintonia
global baseado em agentes que possa ser embutido dentro de um SGBD.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 35
Entra, portanto, dentro da classi�cação de sistemas de auto-sintonia por
adaptação (veja [34]).
2.7Conclusões
Nesse capítulo apresentamos alguns conceitos relacionados á nossa
pesquisa, como são os agentes de software, assim como as considerações que
serão assumidas ao longo do trabalho. Foi mostrado um panorama geral das
abordagens atuais para a realização de sintonia e auto-sintonia de SGBDs.
Finalizamos com as motivações que originaram o presente trabalho.
No próximo capítulo discutiremos possíveis abordagens para o pro-
blema da auto-sintonia de SGBDs usando agentes. Mostraremos os proble-
mas que devem ser resolvidos e, �nalmente, proporemos uma arquitetura
para a auto-sintonia global de sistemas de bancos de dados usando agentes.
3
Arquitetura
Neste capítulo serão sugeridos um conjunto de requisitos que devem
ser satisfeitos pelos sistemas de auto-sintonia e serão discutidas possíveis
arquiteturas para sua construção usando agentes.
3.1Requisitos
A meta fundamental do sistema de auto-sintonia global é garantir que
o SGBD controlado mantenha um bom desempenho. Para satisfazer esse
objetivo é proposto nesta dissertação que o sistema deva cumprir um grupo
de requisitos, a saber:
1. A correção na detecção e diagnóstico de problemas de desempenho
crítico1 que o SGBD possa sofrer. Nesses casos os problemas devem
ser corrigidos imediatamente se for possível (se não for possível o
administrador do sistema deverá ser noti�cado).
2. Não tornar o SGBD indisponível. É necessária uma cuidadosa imple-
mentação do sistema de forma a evitar que erros de programação ou
ações do sistema de auto-sintonia possam deixar o SGBD indisponível.
3. Não introduzir instabilidade no SGBD. Este requisito se aplica a ajus-
tes on-line e se refere a evitar oscilações e outros tipos de comporta-
mento errôneo que podem ser causados pelos ajustes.
4. Não alterar os serviços do SGBD. Por exemplo, o sistema de auto-
sintonia não pode fazer com que o SGBD comece a devolver dados
aproximados para aumentar o desempenho. Qualquer decisão desse
tipo cabe apenas ao administrador.
1situações em que esteja em risco a disponibilidade do SGBD ou em que o desempenhoseja inadmissível sob a ótica dos usuários
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 37
5. Garantir que a sobrecarga provocada pelo sistema de auto-sintonia
seja inferior ao benefício gerado.
Têm sido identi�cados também um grupo de requisitos desejáveis:
1. Ser pró-ativo. O sistema deverá ser capaz de detectar e corrigir situa-
ções que indiquem futuros problemas de deterioração de desempenho.
2. Requerer do administrador do sistema a mínima intervenção possível.
3. A interação com o administrador deve ser a alto nível, de forma que
ele não precisará dominar detalhes da arquitetura interna do SGBD
para interagir com o sistema de auto-sintonia.
4. Comportar-se melhor que a simples união de mecanismos de auto-
sintonia isolados.
Os trabalhos existentes em auto-sintonia global satisfazem parcial-
mente esses requisitos. Assim, a tendência à pró-atividade está presente
tanto nos sistemas comerciais [63, 72] como nos trabalhos acadêmicos [11,
55, 61, 64]. Por outro lado, os detalhes de implementação do sistema que
devem ser seguidos para manter a disponibilidade do SGBD não têm sido
muito comentados. O fato de que o administrador é que toma as decisões �-
nais afeta a correção imediata de problemas críticos. A intenção de requerer
do administrador do sistema uma intervenção mínima e a nível de objetivos
do negócio é também uma tendência atual [34]. Estudos sobre como limitar a
sobrecarga gerada pelo sistemas de auto-sintonia �caram como trabalhos fu-
turos em [8, 9], pelo que concluímos que não é ainda um problema resolvido.
Outro problema igualmente não resolvido identi�cado em [9] (relacionado
com o requisito 8) é como garantir que o processo de diagnóstico alcance
o desempenho ótimo do SGBD. O requisito de se comportar melhor que a
simples união de componentes isolados não é válido em trabalhos anteriores,
pois nenhuma das propostas revisadas trata o problema da combinação de
componentes de auto-sintonia dentro do SGBD.
Os requisitos propostos sugerem alguns princípios para a construção
de sistemas desse gênero, tanto no que se refere ao processo de sintonia
como à integração dos agentes com o sistema.
Dado que as interações no sistema fazem com que as reações às ações
de sintonia não sejam totalmente previsíveis o sistema de auto-sintonia pre-
cisa de um mecanismo que permita controlá-las. A prática tem demonstrado
a efetividade do ciclo de controle de realimentação como método de controle
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 38
do processo de auto-sintonia [18, 28, 66]. Combinado com políticas conserva-
doras de ajuste, esse método pode garantir a satisfação do requisito número
3.
A etapa de planejamento deverá conferir o custo da operação, de
forma que se ele for maior que o ganho a ação não deverá ser executada,
satisfazendo o requisito de baixa sobrecarga (requisito 5). Às ações podem
ser associados custos, de forma que será possível escolher a de menor custo
entre um grupo de ações candidatas. Nesse sentido também pode ser levada
em conta a idéia de priorizar as consultas mais importantes e controlar as
métricas seguindo uma hierarquia, como proposto em [8].
Para cumprir o requisito de manter a estabilidade do sistema, testes
on-line devem ser evitados exceto em momentos de pouca carga de trabalho.
Pode ser criado, para cada sistema, um modelo que descreva a resposta para
uma con�guração e uma carga de trabalho determinadas. Este modelo pode
ser gerado de várias formas. Uma delas é construí-lo com redes neurais
como proposto em [7], outra pode ser extraí-lo em forma de regras [9] a
partir dos dados coletados pelos sensores, armazenados no repositório de
desempenho como tuplas que relacionam grupos de valores dos parâmetros
de sintonia e as respectivas métricas de desempenho resultantes para cada
carga de trabalho. Inicialmente os dados podem ser gerados usando uma
carga padrão como TPC-C [58] e modi�cando os controles de sintonia para
obter a resposta do sistema para diferentes con�gurações.
A obtenção das métricas de desempenho deve minimizar o consumo
de recursos de sistema para não comprometer a sua correção nem afetar o
sistema observado.
Objetivando reagir ante manifestações de problemas de desempenho
(requisito 8), deverão coletar-se continuamente amostras dos parâmetros
que caracterizam o desempenho do sistema. Estas métricas devem ser
cuidadosamente escolhidas como discutido no capítulo anterior. Os dados
coletados devem ser checados periodicamente para detectar violações das
políticas de sintonia (veja a seção 2.5.2). A detecção de tais violações devem
gerar um processo para o diagnóstico do problema e ajuste de parâmetros de
controle. Esse processo deverá continuar até que sejam satisfeitas as políticas
de sintonia ou então que não seja possível executar ações que resolvam o
problema de desempenho. O sistema de auto-sintonia deve incluir, entre as
possíveis soluções dos problemas de falta de recursos, a opção de desligar-se
para liberar seus recursos em favor do SGBD (requisito 2).
As amostragens devem ser pouco intrusivas para não sobrecarregar o
sistema (requisito 5). Os dados coletados serão armazenados em repositó-
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 39
rios de desempenho a �m de permitir a detecção de padrões que indiquem
problemas que estão por surgir (requisito 1). Nesse repositório são também
mantidas outras informações, tais como as políticas ou objetivos de sinto-
nia. A de�nição destas políticas permite ao administrador de�nir as suas
necessidades em termos de políticas da empresa, afastando-o dos detalhes
do sistema (requisito 3).
A construção de um sistema global não se justi�ca se a simples
combinação de mecanismos isolados de auto-sintonia for mais bené�ca.
Nesse sentido, medidas deverão ser tomadas como, por exemplo, limitar
a sobrecarga causada pelos mecanismos de coordenação (requisito 4).
A seguir discutiremos à integração dos agentes com o sistema. Nesse
sentido, é preciso desenvolver uma arquitetura que faça com que as ações dos
agentes convirjam com os objetivos globais do sistema de auto-sintonia. Um
sistema coerente pode ser construído através de um controle global ou da
cooperação entre seus componentes(veja a seção 2.1). Essas duas abordagens
são discutidas nas seções 3.3 e 3.4.
3.2Propostas de Arquitetura
Uma abordagem para o desenvolvimento de uma arquitetura para a
construção de sistemas de auto-sintonia é a integração de módulos que im-
plementem resultados de estudos sobre auto-sintonia local, sendo que cada
módulo pode ser constituído por um ou mais agentes. No desenvolvimento
dessa arquitetura devem ser destacados vários detalhes importantes:
1. Nos sistemas comerciais existem usualmente uma grande quantidade
de parâmetros de ajuste. Por isso, não é uma boa solução armazenar
todas as medidas que descrevem a reação do sistema considerando
todos os parâmetros de ajuste para cada uma das cargas de trabalho
possíveis.
2. Existem estudos sobre auto-sintonia local para quase todos os compo-
nentes de um SGBD. Alguns deles têm sido testados em sistemas reais
e inclusive implementados em sistemas comerciais [34]. Esses estudos,
em geral, descrevem o processo de auto-sintonia de um determinado
aspecto, desde a detecção até o ajuste. Entretanto, eles fazem determi-
nadas considerações com respeito ao estado do SGBD [49] que podem
ser inválidas em determinado momento, ainda que se possa esperar
que essas situações não aconteçam na maioria dos casos.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 40
3. A maior parte das propostas não leva em conta os outros componentes
do sistema, inclusive aqueles que podem causar um desvio similar nas
métricas de sintonia. Isto implica que a integração destas propostas
dentro do mesmo sistema pode ter efeitos inesperados. Por exemplo,
em [66] se descreve a situação em que uma carga mal balanceada
entre os discos provoca demoras em alguns acessos que podem fazer
com que aumente a duração de alguns bloqueios. Se a contenção
de dados chegar a um nível crítico, o mecanismo proposto nesse
trabalho A.2 reagiria detendo a admissão de novas transações no
sistema e cancelando algumas das transações em curso, causando a
sobrecarga da CPU por causa do processamento causado pelo reinício
das transações.
4. Conforme concluído em [16] nem sempre a combinação dos resultados
oferecidos pelos algoritmos de análise de um processo de auto-sintonia
é a melhor solução no nível global.
5. A complexidade de alguns processos de diagnóstico e ajuste justi�ca
sua execução separada do trabalho do sistema, em um processo
concorrente. Este é o caso da proposta em [50], na qual um processo
de coleta de consultas SQL submetidas deve ser executado em paralelo
a um processo de escalonamento de ações de criação e destruição
de índices e a outro de análise. Enquanto o processo de coleta é
executado por um agente dentro do sistema, os restantes executam
fora do sistema a �m de satisfazer o requisito de baixa sobrecarga
(requisito 5).
6. Os mecanismos que integram a etapa de ação de um componente
de auto-sintonia local podem ser úteis aos outros componentes do
sistema. É o caso do algoritmo de controle de admissão que forma
parte do mecanismo de controle de contenção de dados. Ele pode ser
usado por outro mecanismo que precise do controle do número de
transações concorrentes no sistema.
7. Conforme discutido na seção 2.5.2, o reconhecimento da causa da
deterioração de desempenho é facilitada se os processos de sintonia são
executados um de cada vez, separados por intervalos que dependem
do tempo de reação do sistema ao ajuste em particular, e do intervalo
de monitoramento.
Dessas constatações podemos concluir que pode resultar em benefício
a implementação de algumas das propostas de auto-sintonia local dentro
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 41
de um sistema de auto-sintonia global. Entretanto, a introdução dessas
propostas requer uma arquitetura que garanta o caráter social que devem ter
o diagnóstico e o escalonamento das ações a executar (veja a seção 2.5.2).
Essa é a motivação da nossa proposta de arquitetura para auto-sintonia
global.
Essa arquitetura consiste basicamente em um grupo de agentes que
controlam os diversos módulos do SGBD e em uma base de conhecimento
que armazena toda a informação relativa ao estado do SGBD e as ações
executadas pelos agentes, assim como as interações entre os componentes
do SGBD (regras, con�itos) e os objetivos dos usuários. Os acessos á base
de conhecimento podem ser executados através de um Agente de Histórico.
Outros agentes podem ser incorporados à infra-estrutura do sistema, como
será discutido nas seções seguintes. A combinação do trabalho dos agentes
permite não só coordenar o trabalho como também aproveitar os recursos
oferecidos por cada um deles, como seria o caso do módulo de coleta
de consultas proposto em [50] que seria útil para que o sistema tivesse
conhecimento da carga de trabalho submetida.
O relacionamento entre os agentes na arquitetura proposta dependerá
do grau de distribuição do controle do sistema. Desta forma podem ser
construídas versões decorrentes dessa magnitude que vão desde a abordagem
totalmente centralizada até a totalmente distribuída.
Em cada caso é importante para o sucesso de um sistema que siga
quaisquer destas abordagens, que os agentes que o compõem cumpram
determinados compromissos sociais (aqueles que estabelecem os agentes
entre si dentro da sociedade). Para os efeitos dessa proposta em particular,
consideramos que os agentes que integram o sistema devem cumprir os
seguintes compromissos:
� Os agentes são honestos. Não cabem no sistema atitudes como a
de ocultar informação, informar dados errôneos propositadamente ou
aceitar tarefas que não serão executadas.
� Os agentes formam parte de uma sociedade e não podem executar de
forma independente tarefas inerentemente sociais.
3.3Abordagem centralizada
A abordagem centralizada proposta é bem semelhante à forma como
é executado o processo de sintonia no mundo real. Ou seja, o administra-
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 42
dor recebe informações de problemas de desempenho no SGBD e efetua uma
análise para resolvê-los. Essa análise baseia-se nas métricas coletadas, na do-
cumentação do sistema, na experiência do administrador e, possivelmente,
em alguma ferramenta oferecida pelo sistema ou por terceiros. Com essas
informações o administrador determina as causas prováveis do problema
e começa a executar ajustes, enquanto observa a reação do sistema para
desfazê-los no caso de mostrarem-se negativos para o desempenho do sis-
tema. A abordagem centralizada apresentada na �gura 3.1 permite executar
esta metodologia substituindo o administrador por um agente de software.
Figura 3.1: Abordagem centralizada para auto-sintonia global
Nessa arquitetura o processo consiste em um agente que comanda a
execução de ações de sintonia quando recebe alguma noti�cação dos senso-
res de que alguma métrica não está respeitando os valores esperados. Nessa
abordagem os agentes que estão relacionados diretamente com os recursos
são meramente sensores e efetuadores, comprometendo seriamente sua au-
tonomia a tal ponto que estes podem ser substituídos por objetos. O agente
central é o único que domina a visão global do sistema e portanto é quem
pode determinar qual é a verdadeira causa do problema de desempenho,
dado que um sintoma pode ter diferentes causas. Isto implica que o único
agente do sistema com poder para comandar a execução de ações é o agente
coordenador, coincidindo com a proposta de [8]. Para efetuar as análises,
ele precisará dominar o signi�cado de cada variável, assim como particu-
laridades dos mecanismos disponíveis no sistema que permitam resolver o
problema.
Problemas presentes nessa arquitetura, como a di�culdade de expan-
são, a falta de autonomia dos agentes e a dependência do agente coordenador
nos levam a uma arquitetura onde o controle e os dados estejam mais dis-
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 43
tribuídos entre todos os agentes componentes do sistema, como veremos a
seguir.
3.4Abordagem distribuída
Na abordagem distribuída o controle (e o conhecimento) se encontram
distribuídos pelo sistema. Na �gura 3.1 apresenta-se uma proposta que segue
a abordagem distribuída para auto-sintonia global de SGBDs.
Figura 3.2: Arquitetura distribuída para auto-sintonia global
Essa arquitetura é formada por um agente analisador, agentes compo-
nentes e o agente de histórico que controla a base de conhecimento. Os agen-
tes componentes contêm mecanismos que permitem variar os parâmetros de
sintonia e os oferecem como serviços aos outros agentes. Nessa variante
as funções de análise se distribuem pelo sistema, de modo que os agentes
componentes tomam parte também na geração das soluções. A resolução
distribuída de um problema de desempenho é descrita a seguir:
1. Durante a etapa de monitoramento cada sensor coleta as métricas de
desempenho.
2. Os dados coletados são ora enviados ao agente de histórico, que oferece
um serviço de registro com esse propósito, ora mantidos pelo próprio
agente, sendo que no último caso algum mecanismo deverá existir
que permita aos outros agentes ter acesso a esses dados. O fato de
que existe uma grande quantidade dessas métricas indica que não é
possível trafegá-las livremente dentro do sistema.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 44
3. Os dados coletados são comparados com as expectativas. Se for
detectado um problema de desempenho, um processo de sintonia deve
ser iniciado.
4. A etapa de planejamento objetiva a determinação da causa do pro-
blema e a elaboração de um plano de ações (ou intenção) que deve
resolvê-lo. As decisões do agente analisador tem a maior prioridade,
pois ele tem acesso às informações contidas na base de conhecimento
relativas a restrições e con�itos. Os agentes componentes relaciona-
dos com o problema podem elaborar propostas que podem ser eleitas
desde que não violem essas restrições.
5. As ações enumeradas no plano resultado são escalonadas para ser
executadas por agentes com as devidas capacidades. As solicitações de
execução de ações são feitas em forma de requisições por serviços. A
execução de cada tarefa está reservada ao agente que sugeriu a solução
selecionada para execução, mas este pode delegá-la a qualquer agente
que ofereça o serviço. Um dos protocolos mais usados para alocação
de tarefas é o Contract Net [73].
Esta metodologia pode ser melhor compreendida através de um exem-
plo. Durante a etapa de monitoramento um sensor coleta dados de vazão
média no sistema, que são enviados pelo agente para o repositório. No caso
em que o valor médio foi menor que o valor esperado para esta métrica,
uma mensagem de alarme é enviada ao sistema. O agente analisador envia
uma mensagem anunciando um problema de "vazão baixa", a partir da qual
os agentes relacionados com o problema reconhecem que irá começar uma
sessão de planejamento.
Cada agente convocado pela mensagem pode oferecer a sua solução
para o problema. Um agente implementado seguindo a proposta de [25] irá
diminuir o MPL assim que a vazão descer, e começará aumentá-lo quando a
queda da vazão parar. O agente encarregado do controle de páginas em
bu�er irá sugerir a troca de estratégia de substituição se for detectado
uma varredura seqüencial muito longa. Um agente de índices pode sugerir a
destruição de um índice que está causando um elevado nível de bloqueios. E
o agente analisador, segundo o modelo, irá sugerir a diminuição do MPL ou
detenção temporal da aceitação de novas transações. Nesse caso somente as
propostas de controle de MPL entram em con�ito. Considerando que não
tenham sido encontradas situações similares no histórico que provocassem
deterioração do desempenho, todas as propostas serão executadas exceto
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 45
aquela de controle de MPL que entra em con�ito com a proposta do agente
analisador. Estas ações serão escalonadas para execução seqüencial.
Quanto a qual será o grupo de agentes que receberá a mensagem de
convocação, a mensagem pode ser um broadcast a todos os agentes do
sistema multi-agentes. Nesse caso a vantagem é que não se precisa saber
de antemão a lista de agentes relacionados com cada problema, enquanto a
desvantagem é a sobrecarga desnecessária que representa no que diz respeito
às comunicações. Uma possibilidade mais atraente pode ser aproveitar o
processo de inscrição do agente na entrada no sistema multi-agentes, para
registrar também os problemas que está capacitado para resolver.
Os resultados obtidos por cada agente envolvido no problema podem
ser diferentes. O intercâmbio de resultados entre os agentes oferece todas as
soluções disponíveis que o sistema de agentes pode acionar para resolver um
determinado problema. Cada agente formula o resultado de acordo com o
seu próprio algoritmo e a sua visão do sistema. Embora essa solução implique
em um esforço inútil para os agentes cujas soluções não serão escolhidas,
o dinamismo que oferece introduz vantagens tais como os agentes poderem
entrar no sistema no meio da execução sem precisar de recon�guração e
experimentarem alternativas não previamente consideradas.
Os custos de sobrecarga que implica esta alternativa podem ser reduzi-
dos concentrando a negociação em um repositório comum como o oferecido
nas arquiteturas de blackboards. Um blackboard é um repositório comparti-
lhado que permite intercâmbios indiretos de informação entre fontes inde-
pendentes. Durante a resolução de um problema os especialistas trabalham
cooperativamente, acrescentando suas contribuições ao blackboard toda vez
que tem informação su�ciente para fazê-lo, em um processo que continua até
o problema ser resolvido [24]. Esta opção permite também que o agente não
precise conhecer a quem noti�car as decisões. Por outro lado, o blackboard
precisa de um elemento de coordenação que introduz novamente problemas
da arquitetura centralizada. No entanto, a vantagem é que ao pertencer à
infra-estrutura do sistema, este elemento não precisa ser alterado toda vez
que se precisa acrescentar um novo algoritmo, ao contrário do que acontece
na arquitetura centralizada. Outra vantagem está em que esses elementos
são padronizados e disponíveis, minimizando o esforço de programação e a
possibilidade de erros.
Outra possibilidade é utilizar o método de Criação-Destruição (Create-
Destruction). Segundo esse método, um grupo de agentes, cujas funções são
construtores ou destrutores, trabalham em um problema. Os construtores
incorporam novas soluções ao conjunto, enquanto os destrutores eliminam
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 46
soluções. A eliminação de soluções que não deveriam ter sido criadas deve
melhorar a qualidade da solução. Nesse caso o analisador seria basicamente
um destrutor, pois baseado nas conclusões extraídas da base de conheci-
mento pode determinar se alguma solução proposta pode dani�car o de-
sempenho.
A vantagem dessa proposta distribuída está no fato, já mencionado, de
que existem situações em que os mecanismos de auto-sintonia não oferecem a
melhor solução mas a experiência da sua utilização em sistemas comerciais
e os resultados de estudos podem mostrar sua e�cácia em boa parte das
situações. Entretanto, o processo de diagnóstico e planejamento precisa que
as decisões do agente analisador sejam sempre as mais prioritárias e que os
compromissos sociais colocados sejam cumpridos.
Uma abordagem que pode ser considerada intermediária entre a cen-
tralizada e a distribuída consiste em fazer com que o agente analisador
avalie as soluções extraídas da base de conhecimento e as propostas ofereci-
das pelos agentes. Esta variante não é totalmente distribuída e novamente
é sensível a falhas no agente analisador, mas permite um grau mais forte de
agência que a versão centralizada sem afetar a coerência do sistema além
de simpli�car o processo de negociação.
A abordagem distribuída supõe algumas vantagens sobre a centrali-
zada:
1. Maior capacidade de resposta dado que existe mais de um agente
atendendo as noti�cações e é possível a comunicação entre grupos de
agentes em separado.
2. Permite implementar métodos de sintonia distintos em componentes
separados, de forma que estes podem ser acrescentados e modi�cados
sem alterar o sistema. No caso da arquitetura centralizada o código do
componente mais sensível do sistema (o agente coordenador) deveria
ser modi�cado.
3. Permite o reuso dos resultados de estudos existentes sobre auto-
sintonia local. Este fato, além de aliviar o trabalho do agente central,
representa uma notável diminuição do esforço de programação do
sistema e facilita a sua escalabilidade.
4. Facilita a introdução progressiva de novas funções e o trabalho em
conjunto de distintos programadores.
5. Diminui a probabilidade de falhas do sistema.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 47
6. Aumenta a facilidade na introdução de novos agentes, cujas propostas
são avaliadas assim que ocorre algum problema com os recursos
relacionados com o agente.
Por outro lado, podem ser citadas algumas desvantagens da aborda-
gem distribuída:
1. Maior complexidade.
2. Os agentes precisam ter conhecimento dos outros agentes.
3. O conhecimento no sistema está disperso. As ações dos agentes devem
ser coordenadas pois a solução depende sempre do contexto global que
envolve todas as variáveis observadas.
A forma em que a arquitetura proposta satisfaz os requisitos de auto-
sintonia colocados em 3.1 é mostrada na tabela 3.4
Requisito Resolvido ComentáriosCorreção na detecção e diagnós-tico de problemas de desempe-nho crítico
Não Não existe até o momento uma forma de comprovar que o sistemaescolhe a melhor solução.
Não tornar o SGBD indisponí-vel.
Não Esse aspecto depende da implementação
Não introduzir instabilidade noSGBD.
Sim É possível introduzir nas crenças do agente os limites para as modi�ca-ções do sistema. Da mesma forma a detecção de ciclos de modi�caçõesdeve ser codi�cada como parte do raciocínio do agente coordenadorna abordagem centralizada, ou do sistema na distribuída
Não alterar os serviços doSGBD.
Não Esse aspecto não pode ser resolvido pela infra-estrutura do sistema.Em arquiteturas de integração como a embutida ou a integrada oacesso às funções do SGBD somente pode ser limitado por este. Ficapelo implementador levar em conta esse tipo de limitações
Garantir que a sobrecarga pro-vocada pelo sistema de auto-sintonia seja inferior ao benefíciogerado
Sim No caso de serem detectadas pioras no desempenho decorrentes daexecução de ações de auto-sintonia, estas devem ser desfeitas pelopróprio sistema. Ações cujo custo ultrapasse um certo limite deverãoser adiadas o impedidas de serem executadas. Idealmente, um cálculode custo benefício poderia resolver este problema, se bem este nemsempre pode ser determinado previamente.
Ser pró-ativo Sim A introdução de agentes facilita a execução de algoritmos de prediçãoque detectem problemas potenciais e iniciem processos de resoluçãodestes. O aprendizado é uma característica importante nessa tarefa.
Requerer do administrador dosistema a mínima intervençãopossível
Sim Às soluções que impliquem interação com o administrador deve seralocado um custo alto
A interação com o administradordeve ser a alto nível
Sim Na base de conhecimento podem ser armazenados mapeamentos entreos níveis
Comportar-se melhor que a sim-ples união de mecanismos deauto-sintonia isolados
Sim A arquitetura pretende corrigir os problemas decorrentes das intera-ções entre os mecanismos de auto-sintonia local
Tabela 3.1: Satisfação dos requisitos propostos para um sistema de auto-sintonia global de SGBDs na arquitetura.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 48
3.5Agentes na arquitetura
Entre as vantagens que apresenta a introdução de agentes no projeto
e implementação dessas arquitetura está a facilidade de integração de novos
mecanismos de auto-sintonia. Estes podem ser acrescentados progressiva
e independentemente um do outro, sendo a sua inter-relação gerenciada
pelo sistema. Esta é uma grande diferença entre esse trabalho e propostas
anteriores, em que os sistemas de auto-sintonia têm sido sempre tratados
centralizadamente dentro do contexto do SGBD.
A arquitetura oferece variantes para a integração do sistema de
auto-sintonia com o SGBD. No caso, dada a indisponibilidade de SGBDs
construídos seguindo a arquitetura integrada (veja a seção 2.1.1), as opções
se limitam às arquiteturas embutidas e em camadas. A arquitetura embutida
possibilita uma implementação mais e�ciente, tanto pela possibilidade de
aproveitar componentes do SGBD como por poder acessar diretamente as
funções e variáveis necessárias para efetuar o monitoramento e a execução
de ações. De outro lado, complica a implementação pois é necessário
entender o funcionamento interno do banco de dados e, possivelmente,
alterar algumas das suas estruturas. A arquitetura em camadas, por outro
lado, utiliza as interfaces que dispõe o sistema para uso público, em geral
bem documentadas e mais fáceis de utilizar. As desvantagens desta se
baseiam fundamentalmente em critérios de e�ciência.
Ambas as arquiteturas permitem integrar mecanismos de auto-sintonia
conhecidos, sendo que na abordagem centralizada seria preciso modi�car o
código do agente coordenador.
3.6Conclusões
Nesse capítulo foram apresentados os requisitos que deve satisfazer
um sistema para auto-sintonia de SGBDs. Duas abordagens de arquitetura
(centralizada e distribuída) foram propostas, e comentadas as vantagens e
desvantagens de cada uma, assim como detalhes da forma de operação.
Em seguida iremos descrever os detalhes da implementação do sistema.
O protótipo implementado foi baseado na arquitetura centralizada pois
a implementação da arquitetura distribuída de forma completa não seria
possível devido aos limites de tempo de desenvolvimento dessa dissertação.
4
Implementação
Nesse capítulo se descreve a implementação de um protótipo que im-
plementa a arquitetura centralizada proposta no capítulo 3. O protótipo
consiste de um sistema de auto-sintonia embutido em um SGBD relacional
baseado nessa arquitetura. A idéia é mostrar que é factível a implementa-
ção deste tipo de sistema, assim como testar a in�uência do MAS sobre o
desempenho do SGBD e pesquisar as di�culdades que apresenta a imple-
mentação.
Na próxima seção serão expostas questões relacionadas ao desenvol-
vimento do sistema de auto-sintonia. Finalmente será descrito um exemplo
de aplicação desse sistema embutido no SGBD PostgreSQL e uma avaliação
da factibilidade da implementação do protótipo, assim como as di�culdades
que esta tarefa apresenta.
4.1Infra-estrutura
O sistema de auto-sintonia foi projetado seguindo a arquitetura centra-
lizada descrita em 3.3. O sistema pode ser integrado com o SGBD seguindo a
arquitetura em camadas ou embutida. Esse sistema deve permitir a inclusão
de agentes componentes construídos seguindo um template oferecido pelo
sistema 1 de forma a minimizar o esforço de programação de novos agentes
componentes e a padronizar a interação entre eles. Os agentes podem tra-
balhar isoladamente (desde que não exista outro agente ativo no sistema)
ou em conjunto. Isto permite uma integração progressiva de mecanismos de
auto-sintonia no sistema de banco de dados. O template segue a arquitetura
proposta em [33], que também foi usada em [11, 40, 51] e é apresentada na
�gura 4.1.
1devido aos requisitos de e�ciência da aplicação, não foram usadas plataformas paraa implementação dos agentes
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 50
Figura 4.1: Framework para a construção de agentes [33]
Algumas desvantagens dessa arquitetura colocadas em [19] são que
alguns aspectos como a autonomia atravessam as diferentes camadas, e por
estar muito interrelacionadas, não é trivial remover ou acrescentar uma
camada. No entanto, ela foi escolhida para a implementação desse trabalho
devido a sua relativa simplicidade e o fato de que já existia uma versão
parcial disponível em C++ [51]. Nessa dissertação essa versão foi modi�cada
para incluir a camada de Colaboração e a gerência de concorrência.
A implementação está baseada em padrões de desenho orientado a
objetos como Facade e Singleton que podem ser consultados em [21].
4.1.1Gerência de concorrência
Um programa concorrente contêm dois ou mais processos que traba-
lham em conjunto para executar uma tarefa. Visando garantir um controle
contínuo da atividade do SGBD afetando no mínimo possível o seu funcio-
namento, todas as medições, assim como as ações tanto de sintonia como
de colaboração deverão ser executados por processos concorrentes.
Esses processos podem ser threads ou processos de aplicação. Enquanto
a criação de um processo de aplicação implica na duplicação do processo
pai junto com todo seu contexto, as threads são processos leves(lighweight)
que só precisam da criação de um novo contador de programa e pilha de
execução [57]. O mecanismo para escrever aplicações multithreaded em C foi
padronizado e criada a biblioteca Pthreads (POSIX API, standard 1003.1c-
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 51
1995 da IEEE), amplamente suportada.
A linguagem C++ não possui gerência intrínseca de concorrência.
As funções relacionadas estão contidas na biblioteca pthreads [57]. Para
encapsular o comportamento concorrente nesse trabalho foi criada uma
classe Thread que faz chamadas às funções desta biblioteca. As informações
no sistema são trafegadas entre os processos através de �las de mensagens
(Message Queues) [57], que encapsula por sua vez detalhes de controle de
concorrência.
4.1.2Implementação dos agentes
As camadas dos agentes foram implementadas usando o padrão Fa-
cade [21], de forma a isolar as camadas do agente. Esse isolamento foi, no
entanto, prejudicado pela ausência de re�exividade do C++. Assim, por
exemplo, na implementação original desenvolvida em Java [33] os planos
de execução são enviados à camada de ação como strings. As ações são
instanciadas a partir destas variáveis utilizando facilidades oferecidas pela
linguagem. Dado que o C++ não permite este tipo de operação, optamos
aqui por criar fábricas de objetos cuja referência é trafegada de uma camada
a outra segundo a classe a instanciar.
Nesse trabalho assume-se que todos os agentes utilizam uma ontologia
comum e não se consideram aspectos relativos à mobilidade. Por essa causa,
o template não inclui as camadas de Tradução e Mobilidade. As camadas
restantes serão descritas a seguir:
Camada Sensor
A camada Sensor está constituída pela interface ASensor e pela classe
SensoryFacade. A interface ASensor deve ser herdada pelas novas classes
sensor. O SensoryFacade é o ponto de entrada na camada e, como as outras
Façades, seu objetivo é manter o isolamento da camada.
O sensor executa em um processo independente do sistema, que é
iniciado assim que são inicializadas as estruturas do agente e iniciada a
execução da camada de Colaboração. Sua tarefa é a coleta de dados. Esta
pode ser efetuada por amostragem ou por eventos (noti�cação). Os dados
são repassados ao objeto crença subscrito como observador desse sensor,
através do padrão Observer [21].
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 52
Camada de Crença
A camada Crença é composta das classes ABelief e BeliefFacade.
ABelief é a interface das classes Crença dos novos agentes componentes. O
objeto Crença deve ser subscrito como observador de um ou vários sensores,
de forma a ser noti�cado em caso de mudanças. Eventos importantes devem
ser noti�cados por sua vez à camada de Raciocínio.
Camada Raciocínio
Na camada de Raciocínio, o objeto observador da crença avalia a
informação e pode gerar intenções que serão executadas pela camada de
ação. Essas intenções podem ser de colaboração ou de ação. As intenções de
ação contêm um plano com uma ou várias ações a executar, sendo que para
manter o isolamento entre as camadas, nessa implementação são repassadas
uma referência a uma fábrica do tipo de objeto indicado para executar a
ação e seus parâmetros.
Um exemplo para um caso que precise da mudança de estratégia de
substituição de páginas em bu�er é mostrado na �gura 4.2.
Figura 4.2: Processo executado pelas camadas de Crença, Raciocínio e Açãopara o controle da estratégia de substituição de páginas em bu�er.
Após ser noti�cado, o plano observador na camada de raciocínio
(bu�ReplStrategyPlan) avalia as crenças. Como conseqüência dessa avaliação
podem ser geradas intenções de ação e colaboração, que são transmitidas
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 53
à camada de ação. As intenções de ação indicam a execução de uma ou
várias ações listadas dentro do plano de ação (plan) que é passado como
parâmetro. Cada ação é de�nida por uma fábrica (BufRepStrategyFactory)
e um grupo de parâmetros para a instanciação da ação. Já na camada de
ação, uma intenção é criada que consulta o plano de ações e recebe as ações
instanciadas. Essas ações serão executadas pela intenção seqüencialmente
em um novo processo.
Por outro lado, a intenção de colaboração implica em uma chamada
ao método collaborate da camada de colaboração repassando os parâmetros
recebidos na camada de ação.
Além das classes ActionPlan, APlan e ReasoningFacade, a camada de
Raciocínio está integrada também pela classe ReasForwarder, que recebe as
mensagens transmitidas pela camada de Ação, e a classe InterpretPlan, que é
observadora de ReasForward e é executada para processar essas mensagens,
possivelmente invocando outros planos disponíveis no agente.
Camada Ação
A camada de Ação executa as intenções de ação e repassa para a ca-
mada de Colaboração as intenções de colaboração. As ações são executadas
seqüencialmente dentro de uma intenção, sendo que cada intenção é exe-
cutada em um processo separado. A camada está formada pelas interfaces
AAction e as classes ActionFacade, AIntention, Forwarder e ReactionInten-
tion. A classe Forwarder recebe as mensagens da camada de Colaboração
enviadas por outros agentes do sistema e as repassa para a camada de Ra-
ciocínio.
Camada Colaboração
Essa camada está constituída pelas classes CollabFacade, PostO�ce,
Acceptor, Connector eMessage. A classe PostO�ce é um Singleton: somente
existe um objeto PostO�ce no sistema. Ele é um depósito de mensagens,
de forma que os objetos Connector deixam as mensagens especi�cando o
destinatário e a prioridade, e o PostO�ce as coloca na �la de prioridade
correspondente a esse destinatário. O destino pode ser broadcast (todos os
agentes do sistema), um agente em particular ou um provedor de serviço.
Nesse último caso o destinatário será primeiro registrado como provedor do
serviço em particular no PostO�ce. O processo de envio de uma mensagem
é ilustrado na �gura 4.3.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 54
Figura 4.3: Envio de uma mensagem
Como mostra a �gura, as mensagens enviadas à camada de Colabo-
ração são repassadas ao Connector, que as envia ao PostO�ce e retorna
o controle ao agente. O Connector também cria e retorna um objeto para
armazenar a resposta recebida no caso da camada de raciocínio esperar
resposta.
O envio das mensagens pode ser síncrono ou assíncrono. O envio
síncrono é utilizado quando um objeto precisa de uma informação para
continuar seu processamento. Nesse caso ele envia uma mensagem e �ca
bloqueado até a resposta chegar. Esta é enviada diretamente do Acceptor
ao objeto destino usando a referência contida no campo future.
No agente receptor, o Acceptor �ca bloqueado esperando por men-
sagens na �la até ser noti�cado de que pode retirar a sua mensagem. Ela
é repassada para a camada de ação, que a sua vez a transmite para a ca-
mada de Raciocínio, onde é analisada por um objeto da classe InterpretPlan
que está registrado como observador dessa camada. Esse objeto pode criar
planos que por sua vez gerem novas intenções de ação ou colaboração. Na
�gura 4.4 se mostra a seqüência de ações desde o PostO�ce até a camada
de Raciocínio durante o recebimento de uma mensagem.
A comunicação envolve as camadas:
1. transmissão: que descreve a forma em que a mensagem vai trafegar
pelo sistema;
2. sintaxe: de�ne o formato da informação;
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 55
Figura 4.4: Recebimento de uma mensagem (comunicação assíncrona)
3. semântica: que de�ne o tipo da mensagem e o seu conteúdo.
Estas três camadas são idealmente independentes, de forma que é
possível substituir uma sem afetar as outras.
A comunicação pode ser tanto ponto a ponto como broadcast. As
mensagens são encapsuladas para sua transmissão em objetos da classe
Message. O protocolo da camada de sintaxe de�ne os seguintes campos:
� MsgID
� SessionID
� Performative
� origem
� destino
� prioridade
� conteúdo
� future
O campo future guarda uma referência ao objeto ao que deverá ser
entregue a informação retornada no caso de uma comunicação síncrona.
Origem e destino são os identi�cadores únicos reservados a cada agente
durante o processo de registro no sistema. O campo Performative contém o
tipo de mensagem.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 56
O conteúdo propriamente dito está estruturado como uma sucessão
de cadeias de caracteres separadas por espaços, em que a primeira cadeia é
o serviço requisitado no caso do tipo da mensagem (performative) ser um
REQUEST. O restante da mensagem pode ser organizado livremente desde
que a estrutura seja compartilhada por todos os agentes do sistema. Assim,
por exemplo, uma intenção de colaboração expressada da seguinte forma:
newintention(0,1,REQUEST,"record BuffRepStrategy MRU=true",false,0);
sendo que esse método está de�nido como:
void ActionFacade::newIntention(int ID, int prioridade,
Performative performative, char *message, bool resposta, int Destino)
signi�ca que o agente Bu�RepStrategy solicita ao agente de histórico, cuja
identi�cação não tem, o registro de uma ação como resultado da qual a
política de substituição de páginas em bu�er foi trocada para MRU. O
agente não espera resposta.
Um problema dessa implementação está na mistura entre as camadas
semântica e de sintaxe, pois é necessário "abrir"o conteúdo da mensagem
para saber o serviço requisitado e com isso, o destinatário da mensagem no
caso deste não estar especi�cado no campo destino. Uma solução pode ser
acrescentar um campo ao envelope da mensagem com o nome do serviço.
Essa mudança será efetuada em breve no sistema.
Na �gura 4.5 se mostra um processo de comunicação. Nele estão
envolvidos um processo do SGBD e dois agentes. Note que as requisições
entre os agentes são trafegadas na forma de serviços. Aqui é possível perceber
que um dos agentes possui somente as camadas de Crença, Raciocínio e
Colaboração, como pode ser o caso do Agente Coordenador na Arquitetura
Centralizada. Esse agente não precisaria da camada Sensor porque as noções
que ele tem sobre o ambiente vem todas da camada de colaboração. A
camada de ação não é necessária porque as ações a executar são requisições
de serviços a outros agentes do sistema que serão enviadas através da
camada de colaboração. No caso, o trabalho do agente consiste em decidir
sobre a base das informações recebidas dos outros agentes quais devem ser
as ações a tomar e mandar a executá-las na forma de requisições de serviço.
Um exemplo de requisição de serviço poderia ser uma mensagem do agente
de Bu�RepStrategy ao agente de histórico pedindo para que seja armazenado
o dado "MRU=true".
O tráfego de informação entre os processos pode obrigar ao uso de
estruturas protegidas.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 57
Figura 4.5: Interações no sistema de auto-sintonia
Sistema de Agentes
A entrada no Sistema de Agentes é feita através do cadastro de cada
agente na lista mantida no objeto AgentSystem, que é único no sistema. Ao
mesmo tempo é inicializada a camada de Colaboração do agente e o agente
se registra no PostO�ce. A execução de tarefas no sistema de auto-sintonia é
orientada a serviços. Esses serviços são especi�cados durante a con�guração
do agente e registrados no PostO�ce para disponibilizá-los para os outros
agentes do sistema. A saída acontece com o cancelamento do cadastro do
agente com o AgentSystem.
4.1.3Validação da gerência de concorrência
A função da sincronização é restringir o grupo de possíveis �uxos de
execução a aqueles que são desejáveis. Nessa implementação a sincronização
entre os processos do PostgreSQL e os sensores do agente é garantida pelas
�las de mensagens. As �las de mensagens permitem implementar esperas por
condição e não precisam do uso de semáforos para garantir acesso exclusivo.
As ações do agente consistiram em escritas em variáveis compartilhadas
protegidas por semáforos.
A correção de um programa concorrente implica na satisfação das
propriedades segurança(safety) e vitalidade(liveness) [4], que podem ser
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 58
de�nidas como que nada "ruim"vai a acontecer durante a execução e que em
algum momento algo de "bom"vai a acontecer, respectivamente. Para o tipo
de aplicação que está sendo discutida aqui o termo "em algum momento"não
é su�ciente pois algumas decisões deverão ser tomadas em tempo real.
Por esse motivo consideraremos que o sistema satisfaz a propriedade de
vitalidade se o tempo em que ocorre "algo de bom"está dentro do admissível
segundo o domínio da aplicação.
Dado que todas as comunicações serão efetuadas mediante �las de
mensagens, o programa não deve entrar em um estado no qual um ou mais
processos estejam em uma zona mutuamente crítica.
Outro requerimento para considerar o programa seguro é que esteja
livre de deadlock. O deadlock acontece quando dois ou mais processos espe-
ram por uma condição que nunca vai acontecer. As condições necessárias e
su�cientes para a ocorrência de deadlock são [4]:
� necessidade de que os processos envolvidos precisem compartilhar
recursos que devam ser usados em exclusão mutua;
� que os processos mantenham os recursos já adquiridos enquanto
esperam por outros;
� ausência do controle do sistema sobre a liberação dos recursos;
� existe uma cadeia circular de requisições e aquisições.
A política adotada é usar o recurso e liberá-lo imediatamente, isso
implica que não existem possibilidades de deadlock no sistema.
O livelock é o estado no qual o processo não executa mais do que
instruções inúteis. O livelock é uma violação da vitalidade. Uma situação
em que o processo pode entrar em livelock é na espera por condição. Se
a condição nunca acontece o processo vai esperar inutilmente. Novamente,
situações de livelock podem ser codi�cadas como parte da programação
dos agentes. Todas as operações de colaboração que impliquem espera
devem incluir timeouts, protegendo-se de erros que possam eventualmente
acontecer. Seguidas essas regras nosso sistema deverá ser um sistema seguro.
A inanição (starvation) é outra violação de vitalidade. Nessa situação
o sistema consegue progredir, mas tem algum processo que não consegue
acesso aos recursos porque sempre perde na concorrência, por exemplo, por
ser de menor prioridade. Há dois candidatos potenciais a gerar situações
de inanição que são as mensagens armazenadas nas �las do PostO�ce e o
escalonador de ações. Ações pouco prioritárias não serão jamais executa-
das se tiver sempre ações mais prioritárias esperando, da mesma forma que
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 59
as mensagens menos prioritárias não conseguirão sair da �la enquanto tiver
mensagens de maior prioridade. Isso pode ser resolvido de duas formas: uma
é codi�car o escalonador seguindo princípios de justiça (fairness), garan-
tindo que cada processo será eleito em algum momento, com independência
da sua prioridade. A outra solução é assumir que as ações mais prioritárias
são aquelas que devem ser executadas em tempo real, enquanto as menos
prioritárias não têm restrições de tempo. Nesse caso o fato das mensagens
menos prioritárias �carem na �la não constitui um problema, desde que as
prioridades sejam cuidadosamente alocadas.
4.2Exemplo de aplicação
Para veri�car a arquitetura proposta na prática o sistema proposto
neste trabalho foi embutido dentro de um SGBD. Uma di�culdade que
enfrentamos foi a escolha desse SGBD, que deveria expor tanto as variáveis
a medir como os parâmetros ou funções de controle. Os SGBDs comerciais
publicam um grupo de APIs que permitem o acesso às funções do sistema.
Entretanto, não permitem modi�car seu código. Outro problema é o fato
de que já existe um grupo de funções de auto-sintonia implementada
nesses sistemas comerciais que poderia afetar os resultados dos testes. Por
último está a motivação deste trabalho ter sido conduzido em colaboração
com outro [50] que seria aproveitado aqui que precisava de funções não
publicamente disponíveis em sistemas comerciais.
Por essas razões foi escolhido um sistema de código aberto. Os sistemas
analisados foram o MySQL e o PostgreSQL. O MySQL é um SGBD
relacional de código aberto disponível em [43]. O PostgreSQL [47] é um
sistema de gerência de bancos de dados objeto-relacional também de código
aberto disponível nas plataformas Unix.
Para o desenvolvimento do trabalho seria necessário previamente im-
plementar funções e criar novas variáveis dentro do SGBD que permitissem
observar determinadas métricas e ajustar parâmetros de controle. O MySQL
demostrou não ser uma boa escolha para este tipo de trabalho devido à falta
de documentação e a desorganização do código. No PostgreSQL, por outro
lado, são notáveis a limpeza e organização do código, assim como a abun-
dância de documentação. Esses aspectos foram determinantes na escolha
desse sistema para a nossa implementação.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 60
4.3Ambiente de desenvolvimento
A linguagem escolhida para a implementação desse trabalho foi C++.
A razão dessa escolha se deve ao fato do PostgreSQL estar escrito nessa
linguagem. O compilador de linha usado foi o gcc versão 3.2.2. A depuração
foi uma das tarefas mais difíceis deste trabalho devido às di�culdades
inerentes à depuração de código concorrente. Esta foi feita usando gdb [20]
e checkpoints manuais.
A ferramenta de modelagem UML usada foi o Together 6.0 para
Windows [60]. Essa é uma plataforma implementada na linguagem Java
que permite modelar e documentar sistemas orientados a objetos. Usando a
ferramenta é possível tanto a geração de código na linguagem C++ ou Java
a partir dos diagramas UML como efetuar o processo inverso.
A plataforma foi um Athlon de 1.6GHz com 128Mb de RAM sob o
sistema operacional Linux versão 8.0.
4.3.1Interação com o SGBD
O código do PostgreSQL foi modi�cado de forma a incluir um parâ-
metro na linha de comandos para iniciar o sistema de auto-sintonia (arquivo
postmaster/postmaster.c). No caso de ser habilitada a opção são instancia-
dos os agentes e incluídos dentro do sistema de agentes.
O sistema de auto-sintonia foi implementado de forma a não intervir
na atividade do SGBD. Assim, no caso do sistema de auto-sintonia estar
desligado o SGBD seguirá funcionando. Os agentes estão embutidos [40]
dentro do SGBD, consumindo recursos deste ainda quando executam em
processos separados.
O motivo para não ter escolhido uma arquitetura integrada é o fato
de não existir um sistema de banco de dados relacional baseado em agen-
tes disponível para esta implementação. A arquitetura em camadas permite
não requer modi�cações no sistema de banco de dados, mas depende das
interfaces que este ofereça para observar e agir sobre o sistema controlado.
Por outro lado, os agentes embutidos tem acesso a todos os componentes
do banco, porém a sua construção se complica pelo fato de precisar com-
preender o funcionamento interno do sistema. Outras desvantagens contra a
arquitetura embutida estão no fato de que somente pode ser implementada
em SGBDs de código aberto, assim como em aspectos relacionados com a
interação com o SGBD como é o caso do modelo de concorrência. Uma van-
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 61
tagem fundamental dessa arquitetura é que permite uma implementação
mais otimizada que a versão em camadas. Diferentemente da arquitetura
integrada, na arquitetura embutida pode-se utilizar o sistema ainda sem
ativar os agentes.
O tema da inclusão de threads na implementação do PostgreSQL tem
sido bastante levantada em listas públicas de discussão. No entanto, a equipe
de desenvolvimento do PostgreSQL mantém a posição de que o isolamento
que os processos oferecem garante uma segurança e uma portabilidade
difíceis de alcançar com threads, além de que critérios de e�ciência são muito
dependentes da implementação particular de cada sistema operacional.
Dessa forma, o PostgreSQL segue o esquema de um servidor concorrente que
cria um processo toda vez recebe uma nova conexão. A comunicação entre
os processos se efetua através de sinais, os dados são compartilhados usando
uma estrutura chamada de Memória Compartilhada (Shared Memory) [57]
e a sincronização através de semáforos.
A interação entre o PostgreSQL e o sistema de auto-sintonia se
desenvolve através de uma interface (postgresInterface.cpp). Ela contém
as funções que chamam os métodos de criação e destruição do sistema de
agentes, assim como as funções que executam ações sobre o SGBD e aquelas
invocadas por este para noti�car um evento.
Ao ser iniciado o PostgreSQL com a opção -t, o postmaster faz um
chamado à função ags_create da interface. Essa função cria os agentes, os
inclui no sistema de agentes e inicializa as estruturas de comunicação entre
o PostgreSQL e os agentes.
A detecção de eventos internos se efetua através de checkpoints ou
software probes, que são instruções que se inserem no código de um programa
para coletar e armazenar dados ou chamar a uma rotina de medição [18]. A
interferência produzida pode ser intolerável se for introduzido em porções
críticas do programa medido, ou se tempo de interferência for considerável.
Levando em conta este problema, a política assumida é fazer com que o
processo PostgreSQL somente precise colocar a informação e retornar pois
o sensor correspondente está executando em outro processo concorrente.
O sistema de auto-sintonia implementado usa como repositórios de
informação arquivos de texto simples. A informação contida nesses arquivos
deve ser analisada para detectar violações das expectativas de desempenho
e veri�car a validade de uma ação que tenha sido executada antes em um
contexto similar.
Com o objetivo de comprovar a factibilidade da implementação, assim
como avaliar as di�culdades que esta apresenta, foram implementados
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 62
dois mecanismos de auto-sintonia referentes aos problemas de escolha da
estratégia de substituição de páginas em memória (veja a seção A.1) e
ao de thrashing e contenção de dados(veja a seção A.2). Os detalhes da
implementação desses mecanismos se expõem a seguir.
4.3.2Estratégia de substituição de páginas em memória
Foi acrescentada ao PostgreSQL uma função que implementa o método
MRU de substituição de páginas em bu�er (veja o anexo A.1). Esta
função está disponível livremente na Internet, mas ainda não foi inclusa na
distribuição o�cial do PostgreSQL. A diferença da estratégia LRU, a MRU
coloca as páginas no extremo MRU da �la, de forma que serão as primeiras
candidatas a substituição. Isso faz sentido em casos em que a informação será
usada somente uma vez, como pode ser o caso das varreduras seqüenciais,
e pretende preservar a informação útil armazenada no bu�er.
Ao detectar a geração de um plano que inclui varreduras seqüenciais,
o sensor é noti�cado pelo processo PostgreSQL correspondente. O agente
pode então avaliar a execução de uma ação consistente na troca da estratégia
de substituição de páginas utilizando uma função incluída no PostgreSQL
com esse propósito.
4.3.3Thrashing de contenção de dados
A variável razão de con�itos é a razão entre o número total de
bloqueios no sistema e quantos deles são possuídos por transações ativas.
O registro desses valores é feito introduzindo checkpoints nos pontos de
con�rmação de bloqueios no arquivo lock.c do PostgreSQL que consistem
em chamadas à função ags_notify_lock() da interface para noti�car esses
valores.
O �nal de cada transação também é noti�cado. Esse evento supõe a
ativação do mecanismo de controle de admissão, que pode liberar transações
da �la dependendo do valor da razão de con�itos (veja a seção A.2).
Finalmente, a �gura 4.6 mostra o processo executado pelo sistema
após um alarme indicando perigo de thrashing de contenção de dados no
PostgreSQL.
Ao receber um dado do PostgreSQL, o agente de controle de MPL
calcula o valor atual da razão de con�itos. Esse valor é enviado ao agente de
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 63
Figura 4.6: Atividade do sistema em um evento de violação de razão decon�itos
histórico para ser armazenado no repositório centralizado e também avaliado
para detectar se existe perigo de thrashing de contenção de dados. Em caso
de violação, o agente Coordenador é noti�cado. Ele inicia um processo de
análise do estado do sistema objetivando diagnosticar as causas reais dos
problemas e assim evitar situações como a comentada na seção 3.2, em
que a reação do mecanismo de auto-sintonia a uma causa aparente piora
mais ainda o desempenho do sistema. Posteriormente as possíveis soluções
ao problema são enumeradas e avaliadas com a informação disponível sobre
ações executadas. As ações �nalmente escolhidas são repassadas aos agentes
correspondentes na forma de requisições de serviço, cujo objetivo é agir sobre
o PostgreSQL para resolver a situação.
4.4Aspectos de implementação
O desenvolvimento do trabalho consistiu na implementação em C++
do framework de agentes discutido anteriormente (veja 4.1) e nas adaptações
necessárias para embutir agentes instanciados a partir desse framework em
um SGBD real, no caso no PostgreSQL. Para esse trabalho aproveitamos
duas versões implementadas por pessoas do nosso grupo em C++ [40, 51].
Ambas implementações foram construídas pensando em um único agente.
Partindo desse código, da documentação e o código original em Java
disponível em [33], foi criada para essa dissertação uma versão que inclui a
gerência de concorrência e a camada de colaboração.
A implementação em geral apresentou a di�culdade já discutida da
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 64
falta de suporte a concorrência em C++. O uso deMessage Queues facilitou
a implementação pois evitou a necessidade de utilizar semáforos para
garantir o acesso exclusivo e por permitir implementar facilmente esperas
por condição. Assim como em [33], grande parte da nossa implementação
está baseada em padrões de projeto. A implementação da camada de
colaboração foi di�cultada pois em [33] a colaboração centralizada não está
muito documentada e a implementação distribuída dessa camada não é
completa. Para essa dissertação concluímos que a complexidade da variante
distribuída não era necessária. A versão centralizada foi implementada
seguindo a sugestão de usar o padrão Mediator [33], que é a base do
PostO�ce. Além de suportar o envio de mensagens assíncronas, inclui
também o trafego síncrono de mensagens devido às necessidades do agente
central, que não deveria �car esperando inde�nidamente por consultas
necessárias para a tomada de decisões. Com esse objetivo foi acrescentado
na mensagem o campo future, que contém uma referência à estrutura onde
será armazenado o dado retornado. Essa referência é devolvida ao objeto
que espera a resposta, o qual �cará esperando o dado para continuar o
processamento.
Já construída a estrutura básica dos agentes basta estender as clas-
ses Sensor, Belief, Reasoning e Action (na realidade somente aquelas que o
agente precise) para instanciar cada agente que formará parte do sistema.
Para comprovar a comunicação entre os agentes e a sua inserção no SGBD,
em nosso protótipo foram instanciados um agente de histórico, um agente de
Controle de Carga, um outro agente para o controle de política de substitui-
ção de páginas no bu�er e um agente central. Dado que os algoritmos usados
por esses agentes in�uem na e�cácia do sistema, eles devem ser melhorados
para obter bons resultados.
A inserção do sistema de agentes no PostgreSQL representou um
grande desa�o. O PostgreSQL é um sistema robusto e complexo que precisou
ser estudado a fundo devido à escolha de embutir o sistema de agentes
dentro do SGBD. Diversas veri�cações são feitas pelo PostgreSQL durante
a execução dos processos, de forma que o sistema deveria inserir-se da forma
mais transparente possível para não gerar inconsistências. No protótipo os
agentes executam em threads diferentes dentro do processo do postmaster.
Uma solução melhor seria colocar o sistema de agentes dentro de um
processo separado, de forma a garantir o isolamento do SGBD no caso de
erros no sistema de agentes, facilitando também a depuração. No entanto,
essa não é uma tarefa fácil, pois é preciso reproduzir o procedimento (não
documentado) que o PostgreSQL executa a cada vez que um novo processo
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 65
é criado. Essa solução foi implementada posteriormente em [52].
4.5Conclusões
A implementação por um lado mostrou a viabilidade da inserção
de um sistema de agentes construído seguindo a arquitetura centralizada
dentro de um SGBD real, assim como as di�culdades que isto implica. A
problemática da integração do sistema de agentes com o SGBD usando
uma arquitetura embutida fez aumentar consideravelmente a complexidade
da implementação, impossibilitando no caso a apresentação de resultados
quantitativos.
As di�culdades fundamentais enfrentadas durante a implementação
foram:
� Integração com o PostgreSQL.
� Depuração em ambiente concorrente
� Gerência de concorrência.
� Implementação do framework de agentes sob as limitações do C++.
5
Conclusões e Contribuições
Neste capítulo se comentam brevemente os resultados obtidos, des-
crevendo as conclusões e principais contribuições, assim como as possíveis
extensões e os trabalhos futuros.
5.1Resumo
No presente trabalho foi feito um estudo do problema da auto-sintonia
global de SGBDs, assim como os trabalhos relacionados a esse tema. Tam-
bém foram discutidas algumas possíveis abordagens. As vantagens da im-
plementação de sistemas de auto-sintonia usando agentes foram colocadas
e propostas duas arquiteturas para a implementação de sistemas de auto-
sintonia usando agentes. Essas arquiteturas propõem aproveitar as caracte-
rísticas dos agentes para construir sistemas auto-adaptáveis. Os mecanismos
de auto-sintonia locais podem ser integrados ao SGBD como agentes que
colaboram para garantir o desempenho do SGBD como um todo. Para ava-
liar as arquiteturas propostas foi implementado e estudado um sistema de
auto-sintonia embutido em um SGBD PostgreSQL.
5.2Principais contribuições
Consideramos que as principais contribuições do trabalho são:
1. Uma arquitetura para auto-sintonia global baseada em agentes.
2. A enumeração dos requisitos que devem possuir os sistemas de auto-
sintonia global.
3. A abordagem usando agentes, que assim como facilita a introdução
de inteligência no sistema, oferece uma grande �exibilidade na mo-
di�cação dos mecanismos que governam cada etapa do processo de
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 67
auto-sintonia. Isto sugere a vantagem dessa abordagem para a pes-
quisa e implementação de protótipos.
4. Uma proposta que permite a integração paulatina e relativamente
simples de novos mecanismos de auto-sintonia local, ao mesmo tempo
que trata o problema de sintonia do SGBD como um todo.
5. A implementação de um protótipo para a avaliação da e�cácia e
complexidade da implantação da arquitetura centralizada em um
SGBD real.
Entre as vantagens que apresenta a introdução de agentes no projeto
e implementação dessas arquitetura está a facilidade de integração de novos
mecanismos de auto-sintonia. Estes podem ser acrescentados progressiva
e independentemente um do outro, sendo a sua inter-relação gerenciada
pelo sistema. Esta é uma grande diferença entre esse trabalho e propostas
anteriores, em que os sistemas de auto-sintonia tem sido sempre tratados
centralizadamente dentro do contexto do SGBD.
5.3Conclusões
A auto-sintonia é uma necessidade em um número crescente de con-
textos. Mesmo quando a decisão �nal ainda deva ser tomada por um admi-
nistrador, os sistemas devem possuir capacidade de se auto-adaptar ao seu
ambiente de forma a não precisar dos administradores em tarefas rotineiras.
Os SGBDs atuais não oferecem infra-estruturas para auto-sintonia global,
apesar de que a sua estrutura monolítica faz com que as interações entre
componentes e cargas de trabalho sejam imprevisíveis, di�cultando a tarefa
de auto-sintonia que sempre tem que lidar com uma dose de incerteza.
A construção de novos tipos de SGBDs desenhados desde o inicio
visando obter um bom desempenho parece ser a solução a esse problema,
e já existem trabalhos que seguem essa vertente [12, 23, 41]. Entretanto,
iniciativas que integrem auto-sintonia global em sistemas já existentes
podem ser aplicadas.
Este trabalho propõe uma abordagem inicial à implementação desses
sistemas usando agentes de software. Os agentes podem embutir nos siste-
mas em que são integrados características que lhes são próprias, como é o
caso da sua adaptabilidade, desejáveis nesse tipo de aplicação.
Concluímos nesse trabalho que a arquitetura proposta é capaz de
acrescentar adaptabilidade aos sistemas ante mudanças do ambiente. O uso
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 68
de agentes introduz �exibilidade na implementação. O sistema de auto-
sintonia representa uma carga para o sistema observado, mas ainda assim
resulta em benefícios. O sistema cumpre com os requisitos para os quais foi
projetado.
5.4Trabalhos futuros
Enquanto acreditamos que é possível estender a implementação atual
do sistema para incluir a criação tanto de threads como de processos de
aplicação, até o momento nossa implementação inclui somente a gerência
de threads. A inclusão de processos de aplicação deve ser valorada como
trabalho futuro.
Acreditamos que a incerteza provocada pelas inter-relações existentes
no sistema possam ser contornadas com uma mistura entre a realimentação
do ciclo de controle e um forte componente probabilístico no raciocínio.
As estratégias de negociação dos agentes devem continuar a ser
exploradas. O sistema ganharia em autonomia se os agentes, provavelmente
baseados em noções de utilidade, considerassem a obtenção de con�gurações
ótimas do sistema como m todo como um bene�cio para os seus próprios
interesses em lugar de manter a coerência global sujeitos a compromissos
sociais.
Os estudos sobre o processo de con�guração do sistema devem ser
aprofundados.
O problema identi�cado em [9] de como garantir que o processo de
diagnóstico vai alcançar o desempenho ótimo do SGBD ainda está por ser
resolvido.
Ficam também por estudar as diferentes alternativas de construção e
gerência da base de conhecimento.
Por último, acreditamos que a arquitetura apresentada é válida não
somente para SGBDs mas também para sistemas que precisem da alocação
de recursos em geral. Aplicar a arquitetura proposta em sistemas similares
pode ser um trabalho interessante.
Bibliogra�a
[1] ANDREWS, G.. Foundations of Multithreaded Parallel and
Distributed Programming. Addison-Wesley, 2000.
[2] BERNSTEIN, P.; BRODIE, M.; CERI, S.; DEWITT, D.; FRANKLIN,
M.; GARCIA-MOLINA, H.; GRAY, J.; HELD, J.; HELLERSTEIN, J.;
JAGADISH, H.; LESK, M.; MAIER, D.; NAUGHTON, J.; PIRAHESH,
H.; STONEBRAKER, M. ; ULLMAN, J.. The Asilomar report on
database research. ACM SIGMOD Record, 27(4):74�80, 1998.
[3] BROWN, K.; CAREY, M. ; LIVNY, M.. Managing memory to meet
multiclass workload response time goals. Em: PROCEEDINGS OF
THE INTERNATIONAL CONFERENCE ON VERY LARGE DATABASES
(VLDB), 1993.
[4] BURNS, A.; DAVIES, G.. Concurrent Programming. Addison-Wesley,
1993.
[5] BAILEY, J.; GEORGEFF, M.; KEMP, D.; KINNY, D. ; RAMAMOHA-
NARAO, K.. Active databases and agent systems - a compari-
son. Em: PROCEEDINGS OF THE INTERNATIONAL WORKSHOP ON
RULES IN DATABASE SYSTEMS, LECTURE NOTES IN COMPUTER
SCIENCE 985, p. 342�356. Springer, 1995.
[6] BERRY, R. F.; HELLERSTEIN, J. L.. A �exible and scalable appro-
ach to navigating measurement data in performance manage-
ment applications. Em: PROCEEDINGS OF THE IEEE INTERNATI-
ONAL WORKSHOP ON SYSTEMS MANAGEMENT (SMW), p. 92�103,
1996.
[7] BIGUS, J. P.; HELLERSTEIN, J. L.; JAYRAM, T. S. ; SQUILLANTE,
M. S.. Auto tune: A generic agent for automated perfor-
mance tuning. Em: PROCEEDINGS OF THE INTERNATIONAL CON-
FERENCE AND EXHIBITION ON THE PRACTICAL APPLICATION OF
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 70
INTELLIGENT AGENTS AND MULTI-AGENT SYSTEMS (PAAM), p.
33�52, 2000.
[8] BARRERA III, J. S.. Self-tuning systems software. Em: PROCEE-
DINGS OF THE WORKSHOP ON WORKSTATION OPERATING SYS-
TEMS, IEEE COMPUTER SOCIETY, p. 194�197, 1993.
[9] BENOIT, D.. Automatic Diagnosis of Performance Problems in
Database Management Systems. PhD thesis, School of Computing,
Queen's University, 2003.
[10] CHAUDHURI, S.; GUPTA, A. ; NARASAYYA, V.. Compressing sql
workloads. Em: PROCEEDINGS OF THE ACM SIGMOD INTERNA-
TIONAL CONFERENCE ON MANAGEMENT OF DATA, p. 488 � 499,
2002.
[11] COSTA, R. L. C.; LIFSCHITZ, S.. Index self-tuning with agent-
based databases. Em: PROCEEDINGS OF THE LATIN-AMERICAN
CONFERENCE ON INFORMATICS (CLEI), p. 76, Abstracts Proceedings;
12 pp. CD�ROM Proceedings, 2002.
[12] CHAUDHURI, S.; WEIKUM, G.. Rethinking database system archi-
tecture: Towards a self-tuning risc-style database system. Em:
PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON VERY
LARGE DATABASES (VLDB), p. 1�10, 2000.
[13] DIAO, Y.; HELLERSTEIN, J. L.; PAREKH, S. ; BIGUS, J. P.. Managing
web server performance with autotune agents. IBM SYSTEMS
JOURNAL, 42(1):136 � 149, 2003.
[14] EHRGOTT, M.; GANDIBLEUX, X.. An Annotated Bibliography of
Multi-objective Combinatorial Optimization. Technical Report
62/2000, Universitat Kaiserslautern, 2000.
[15] ELMASRI, R.; NAVATHE, S.. Fundamentals of Database Systems.
Benjamin-Cummings, 1994.
[16] FEITELSON, D. G.; NAAMAN, M.. Self-tuning systems. IEEE
Software, 16(2):52�60, 1999.
[17] FRANK, M.; OMIECINSKI, E. ; NAVATHE, S.. Adaptive and Auto-
mated Index Selection in RDBMS. Em: PROCEEDINGS OF THE
INTERNATIONAL CONFERENCE ON EXTENDING DATABASE TECH-
NOLOGY (EDBT), p. 277�292, 1992.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 71
[18] FERRARI, D.. Computer Systems Performance Evaluation.
Prentice Hall, 1978.
[19] GARCIA, A.; CHAVEZ, C.; SILVA, V. ; LUCENA, C.. Developing
Multi-Agent Software: an Aspect-Based Approach and a
Pattern-Based Approach. Technical report, PUC-RIO, November
2001. MCC40/01.
[20] GDB: The GNU Project Debugger.
http://www.gnu.org/software/gdb/gdb.html, acessado em 5/03/2004.
[21] GAMMA, E.; HELM, R.; JOHNSON, R. ; VLISSIDES, J.. Padrões de
projeto: soluções reutilizáveis de software orientado a objetos.
Porto Alegre: Bookman, 2000.
[22] GREY, J.. The Benchmark Handbook. Morgan Kaufmann Publishers,
Inc., second edição, 1998.
[23] HARIZOPOULOS, S.; AILAMAKI, A.. A case for staged database
systems. Em: PROCEEDINGS OF THE BIENNIAL CONFERENCE ON
INNOVATIVE DATA SYSTEMS RESEARCH (CIDR), 2003.
[24] HUHNS, M.; STEPHENS, L.. Multiagent systems and societies of
agents. Em Weiss [70], capítulo 2, p. 79�120.
[25] HEISS, H.; WAGNER, R.. Adaptive load control in transaction
processing systems. Em: PROCEEDINGS OF THE INTERNATIONAL
CONFERENCE ON VERY LARGE DATABASES (VLDB), p. 47�54, 1991.
[26] HARVEY, A.. Time series models. MIT Press, second edição, 1993.
[27] HELLERSTEIN, J. L.. A comparison of techniques for diagnosing
performance problems in information systems. Em: PROCE-
EDINGS OF THE SIGMETRICS CONFERENCE ON MEASUREMENT
AND MODELING OF COMPUTER SYSTEMS, p. 278�279. ACM, 1994.
[28] HELLERSTEIN, J. L.. Automated tuning systems: Beyond deci-
sion support. Em: PROCEEDINGS OF THE COMPUTER MEASURE-
MENT GROUP, p. 277�292, 1997.
[29] HORN, P.. Autonomic computing: IBM's perspec-
tive on the state of information technology, 2001.
http://www.research.ibm.com/autonomic/manifesto, acessado em
11/01/2004.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 72
[30] IBM and Autonomic Computing, 2003. http://www-
306.ibm.com/autonomic/pdfs/ACwpFinal.pdf, acessado em 11/01/2004.
[31] JAIN, R. K.. The Art of Computer Systems Performance
Analysis. John Wiley & Sons, 1991.
[32] KWAN, E.; LIGHTSTONE, S.; SCHIEFER, B.; STORM, A. ; WU, L.. Au-
tomatic database con�guration for DB2 universal database:
Compressing years of performance expertise into seconds of
execution. Em: PROCEEDINGS OF THE CONFERENCE ON DATA-
BASE SYSTEMS FOR BUSINESS, TECHNOLOGY AND WEB (BTW
2003), 2003.
[33] KENDALL, E.; MURALI KRISHNA, P.; C.V., P. ; SURESH, C.. A
framework for agent systems, capítulo 6, p. 113�154. John Wiley &
Sons, 1999.
[34] LIFSCHITZ, S.; MILANÉS, A. ; SALLES, M. V.. Estado da arte em
auto-sintonia de sgbd relacionais. Preprint, 2004.
[35] LAVENDER, R. G.; SCHMIDT, D. C.. Active object: an object beha-
vioral pattern for concurrent programming. Em: Vlissides, J.;
Coplien, J. ; Kerth, N., editors, PATTERN LANGUAGES OF PROGRAM
DESIGN 2, capítulo 30, p. 483��499. Addison�Wesley, 1996.
[36] LERNER, A.. Troubleshooting, capítulo 7. Em SB03 [49], 2003.
[37] MENASCE, D.; ALMEIDA, V.. Capacity Planning for Web Perfor-
mance: Metrics, Models, and Methods. Prentice Hall, 1998.
[38] MENASCÉ, D. A.; BARBARÁ, D. ; DODGE, R.. Preserving QoS of E-
commerce Sites Through Self-Tuning: A Performance Model
Approach. Em: PROCEEDINGS OF THE ACM CONFERENCE ON
ELECTRONIC COMMERCE (ACM EC), p. 224 � 234. ACM Press, 2001.
[39] MARTIN, P.; POWLEY, W.; LI, H. ; ROMANUFA, K.. Managing
database server performance to meet QoS requirements in
electronic commerce systems. International Journal on Digital
Libraries, 3(4):316�324, 2002.
[40] MACÊDO, J. A. F.. Um estudo de SGBDs baseados em agentes.
Master's thesis, Departamento de Informática, Pontifícia Universidade
Católica do Rio de Janeiro (PUC-Rio), 2000.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 73
[41] MCCANN, J. A.. The database machine: Old story, new slant?
Em: PROCEEDINGS OF THE BIENNIAL CONFERENCE ON INNOVA-
TIVE DATA SYSTEMS RESEARCH (CIDR), 2003.
[42] MOHAN, C.. Interactions between query optimizations and con-
currency control. Em: PROCEEDINGS OF THE INTERNATIONAL
WORKSHOP ON RESEARCH ISSUES ON DATA ENGINEERING: TRAN-
SACTION AND QUERY PROCESSING (RIDE-TQP), p. 26�35, 1992.
[43] MySQL. http://www.mysql.com, acessado em 11/01/2004.
[44] NIEMIEC, R.; BROWN, B. ; TREZZO, J.. Oracle 9i Performance
Tuning: dicas e técnicas. Campus, 2003.
[45] OGATA, K.. Modern Control Engineering. Prentice Hall, 3rd edição,
1997.
[46] Patrol(r) knowledge module (tm) for unix v8.3 - features and
faqs. http://www.softwareinnovations.co.uk/downloads/patrol/9066.pdf,
acessado em 11/01/2004.
[47] PostgreSQL. http://www.postgresql.com, acessado em 11/01/2004.
[48] RUSSELL, S. J.; NORVIG, P.. Arti�cial Intelligence: A Modern
Approach. Prentice Hall, 2nd edição, 1995.
[49] SHASHA, D.; BONNET, P.. Database Tuning: Principles, Experi-
ments and Troubleshooting Techniques. Morgan Kaufmann, 2003.
[50] SALLES, M. V.. Uma arquitetura baseada em agentes para a
resolução do problema de auto-sintonia de índices em sgbds
relacionais. Documento apresentado na defesa de proposta de Disser-
tação, Departamento de Informática, Pontifícia Universidade Católica do
Rio de Janeiro (PUC-Rio), 2003.
[51] SALLES, M. V.. Agente de auto-sintonia de Índices baseado em
diferenças. Projeto Final de Programação, Departamento de Informática,
Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio), 2003.
[52] SALLES, M. V.. Criação autônoma de Índices em bancos de
dados. Master's thesis, Departamento de Informática, Pontifícia Univer-
sidade Católica do Rio de Janeiro (PUC-Rio), 2004.
[53] SANDHOLM, T.. Distributed rational decision making. Em Weiss
[70], capítulo 5, p. 201�258.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 74
[54] SEVCIK, K. C.. Database system performance prediction using
an analytical model (invited paper). Em: PROCEEDINGS OF
THE INTERNATIONAL CONFERENCE ON VERY LARGE DATABASES
(VLDB), p. 182�198. IEEE Computer Society, 1981.
[55] SHALLAHAMER, C.. Total performance management. Oracle
Magazine, 69(2), 1995.
[56] SHASHA, D.. Tuning databases for high performance. ACM
Computing Surveys, 28(1):113�115, March 1996.
[57] STEVENS, R.. Unix Network Programming, volume 2. Prentice
Hall, 2 edição, 1999. Interprocess Communications.
[58] Transaction processing council. http://www.tpc.org, acessado em
11/02/2004.
[59] THOMASIAN, A.. Two-phase locking performance and its th-
rashing behavior. ACM Transactions in Database Systems, 18(4):579�
625, 1993.
[60] Together. http://www.togethersoft.com, acessado em 11/02/2004.
[61] VILALTA, R.; APTE, C.; HELLERSTEIN, J.; MA, S. ; WEISS, S.. Pre-
dictive algorithms in the management of computer systems.
IBM Systems Journal, special issue in Arti�cial Intelligence, 41(3):461�474,
2002.
[62] VAN DEN AKKER, J.; SIEBES, A.. Enriching active databases with
agent technology. Em: PROCEEDINGS OF THE INTERNATIONAL
WORKSHOP ON COOPERATIVE INFORMATION AGENTS, p. 116�125,
1997.
[63] Veritas software corporation.
http://www.veritas.com, acessado em 11/01/2004.
[64] VICARI, S.. Proposta de um sistema de regras de sintonia de
performance para aplicações de bancos de dados. Master's thesis,
Universidade Federal do Rio Grande do Sul, July 1998.
[65] WORSLEY, J.; DRAKE, J.. Practical PostgreSQL. O'Reilly &
Associates, 2002.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 75
[66] WEIKUM, G.; HASSE, C.; MÖNKEBERG, A. ; ZABBACK, P.. The
comfort automatic tuning project. Information Systems, 19(5):381�
423, 1994.
[67] WEISS, S. M.; INDURKHYA, N.. Predictive Data Mining: A
Practical Guide. Morgan Kaufmann Publishers, 1998.
[68] WEIKUM, G.; MÖNKEBERG, A.; HASSE, C. ; ZABBACK, P.. Self-
tuning database technology and information services: from
wishful thinking to viable engineering. Em: PROCEEDINGS OF
THE INTERNATIONAL CONFERENCE ON VERY LARGE DATABASES
(VLDB), p. 20�31, 2002.
[69] VON WANGENHEIM, C. G.; VON WANGENHEIM, A.. Raciocínio
Baseado em Casos. Editora Manole Ltda., 2003.
[70] Weiss, G., editor. Multiagent Systems: A modern Approach to
Distributed Arti�cial Intelligence. The MIT Press, Cambridge, MA,
USA, 1999.
[71] WEISER, M.. Some computer science issues in ubiquitous
computing. Communications of the ACM, 36(7):75�84, 2003. Special
issue on Computer Augmented Environments.
[72] WISETH, K.. Oracle database 10g, the world's �rst self-
managing, grid-ready database arrives. Oracle Magazine, p. 28�37,
September 2003.
[73] WOOLDRIDGE, M.. Intelligent agents. Em Weiss [70], capítulo 1, p.
27�78.
A
Anexo
Apresentamos aqui um grupo de algoritmos para controle de sintonia
que foram usados durante a implementação deste trabalho para comprovar as
interações entre os agentes.
A.1Substituição de páginas em cache
As operações sobre os dados são realizadas em memória principal. Dado
que seu custo usualmente impede manter o banco de dados em memória RAM,
são utilizadas técnicas que gerenciam a disponibilidade das páginas de memória,
assim como a integridade e persistência dos dados. A página é a unidade
básica de transferência de dados entre memória principal e disco. O propósito
fundamental do gerente de bu�er é manter endereçáveis as páginas em memória
principal e coordenar a escrita das páginas a disco com outros gerentes.
O número de acessos a disco deve ser minimizado. O gerente de bu�er
administra um segmento em memória virtual que está particionado em frag-
mentos de igual tamanho chamados de frames, que podem conter exatamente
uma página.
O bu�er de dados está implementado como uma �la, como é mostrado
na �gura A.1. Essa �la se organiza de forma que em um extremo se colocam
as páginas mais recentemente usadas que vão avançando na �la no sentido
LRU (Least Recently Used - Menos Recentemente Usadas) na medida em que
aumenta o tempo sem serem atualizadas. Quando são atualizadas se colocam no
extremo MRU (Most Recently Used - Mais Recentemente Usadas) novamente.
A estratégia LRU consiste em que a página substituída é aquela do extremo
LRU, que é então colocada no extremo MRU da �la. Já a estratégia MRU
substitui a página no extremo MRU.
Uma requisição de página ao gerente de bu�er é seguida dos seguintes
passos:
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 77
Figura A.1: A estratégia LRU toma uma página limpa do extremo LRU dacache
� Checar se a página solicitada está no bu�er. Se for encontrada é devolvido
o endereço do frame. Esse caso é chamado de cache hit.
� Caso contrário a página deve ser trazida do disco e colocada no bu�er.
Por esse motivo se procura primeiramente algum frame que não contenha
uma página válida.
� Se não existem frames com páginas não válidas, segue a determinação da
página que será retirada. A escolha depende da estratégia de substituição
de páginas implementada. Por exemplo, de seguir uma estratégia MRU
será selecionada a página mais recentemente utilizada (a que está no
extremo MRU da �la). Já utilizando uma estratégia LRU, a escolhida
será a página menos recentemente utilizada(extremo LRU).
� Se a página a retirar estiver marcada como dirty (modi�cada), deverá ser
escrita em seu bloco do disco.
� O bloco que contém a página solicitada é copiado no frame eleito.
� O endereço do frame é devolvido.
LRU é usada comumente para páginas que serão usadas mais de uma vez
ou que precisam ser atualizadas. Já o MRU é usado para páginas que serão lidas
somente uma vez, como longas varreduras de tabelas únicas.
A política de substituição de páginas de PostgreSQL é LRU. Aplicando
essa política se obtém bons resultados para determinados padrões de acesso
ao banco de dados, como aqueles que implicam atualizações freqüentes e alta
localidade de dados 1. No caso de operações como longas varreduras seqüenciais,
1Localidade é a tendência de dados recentemente usados de serem novamente referen-ciados por operações posteriores.
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 78
entretanto, não deve ser usada essa estratégia, pois a cache seria esvaziada de
informação útil. Nesses casos, MRU torna-se uma boa escolha.
A.2Nível de Multiprogramação
O Nível de Multiprogramação (MultiProgramming Level - MPL) é o
parâmetro que controla o número máximo de processos concorrentes que podem
ser atendidos pelo sistema. O MPL pode in�uir de forma inversa na vazão e no
tempo de resposta, sendo que até um certo limite o aumento do MPL aumenta
a vazão mas diminui o tempo de resposta por causa da contenção de recursos
requisitados por vários processos simultaneamente. A determinação de seu valor
ótimo é um processo complexo por causa da dependência que tem com a carga
de trabalho, como mostrado na �gura 2.2.
Em sistemas de processamento de transações que executam concorrente-
mente, pode ocorrer um problema de sobrecarga em que excessivos con�itos de
bloqueio provoquem que o tempo de resposta de uma grande parte das transa-
ções aumente drasticamente, a vazão caia e o sistema deva ser reiniciado. Este
problema é chamado de thrashing de contenção de dados. Conforme [18, 66],
o thrashing pode ser evitado através do controle do MPL.
Em [49] se sugere basear a escolha do nível de multiprogramação no
método de ajustes incrementais [25], dado que lamentavelmente os sistemas
de banco de dados não possuem o algoritmo proposto em [66] que não pode
ser usado de outra forma porque requer monitoramento contínuo. A proposta
de [66] propõe um método chamado controle de carga orientado a con�itos.
Nele se procura o controle automático e dinâmico do nível de bloqueios através
da observação de uma métrica chamada de "razão de con�ito"(con�ict ratio)
que se calcula como a razão entre o total de bloqueios existentes no sistema
e o total que pertencem a transações ativas, re�etindo o grau de contenção
de dados presente no sistema. A razão de con�ito tem um valor crítico quase
constante com independência da carga bem de�nido tanto experimental como
analiticamente em torno de 1.3 [59, 66]. Caso esta métrica alcance seu valor
crítico, existem grandes probabilidades de thrashing e devem ser tomadas
ações de sintonia. Estas podem ser o controle de admissão e o controle de
cancelamento. O princípio de trabalho do controle de carga orientado a con�itos
é mostrado na �gura A.2.
O controle de admissão determina se uma nova transação deve ser
processada ou se deve esperar em �la na entrada do sistema. O algoritmo para
o controle de admissão proposto em [66] é o seguinte:
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 79
Figura A.2: O princípio de trabalho do controle de carga orientado a con�itos[66].
upon a BOT request for transaction T:
if conflict ratio < critical conflict ratio
then admit T
else put T in the transaction queue
fi
upon the EOT of transaction T:
update conflict ratio
if conflict ratio < critical conflict ratio then
foreach transaction Tqueued in the transaction queue do
if (Tqueued will be started the first time) or
Tqueued has been a deadlock victim or cancelation
victim before and all transactions that Tqueued was
waiting for in its previous execution have been
succesfully completed)
then admit Tqueued
fi
od
fi
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 80
Note que o algoritmo é executado ao ser requisitado um inicio de
transação (BOT - Begin Of Transaction) e ao terminar uma transação. Uma
nova transação será admitida no sistema se o valor da razão de con�itos não
ultrapassar o nível crítico. Caso contrário a transação é colocada na �la. Ao
terminar de executar uma transação é checado o estado da razão de con�itos.
Se o valor da variável estiver dentro do intervalo admissível, uma heurística
é executada para liberar transações da �la. Esta prioriza transações novas e
aquelas que foram canceladas e já podem ser completadas.
Uma melhora ao algoritmo pode consistir na determinação dos locks
que cada nova transação vai solicitar, de forma que não sejam colocadas na
�la aquelas cujas requisições não estão relacionadas com o problema presente
de thrashing. Da mesma forma podem ser escolhidas as transações a serem
liberadas da �la quando o valor da razão de con�ito sair da região crítica.
Isso implica, por outro lado, na necessidade de algoritmos para controlar
a possibilidade de deadlocks entre as transações que �cam na �la. Nessa
dissertação não foi usada uma implementação aprimorada deste controle pois
não se trata de um objetivo fundamental da pesquisa e também devido as
limitações de tempo para desenvolvimento.
Dado que as transações que estão sendo executadas pelo sistema podem
continuar a solicitar novos bloqueios, o controle de admissão é complementado
com o controle de cancelamento. O controle de cancelamento pode abortar tran-
sações que presentemente estão no sistema, colocando-as na �la de transações
até serem reiniciadas posteriormente pelo mecanismo de controle de admissão.
O algoritmo para o controle de cancelamento proposto é apresentado a seguir:
Upon a lock wait of transaction T:
update conflict ratio
while conflict ratio >= critical conflict ratio do
among the transactions that are blocked and block
other transactions
determine the transaction Tvictime with the smallest product
number of locks held * number of previous restarts
(with the transaction with the highest product being exempt)
abort Tvictim and put it in the transaction queue
if no elegible transaction found then exit loop fi
od
O algoritmo mostrado cancela a transação com o menor produto número
de bloqueios possuídos*número de prévios reinícios. A idéia por trás a heurística
Uma arquitetura para auto-sintonia global de SGBDs usando agentes 81
para a escolha da vítima de cancelamento está em um compromisso entre a
minimização de esforço perdido e a tentativa de evitar starvation. A transação
cancelada é colocada na �la de transações até ser readmitida no sistema pelo
controle de admissão.