Baixar este arquivo PDF

Caderno de Estudos Tecnológicos
Uma abordagem prática sobre otimização de Banco de Dados
utilizando o gerenciamento automático de memória no Sistema
Gerenciador de Banco de Dados Oracle
Bruno P. Macedo1, José Mario P. Climaites1, Natanael S. Soares1.
Gustavo C. Bruschi²
1
Graduando em Tecnologia em Banco de Dados – Faculdade de Tecnologia de Bauru (FATEC)
Bauru – SP – Brasil
²
Professor do Curso de Tecnologia em Banco de Dados – Faculdade de Tecnologia de Bauru
(FATEC)
Bauru – SP – Brasil
[email protected], [email protected], [email protected],
[email protected]
Abstract. Database systems are becoming more and more useful. They help companies and
individuals to organize themselves better, have access to quick and precise information and
ensure a more competitive market position. The purpose of this project is to show what is
tuning of database using the Oracle, enabling businesses and information technology
professionals obtain some information.
Página
110
Resumo. Os sistemas de bancos de dados estão cada vez mais auxiliando empresas e as
pessoas a se organizarem e terem acesso à informações rápidas e precisas que as tornem
competitivas no mercado. Este trabalho mostrar a otimização de banco de dados,
utilizando o gerenciamento automático de memória do Oracle, possibilitando que empresas
e profissionais de tecnologia da informação obtenham algumas informações.
Faculdade de Tecnologia de Bauru
volume 01 – número 01 – julho/2013
Caderno de Estudos Tecnológicos
1. Introdução
O maior desafio desse trabalho é apresentar os benefícios alcançados com a otimização de
desempenho em banco de dados e as vantagens que ela pode trazer para as empresas e profissionais
de tecnologia da informação nos seus negócios.
Os bancos de dados têm se tornado cada vez mais importantes na sociedade moderna e, por
isso é cada vez mais necessário materiais e profissionais que dominem os seus conceitos, auxiliando as
empresas a tirarem o maior proveito de suas informações.
Esse trabalho visa auxiliar nesse processo com informações abordando o recurso de
gerenciamento automático de memoria do Sistema Gerenciador de Banco de Dados Oracle (SGBD) a
fim de obter maiores informações a respeito. Mesmo as empresas que desconhecem ou não acreditam
que a otimização de banco de dados possa ter impacto poderão ficar satisfeitas com os resultados
apresentados por esse trabalho.
1.1. Metodologia
Para a elaboração desse trabalho foi utilizado o SGBD, Oracle 11g Release 2 na sua versão Standard
Edition para sistemas sessenta e quatro bits, que pertence a Oracle Corporation sendo executado
sobre a plataforma de Sistema Operacional Windows 7 sessenta e quatro bits.
O Oracle Database 11g para Windows oferece uma solução de banco de dados otimizada para
disponibilizações que exigem escalabilidade, confiabilidade e alto desempenho. Usando um modelo de
serviço nativo do Windows baseado em thread, o Oracle Database 11g assegura alto desempenho,
escalabilidade, e integra-se perfeitamente aos avançados recursos do sistema operacional Windows e
ao hardware subjacente, oferecendo desempenho empresarial por meio de suporte a memória grande,
a arquivos grandes e brutos e a grid computing, certificado para sistemas operacionais Windows de 32
bits e de 64 bits (Colello, D; 2007).
Além do SGBD foi utilizado outro programa chamado Benchmark Factory sendo uma
ferramenta de teste de desempenho de banco de dados que permite conduz a reprodução da carga de
trabalho do banco de dados, testes esses de benchmark padrão industrial, e testes de escalabilidade,
ele permite que você implante alterações em seu ambiente de banco de dados com segurança, essa
alternativa foi usada para os testes na sua versão de avaliação por trinta dias, que pertence a Quest
Software. Outra curiosidade sobre o Benchmark Factory que ele é capaz simular uma quantidade
qualquer de usuários acessando simultaneamente como um servidor, permitindo avaliar o
comportamento do ambiente diante de uma grande quantidade de consultas e fazendo com que os
testes apresentados aqui sejam os mais reais possíveis.
Bancos de dados e sistemas de banco de dados são um componente essencial da vida na
sociedade moderna; a maioria de nós encontra diariamente diversas atividades que envolvem alguma
interação com um banco de dados. Por exemplo, quando vamos ao banco para depositar ou retirar
Faculdade de Tecnologia de Bauru
volume 01 – número 01 – julho/2013
Página
Em qualquer atividade ou lugar existe uma relação com sistemas de banco de dados. Nem sempre
essa relação é profunda, mas mesmo assim eles podem estar integrados. No mundo atual e na
proporção que necessitamos de informações em tempo hábil os bancos de dados tornam-se vitais em
nossas vidas.
111
2. Sistemas de Banco de Dados
Caderno de Estudos Tecnológicos
fundos, fazemos uma reserva de hotel ou voo, acessamos o catálogo de uma biblioteca virtual para
procurar uma referência bibliográfica, ou compramos algo on-line – como um livro ou brinquedo ou
um computador, provavelmente essas atividades envolveram alguém ou algum programa de
computador que acessa um banco de dados. Até mesmo a compra de produtos em um supermercado
atualiza automaticamente o banco de dados que mantém o controle de estoque dos itens (Elmasri;
Navathe, 2011)
Elmasri e Navathe, (2011) definem o termo banco de dados como: “Um banco de dados é uma
coleção de dados relacionados. Com dados queremos dizer fatos conhecidos que podem ser
registrados e possuem significado implícito.’’
3. Sistemas Gerenciadores de Banco de Dados (SGBD)
São softwares que permitem construir e manipular um banco de dados. Tudo o que fazemos
em um banco de dados passa pelo SGBD, ele é responsável por analisar, salvar, ligar e disponibilizar
os dados.
Um sistema gerenciador de banco de dados (SGBD - Database Management System) é uma
coleção de programas que permite aos usuários criar e manter um banco de dados. O SGBD é um
sistema de software de uso geral que facilita o processo de definição, construção, manipulação e
compartilhamento de bancos de dados entre diversos usuários e aplicações. (Elmasri; Navathe, 2011)
Para permitir a manipulação de um banco de dados, ele possui linguagens para definição,
consulta e manipulação desses dados. Essas linguagens auxiliam os desenvolvedores, administradores
de banco de dados e qualquer profissional que precisa manipular as informações contidas neles.
É muito comum que as pessoas chamem o SGBD de banco de dados (por exemplo: banco de
dados Oracle) sendo que na verdade eles são SGBD’s e banco de dados é o que eles oferecem aos
usuários.
4. Otimização de Banco de Dados
A otimização ou tuning pode ser definido como um ajuste para que algo funcione melhor,
independente do que seja. No caso desse trabalho estamos ajustando um banco de dados para ele
obtenha o melhor desempenho possível.
Faculdade de Tecnologia de Bauru
volume 01 – número 01 – julho/2013
Página
O processo de otimização em um banco de dados pode ser lento e envolver muitas
modificações na sua estrutura embora o resultado final deva compensar tudo isso. Essas modificações
podem envolver desde alterações nas instruções Structured Query Language (SQL) e no diagrama
entidade relacionamento até no hardware do servidor que está hospedando o banco de dados.
112
Segundo Ikematu (2000) a abordagem mais efetiva para realizar “tuning” é a abordagem
proativa na fase de projeto. O processo de tuning não começa quando os usuários reclamam sobre
tempo de respostas ruins. Quando o tempo de resposta está ruim, geralmente é muito tarde para usar
algumas das estratégias mais eficientes de “tuning”. Neste ponto, se não quiser redesenhar
completamente a aplicação, você pode somente melhorar a performance pela realocação de memória
e ajuste de I/O. Podendo chegar à conclusão que tanto o SGBD quanto o sistema operacional estão
funcionando bem. Neste caso, para conseguir obter performance adicional precisaria ajustar a
aplicação ou adicionar recursos.
Caderno de Estudos Tecnológicos
Vale ressaltar que a real possibilidade de implantação de qualquer otimização, ou seja, melhora
de performance, está ligada diretamente com o potencial intrínseco existente no modelo relacional,
caso uma otimização não seja possível de ser implantada, com certeza poderemos apontar para uma
falha de elaboração lógica do banco de dados, dentro das regras reais do modelo relacional. (Delgado
2011)
4.1. Tipos de Otimização
Podemos separar a otimização de banco de dados em três tipos principais, independente do SGBD
utilizado para realizar as mudanças:
1.
Otimização de consultas e objetos internos do banco de dados: aqui são avaliadas as consultas
executadas no banco de dados, os índices criados, recursos adicionais de otimização de
consulta oferecidos pelo SGBD utilizado, além de qualquer objeto interno que possa ser
melhorado;
2.
Otimização de sistema operacional: verificamos aqui os parâmetros e configurações existentes
no sistema operacional em uso pelo servidor;
3.
Otimização da arquitetura de memória do SGBD: essa é a otimização mais particular, pois são
avaliados parâmetros internos e comuns de cada SGBD. Parâmetros esses que se alterados
podem maximizar ou minimizar o desempenho ou comportamento do banco de dados, essa
está relacionada ao tema do artigo deste trabalho.
6. A Estrutura de Memória do Oracle
O Oracle é formado por duas estruturas de memória que são chamadas de Program Global
Area (PGA) e System Global Area (SGA). Abaixo temos as definições da PGA e SGA segundo dois
autores:
A Program Global Area é uma área de memória alocada e privada para um processo. A
configuração da PGA depende da configuração da conexão do banco de dados Oracle: ou servidor
compartilhado ou dedicado. (Bryla e Loney 2008).
Página
113
A System Global Area é um grupo de estruturas de memória compartilhada para uma instância
Oracle, compartilhada pelos usuários da instância de banco de dados. Quando uma instância Oracle é
iniciada, a memória é alocada para a SGA baseada nos valores especificados no arquivo de
parâmetros de inicialização ou codificado no software Oracle (Bryla e Loney 2008).
Faculdade de Tecnologia de Bauru
volume 01 – número 01 – julho/2013
Caderno de Estudos Tecnológicos
Imagem 1. Descrição da Estrutura da Memória do Oracle
Componentes e Grânulos da SGA
A SGA é composta por uma série de componentes de memória onde cada um tem sua função e
responsabilidade dentro do Oracle.
A Memória na SGA é alocada em unidades de grânulos. Um grânulo pode ser de quatro
megabytes ou dezesseis megabytes, dependendo do tamanho total da SGA. Se a SGA é menos que ou
igual a cento e vinte e oito megabytes, um grânulo é de quatro megabytes; do contrário ele é de
dezesseis megabytes (Bryla e Loney 2008).
Shared Pool
A Shared Pool é utilizada para armazenar os comandos SQL e Procedural Language/ Structured
Query Language (PL/SQL) que foram utilizados recentemente no servidor e as informações do
dicionário de dados que contém dois subcaches principais: a Library Cache e o Data Dictionary
Cache. A Shared Pool é medida pelo parâmetro de inicialização SHARED_POOL_SIZE. Este é um
outro parâmetro dinâmico que pode ser redimensionado desde que o tamanho total da SGA seja
menos que o SGA_MAX_SIZE ou SGA_TARGET. (Bryla e Loney 2008).
A Library Cache é responsável por armazenar os comandos SQL e PL/SQL enquanto que o
Data Dictionary Cache é uma coleção das tabelas do banco de dados que são de propriedade dos
usuários SYS e SYSTEM.
A partir do Oracle9i, a área de memória na SGA que armazena esses blocos de dados é
dinâmica. Isto é uma coisa boa, considerando que lá podem estar tablespaces no banco de dados com
tamanho de bloco diferentes do tamanho de bloco padrão; tablespaces com até cinco tamanhos de
Faculdade de Tecnologia de Bauru
volume 01 – número 01 – julho/2013
Página
Utilizado para armazenar os dados recentemente utilizados pelo banco de dados. Esta área é uma das
mais importantes, pois um correto gerenciamento dela diminui as gravações e leituras em disco.
114
Database Buffer Cache
Caderno de Estudos Tecnológicos
bloco diferentes (um tamanho de bloco pelo padrão, e até outros quatro tamanhos de bloco) requerem
seus próprios buffer cache. (Bryla e Loney 2008).
Redo Log Buffer
O Redo Log Buffer armazena as alterações feitas recentemente no banco de dados. As alterações são
armazenadas aqui antes de serem gravadas nos arquivos físicos.
Quando o Redo Log Buffer está um terço cheio, ou a cada três segundos, Oracle escreve os
registros Redo Log Buffer para os arquivos de Redo Log File. A transação cometida dos usuários não
é considerada completa até as entrada do Redo Log terem sido escritas de forma bem sucedida para
os arquivos do Redo Log (Bryla e Loney 2008).
Large Pool
Algumas operações requerem grandes blocos de memória para serem executadas e a Large Pool
reserva esse espaço para que elas possam utilizar quando precisarem.
A Large Pool é uma área opcional da SGA. É usado para transações que interagem com mais
que um banco de dados, mensagens do buffer para processos executando consultas paralelas, e o
RMAN paralelo salva e restaura as operações. Como o nome diz, o Large Pool disponibiliza grandes
blocos de memória para operações que precisam alocar grandes blocos de memória um de cada vez.
(Bryla e Loney 2008).
Java Pool
Utilizada pela Java Virtual Machine (JVM) para armazenar os códigos Java e funciona da mesma
maneira que a Shared Pool com os códigos SQL e PL/SQL.
Stream Pool
Utilizada armazenar os dados e manter o controle sobre o recurso Oracle Streams da Enterprise
Edition do Oracle.
Oracle Stream gerencia o compartilhamento dos dados e eventos num ambiente distribuído.
(Bryla e Loney 2008).
7. O Automatic Shared Memory Management
Quando o gerenciamento automático de memória está habilitado, os tamanhos dos diferentes
componentes da SGA são flexíveis e podem se adaptar às necessidades de uma carga de trabalho sem
exigir qualquer configuração adicional. O banco de dados automaticamente distribui a memória
Faculdade de Tecnologia de Bauru
volume 01 – número 01 – julho/2013
Página
O Gerenciamento Automático de Memória Compartilhada simplifica o gerenciamento de
memória do SGA. Você especifica o montante total da memória disponível da SGA para uma instância
usando o parâmetro de inicialização SGA_TARGET e o banco de dados Oracle automaticamente
distribui esta memória entre os vários componentes da SGA para assegurar a mais efetiva utilização
de memória. (Fogel 2007)
115
A SGA pode ser configurada manualmente com qualquer quantidade de memória (dependendo
da quantidade existente no servidor que o Oracle está instalado) ou então podemos habilitar uma
opção chamada de Automatic Shared Memory Management (ASMM). A função de gerenciamento
automático de memória foi introduzida no Oracle 11g.
Caderno de Estudos Tecnológicos
disponível entre os vários componentes como é exigido, permitindo ao sistema maximizar o uso de
toda a memória disponível na SGA. (Fogel 2007)
Habilitando o ASMM
Para habilitar o ASMM no Oracle podemos simplesmente definir o parâmetro SGA_TARGET com o
valor zero e ele vai começar a gerenciar a SGA sozinho com toda a quantidade de memória que
estiver disponível. Caso coloquemos algum outro valor diferente de zero nesse parâmetro o Oracle vai
destinar essa quantidade de memória para a SGA.
O comando que pode ser usado na linha de comando do Oracle para alterar os parâmetros são as
instruções a seguir:
ALTER SYSTEM SET SGA_TARGET=valor [SCOPE={SPFILE|MEMORY|BOTH}].
8. Comparação de Desempenho
Esse trabalho oferece comparações entre ambientes com menor carga de usuários e maior carga de
usuários configurado para gerenciamento manual e automático de memória. Para os testes com a SGA
configurada de forma manual são destinados um gigabyte de memória.
Conforme os testes são mostrados, as tabelas e gráficos ajudam a entender melhor os
resultados e em quais situações o gerenciamento automático de memória é mais indicado.
Testes com menor carga
Para os testes com menor carga de usuários foi utilizada uma quantidade máxima de quarenta usuários
acessando e manipulando o banco de dados simultaneamente. Essa é uma quantidade grande para
algumas empresas e pequena para outras, mas é o parâmetro passado ao software de simulação de
ambiente.
Veja nas tabelas e gráficos os resultados obtidos nos testes feitos com o ASMM desabilitado.
Tabela 1. Resultados dos testes com menor carga e ASMM desabilitado (Fonte: simulação
no software de Benchmark Factory)
Resultados
Transações por segundo
1332.697
Tempo médio de resposta (em milissegundos)
0.010
Tempo médio das transações (em milissegundos)
0.030
Número de execuções
218.995
Número de Linhas
219.323
Erros
0
Página
116
Descrição
Faculdade de Tecnologia de Bauru
volume 01 – número 01 – julho/2013
Caderno de Estudos Tecnológicos
Imagem 2. Transações por segundo e tempo de resposta em milissegundos (Fonte:
simulação no software de Benchmark Factory).
Imagem 3. Transações por segundo, número de usuários e a média de tempo de resposta
em milissegundos (Fonte: simulação no software de Benchmark Factory).
Descrição
Resultados
Transações por segundo
778.439
Faculdade de Tecnologia de Bauru
volume 01 – número 01 – julho/2013
Página
Tabela 2. Resultados dos testes com menor carga e ASMM habilitado (Fonte: simulação no
software de Benchmark Factory)
117
Na tabela 2 vejamos os resultados obtidos com o ASMM habilitado.
Caderno de Estudos Tecnológicos
Tempo médio de resposta (em milissegundos)
0.032
Tempo médio das transações (em milissegundos)
0.051
Número de execuções
136.707
Número de Linhas
136.752
Erros
0
Faculdade de Tecnologia de Bauru
volume 01 – número 01 – julho/2013
Página
Imagem 5. Transações por segundo, número de usuários e a média de tempo de resposta
em milissegundos (Fonte: simulação no software de Benchmark Factory).
118
Imagem 4. Transações por segundo e tempo de resposta em milissegundos (Fonte:
simulação no software de Benchmark Factory).
Caderno de Estudos Tecnológicos
Analisando esses resultados e gráficos podemos ver que a SGA manual executa mais
transações por segundo além de um tempo médio de resposta e transações menores. Percebe-se que a
quantidade de linhas executadas é maior no gerenciamento manual e mesmo assim temos um tempo
de resposta menor.
Pode-se pensar que o ASMM não é útil então, mas um dos objetivos desse trabalho é mostrar
que a utilização do ASMM se torna mais necessária conforme o ambiente do banco de dados cresce.
Em ambientes mais complexos a diferença de desempenho aumenta e pende para o lado do
gerenciamento automático e é isso que veremos no próximo tópico desse artigo.
Testes com maior carga
Para os testes com maior carga de usuários utilizamos uma quantidade máxima de cem usuários
acessando e manipulando o banco de dados simultaneamente. Essa é uma quantidade grande e simula
bem o ambiente de empresas de maior porte. Lembrando que mesmo empresas que possuem mais do
que essa quantidade de usuários nem sempre todos estão acessando simultaneamente.
Vejamos a seguir nas tabelas e gráficos os resultados obtidos nos testes feitos com o ASMM
desabilitado.
Tabela 3. Resultados dos testes com maior carga e o ASMM desabilitado (Fonte: simulação
no software de Benchmark Factory)
531.362
0.138
Tempo médio das transações (em milissegundos)
0.190
Número de execuções
81.539
Número de Linhas
81.598
Erros
0
Imagem 6. Transações por segundo e tempo de resposta em milissegundos (Fonte:
simulação no software de Benchmark Factory).
Faculdade de Tecnologia de Bauru
volume 01 – número 01 – julho/2013
Página
119
Transações por segundo
Tempo médio de resposta (em milissegundos)
Caderno de Estudos Tecnológicos
Imagem 7. Transações por segundo, número de usuários e a média de tempo de resposta
em milissegundos (Fonte: simulação no software de Benchmark Factory).
Vejamos os resultados obtidos com o ASMM habilitado.
Tabela 4. Resultados dos testes com maior carga e o ASMM habilitado (Fonte: simulação no
software de Benchmark Factory)
Resultados
Transações por segundo
745.300
Tempo médio de resposta (em milissegundos)
0.094
Tempo médio das transações (em milissegundos)
0.171
Número de execuções
77.239
Número de Linhas
77.276
Erros
0
Página
120
Descrição
Faculdade de Tecnologia de Bauru
volume 01 – número 01 – julho/2013
Caderno de Estudos Tecnológicos
Imagem 8. Transações por segundo e tempo de resposta em milissegundos (Fonte:
simulação no software de Benchmark Factory).
Faculdade de Tecnologia de Bauru
volume 01 – número 01 – julho/2013
Página
Analisando os resultados com maior carga podemos ver que o ASMM habilitado resultou num
melhor desempenho. Tivemos melhoras nas transações por segundo além de um tempo médio de
resposta e transações menores também. O fato da quantidade de linhas executadas serem maior no
gerenciamento manual não quer dizer que executou menos linhas simplesmente, mas sim que o
gerenciamento manual não gerenciou corretamente as instruções no tempo do teste (que é padrão
para todos os casos, cerca de quatro minutos).
121
Imagem 9. Transações por segundo, número de usuários e a média de tempo de resposta
em milissegundos (Fonte: simulação no software de Benchmark Factory).
Caderno de Estudos Tecnológicos
Vemos aqui a utilidade e versatilidade do ASMM e sendo mais ambicioso ainda podemos
vislumbrar casos com ambientes ainda mais críticos onde temos mais memória disponível para a SGA
e mais carga de usuários. Em ambientes assim teremos resultados ainda mais visíveis e satisfatórios.
Comparação entre os ambientes de execução
Apesar de ter sido mostrado os resultados dos testes com menor carga e maior carga nos tópicos
anteriores aqui iremos visualizar uma tabela contendo todos esses resultados juntos e agrupados. Com
isso conseguimos comparar mais facilmente os dados.
Tabela 5. Dados comparativos entre os testes efetuados com mais e menos carga e ASMM
habilitado e desabilitado (Fonte: simulação no software de Benchmark Factory)
SGA
1 GB
AUTO
Total de
Usuários
Transações
(Por
Segundo)
Resposta
(Tempo
Médio)
Transações
40
1.332.679
0.010 ms
100
531.362
40
100
Total de
Execuções
Total de
Linhas
0.030 ms
218.995
219.323
0.138 ms
0.190 ms
81.539
81.598
778.439
0.032 ms
0.051 ms
136.707
136.752
745.300
0.094 ms
0.171 ms
77.239
77.276
(Tempo
Médio)
Como dito anteriormente fica mais evidente na tabela acima que em ambientes com menor
carga a SGA de forma manual executa melhor os comandos enquanto que em ambientes com o
ASMM habilitado o Oracle consegue controlar e gerenciar melhor a memória disponível no servidor.
Apesar de tudo isso a realidade das empresas hoje é que a memória disponível nos seus
servidores de banco de dados seja grande e com isso o ASMM seja totalmente indicado.
Conclusão
Com esse trabalho conseguimos mostrar como utilizar o gerenciamento automático de memória no
SGBD Oracle 11g Release 2 e como ele pode tornar-se um tópico importante na avaliação e ações de
um Administrador de Banco de Dados com o objetivo de ganhar performance no acesso ao Banco de
Dados. Através do ASMM deixamos todo o gerenciamento da memória para o Oracle e nos
preocuparmos com outras tarefas como a segurança do nosso ambiente.
Apesar do gerenciamento automático não ser indicado para ambientes com pouca carga, hoje
em dia nas empresas temos um cenário onde cada vez mais temos processamento nos nossos
servidores.
Página
122
Em um ambiente empresarial com muitos usuários e uma quantidade grande de memória
disponível a utilização do ASMM é altamente recomendável, torna-se indispensável dependendo da
necessidade de desempenho que a empresa tenha, como foi dito anteriormente a informação rápida e
precisa é um ponto chave para os ganhos nos negócios.
Faculdade de Tecnologia de Bauru
volume 01 – número 01 – julho/2013
Caderno de Estudos Tecnológicos
9. Referências
Bryla, B. e Loney, K. (2008), Oracle Database 11g DBA Handbook, Oracle Press.
Collelo, D.; Keh, A. e Thammaiah, R. (julho/2007), Arquitetura do Oracle Database 11g no Windows,
p3.
Date, C. J. (2004), Introdução a Sistemas de Banco de Dados, Campus, 8ª edição.
Delgado, H. S. (2011), O Conceito de Tuning Aplicado em Instruções SQL Dentro de um Banco de
Dados Oracle, Guarulhos, São Paulo.
Elsmari, R., Navathe, S. B. (2011), Sistemas de banco de dados, Pearson, 6ª edição.
Fogel S. (2007), Oracle Database Administrator’s Guide 11g Release 1 (11.1), Oracle.
Página
123
Ikematu, R. S., Realizando Tuning na Base de Aplicações. Disponível em
http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1592. Último acesso em
25/05/2013.
Faculdade de Tecnologia de Bauru
volume 01 – número 01 – julho/2013