Curso de Engenharia de Computao

ESTUDO SOBRE OTIMIZAO DE BANCO DE DADOS

Gustavo Buso Pontes

Campinas So Paulo Brasil

Dezembro de 2009
 Curso de Engenharia de Computao

ESTUDO SOBRE OTIMIZAO DE BANCO DE DADOS

Gustavo Buso Pontes

Monografia apresentada disciplina de Trabalho de

Concluso do Curso de Engenharia de Computao da
Universidade So Francisco, sob a orientao do Prof. Ms.
Marcio Henrique Zuchini, como exigncia parcial para
concluso do curso de graduao.

Orientador: Prof. Mestre Marcio Henrique Zuchini.

Campinas So Paulo Brasil

Dezembro de 2009
 iii

ESTUDO SOBRE OTIMIZAO DE BANCO DE DADOS

Gustavo Buso Pontes

Monografia defendida e aprovada em 15 de Dezembro de 2009 pela Banca

Examinadora assim constituda:

Prof. Ms. Marcio Henrique Zuchini

USF Universidade So Francisco Campinas SP.

Prof. Carlos Eduardo Pagani

USF Universidade So Francisco Campinas SP.

Prof . Ms. Cludio Maximiliano Zaina

USF Universidade So Francisco Campinas SP.
 1

A minha famlia, namorada e amigos, os quais me

ofereceram todo o apoio necessrio.
 2

.Agradecimentos

Agradeo primeiramente a Deus, que me deu a vida e a fora para lutar.

Agradeo a meus pais e irm por todo carinho e dedicao em todos os momentos da minha
vida.

Agradeo a minha namorada por sempre demonstrar seu amor, apoio e dedicao.

Agradeo ao Prof. Marcio Henrique Zuchini, pelas crticas, ensinamentos e todo o apoio.
 3

Sumrio

Lista de Siglas ........................................................................................................................ 05

Lista de Figuras ..................................................................................................................... 06

Lista de Tabelas ..................................................................................................................... 07

Resumo ................................................................................................................................... 08

Abstract .................................................................................................................................. 09

1. INTRODUO ................................................................................................................. 10
1.1 Contextualizao .......................................................................................................................................... 10

1.2 Objetivo ......................................................................................................................................................... 10

1.3 Estrutura do texto......................................................................................................................................... 11

2. REVISO BIBLIOGRFICA ......................................................................................... 12

2.1 Banco de Dados ............................................................................................................................................. 12

2.2 Otimizao (Tuning) .................................................................................................................................... 13

2.3 Ajuste de desempenho .................................................................................................................................. 14

2.4 Localizao dos gargalos .............................................................................................................................. 14

2.5 Parmetros ajustveis .................................................................................................................................. 15

2.6 Ajuste de ndices ........................................................................................................................................... 16

3. PROJETO DESENVOLVIDO ......................................................................................... 18

3.1 Virtualizao e VMware .............................................................................................................................. 18

3.2 PostgreSQL ................................................................................................................................................... 19

3.3 Benchmark TPC-C ....................................................................................................................................... 20

3.4 Benchmark SQL ........................................................................................................................................... 20

3.4.1 Metodologia ................................................................................................................................................ 21

3.4.2 Transaes.................................................................................................................................................. 22

3.4.3 Configurao do Benchmark SQL ........................................................................................................... 23

4. IMPLEMENTAO ........................................................................................................ 25
 4

4.1 Mquinas virtuais ......................................................................................................................................... 25

4.2 Simulao 1 ................................................................................................................................................... 26

4.2.1 Anlise dos resultados ............................................................................................................................... 27

4.2.2 Otimizao 1 do PostgreSQL.................................................................................................................... 28

4.2.3 Anlise dos resultados com a Otimizao 1 ............................................................................................. 30

4.3 Simulao 2 ................................................................................................................................................... 32

4.3.1 Anlise dos resultados ............................................................................................................................... 32

4.3.2 Otimizao 2 do PostgreSQL.................................................................................................................... 33

4.3.3 Anlise dos resultados com a Otimizao 2 ............................................................................................. 34

4.4 Anlise das simulaes ................................................................................................................................. 36

5. CONCLUSO.................................................................................................................... 38

5.1 Contribuies ................................................................................................................................................ 39

5.2 Trabalhos futuros ......................................................................................................................................... 40

Referncias Bibliogrficas .................................................................................................... 41

Bibliografia Consultada ........................................................................................................ 42

Apndice 1 Resultado detalhado da Simulao 1 ............................................................ 43

Apndice 2 Resultado detalhado da Simulao 2 ............................................................ 45

 5

Lista de Siglas

ACID Atomicidade, Consistncia, Independncia e Durabilidade.

CPU Central Processing Unit
IDE Intelligent Drive Electronics
JDBC Java Data Base Connectivity
ODBC Open Data Base Connectivity
OLTP On Line Transaction Processing
RAM Random Access Memory
SCSI Small Computer System Interface
SGBD Sistema Gerenciador de Banco de Dados
SQL Structured Query Language
TPC-C Transaction Processing Performance Council
TPC-H Transaction Processing Performance Ad-hoc
TPMC Tempo Mdio de Processamento das Transaes TPC-C
WAL Write Ahead Log
 6

Lista de Figuras

FIGURA 1: Diagrama da hierarquia das relaes TPC-C no BenchmarkSQL. ................................................... 21

FIGURA 2: Diagrama de entidade-relacionamento da base de dados de teste..................................................... 22

FIGURA 3: Arquivo de configurao PostgreSQL.properties............................................................................. 24

FIGURA 4: Tela inicial do BenchmarkSQL. ....................................................................................................... 25

FIGURA 5: Configurao dos recursos do servidor fsico e das mquinas virtuais. ............................................ 26

FIGURA 6: Anlise de desempenho dos Servidores 1 e 2 na Simulao 1.......................................................... 27

FIGURA 7: Comparao do desempenho da otimizao do Servidor 3 em relao aos Servidores 1 e 2.. ......... 30

FIGURA 8: Quantidade de transaes realizadas por Servidor na Simulao 1 .................................................. 31

FIGURA 9: TPMC por Servidor na Simulao 1.. ............................................................................................... 31

FIGURA 10: Anlise de desempenho dos Servidores 1 e 2 na Simulao 2 ........................................................ 33

FIGURA 11: Comparao do desempenho da otimizao do Servidor 3 em relao aos Servidores 1 e 2.. ....... 34

FIGURA 12: Quantidade de transaes realizadas por Servidor na Simulao 2.. .............................................. 35

FIGURA 13: TPMC por Servidor na Simulao 2. .............................................................................................. 35

FIGURA 14: Comparao de desempenho entre os servidores da Simulao 1 e 2. ........................................... 36

FIGURA 15: Comparao do desempenho da TPMC dos servidores na Simulao 1 e 2................................... 37

FIGURA 16: Comparao da quantidade de transaes realizadas nos servidores na Simulao 1 e 2............... 37
 7

Lista de Tabelas

TABELA 1: Percentual de execuo de cada transao no BenchmarkSQL.......................... 22

 8

Resumo

A demanda por sistemas de banco de dados cresce continuamente e junto, o volume e a

complexidade de dados que estes sistemas devem gerenciar. Este trabalho mostra a
importncia que a otimizao de um sistema gerenciador de banco de dados pode exercer
dentro de um ambiente que trabalha com processamento de transaes em tempo real. Sendo
realizada uma anlise de desempenho da otimizao do banco de dados PostgreSQL, com
foco na configurao de seus parmetros. Para a simulao e comparao dos testes de
performance foi utilizada a ferramenta BenchmarkSQL que se baseia na metodologia TPC-C.

PALAVRAS-CHAVE: BANCO DE DADOS, OTIMIZAO, DESEMPENHO.

 9

Abstract

The demand for database systems continually increases and with that, the volume and
complexity of data these systems must manage. This work shows the importance of a database
management system tuning which works on online processing transactions. An analysis of
PostgreSQL database tuning performance has been made focusing on parameter
configuration. For the simulation and comparison of performance tests, the tool
BenchmarlSQL was used, based on TPC-C methodology.

PALAVRAS-CHAVE: DATABASE, TUNING, PERFORMANCE.

 10

1 INTRODUO

1.1 Contextualizao

Atualmente, encontram-se no mercado diversos Sistemas Gerenciadores de Banco de

Dados (SGBD), os quais na maioria dos casos so instalados, configurados e utilizados com
todos os seus parmetros em valores padro, desconsiderando o tipo de aplicao para o qual
sero utilizados, o hardware e at mesmo o sistema operacional. Desta forma nem sempre se
obtm o melhor desempenho do sistema, visto que diversos parmetros podem ser
considerados e ajustados.

Quando uma empresa no possui uma equipe tcnica com um bom grau de
treinamento e conhecimento do SGBD que utiliza, certamente no possuir um sistema
totalmente configurado e adaptado para as suas aplicaes, o que acaba gerando uma baixa
performance. Muitas vezes por falta desse conhecimento especfico pode ocorrer um erro de
planejamento, pois se investe em aquisio de novos equipamentos mais potentes, para suprir
uma necessidade que poderia ser melhorada apenas com uma melhor administrao dos
recursos de software de seu SGBD.

1.2 Objetivo

Este trabalho tem por objetivo mostrar como um SGBD que ir trabalhar com
aplicaes OLTP (On Line Transaction Processing) pode se comportar ajustando-se
parmetros de configuraes especificas e tambm de mudanas dos recursos de hardware.
Intenciona-se mostrar que alguns ajustes podem trazer grandes ganhos de desempenho e que
nem sempre o melhor caminho para melhoria de desempenho o investimento em novos
recursos de hardware.
 11

1.3 Estrutura do texto

Este trabalho est dividido da seguinte maneira:

Capitulo1 Introduo contendo a contextualizao e a estrutura do texto.

Capitulo 2 Reviso Bibliogrfica contendo os conceitos sobre banco de dados,

otimizao, o ajuste de desempenho, a localizao dos gargalos, os parmetros ajustveis e o
ajuste de ndices.

Capitulo 3 Projeto Desenvolvido contendo descrio da virtualizao, do banco de

dados e das ferramentas utilizadas.

Capitulo 4 Implementao contendo a descrio das mquinas virtuais, a

metodologia utilizada nas simulaes, a tcnica utilizada para otimizao do sistema e a
anlise dos resultados.

Capitulo 5 Concluso contendo concluso sobre os resultados obtidos, a contribuio

e a proposta para os trabalhos futuros.
 12

2 REVISO BIBLIOGRAFICA

2.1 Banco de dados

A necessidade por Sistemas de Gerenciamento de Bancos de Dados cresce

continuamente. Junto com essa demanda, cresce tambm o volume de dados que estes
sistemas devem gerenciar e a complexidade de suas aplicaes. Os bancos de dados esto em
toda parte e a maioria das pessoas interage diariamente, direta ou indiretamente com esses
sistemas. Neste cenrio, realizar operaes com segurana, de forma eficiente, garantindo a
integridade sobre estas grandes colees de dados uma questo fundamental, j que o
desempenho de um SGBD medido a partir de sua eficincia diante das consultas e
alteraes.

Segundo [SILBERSCHATZ 2006]: O principal objetivo de um banco de dados

fornecer um ambiente que seja tanto conveniente quanto eficiente para as pessoas usarem na
recuperao e armazenamento das informaes, oferecendo aos usurios apenas o resultado
final atravs de uma viso abstrata dos dados e assim, ocultando os detalhes de como os dados
so armazenados e mantidos.

[DATE 2003] define: Sistema Gerenciador de Banco de Dados o software que

manipula todos os acessos ao banco de dados. O SGBD um software que funciona como
uma interface entre o usurio e o banco de dados, ou seja, todas as solicitaes dos usurios,
como criao de tabelas, insero de dados, recuperao de dados, so manipuladas pelo
SGBD.

As principais funes desempenhadas por um SGBD incluem:

Processamento e Otimizao de Consultas: uma consulta expressa em linguagem de

alto nvel como SQL (Structured Query Language), deve primeiro, ser examinada,
analisada, validada e otimizada, para s ento ser executada;
 13

Processamento de Transaes: a manipulao do banco de dados se d por meio de

transaes. Uma transao uma unidade lgica de processamento, formada por uma
ou mais operaes de acesso a dados. O SGBD deve garantir que as transaes tenham
um conjunto de propriedades conhecido como ACID (Atomicidade, Consistncia,
Independncia e Durabilidade). Para tal, ele deve escalonar as transaes, provendo
controle de concorrncia;

Recuperao de Falhas: responsabilidade de SGBD manter a consistncia do banco

de dados mesmo aps falhas. Para fazer isso, o SGBD deve manter informaes sobre
as alteraes executadas pelas transaes em um arquivo de log. A partir do log
possvel refazer ou desfazer os efeitos das transaes;

2.2 Otimizao (Tuning)

A avaliao de desempenho est presente em todos os momentos do ciclo de vida de um

sistema computacional. Na hora de projetar, produzir ou implantar um sistema, o objetivo
final sempre o mesmo: escolher dentre diversas alternativas aquela que proporcione o
melhor desempenho, com o menor custo possvel.

Um banco de dados mal configurado ou que no tenha tido um bom projeto de

desenvolvimento gera um grande desperdcio de recursos tanto de hardware e sotfware e essa
improdutividade pode ser mais crtica em sistemas OLTP ou que necessitem de algum tipo de
backup em tempo real, como por exemplo: sistemas de reserva de passagem area, sistemas
bancrios, sistemas de acompanhamento do mercado financeiro etc.

Aps um banco de dados ter sido desenvolvido e estar em operao, o uso real das
aplicaes, das transaes, das consultas e das vises revela fatores e reas de problemas que
podem no ter sido considerados durante o projeto de desenvolvimento.

As informaes de entrada para o projeto fsico podem ser revisadas por meio da coleta
de estatsticas reais sobre os padres de uso. A utilizao dos recursos, bem como o
 14

processamento interno do SGBD pode ser monitorado para revelar gargalos, tais como a
disputa pelos mesmos dados ou dispositivos. Os volumes de atividades e os tamanhos dos
dados podem ser melhor estimados. Portanto, necessrio monitorar e revisar o projeto fsico
do banco de dados constantemente, mostrando quais ajustes devem ser efetuados no sistema
para melhor atender s necessidades dos usurios finais, propiciando a execuo mais rpida
do mesmo volume de transaes sobre o mesmo hardware e software.

2.3 Ajuste de desempenho

No projeto de SGBD comum descobrir que, quando uma aplicao montada, ela
fica mais lenta do que os desenvolvedores previam, ou trata menos transaes por segundo.
De acordo com [SILBERSCHATZ 2006]: Uma aplicao que leva um tempo excessivo para
realizar as aes solicitadas pode causar, insatisfao do usurio e tambm se tornar
inutilizvel.

O ajuste de desempenho envolve ajustar vrios parmetros e opo de projeto a fim de

melhorar seu desempenho para uma aplicao especfica. Em um sistema de banco de dados,
diversos aspectos podem ser ajustados, variando desde aspectos de alto nvel, como os
projetos de esquema de transaes, at parmetros do sistema como buffer de memria, limite
de conexes e aspectos de hardware, como nmero de discos e tamanho de memria fsica.

Mas para que seja possvel realizar o ajuste de um sistema, primeiro preciso tentar
descobrir quais so os gargalos do sistema e depois tentar elimin-los da maneira mais eficaz
possvel.

2.4 Localizao dos gargalos

O desempenho da maioria dos sistemas em geral limitado principalmente pelo

desempenho de alguns componentes, chamados de gargalos. Por exemplo, um programa pode
gastar 80% do seu tempo em um pequeno loop dentro do cdigo e 20% no restante do cdigo,
ento o pequeno loop considerado um gargalo. A melhoria do desempenho de um
 15

componente que no seja um gargalo faz pouca diferena para melhorar a velocidade do
sistema. No exemplo a melhoria de desempenho no restante do cdigo no pode resultar em
mais que 20% de melhoria do sistema, enquanto que a melhoria da velocidade do loop de
gargalo, poderia resultar em um ganho significativo de desempenho.

Em um sistema balanceado nenhum componente isolado um gargalo, quando um

gargalo removido pode acontecer que outro componente se torne um gargalo, pois o outro
componente estava sendo subtilizado e talvez no estivesse preparado para uma nova
demanda que surgiu com a soluo do primeiro gargalo. [SILBERSCHATZ 2006] afirma:
que utilizaes de recursos em torno de 70% so consideradas boas, e as utilizaes acima
de 90% so consideras excessivas e podem ser tratadas como um gargalo.

Pode-se concluir que em sistemas que contenham gargalos que no possam ser
solucionados por algum motivo tcnico ou financeiro, os componentes que no fazem parte
do gargalo so subtilizados e talvez possam ser substitudos por componentes mais baratos
com menor desempenho, gerando uma reduo de custos.

2.5 Parmetros ajustveis

Os administradores de um banco de dados podem ajustar um SGBD em trs nveis

[SILBERSCHATZ, 2006].

O nvel mais baixo o de hardware. As opes para o ajuste de um sistema de banco

de dados no nvel de hardware podem incluir acrescentar discos rgidos de maior capacidade,
aumentar a quantidade de memria, passar para um processador mais rpido ou aumentar a
largura de banda. Para uma determinada funo existem diversos tipos de hardware que so
diferenciados de acordo com sua capacidade e performance, quanto melhor for a performance
do dispositivo, maior ser a tecnologia agregada e assim maior ser o seu custo final. Por
exemplo, um disco rgido IDE (Intelligent Drive Electronics) pode possuir a mesma
capacidade de armazenamento de um disco SCSI (Small Computer System Interface), mas a
performance e o custo do dispositivo SCSI ser mais elevada.
 16

O segundo nvel consiste em parmetros de configurao do sistema de banco de

dados, como tamanho do buffer de controle de checkpoints (pontos de controle). O conjunto e
tipo de parmetros exatos que podem ser ajustados dependem do sistema especifico de banco
de dados, a maioria dos sistemas oferecem manuais com informaes sobre quais parmetros
que podem ser ajustados. Sistemas de banco de dados bem projetados realizam o mximo de
desempenho possvel automaticamente, poupando os usurios e administradores desse
trabalho.

O terceiro nvel o projeto de mais alto nvel, englobando esquemas e transaes.

Pode-se ajustar o projeto do esquema, a criao de ndices e a execuo de transaes de
modo a melhorar o desempenho. O ajuste nesse nvel relativamente, independente do tipo de
SGBD.

Os trs nveis de ajuste interagem entre si. Devemos considerar tal combinao
quando ajustamos o sistema. Por exemplo, ajustar um nvel mais alto pode resultar em uma
alterao no gargalo de hardware, como do disco rgido para CPU (Central Processing Unit).

2.6 Ajuste de ndices

Podemos ajustar os ndices de um sistema de banco de dados para melhorar seu

desempenho. Se for constatado que as consultas so um gargalo, pode-se acelerar seu
processamento criando ndices apropriados paras relaes. Se as atualizaes so o gargalo,
provvel que haja um excesso de ndice que precisam ser alterados quando as relaes so
atualizadas. A remoo dos ndices pode melhorar o desempenho das atualizaes.

O uso de ndices contribui para o processo de otimizao do sistema. Os ndices so

estruturas opcionais mantidas pelo SGBD, que fornece a otimizao e o acesso a seus dados.
Para a criao de um ndice necessrio especificar uma tabela e uma ou mais colunas a
controlar. Uma vez criado um ndice, o SGBD o mantm automaticamente quando os dados
so criados, alterados e eliminados de suas tabelas. [DATE 2003], define as seguintes regras
para ajuda na deciso de se criar um ndice:
 17

Deve-se indexar colunas que tenham um intervalo de valores distintos.

Se determinado valor da coluna de uma tabela apresentado em 20%
ou mais das tuplas, ento a coluna uma candidata para um ndice;

Se vrias colunas so, continuamente referenciadas juntas nos

predicados da declarao SQL, deve-se considerar a colocao delas em
um ndice;

Ao construir um ndice em uma tabela, se todos os valores de coluna

ndice so distintos, aconselhvel cria-lo como ndice nico,
Encontrar modos de usar ndices nicos ajuda o processo de
otimizao;
 18

3 PROJETO DESENVOLVIDO

Este trabalho prope uma anlise da otimizao do banco de dados PostgreSQL (seo
3.2), em diferentes ambientes de testes, atravs da ferramenta BenchmarkSQL (seo 3.4) que
se baseia na metodologia TPC-C (Transaction Processing Performance Council) (seo 3.3).

Primeiramente foram criados dois ambientes de testes, sendo um com SGBD

otimizado e outro no. Dentro de cada ambiente foram implementadas trs mquinas virtuais
com o software VMware (seo 3.1), cada uma com uma configurao especfica de
hardware, mas com a mesma configurao de sistema operacional.

Aps a criao das mquinas virtuais, foi realizado a instalao e configurao do

banco de dados PostgreSQL, que foi submetido a uma carga de testes de desempenho com o
software BenchmarkSQL nos diferentes ambientes com as diferentes configuraes de
otimizao. O software simulou uma carga de dados e a execuo de determinado conjunto de
transaes, por um determinado perodo de tempo. Nos dois ambientes virtuais o SGBD
trabalhou com transaes OLTP em duas situaes: com uma quantidade razovel de
transaes, aproximadamente 12.000 e outro com uma grande quantidade de transaes
superior a 200.000.

Depois de executado todas as cargas de testes em cada mquina virtual, coletou-se os

dados obtidos e realizou uma anlise de comparao do desempenho do PostgreSQL.
Observando seu comportamento em cada mquina virtual e em especial no ambiente onde foi
realizada a otimizao do SGDB.

3.1 Virtualizao e VMware

Virtualizao o processo de executar vrios sistemas operacionais em um nico

equipamento. Uma mquina virtual um ambiente operacional completo que se comporta
 19

como se fosse um computador independente. Com a virtualizao, um servidor pode manter

vrios sistemas operacionais em uso [VMware 2008].

Neste trabalho foi utilizado o software VMware Workstation 6.5, que permite trabalhar
com um ou mais sistemas operacionais simultaneamente num ambiente isolado, criando
mquinas virtuais completas dentro de um computador fsico que esta utilizando um sistema
operacional totalmente distinto [VMware 2008].

3.2 PostgreSQL

O PostgreSQL um Sistema Gerenciador de Banco de Dados Objeto Relacional,

desenvolvido pelo Departamento de Cincia da Computao da Universidade da Califrnia
em Berkeley. Suporta grande parte do padro SQL:2003, alm de serem oferecidas muitas
funcionalidades modernas que existem nos principais SGBD comerciais, como:

- comandos complexos;

- chaves estrangeiras;

- gatilhos;

- vises;

- integridade transacional;

- controle de simultaneidade multiverso;

Devido sua licena aberta, o PostgreSQL pode ser utilizado, modificado e distribudo
por qualquer pessoa para qualquer finalidade, seja privada, comercial ou acadmica, livre de
encargos. Para este trabalho foi utilizado a verso 8.4.1.
 20

3.3 Benchmark TPC-C

O benchmark TPC-C considerado um dos principais metodologia da indstria para

avaliao da performance de sistemas OLTP. Encarrega-se de testar a maior parte das
funcionalidades de um banco de dados, como consultas e atualizaes [TPC-C 2009].

TPC-C mede a taxa de transferncia de transaes de negcios mesclando transaes de

apenas leitura com transaes que fazem intensivas atualizaes. O teste quantifica quantas
novas transaes de pedidos um sistema pode absorver por minuto enquanto esse mesmo
sistema executa, simultaneamente, outros quatro tipos de transaes.

3.4 BenchmarkSQL

O BenchmarkSQL uma ferramenta de cdigo aberto baseada na metodologia TPC-C

desenvolvida em linguagem de programao Java. Utiliza drivers JDBC (Java Database
Connectivity) para se comunicar com o SGBD e isto o torna compatvel com a grande maioria
dos sistemas de bancos de dados.

Por ser uma ferramenta baseada na metodologia TPC-C, que o objetivo a avaliao
do desempenho de determinado sistema de banco de dados, atravs da execuo de diversas
transaes do tipo OLTP, mistura transaes de apenas leitura com transaes que fazem
intensivas atualizaes no banco de dados.
 21

3.4.1 Metodologia

O BenchmarkSQL composto de uma srie de transaes projetadas para simular um

tpico sistema de aquisio de produtos, com funcionalidades genricas que se enquadram
para qualquer tipo de negcio que trabalhem com transaes online.

O ambiente simula um fornecedor atacadista que possui determinado nmero de

territrios de vendas e lojas associadas. Conforme a empresa cresce, novas lojas e territrios
so criados. Cada territrio tem capacidade para atender 3000 clientes. Existem tambm os
armazns regionais, sendo que cada armazm atende 10 territrios. Todas as lojas mantm um
estoque de 100.000 produtos que so vendidos pela empresa. Os detalhes do ambiente de
simulao podem ser visto nas Figuras 1 e 2:

FIGURA 1: Diagrama da hierarquia das relaes TPC-C no BenchmarkSQL.

 22

FIGURA 2: Diagrama de entidade-relacionamento da base de dados de teste.

3.4.2 Transaes

O BenchmarkSQL define cinco tipos de transaes que devem ser submetidas contra o
SGBD durante a carga de teste: New-Order, Payment, Order-Status, Delivery e Stock-Level.

A tabela 1 mostra o percentual de execuo de cada transao definido de acordo com

as especificaes do TPC-C, sendo possvel sua a alterao dentro do BenchmarkSQL, assim
sendo possvel obter uma simulao mais prxima da aplicao real e focando nas transaes
mais especificas para cada tipo de simulao [TPC-C 2009].

TABELA 1: Percentual de execuo de cada transao no BenchmarkSQL.

New-Order: A transao New-Order representa a entrada de uma nova ordem no

sistema. Considerada uma transao leve, no consumindo muitos recursos
computacionais e com alto ndice de execuo;
 23

Payment: A transao Payment atualiza o crdito de um cliente e reflete este

pagamento nas estatsticas da tabela de territrios (DISTRICT). Considerada
uma transao leve e com alto ndice de execuo;

Order-Status: A transao Order-Status verifica o estado da ltima ordem de

pedido solicitada por um cliente. Transao de apenas leitura e considerada
mediana em relao ao consumo de recursos;

Delivery: A transao Delivery envolve o processamento em lote de dez novas

ordens. Cada ordem processada por completo, envolvendo operaes de leitura
e escrita na tabelas do banco de dados. Considerada uma transao leve, pois
possui baixa freqncia de execuo;

Stock-Level: A transao Stock-Level fornece o nmero de itens vendidos

recentemente e que possuem quantidade em estoque abaixo do limite
especificado. Esta transao representa uma operao pesada, ou seja, que
demanda grande quantidade de recursos computacionais.

3.4.3 Configurao do BenchmarkSQL

Consiste em cinco etapas: Configurao do Acesso ao SGBD, Criao das Tabelas no

SGBD, Carga das Tabelas, Criao de ndices e Execuo do BenchmarkSQL
[BenchmarkSQL 2006].

- Configurao do Acesso ao SGBD: Antes de realizar a execuo de qualquer

atividade no BenchmarkSQL, primeiramente foi necessrio fazer a configurao
do acesso ao SGBD utilizado. Essa configurao foi realizada dentro do arquivo
PostgreSQL.properties, que contem o driver ODBC (Open Data Base
Connectivity) do SGBD, caminho de acesso, usurio e senha. Como mostra a
Figura 3:
 24

FIGURA 3: Arquivo de configurao PostgreSQL.properties

- Criao das Tabelas: Nesta etapa foram criadas as tabelas dentro do SGBD,
executando um arquivo que faz parte do software BenchmarkSQL, chamado
runSQL.bat para o sistema operacional Windows ou runSQL.sh para o sistema
Unix, mais o comando sqlTableCreates. Comando:

runSQL PostgreSQL.properties sqlTableCreates

- Carga das Tabelas: Para a carga das tabelas no SGBD foi executado o arquivo
loadData.bat para o sistema operacional Windows ou loadData.sh para o sistema
Unix. Que gerou uma base de dados aleatrios nas tabelas do mtodo TPC-C,
aproximadamente 600.000 registros foram inseridos. Comando:

loadData PostgreSQL.properties

Por padro o BenchmarkSQL esta preparado para trabalhar apenas com uma
Warehouse, sendo possvel aumentar o nmero de Warehouses do ambiente,
atravs do parmetro numWarehoues=N, no final do comando loadData.
Comando:

loadData PostgreSQL.properties numWarehouses=10

- Criao de ndices: Nesta etapa foram criados os ndices e as chaves primrias

que identificam as tabelas, sendo apenas necessrio executar o comando
sqlIndexCreates. Comando:

runSQL PostgreSQL.properties sqlIndexCreates

- Execuo do BenchmarkSQL: Aps concluso das estapas de configuraes,

foi executado o programa BenchmarkSQL atravs do comando:

runBenchmark PostgreSQL.properties
 25

A Figura 4, mostra a tela inicial do BenchmarkSQL, com as opes de configurao

do banco de dados e o nome de usurio e senha.

FIGURA 4: Tela inicial do BenchmarkSQL.

4 IMPLEMENTAO

Este captulo tem por objetivo apresentar os detalhes da implementao dos dois
ambientes de simulao que foram utilizados e uma anlise dos resultados de desempenho do
SGBD dentro da cada ambiente.

4.1 Mquinas virtuais

Para a realizao deste trabalho utilizou-se um servidor fsico como hospedeiro, em

que foi instalado software VMware, dentro do software foram criadas trs mquinas virtuais,
chamadas de Servidor 1, Servidor 2 e Servidor 3. Os Servidores 1 e 2 possuem as mesmas
configuraes de software: sistema operacional Windows XP e banco de dados PostgreSQL
com sua configurao padro, sendo diferenciados pela configurao de hardware que torna o
Servidor 2 superior ao Servidor 1, devido o fato de possuir uma maior quantidade de memria
RAM (Random Access Memory)
 26

No caso do Servidor 3 que possui a mesma configurao de hardware do Servidor 1,

foram realizadas alteraes nas configuraes padres do banco de dados PostgreSQL,
criando uma otimizao voltada para operar com transaes OLTP. Essas configuraes esto
descritas em detalhes na seo 4.2.2. A Figura 5 mostra as configurao dos recursos do
servidor fsico e das mquinas virtuais:

FIGURA 5: Configurao dos recursos do servidor fsico e das mquinas virtuais.

4.2 Simulao 1

Aps a etapa de criao dos trs servidores virtuais, foi criada a primeira simulao de
desempenho, que consistiu em criar um ambiente que simulou um nmero razovel de
transaes OLTP nos trs servidores virtuais por um perodo de 10 minutos, atravs do
BenchmarkSQL. Para esta etapa foi utilizado a relao de 1 warehouse para 10 terminais.

O primeiro passo foi realizar a carga da base de dados no PostgreSQL, essa carga
consiste na criao de um banco de dados chamado TEST, que contm nove tabelas com
aproximadamente 600.000 tuplas e dentro dessas nove tabelas foram geradas vrias
transaes do tipo: New-Order, Payment, Order-Status, Delivery e Stock-Leve. Importante
ressaltar que para garantir um melhor resultado das avaliaes, sempre que uma simulao
 27

iniciada a base de dados antiga excluda e um novo banco criado novamente com mesmas
caractersticas.

4.2.1 Anlise dos resultados

Para poder mensurar o desempenho de um SGBD pelo BenchmarkSQL, foram

utilizadas duas mtricas de avaliao de performance: a primeira foi a Quantidade de
Transaes que foram processadas em um perodo de tempo e a segunda o Tempo Mdio de
Processamento das Transaes TPC-C (TPMC) que ser expresso em milisegundos (ms).

Primeiramente realizou-se uma anlise do desempenho dos Servidores 1 e 2, conforme

segue na Figura 6 :

FIGURA 6: Anlise de desempenho dos Servidores 1 e 2 na Simulao 1.

Observa-se que no Servidor 2 foram realizadas 25,1% menos transaes que o

Servidor 1 e que a TPMC do Servidor 2, foi 32,5% maior que no Servidor 1.

Os resultados das simulaes detalhadas por cada servidor e seus terminais, encontra-
se no Apndice 1.
 28

4.2.2 Otimizao 1 do PostgreSQL

Para a realizao da simulao no Servidor 3, foi desenvolvida uma configurao

otimizada para o banco de dados PostgreSQL, com o objetivo de melhorar o desempenho do
SGBD em um ambiente que necessite trabalhar com muitas transaes OLTP, mas com
comandos no muito complexos. Para isso foram alterados alguns parmetros considerados
mais importantes para um sistema que ser submetido o este ambiente.

Todos as alteraes foram feitas diretamente no arquivo de configurao do

PostgreSQL, postgresql.conf. A baixo seguem as alteraes que foram realizadas nos
parmetros e o motivo dessas alteraes. As informaes complementares a respeito de cada
parmetro esto disponveis em maiores detalhes no manual do SGBD [PostgreSQL 2009].

max_connections: nmero mximo de conexes concorrentes que podem fazer

acesso ao banco de dados, pode ser considerado um dos parmetros mais
importantes para se obter um bom desempenho em transaes OLTP. Seu valor
padro 100, mas foi alterado para 130.

shared_buffers: nmero de buffers da memria compartilhada que utilizada

pelo SGBD. Este parmetro considerado um dos mais importantes dentro do
PostgreSQL. Seu valor padro 32Mb, como foi utilizado um servidor
dedicado apenas para SGBD com 512Mb de memria disponvel, com um
sistema operacional que no exige um grande consumo de memria, seu valor
foi alterado para 128Mb, 25% da memria disponvel.

wal_buffers: este parmetro responsvel pelo tamanho do nmero de buffers

que podem ser utilizados pelo WAL (Write Ahead Log) do sistema, garantindo
que os registros possam ser recuperados no caso de falha em alguma transao.
Como o ambiente que esta sendo simulado realiza muitas transaes de escrita
e leitura e gera uma grande quantidade Logs, esse parmetro teve seu valor
padro de 64Kb alterado para 128Kb. Entretanto, importante ressaltar que
 29

aumentar muito o valor deste parmetro pode resultar em perda de dados

durante uma possvel queda de energia, por exemplo.

maintenance_work_mem: quantidade de memria disponvel para operaes

de manuteno, como por exemplo, o comando Vacuum. O comando Vacuum
recupera a rea de armazenamento ocupada pelas tuplas excludas. Na
operao normal do PostgreSQL as tuplas excludas, ou tornadas obsoletas por
causa de uma atualizao, no so fisicamente removidas da tabela,
permanecem presentes at o comando Vacuum ser executado. Como o
ambiente simulado faz um nmero grande de alteraes nas tuplas, foi
realizada uma alterao no parmetro maintenance_work_mem que tem seu
valor padro definido em 16Mb e foi alterado para 48Mb, com o objetivo de
aumentar a velocidade de processamento do comando Vacuum.

effective_cache_size: este parmetro define o quanto de memria RAM ser

alocada para o sistema, sendo a configurao que agrega um maior
desempenho ao SGBD, pois evita a constante leitura das tabelas e ndices, dos
arquivos do disco rgido. Por exemplo, se uma tabela do banco de dados possui
20Mb, e o tamanho para esta configurao limita-se a 8Mb, o SGBD ir
carregar a tabela por etapas, em partes, at a concluso total da operao. Por
isso este parmetro impacta diretamente o aumento da performance do banco
de dados, pois diminui consideravelmente as operaes entrada e saida de
disco. O valor padro para este parmetro 128Mb, mas como esta sendo
utilizado um servidor dedicado apenas ao SGBD, foi altetrado para 50% da
memria RAM, ou seja, 256Mb.
 30

4.2.3 Anlise dos resultados com a Otimizao 1

Aps a realizao da otimizao do banco de dados PostgreSQL, foi realizado a

simulao dentro do Servidor 3 e uma nova anlise dos resultados comparando a performance
do Servidor 3 contra o Servidor 1 e 2. Conforme mostrado na Figura 7:

FIGURA 7: Comparao do desempenho da otimizao do Servidor 3 em relao aos

Servidores 1 e 2.

Percebe-se que o Servidor 3 teve um desempenho superior em 15,9% no nmero de

transaes que o Servidor 1 e a TPMC menor em 14,8%, sendo que os dois servidores
possuem a mesma configurao de hardware.

A anlise entre o Servidor 2 e o Servidor 3, mostra que o Servidor 3 teve um

desempenho no nmero de transaes superior a 54,6% e a mdia TPMC menor em 35,7%,
sendo que o Servidor 2 esta com uma configurao de hardware superior.

Os grficos das Figuras 8 e 9, mostram que a relao entre a quantidade de transaes

executadas e a mtrica TPMC so inversamente proporcionais, quanto menor for a TPMC do
SGBD, maior ser o nmero de transaes realizadas pelo sistema.
 31

FIGURA 8: Quantidade de transaes realizadas por Servidor na Simulao 1.

FIGURA 9: TPMC por Servidor na Simulao 1.

 32

4.3 Simulao 2

Nesta etapa criou-se um ambiente que simulou um grande nmero de transaes

OLTP nos trs servidores virtuais, por um perodo de 20 minutos, atravs do BenchmarkSQL.
Para isto foi utilizada uma relao de 10 warehouses para 50 terminais.

O primeiro passo foi realizar a carga da base de dados no PostgreSQL, essa carga
consiste na criao de um banco de dados chamado TEST2 que contm nove tabelas com
aproximadamente 3.000.000 tuplas e dentro dessas nove tabelas foram geradas vrias
transaes do tipo: New-Order, Payment, Order-Status, Delivery e Stock-Leve. Importante
ressaltar que para garantir um melhor resultado das avaliaes, sempre que uma simulao
iniciada o banco de dados antigo excludo e um novo banco criado novamente com
mesmas caractersticas.

4.3.1 Anlise dos resultados

Para esta simulao foram utilizadas a mesmas mtricas da Simulao 1: quantidade

de transaes e a TPMC.

Observa-se que na Figura 10, que o nmero de transaes realizadas pelos Servidores
1 e 2 foi aproximadamente 2.000 vezes maior que nmero de transaes realizadas na
Simulao 1 .
 33

FIGURA 10: Anlise de desempenho dos Servidores 1 e 2 na Simulao 2.

A Figura 10 mostra que no Servidor 2 foram realizadas 18,7% a menos de transaes e

que a TPMC no Servidor 2 foi 29,0% maior que no Servidor 1.

Os resultados das simulaes detalhadas por cada servidor, warehouses e seus

terminais, encontra-se na seo Apndice 2.

4.3.2 Otimizao 2 do PostgreSQL

Para a realizao da Simulao 2 no Servidor 3, foi mantida a mesma configurao de

otimizao da Simulao 1, pois todos os parmetros j estavam ajustados na configurao
mxima dentro do SGBD, com exceo do parmetro max_connections que ser detalhado a
seguir.

Como o parmetro max_connections considerado um dos mais importantes para

transaes OLTP, e a Simulao 2 executou com um nmero muito superior de transaes
que a Simulao 1, este parmetro teve seu valor aumentado em duas vezes, passando do
valor padro de 100 conexes para 200.
 34

4.3.3 Anlise dos resultados com a Otimizao 2

Aps a realizao da otimizao do sistema do PostgreSQL, foi realizado a simulao

dentro do Servidor 3 e uma nova anlise dos resultados comparando a performance do
Servidor 3 contra o Servidor 1 e 2. Conforme mostrado na Figura 11:

FIGURA 11: Comparao do desempenho da otimizao do Servidor 3 em relao aos

Servidores 1 e 2.

Percebe-se que o Servidor 3 teve um desempenho superior a 7,6% no nmero de

transaes que o Servidor 1 e a TPMC menor em 31,5%, sendo que os dois servidores
possuem a mesma configurao de hardware.

A anlise entre o Servidor 2 e o Servidor 3, mostra que o Servidor 3 teve um

desempenho no nmero de transaes superior a 32,4% no Servidor 2 e a TPMC menor em
46,9,7%, sendo que o Servidor 2 esta com uma configurao de hardware superior.

Os grficos das Figuras 12 e 13, mostram que a relao entre a quantidade de

transaes executadas e a TPMC tambm continuam inversamente proporcionais, seguindo a
mesma tendncia da Simulao 1.
 35

FIGURA 12: Quantidade de transaes realizadas por Servidor na Simulao 2.

FIGURA 13: TPMC por Servidor na Simulao 2.

 36

4.4 Anlise das simulaes

Percebe-se que existe uma perda de desempenho do Servidor 1 e Servidor 2 em

comparao ao Servidor 3, nas duas simulaes. Percebe-se tambm que essa perda menor
na Simulao 2 que trabalha com um nmero muito maior de transaes e um perodo maior
de tempo. Enquanto na Simulao 1 o Servidor 3 realiza 15,9% a mais de transaes em
comparao com o Servidor 1, na Simulao 2 esta diferena diminui para 7,6%, essa
diferena no caso do Servidor 2 vai de 54,6% na Simulao 1, para 32,4% na Simulao 2. Na
Figura 14, possvel visualizar essas diferenas.

FIGURA 14: Comparao de desempenho entre os servidores da Simulao 1 e 2 .

A TPMC do Servidor 3 obteve seu melhor desempenho de 52,31ms na Simulao 2,

que exige uma maior capacidade de processamento de transaes em um perodo mais longo
de tempo. Mostrando que foi realizada uma configurao de otimizao adequada para o
ambiente de testes em que o SGBD foi submetido. Conforme mostra o grfico da Figura 15.
 37

FIGURA 15: Comparao do desempenho da TPMC dos servidores na Simulao 1 e

2.

Transaes

300.000
272.547
253.222
250.000
205.916
s 200.000
e

sa
n
ar 150.000
T
e
d
t
Q 100.000

50.000
12.152 9.107 14.082
-
Servidor 1 Servidor 2 Servidor 3

Simulao 1 Simulao 2

FIGURA 16: Comparao da quantidade de transaes realizadas nos servidores na

Simulao 1 e 2.
 38

5 CONCLUSO

Este trabalho teve como objetivo mostrar a importncia da otimizao de um SGBD

em um ambiente OLTP, ou seja, que trabalha com uma grande quantidade de transaes
concorrentes e consultas simples. Atravs da ferramenta BenchmarkSQL que simula um
ambiente de teste atravs da metodologia TPC-C, sendo possvel mostrar as diferenas de
comportamento do SGBD nos dois ambientes de testes propostos.

Percebe-se que para um ambiente OLTP existe um gargalo nas configuraes padres
do PostgreSQL e que para a otimizao dos parmetros de configurao foi levado em
considerao alguns fatores especficos que envolveram: o tamanho de memria disponvel no
servidor, quantidade de conexes que podem ser realizadas no banco de dados
simultaneamente, tamanho da memria disponvel para operaes de manuteno e
configurao dos parmetros de log. Concluindo-se que as otimizaes foram realizadas de
forma balanceada, pois o gargalo no estava em um parmetro isolado.

Com relao ao SGBD PostgreSQL pode-se afirmar que sua configurao padro
comporta-se de forma eficiente em grandes bases de dados e quando executa funes
complexas, s que tal configurao no exerce o mesmo desempenho em um ambiente OLTP,
assim, sendo de extrema importncia sua otimizao para este tipo de ambiente. Tambm foi
comprovado que o servidor que estava com banco de dados PostgreSQL otimizado, teve uma
performance muito superior aos outros servidores, tanto no ambiente de Simulao 1 que
trabalhou com uma quantidade menor transaes e tanto para a Simulao 2 que trabalhou
com uma quantidade maior de transaes em um perodo maior de tempo.

Conclui-se que a realizao de uma otimizao correta para a o tipo de aplicao que o
SGBD ir trabalhar pode resultar em ganho significativo de desempenho, sendo de extrema
importncia possuir um bom conhecimento tcnico do SGBD que ser utilizado. Tambm se
conclui que liberar demasiadamente recursos computacionais do sistema para o SGBD nem
sempre resulta em aumento de desempenho, muito pelo contrrio, s vezes provoca perda de
desempenho. Podendo afirmar que a otimizao de um SGBD em uma corporao pode
 39

resultar em uma reduo substancial de custos, pois pode-se ter uma melhoria de performance
do sistema e um ganho de produtividade dos usurios finais, sem a necessidade de
investimento em novos recursos de hardware e software.

Otimizao de banco de dados ou simplesmente tuning pode ser definido com um

processo continuado de obteno de dados, que analisados, permitiro decidir quais ajustes
devem ser efetuados no sistema para melhor atender s necessidades dos usurios,
propiciando a execuo mais rpida do mesmo volume de transaes sobre o mesmo
hardware e software.

5.1 Contribuies

Atravs deste trabalho foi possvel comprovar que um SGBD mal configurado gera um
grande desperdcio de recursos, mostrando a importncia e necessidade dos benficos da
otimizao no PostgreSQL dentro do ambiente OLTP, gerando um ganho de performance
significativo sobre os mesmo recursos de hardware.

Assim, aps a uma anlise e concluso, podemos citar abaixo as contribuies que este
trabalho oferece para o leitor que deseja conhecer mais sobre a otimizao de banco de dados:

Que tipos de parmetros podem ser ajustados no PostgreSQL, quando se

trabalha com transaes OLTP e porque desses ajustes;

Implementao de uma forma de analise de performance para sistemas que

trabalhem com transaes OLTP.
 40

5.2 Trabalhos futuros

Para este trabalho foi utilizada a ferramenta BenchmarkSQL que utiliza o TPC-C que
uma das metodologias de anlise de peformance para SGBD da instituio TPC. A proposta
seria o desenvolvimento de um trabalho sobre os outros benchamrks da TPC, como por
exemplo o TPC-H (Transaction Processing Performance Ad-hoc) que simula um sistema de
suporte a deciso para grandes volumes de dados em tempo real.

Outra sugesto seria o desenvolvimento deste mesmo trabalho com o BenchmarkSQL

em outros SGBD, que esto disponveis no mercado e se possvel a realizao de uma
comparao entre o desempenho de cada fabricante.
 41

Referncias Bibliogrficas

[SILBERSCHATZ 2006] SILBERSCHATZ, Abraham; SILBERSCHATZ, Henry; SUDARSHAN, S. Sistema

de Banco de Dados. 5 ed. So Paulo: Pearson Makron Books,2006.

[DATE 2003 ] DATE, C. J. Introduo a Sistemas de Banco de Dados.5 ed. Rio de Janeiro: Campu, 2003.

[PostgreSQL 2009] Documentao do PostgreSQL 8.0.0. Disponvel online em

http://www.postgresql.org.br/docs

[BenchmarkSQL 2006] Documentao do BenchmarSQL User Guide. Disponvel online em

http://sourceforge.net/projects/benchmarksql/

[TPC-C 2009] TPC BENCHMARK C. Standard Specification Revision 5.10. Disponivel em

http://www.tpc.org/tpcc/spec/tpcc_current.pdf

[VMware 2008] VMware Workstation Users Manual. Disponvel online em

http://www.vmware.com/pdf/ws7_manual.pdf
 42

Bibliogrfica Consultada

Guest Operating System Installation Guide.Disponvel online em

http://www.vmware.com/pdf/GuestOS_guide.pdf

RODRIGUES, Marcelo Nunes. Analise de Desempenho de Sistemas OLTP Utilizando Benchmark TPC-C.
Centro de Informtica Universidade Federal de Pernambuco: Pernambuco 2006.

LEMKE, Vilson Zarnott. Anlise Comparativa dos Parmetros Envolvidos no Ajuste de Desempe dos Bancos de
Dados Oracle 91 e Interbase 6.5. Universidade Luterana do Brasil: Gravatai, 2002.
 43

Apndice 1 - Resultado detalhado da Simulao 1

As tabelas abaixo, mostram o resultado das simulaes detalhadas por cada servidor e
seus terminais, para a Simulao 1:
44
 45

Apndice 2 - Resultado detalhado da Simulao 2

As tabelas abaixo, mostram o resultado das simulaes detalhadas por cada servidor e
seus terminais, para a Simulao 2:
46
47