Utilização de Redes Neurais na Manutenção Pró-Ativa de Índices

Transcrição

1 Utilização de Redes Neurais na Manutenção Pró-Ativa de Índices André Medeiros 1,2, Aristênio Saraiva 2, Gustavo Campos 2, José Maria Monteiro 3 1 IBM - Brasil agbm@br.ibm.com 2 Departamento de Computação, Universidade Estadual do Ceará (UECE) - Brasil {aristenio, gustavo}@uece.br 3 Departamento de Computação, Universidade Federal do Ceará (UFC) - Brasil monteiro@lia.ufc.br Abstract. This paper presents a mechanism, denoted Neural-PIM, for proactive index management based on the use of artificial neural networks. Neural-PIM is DBMS-independent, runs continuously and with no DBA intervention. Additionally, Neural-PIM is based on a four steps approach: (1) monitoring the workload submitted to DBMS, (2) identifying a set of time consuming queries and discovery the more appropriate index structures to reduce the response time of the previous identified queries, (3) prediction, using a neural network, of the next time that these queries will run again, and (4) index creation/drop in an automatic and proactive manner. Experiments show that our method can be effectively deployed to predict the time consuming queries execution and provides performance gains, even if the created index are dropped as soon as the predicted query (associated with it) runs. Categories and Subject Descriptors: H. Information Systems [H.m. Miscellaneous]: Databases Keywords: neural network, index, self-tuning 1. INTRODUÇÃO As aplicações de banco de dados têm como um de seus principais requisitos o desempenho, o qual pode ser expresso pelo tempo de resposta das consultas e pela vazão (throughput) das transações. Neste contexto, as estruturas de índice adquirem um papel de fundamental importância. A existência de índices adequados acelera a execução das consultas submetidas ao SGBD (Sistema de Gerenciamento de Banco de Dados) [Morelli et al. 2009]. Assim, uma das principais atividades de um administrador de banco de dados (DBA - Database Administrator) consiste em manter uma configuração (conjunto) de índices sempre adequada, ou seja, que minimize o tempo de execução da carga de trabalho (conjunto de consultas e atualizações) submetida ao SGBD. Contudo, realizar manutenção (criação, remoção e reorganização) da configuração de índices de forma manual tem se tornado uma tarefa complexa, uma vez que requer um profundo conhecimento acerca dos parâmetros dos SGBDs, das características dos dados armazenados e da carga de trabalho [Chaudhuri and Narasayya 2007]. Nos últimos anos, alguns trabalhos têm investigado estratégias para realizar a manutenção da configuração de índices de forma automática e contínua [Bruno and Chaudhuri 2007a; 2007b; Schnaitter et al. 2006; 2007; Luhring et al. 2007; Sattler et al. 2003; 2003; Sattler et al. 2004]. Porém, estas soluções usualmente adotam a estratégia clássica de auto-sintonia [Weikum et al. 1994], a qual é composta pelas seguintes fases: Observação, Predição e Reação. Assim, essas abordagens podem ser classificadas como reativas. Uma solução reativa analisa periodicamente uma amostra da carga de trabalho anteriormente executada e, caso ocorram alterações relevantes nas características da carga de trabalho monitorada, o sistema reage alterando a configuração de índices corrente. Já uma solução pró-ativa busca prever mudanças nas propriedades da carga de trabalho, ou seja, procura identificar as particularidades da carga de trabalho que será executada no futuro, e de maneira pró-ativa realizar os ajustes necessários na configuração de índices. 33

2 146-2 J.M. Monteiro et al. Neste trabalho, estamos especialmente interessados em um tipo particular de consultas, às quais serão denominadas consultas com elevado tempo de execução. Tais consultas apresentam os seguintes aspectos: i) elevado tempo de execução; ii) baixa freqüência; iii) distribuição irregular; e iv) existência de estruturas de índice que possibilitem acelerar sua execução. Neste contexto, seria interessante manter um histórico das execuções das consultas que possuem esse perfil e, com base nesse histórico, prever o momento em que uma dessas consultas será executada novamente. Desta forma, uma ferramenta poderia se antecipar a este evento e criar, de maneira automática e pró-ativa, as estruturas de índice adequadas a fim de acelerar a execução da consulta. Este artigo apresenta um mecanismo capaz de realizar a manutenção pró-ativa das estruturas de índices para consultas com elevado tempo de execução. A solução proposta, denominada Neural-PIM, baseia-se na utilização de redes neurais artificiais (RNAs) e é independente da intervenção humana. Adicionalmente, uma arquitetura para a implementação da abordagem proposta é discutida. A arquitetura apresentada é independente do SGBD e executa suas tarefas de forma contínua. Para realizar a previsão da execução das consultas duas redes neurais diferentes foram investigadas: multilayer perceptron (MLP) e radial basis function (RBF) [Bishop 2006]. A abordagem proposta foi implementada e avaliada em um ambiente real. Os testes realizados indicam a viabilidade de se prever a execução das consultas com elevado tempo de resposta e que a criação pró-ativa de índices para estas consultas proporciona ganhos de desempenho. O restante deste artigo está organizado da seguinte forma: a seção 2 apresenta os trabalhos relacionados; a seção 3 discute a arquitetura e a abordagem proposta neste trabalho para a manutenção pró-ativa de índices; na seção 4 os resultados experimentais são apresentados e discutidos e a seção 5 conclui este trabalho e aponta direções para trabalhos futuros. 2. TRABALHOS RELACIONADOS Nesta seção iremos discutir as abordagens encontradas na literatura para a manutenção automática de índices. Vale ressaltar que as abordagens identificadas são reativas, enquanto a solução proposta neste trabalho é pró-ativa. Em [Bruno and Chaudhuri 2007a; 2007b] os autores apresentam uma ferramenta para a sintonia de índices implementada como um componente do Microsoft SQL Server Esta ferramenta executa continuamente e, reagindo a variações na carga de trabalho ou nas características dos dados acessados, modifica de forma automática o projeto físico do banco de dados. Schnaitter et al apresentam em [Schnaitter et al. 2006; 2007] o protótipo de um framework de autosintonia denominado COLT (Continuous On-Line Tuning). Essa ferramenta monitora continuamente as consultas submetidas ao SGBD e automaticamente ajusta a configuração de índices. O COLT foi implementado de forma intrusiva junto ao código do PostgreSQL, substituindo o otimizador de consultas do PostgreSQL por um módulo, denominado Extended Query Optimizer (EQO), e adicionando um novo módulo chamado Self-Tuning Module (STM). Em [Luhring et al. 2007] é apresentada uma extensão ao PostgreSQL cujo objetivo é fornecer suporte para a sintonia automática de índices. Esta ferramenta executa de forma seqüencial e contínua as três fases do ciclo de auto-sintonia definidos em [Weikum et al. 1994]. Em [Sattler et al. 2003; 2003; Sattler et al. 2004] os autores propõem um middleware para o IBM DB2 o qual sugere de forma automática a criação de índices. Esta solução baseia-se em comandos proprietários do DB2 (e.g SET CURRENT EXPLAIN MODE RECOMMEND INDEXES), os quais podem não estar disponíveis em outros SGBDs. Além disso, ela requer que todas as cláusulas SQL sejam encaminhadas para o middleware, o qual redireciona esses comandos para o SGBD. O trabalho proposto em [Salles and Lifschitz 2005; de Carvalho Costa et al. 2005; Morelli et al. 2009] apresenta um componente de sintonia automática de índices implementado junto ao código do PostgreSQL, o qual permite a criação, remoção e reconstrução de índices de forma autônoma. 34

3 3. MANUTENÇÃO PRÓ-ATIVA DE ÍNDICES Utilização de Redes Neurais na Manutenção Pró-Ativa de Índices Nesta seção apresentamos uma abordagem e uma arquitetura para a manutenção pró-ativa das estruturas de índices voltada para consultas com elevado tempo de execução. 3.1 A Arquitetura Proposta A arquitetura proposta neste trabalho (Figura 1), uma extensão do arcabouço apresentado em [Monteiro et al. 2008], permite a manutenção automática e pró-ativa das estruturas de índice. De um modo geral, a arquitetura propõe a realização da auto-sintonia durante a operação normal do SGBD, por meio da colaboração entre agentes de software, os quais utilizam drivers para obter informações do banco de dados. A utilização dos drivers possibilita que a arquitetura seja independente de SGBD. A seguir, discute-se os principais componentes desta arquitetura: Fig. 1. Arquitetura para a Manutenção Pró-Ativa de Índices. Agent for Workload Obtainment (AWO): Este agente captura periodicamente a carga de trabalho submetida ao SGBD alvo. Para isso, o agente consulta a metabase do SGBD e recupera as cláusulas SQL que foram ou estão sendo executadas, juntamente com seus respectivos planos de execução e estimativas de custo. Em seguida, essas informações são armazenadas na metabase local (LM). Local MetaData (LM): A metabase local armazena a carga de trabalho capturada pelo agente AWO e um conjunto de informações acerca das estruturas de índice gerenciadas pela arquitetura. Driver for Workload Access (DWA): Permite recuperar a carga de trabalho submetida ao SGBD. Executer Agent (EA): Este agente é responsável pelas atualizações no esquema do SGBD alvo, isto é, pela criação e remoção de índices. O agente executor recebe uma recomendação do agente APIM e executa esta recomendação no SGBD alvo. Driver for DBMS Update (DDU): Driver responsável por executar os comandos necessários para atualizar a configuração de índices. Agent for Proactive Index Maintenance for Very Heavy Queries (APIM): Este agente é responsável pela manutenção pró-ativa da configuração de índices. 35

4 146-4 J.M. Monteiro et al. 3.2 A Abordagem Proposta A abordagem proposta neste trabalho para a manutenção pró-ativa de índices é composta por quatro etapas. A seguir, cada uma dessas etapas é discutida em detalhes Etapa 1: Monitoramento e captura da carga de trabalho. Consiste em extrair do catálogo (log) do SGBD alvo a carga de trabalho a este submetida. Assim, para cada instrução SQL executada, o agente AWO obtém e armazena na LM: a própria cláusula SQL, seu plano de execução e o seu custo Etapa 2: Identificação das consultas com elevado tempo de execução e das estruturas de índices mais adequadas para estas consultas. A solução proposta para identificar as consultas com elevado tempo de execução baseia-se na heurística de benefícios, inicialmente proposta em [Salles and Lifschitz 2005]. O conceito de beneficio busca quantificar o ganho proporcionado pela utilização de uma determinada estrutura de índice i para uma consulta q. Mais formalmente, podemos definir benefício como: Definição 3.1 Benefício. Seja B i,q o benefício proporcionado pela estrutura de índice i para o processamento de uma consulta q. Temos que: B i,q = max{0, cost(q) cost(q, i)}, onde, cost(q) representa o custo de execução da consulta q sem a utilização do índice i e cost(q, i) representa o custo de execução da consulta q utilizando-se o índice i. A partir do conceito de benefício pode-se definir formalmente o que neste trabalho será considerada uma consulta com elevado tempo de execução. Definição 3.2 Consulta com Elevado Tempo de Execução. Uma consulta q é considerada de elevado tempo de execução se e somente se: i) RT q > t, onde RT q é o tempo de resposta de q e t é uma constante (parâmetro); ii) F q < k, onde F q é a quantidade de execuções de q divida pelo tamanho do período de observação, dado em meses, e k é uma constante (parâmetro); e iii) existe pelo menos uma estrutura de índice i tal que: B i,q > EC Ci, onde EC Ci é o custo estimado de criação da estrutura de índice i. Nesta etapa, com a finalidade de se identificar as consultas com elevado tempo de execução, juntamente com os índices mais adequados para cada uma dessas consultas utilizamos uma adaptação da estratégia proposta em [Monteiro et al. 2008]. O mecanismo proposto em [Monteiro et al. 2008] utiliza o conceitos de Plano Hipotético e foi concebido para identificar os índices que poderiam trazer benefícios para uma determinada consulta. A idéia básica desta estratégia consiste em obter para cada consulta capturada o seu plano de execução real, ou seja, aquele gerado pelo otimizador de consultas, e, em seguida, percorrer esse plano buscando-se identificar operações que não utilizam índices, como um full scan, por exemplo, mas que poderiam ser substituídas por operações que fizessem uso de índices, caso esses índices existissem, como um index scan, por exemplo. As operações substitutas são denominadas hipotéticas, os índices utilizados por elas são chamados índices hipotéticos e o plano gerado por este processamento é denominado plano hipotético. Assim, supõem-se que se os índices hipotéticos existissem o otimizador de consultas poderia escolher um plano de execução melhor que o plano real [Monteiro et al. 2008]. Logo, os índices identificados neste processo são considerados os mais adequados para acelerar a execução da consulta analisada. Neste trabalho, adaptamos a estratégia concebida em [Monteiro et al. 2008] aplicando uma restrição sobre os índices hipotéticos identificados, qual seja: selecionamos somente os índices hipotéticos cujo benefício para a consulta analisada q, (B i,q ), seja maior que o seu custo de criação EC Ci. O conjunto de índices selecionados para a consulta q é denominado I q. Esta tarefa é realizada periodicamente e de forma automática pelo agente APIM, que após processar cada consulta SQL q, previamente capturada e armazenada na LM, armazena na LM: i) a informação de que q é uma consulta com elevado tempo de execução e ii) o conjunto I q. 36

5 Utilização de Redes Neurais na Manutenção Pró-Ativa de Índices Etapa 3: Previsão da execução das consultas com elevado tempo de execução. Nesta etapa, já foram identificadas as consultas com elevado tempo de execução, bem como os índices adequados para cada uma dessas consultas. O próximo passo consiste em instanciar e treinar uma RNA com previsão de tempo (objeto implementado em linguagem Java) para cada consulta q identificada, cuja finalidade é prever quando q irá executar novamente. Contudo, aqui surge um desafio: como identificar a configuração mais adequada para esta rede neural? Esse problema é discutido na seção 3.3. O agente APIM utiliza as redes neurais existentes para prever a próxima ocorrência de uma determinada consulta q. Para isso, dada uma consulta com elevado tempo de execução previamente identificada q, o agente APIM recupera da LM as n últimas execuções (dependendo da janela de tempo utilizada) e, em seguida, aplica a rede neural para prever quando q irá executar novamente. Em seguida, este agente solicita ao EA que agende a criação dos índices associados a q. Essa requisição é composta pela seguinte tripla: < q, I q, N q >, onde N q é a data prevista para a próxima execução de q. Além disso, o agente APIM monitora as consultas executadas e capturadas (a partir da metabase local) com a finalidade de descobrir se uma determinada consulta q, cuja execução foi prevista e cujos índices pertencentes a I q foram criados de maneira pró-ativa, já foi executada Etapa 4: Criação e remoção automática e pró-ativa de índices. Nesta etapa, cada requisição referente à criação de índices (contendo < q, I q, N q >) recebida pela agente EA é agendada para um instante de tempo t anterior a N q. Nos experimentos realizados utilizou como valor de t a madrugada anterior a N q. Vale ressaltar que diminuindo o valor de t seria possível aumentar a taxa de acerto, ou seja, a probabilidade de q executar após t. Contudo, o overhead de manter os índices criados sem serem efetivamente utilizados também seria incrementado. Adicionalmente, após a execução de uma consulta q o agente EA pode: i) receber e executar solicitações para a remoção dos índices em I q ou ii) manter materializados os índices em I q. 3.3 Identificação das Redes Neurais Utilizadas Nesta seção iremos discutir como encontrar uma modelagem de uma rede neural que seja adequada para a previsão da execução de consultas SQL. Com esta finalidade utilizou-se uma estratégia baseada em cinco passos, os quais serão apresentados a seguir Passo 1: Coleta dos dados de treinamento e de teste. Neste passo coletamos o histórico das consultas executas no SGBD alvo. Para a execução desta tarefa existem duas possibilidades: (i) utilizar a metabase local (LM) gerenciada pela arquitetura proposta; e (ii) analisar o arquivo de log (transaction log) do SGBD alvo, o qual armazena todas as cláusulas SQL de todas as transações submetidas ao SGBD. Neste trabalho optamos por utilizar o arquivo de log como fonte dos registros históricos das consultas executadas. Essa escolha foi motivada principalmente pelo fato da metabase local (LM) ainda não possuir um volume significativo de informações. Assim, para implementar e avaliar a abordagem proposta analisou-se os arquivos de log de um banco de dados real utilizado por uma empresa multinacional, cuja identidade não será revelada por questões de sigilo. Foram analisados os registros das transações executadas no período de 2008 a 2010 em um banco de dados de produção, utilizado por uma aplicação OLTP. Este banco de dados é constituído por tabelas e possui o tamanho de 1,5 TB. As informações referentes às consultas executas, aos planos de execução utilizados, bem como data e hora da execução foram extraídas dos arquivos de log armazenadas na LM Passo 2: Pré e pós-processamento dos dados. Neste passo, processamos e analisamos o histórico das consultas executadas no período de 2008 a 2010, com a finalidade de: (i) selecionar (filtrar) somente as consultas com elevado tempo de execução; e, (ii) decompor a data/hora (valor do tipo datetime) de execução de cada consulta em dois valores distintos: dia e mês. Em seguida, selecionou-se as consultas com RT q > 9000s, F q < 5 e distribuição irregular. Esses valores foram escolhidos com o objetivo de gerar uma amostra pequena mas representativa de consultas, as quais foram utilizadas para validar a abordagem proposta e a utilização das redes neurais. Assim, cinco consultas foram selecionadas, o que resultou em 90 redes neurais avaliadas e 360 execuções de teste. 37

6 146-6 J.M. Monteiro et al Passo 3: Projetar a estrutura de rede neural. Este passo tem por finalidade identificar uma modelagem de uma rede neural que seja adequada para a previsão da execução de consultas SQL. Neste sentido, avaliamos duas redes neurais diferentes: multilayer perceptron (MPL) com janela de tempo e radial basis function (RBF). Para cada uma das redes neurais (MPL e RBF) utilizamos três modelagens diferentes, e em cada modelagem variamos a janela de tempo entre duas, três e quatro janelas. A primeira modelagem utiliza classificadores como resultado. Neste caso, a entrada da rede é formada pelas variáveis dia e mês, enquanto a saída desejada consiste em um par contendo um dia e um mês separados por hífen. Quando utilizamos classificadores temos que declarar todos os possíveis valores de entrada e saída da rede neural, o que é chamado de especificação nominal. A segunda modelagem utiliza o coeficiente de correlação como resultado. Neste caso, as entradas da rede têm como variáveis o dia e mês, e como saída desejada o dia do ano, variando entre 1 e 365. Quando se usa coeficiente de correlação não é preciso declarar os valores possíveis das variáveis e sim o tipo de dado, se é numérico e ou inteiro. A terceira modelagem também utiliza o coeficiente de correlação como resultado, só que neste caso as entradas e saídas desejadas da rede têm como variável o dia do ano, variando entre 1 e 365. Para a rede MPL adaptamos o seu algoritmo a fim de possibilitar a execução de tarefas dinâmicas, já que o mesmo não suporta este tipo de arquitetura. Para isso, incluímos na entrada da rede um atraso seqüencial no tempo. Com isso, iremos ter no conjunto de entrada e saída da rede valores seqüências ordenados por tempo, onde em cada interação o conjunto de entrada será iniciado com o valor posterior ao que foi iniciado na seqüência anterior. Assim, para cada uma das cinco consultas selecionadas utilizamos 18 redes neurais diferentes, totalizando 90 redes distintas. Para implementar, treinar e validar cada uma das redes neurais, utilizamos a ferramenta WEKA (Waikato Environment for Knowledge Analysis), a qual é formada por vários algoritmos e técnicas de redes neurais e mineração de dados Passo 4: Treinamento da rede neural. Após a conclusão do projeto das redes neurais, utilizamos a ferramenta WEKA para realizar o treinamento de cada uma dessas 90 redes. Treinamos as redes neurais alterando os valores de diferentes variáveis. Para as redes MPL, por exemplo, alteramos os parâmetros: hiddenlayers, learningrate e trainingtime. A primeira variável define as camadas ocultas da rede neural. Esta é uma lista de números inteiros positivos, uma para cada camada oculta, separadas por vírgula. A segunda variável é o valor dos pesos atualizados e a terceira variável é o número de épocas utilizadas para treinar a rede. As redes neurais do tipo MLP foram treinadas seguindo as combinações descritas na Tabela 1. Configuração HiddenLayers LearningRate TrainingTime 1 5, 10, 20 0, , 10, 20 0, , 10, 20 0, , 10, 20 0, Tabela I. Configuração das Variáveis Utilizadas na Fase de Treinamento das Redes MPL Treinamos as redes neurais do tipo RBF alterando os valores de apenas uma variável: numclusters. Esta variável representa a quantidade de clusters que a RBF irá utilizar. As redes neurais do tipo RBF foram treinadas seguindo as combinações descritas na Tabela II. Configuração numclusters Tabela II. Configurações da Variável numclusters Usadas na Fase de Treinamento das Redes RBF 38

7 Utilização de Redes Neurais na Manutenção Pró-Ativa de Índices Passo 5: Avaliação das redes neurais. Para avaliar os resultados das redes MLP e RBF na fase de validação foi usado o método validação cruzada com 10 partições. Este método é bastante utilizado em cenários onde o objetivo é previsão e envolve o particionamento dos dados em 10 subconjuntos. Um desses subconjuntos é utilizado na fase de treinamento enquanto os outros nove são usados para validação. Os resultados apresentados pelas redes neurais são avaliados de dois modos distintos neste trabalho. Para a primeira modelagem, que utiliza classificadores, a avaliação é realizada pela a porcentagem de classificadores corretos. Já para a segunda e terceira modelagem a avaliação é realizada pelo o coeficiente de correlação. Este coeficiente estabelece um nível de relação entre os valores desejados e os obtidos pela a rede. O coeficiente de correlação pode assumir valores entre -1 e 1. Os sinais são utilizados para indicar correlação linear positiva e negativa. Valores próximos de -1 indicam forte correlação linear negativa entre os valores preditos e obtidos, enquanto que valores próximos de +1 indicam forte correlação linear positiva. Valores entre 0.30 a 0.70 positivos ou negativos indicam correlação moderada. Vale ressaltar que os resultados podem variar dependendo do tamanho da janela de tempo utilizada, da quantidade de camadas ocultas, da atualização dos pesos nos neurônios e o do tempo de treinamento utilizado. Os passos utilizados para se identificar a melhor configuração de uma rede neural para a previsão de consultas foram executados de forma semi-automática. Contudo, uma vez identificada essa rede, para cada nova consulta capturada um objeto java é instanciado automaticamente para representar essa rede, a qual é é treinada e validada de forma automática. 4. RESULTADOS EXPERIMENTAIS A rede MPL, na primeira modelagem e com janela de tempo igual a 2 apresentou na fase de treinamento uma média (para as 5 consultas analisadas) de 77,29% de classificadores corretos. Já na fase de validação esse valor caiu para 52,70%. Contudo, para as janelas de tempo 3 e 4 esta modelagem não conseguiu completar o resultado, pois apresentou um elevado custo computacional. Já na rede RBF, a primeira modelagem não conseguiu completar sua execução para nenhum das três janelas de tempo utilizadas. Por este motivo, desconsideramos a utilização desta modelagem e, a partir deste ponto, iremos analisar apenas os resultados da segunda e terceira modelagens. Nos testes realizados na fase de treinamento foi verificado que a modelagem 2 usando a janela de tempo igual a 2 do algoritmo MPL teve a melhor média (0,7867) considerando os valores dos coeficientes de correlação obtidos para as cinco consultas analisadas, indicando uma correlação forte. Já nos testes realizados na fase de validação foi verificado que a modelagem 3 usando a janela de tempo igual a 3 do algoritmo RBF teve a melhor média de coeficientes de correlação (0,4913) entre as outras modelagens analisadas, indicando uma correlação moderada. A Tabela III ilustra o ganho que abordagem proposta proporciona a cada previsão realizada corretamente. Nesta tabela, mostra-se para cada consulta: o seu tempo de resposta na ausência das estruturas de índice, o seu tempo de resposta na presença dos índices adequados (e criados de maneira pró-ativa), o tempo de criação do índice e o ganho proporcionado pela abordagem a cada acerto, o qual obtido subtraindo do tempo de resposta obtido na ausências dos índices o tempo de resposta na presença de índices mais o tempo de criação dos índices. Vale destacar que o ganho proporcionado pela criação pró-ativa de índices para a Consulta 3 é de 17100s, o que equivale a quase 5 horas. Assim, para esta consulta específica o seu tempo de execução é reduzido em quase 5 horas a cada previsão correta. Como os resultados das previsões realizadas pelas redes neurais com as modelagens 2 e 3 foram obtidos utilizando-se o coeficiente de correlação não foi possível indicar a taxa de acerto e de erro proporcionadas por estas modelagens. Logo, não foi possível afirmar quantas vezes a Consulta 3, por exemplo, foi prevista corretamente ou em quantas oportunidades a previsão dessa consulta falhou. Novos testes estão sendo conduzidos para avaliar esses aspectos. 39

8 146-8 J.M. Monteiro et al. Consulta TR sem Índices TR com os Índices TC dos Índices Ganho da Abordagem Consulta s 4560 s 1200 s 3600 s Consulta s 5820 s 3520 s 4700 s Consulta s 8400 s 3300 s s Consulta s 6600 s 2160 s 7440 s Consulta s 6400 s 4080 s 8720 s Tabela III. Ganho da Abordagem Proposta a Cada Previsão Correta 5. CONCLUSÕES Neste trabalho, apresentamos um mecanismo que possibilita a manutenção pró-ativa das estruturas de índices para consultas com elevado tempo de execução. A solução adotada utiliza um conjunto de heurísticas e uma rede neural com a finalidade de monitorar continuamente a carga de trabalho, identificar as consultas com elevado tempo de execução e as estruturas de índices mais adequadas para essas consultas, inferir o momento em que as consultas identificadas serão novamente executadas e, de forma automática, criar ou remover os índices necessários. O mecanismo desenvolvido também pode ser configurado para funcionar de forma semi-automática, gerando alertas sobre as consultas previstas mas deixando a decisão da criação dos índices para o DBA. Os resultados experimentais indicaram que as redes neurais utilizadas proporcionaram uma correlação forte (0,7867) durante a fase de treinamento e moderada (0,4913) durante a fase de validação entre os valores preditos e obtidos. Além disso, a criação pró-ativa de índices proporcionou uma redução de quase 5 horas, a cada previsão correta, no tempo de execução de uma das consultas analisadas. Esses resultados atestam a viabilidade e a eficácia da solução proposta neste trabalho. REFERÊNCIAS Bishop, C. M. Pattern Recognition and Machine Learning. Springer-Verlag New York, Inc., Secaucus, NJ, USA, Bruno, N. and Chaudhuri, S. An online approach to physical design tuning. In Proceedings of the IEEE International Conference on Data Engineering. Los Alamitos, CA, USA, pp , 2007a. Bruno, N. and Chaudhuri, S. Online autoadmin: (physical design tuning). In Proceedings of the ACM SIGMOD International Conference on Management of Data Conference. ACM, pp , 2007b. Chaudhuri, S. and Narasayya, V. Self-tuning database systems: A decade of progress. In Proceedings of the International Conference on Very Large Data Bases. VLDB Endowment, pp. 3 14, de Carvalho Costa, R. L., Lifschitz, S., de Noronha, M. F., and Salles, M. A. V. Implementation of an agent architecture for automated index tuning. In Proceedings of the International Workshop on Self-Managing Database Systems, Luhring, M., Sattler, K.-U., Schmidt, K., and Schallehn, E. Autonomous management of soft indexes. In Proceedings of the IEEE International Conference on Data Engineering. IEEE Computer Society, Washington, DC, USA, pp , Monteiro, J. M., Lifschitz, S., and Brayner, A. A non-intrusive tool to automatic index maintenance. In In Demo Session of the Brazilian Symposium on Database, Morelli, E. M. T., Monteiro, J. M., Almeida, A. C., and Lifschitz, S. Automatic reindexation in relational dbmss. In Proceedings of the Brazilian Symposium on Databases, Salles, M. A. V. and Lifschitz, S. Autonomic index management. In Proceedings of the International Conference on Autonomic Computing. pp , Sattler, K.-U., Geist, I., and Schallehn, E. Quiet: Continuous query-driven index tuning. In Proceedings of the International Conference on Very Large Data Bases. VLDB Endowment, pp , Sattler, K.-U., Schallehn, E., and Geist, I. Autonomous query-driven index tuning. In Proceedings of the International Database Engineering and Applications Symposium. IEEE Computer Society, Washington, DC, USA, pp , Schnaitter, K., Abiteboul, S., Milo, T., and Polyzotis, N. Colt: continuous on-line tuning. In Proceedings of the ACM SIGMOD International Conference on Management of Data Conference. ACM, New York, NY, USA, pp , Schnaitter, K., Abiteboul, S., Milo, T., and Polyzotis, N. On-line index selection for shifting workloads. In Proceedings of the International Workshop on Self-Managing Database Systems. pp , Weikum, G., Hasse, C., Moenkeberg, A., and Zabback, P. The COMFORT automatic tuning project, invited project review. Information Systems 19 (5): ,