Você está na página 1de 81

CENTRO UNIVERSITÁRIO FEEVALE

MARINES FONTANA

AVALIAÇÃO DE DESEMPENHO DE

SISTEMAS GERENCIADORES DE BANCO DE DADOS

Novo Hamburgo, novembro de 2006.


MARINES FONTANA

AVALIAÇÃO DE DESEMPENHO DE

SISTEMAS GERENCIADORES DE BANCO DE DADOS

Centro Universitário Feevale


Instituto de Ciências Exatas e Tecnológicas
Curso de Ciência da Computação
Trabalho de Conclusão de Curso

Professor orientador: Ms. Alexandre Zamberlam

Novo Hamburgo, novembro de 2006.


RESUMO

A importância da informação para a tomada de decisões nas organizações e o volume


cada vez maior de dados, uma vez que a busca pela informação se torna mais complexa e
demorada, têm exigido preocupação com a velocidade dos bancos de dados. Com base nesse
fato, o presente trabalho trata de uma avaliação de recursos entre os Sistemas Gerenciadores
de Banco de Dados Oracle, MySQL e SQLServer, testando cada um com a linguagem SQL
(Structured Query Language) padrão ou recursos próprios de cada sistema, usando como
plataforma um sistema operacional comum a todos. Foram simuladas e avaliadas situações a
fim de descrever a melhor e a pior situação, freqüência em que ocorrem e em quais os casos.
Desta forma, o principal objetivo da pesquisa foi identificar as características dos SGBD’s que
influenciam no desempenho de acessos realizados por aplicações clientes, apresentando testes
que sejam capazes de detectar pontos fortes e fracos de cada sistema, bem como apontar o que
isso representa em ganho de desempenho e em qual cenário existe o maior ganho.

Palavras-chave: Desempenho, SGBD, SQL, Oracle, MySQL, SQL Server.


ABSTRACT

Title: Database Management Systems Performance Evaluation

The importance of information to take decisions in the organizations and the high
volume of data becoming larger demanding concern with the performance of the databases,
what becomes the information search more complex and slower. Based on this fact, this work
shows an evaluation of resources about the Database Management Systems Oracle, MySQL
and SQL Server, testing each one with the pattern SQL language or own resources of each
system, using as platform operating system common for all. Situations were simulated and
evaluated to describe the best and the worst situations, their frequency and when they happen.
Thus, the main goal of this research was to identify the characteristics of SGBD’s that
influence in the performance of accesses accomplished by clients applications, presenting
capable detailed tests to detect strong and weak points of each system, included to show what
this represents in acquiring performance and in which scenario there is the best gain.

Keywords: Database, Performance, DBMS e SQL.


LISTA DE FIGURAS

Figura 1: Projeto de Banco de Dados (HEUSER, 1999)..........................................................16

Figura 2: Conceitos básicos de Bancos de Dados e SGBD’s (MELLO, 2006)........................16

Figura 3: Estrutura geral de um SGBD (FERREIRA, 2006)....................................................17

Figura 4: Tabelas temporarias por seção...................................................................................27

Figura 5: Sintaxe de criação de uma view................................................................................31

Figura 6: Sintaxe de criação de uma tabela reporária em SQL Server......................................37

Figura 7: Sintaxe Básica de Stored Procedure..........................................................................38

Figura 8: Sintaxe de uma trigger em SQL Server.....................................................................39

Figura 9: Sintaxe de View no SQL Server................................................................................40

Figura 10: Sintaxe de criação de table temporária no MySQL.................................................46

Figura 11: Estrutura do Ambiente de Testes.............................................................................57

Figura 12: Modelo Relacional da base de testes.......................................................................59

Figura 13: Select 1....................................................................................................................64

Figura 14: Select 2....................................................................................................................65

Figura 15: Select 3....................................................................................................................66

Figura 16: Plano de execução Select 3.....................................................................................66

Figura 17: Select 4....................................................................................................................67

Figura 18: Select 5....................................................................................................................68

Figura 19: Select 6....................................................................................................................69


LISTA DE TABELAS

Tabela 1: Configuração das Máquinas......................................................................................57

Tabela 2: Base de dados Media.................................................................................................59

Tabela 3: Chaves Primárias e Chaves Únicas...........................................................................60

Tabela 4: Índices.......................................................................................................................60

Tabela 5: Resultado dos Testes da Select 1...............................................................................64

Tabela 6: Resultado dos Testes da Select .................................................................................65

Tabela 7: Resultado dos Testes da Select 3...............................................................................66

Tabela 8: Resultado dos Testes da Select 4...............................................................................67

Tabela 9: Resultado dos Testes da Select 5...............................................................................68

Tabela 10: Resultado dos Testes da Select 6.............................................................................69

Tabela 11: Teste de Deletes.......................................................................................................70

Tabela 12: Resultados dos Testes de Deletes............................................................................72

Tabela 13: Teste de Updates......................................................................................................73

Tabela 14: Resultados dos Testes de Updates..........................................................................74

Tabela 15: Resultados dos Testes de Inserts.............................................................................75


LISTA DE ABREVIATURAS

ADO ActiveX Data Object

ANSI American National Standards Institute

ARO Army Research Office

BDE Borland Database Engine

CIA Central Intelligence Agency

CS Classic Server

DARPA Defense Advanced Research Projects Agency

DBA DataBase Administrator

DBMS DataBase Management Systems

DDL Data Definition Language

DML Data Manipulation Language

ER Entidade Relacionamento

ERP Enterprise Resource Planning

HD Hard Disk

JDBC Java DataBase Connectivity

NSF National Science Foundation

ODBC Open DataBase Connectivity

PC Personal Computer

RAM Random Access Memory

RSI Relational Software Inc.


SGBDR Sistema Gerenciador de Banco de Dados Relacional

SDL Software Development Laboratories

SQL Structured Query Language

SS Super Server

TI Tecnologia da Informação

XML EXtensible Markup Language


SUMÁRIO

Resumo.......................................................................................................................................3

Abstract.......................................................................................................................................4

LISTA DE FIGURAS.................................................................................................................5

Lista de Tabelas...........................................................................................................................6

Lista de ABREVIATURAS.........................................................................................................7

Sumário.......................................................................................................................................9

Introdução.................................................................................................................................13

1bancos de dados......................................................................................................................16

1.1 Modelos de dados......................................................................................................17

1.1.1 Modelo Relacional...................................................................................17

1.1.2 Modelo Orientado a Objeto......................................................................18

1.2 Aplicações dos Bancos de Dados..............................................................................19

1.3 Otimização dos Bancos de dados..............................................................................20

2ORACLE.................................................................................................................................21

1.4 Histórico....................................................................................................................21

1.5 Características do Oracle...........................................................................................23

1.6 Recursos para aumento de desempenho....................................................................26

1.6.1 Tabelas temporárias..................................................................................26

1.6.2 Stored Procedures.....................................................................................28

1.6.3 Triggers.....................................................................................................29
1.6.4 Views........................................................................................................30

1.6.5 Índices......................................................................................................32

1.7 Segurança...................................................................................................................32

3 SQL Server.............................................................................................................................34

1.8 Histórico....................................................................................................................34

1.9 Características do SQL Server...................................................................................35

1.10 Recursos de aumento de desempenho.....................................................................36

1.10.1 Tabelas temporárias................................................................................36

1.10.2 Stored Procedures...................................................................................37

1.10.3 Triggers...................................................................................................39

1.10.4 Views......................................................................................................40

1.10.5 Índices....................................................................................................41

1.11 Segurança.................................................................................................................42

4Mysql......................................................................................................................................44

1.12 Histórico..................................................................................................................44

1.13 Características do MySQL.......................................................................................44

1.14 Recursos de aumento de desempenho.....................................................................46

1.14.1 Tabelas temporárias................................................................................46

1.14.2 Stored Procedure....................................................................................46

1.14.3 Triggers...................................................................................................47

1.14.4 Views......................................................................................................47

1.14.5 Índices....................................................................................................47

1.15 Segurança.................................................................................................................48

5Critérios de Avaliação.............................................................................................................50

1.1 Consultas...................................................................................................................50

1.1.1 Join...........................................................................................................50

1.1.2 Ordenação das operações na cláusula WHERE.......................................51


1.1.3 Order By...................................................................................................51

1.1.4 Comandos de soma...................................................................................52

1.1.5 Subselects.................................................................................................52

1.1.6 Union........................................................................................................52

1.1.7 Distinct.....................................................................................................53

1.1.8 Outros comandos......................................................................................53

1.2 Otimização.................................................................................................................53

1.3 Controle de concorrência...........................................................................................54

1.4 INSERT, UPDATE e DELETE..................................................................................54

1.5 Trigger’s.....................................................................................................................54

1.6 Views.........................................................................................................................55

1.7 Tamanho do Banco de Dados....................................................................................55

6Ambiente de Testes.................................................................................................................56

1.8 Arquitetura do ambiente de testes..............................................................................56

1.9 Instalação dos SGBDRs.............................................................................................58

1.9.1 MySQL.....................................................................................................58

1.9.2 SQL Server...............................................................................................58

1.9.3 Oracle.......................................................................................................58

1.10 Criação das bases de dados......................................................................................58

7Execução dos Testes................................................................................................................62

1.11 Os Testes..................................................................................................................62

1.12 Selects .....................................................................................................................63

1.12.1 Select 1...................................................................................................63

1.12.2 Select 2...................................................................................................64

1.12.3 Select 3...................................................................................................65

1.12.4 Select 4...................................................................................................66

1.12.5 Select 5...................................................................................................67


1.12.6 Select 6...................................................................................................68

1.12.7 Selects – Resumo dos Resultados..........................................................69

1.13 Deletes.....................................................................................................................69

1.13.1 Deletes - Resultados...............................................................................71

1.14 Updates....................................................................................................................72

1.14.1 Updates - Resultados..............................................................................74

1.15 Inserts.......................................................................................................................75

1.15.1 Inserts - Resultados................................................................................75

1.16 Resultados Finais.....................................................................................................75

Conclusão..................................................................................................................................77

Referências Bibliográficas........................................................................................................79
INTRODUÇÃO

A importância da informação para a tomada de decisões nas organizações e o volume


cada vez maior de dados, uma vez que a busca pela informação se torna mais complexa e
demorada, têm exigido preocupação com a velocidade dos bancos de dados.

Os Bancos de Dados (BD) são uma coleção de dados que mantém relações entre si,
sendo controlados por um sistema que permite guardar, modificar e recuperar dados,
conhecido como Sistema Gerenciador de Banco de Dados (SGBD) (DATE, 1998). Os
SGBD’s podem ser definidos como uma camada entre os dados e as aplicações, responsável
pela execução de tarefas de manipulação, gerenciamento, concorrência e recuperação de
falhas, entre outras.

Problemas de desempenho com esses sistemas, que têm sido a solução escolhida para
armazenar e gerenciar a base de dados das organizações, surgem na medida em que o volume
de informações cresce. Gulutzan e Pelzer (2002) afirmam que quando as informações
recuperadas tardiamente ou equivocadas geram prejuízos, tem-se idéia de sua importância.

Tendo em vista que um dos principais requisitos desejados em SGBD’s é uma boa
performance, busca-se a obtenção de melhor desempenho, tanto na utilização do hardware
quanto na organização dos dados e das consultas feitas aos BD’s. Sabe-se que o desempenho
dos comandos pode ser afetado por vários motivos e que existem possibilidades de tratamento
(GULUTZAN, PELZER/2002).

O interesse da pesquisa advém da grande dificuldade encontrada por gerentes de


Tecnologia de Informação (TI) na escolha do produto adequado para as necessidades da
empresa, já que as pesquisas comparativas existentes são divulgadas pelos próprios
fabricantes dos SGBD’s, sendo esta uma situação que propicia resultados parciais.
14

Diante desse contexto, a presente pesquisa foi proposta com intuito de dar
continuidade ao trabalho apresentado por Edson Luis Pletsch (2005). Uma vez que esse
estudo fez uso dos recursos do Firebird, PostgreSQL e Oracle. Portanto, torna-se pertinente
uma pesquisa na qual sejam submetidos outros bancos a testes similares.

Percebeu-se então, a necessidade de elaborar um trabalho de pesquisa visando avaliar


recursos do Oracle, MySQL e SQL Server, testando cada um com acesso nativo1, em uma base
média2, com a linguagem SQL (Structured Query Language) ou recursos próprios de cada
sistema, usando como plataforma o Sistema Operacional Windows. Sendo assim, foram
simuladas situações em que foi possível avaliar o desempenho dos SGBD’s ecolhidos para
aplicação da pesquisa.

Neste processo, foi avaliado o otimizador de cada SGBD, que é a parte responsável
pela escolha do método utilizado em cada busca realizada na base de dados. Levando em
consideração o fato de que o otimizador trata cada instrução SQL de forma diferente, é
aceitável que o mesmo comando não traga resultados padronizados, quando se trata de
comparações entre diversos SGBD’s. Como cada implementação trata suas variáveis de forma
a atender suas necessidades.

Para a avaliação foram usados os comandos de manipulação select, update, insert e


delete, respeitando as funções de implementação dos mesmos, utilizando índices quando
necessário. Neste contexto, foi utilizada uma base de dados compatível com a necessidade dos
testes executados.

Desta forma, o principal objetivo da pesquisa é identificar as características dos


SGBD’s que influenciam no desempenho de acessos realizados por aplicações clientes,
apresentando testes que sejam capazes de detectar pontos fortes e fracos de cada sistema, de
apontar o que isso representa em ganho de desempenho e em qual cenário existe o maior
ganho.

Como objetivos específicos, destacam-se:

1. Apresentar algumas características dos Bancos de Dados a serem utilizados na


pesquisa, Oracle, MySQL e SQL Server;
2. Utilizar os critérios de avaliação definidos na pesquisa de Pletsch (2005) que
serve como base para este trabalho;
1
Acesso nativo é uma especificação de interface para acesso de dados, elaborada por grupos de padronização,
que provê funções para conectar e desconectar fontes de dados, preparar e executar comandos, processar erros e
processar transações (UNIOESTE/ACESSO NATIVO, 2006).
2
Onde o número de registros das principais tabelas é igual ou superior a 100.000 registros.
15

3. Avaliar SGBD nos critérios apresentados;


4. Comparar recursos de cada SGBD;
5. Apresentar as melhores aplicações para cada SGBD, baseado em seu
desempenho;
6. Apresentar os resultados comparativos.

Finalmente, para melhor compreensão do proposto, este trabalho está organizado em


sete capítulos, sendo que o capítulo 1 aborda o embasamento teórico de Banco de Dados, os
modelos existentes, aplicação e a idéia de otimização. No capítulo 2, é apresentado o SGBD
Oracle, onde é detalhado um histórico, as principais características do BD, as formas de
armazenamento, assim como de que forma é feita a segurança. O terceiro capítulo apresenta o
SGBD SQL Server, histórico, as características, formas de armazenamento e breve descrição
de como o sistema faz a segurança dos dados. O capítulo 4 aborda o SGBD MySQL,
apresentando histórico, as suas características principais, assim como as formas de
armazenamento e segurança. O capítulo 5 trata dos critérios para avaliação. O capítulo 6
apresenta o ambiente de testes. No capítulo 7 são descritos os testes realizados e, por fim, as
conclusões deste Trabalho de Conclusão de Curso de Graduação.
16

1 BANCOS DE DADOS

Segundo Navathe (2005) os Bancos de Dados e os SGBD’s tornaram-se


componentes essenciais no cotidiano da sociedade moderna, pois a execução de muitas
atividades gera interação com esses BDs. De forma geral, entende-se que os bancos de dados
são conjuntos de dados com estrutura regular que organizam informações, agrupando o que é
utilizado para um mesmo fim (ibidem). Conforme pode ser observado na Figura 1.

Figura 1: Projeto de Banco de Dados (HEUSER, 1999).

O SGBD é o software que manipula todos os acessos ao banco de dados, que tem
como objetivo principal tirar da aplicação cliente a responsabilidade de gerenciar o acesso,
manipulação e organização dos dados, disponibilizando uma interface para que os usuários
possam incluir, excluir, alterar ou consultar os dados. (DATE, 1998).

Figura 2: Conceitos básicos de Bancos de Dados e SGBD’s (MELLO, 2006).


17

Logo, pode-se afirmar que o termo banco de dados é aplicado aos dados enquanto o
termo SGBD é aplicado ao software com capacidade de manipular bancos de dados, através
da estrutura ilustrada na figura 3. Sendo assim, este capítulo tem por objetivo apresentar os
principais modelos de dados, a aplicação e otimização desses bancos de dados.

Figura 3: Estrutura geral de um SGBD (FERREIRA, 2006).

1.1 Modelos de dados

O modelo de dados trata de um conjunto de conceitos que podem ser usados para
descrever a estrutura de um banco de dados. Os bancos de dados são classificados de acordo
com a maneira que seus dados são vistos pelos usuários, ou seja, seu modelo de dados.
(KORTH/ SILBERSCHATZ, 1994).

Atualmente, os modelos mais citados são o Modelo Relacional e o Modelo Orientado


a Objeto. Com base nesse fato, as próximas seções abordam estes conceitos.

1.1.1 Modelo Relacional

O Modelo Relacional é mencionado em muitos trechos da pesquisa e diz respeito à


teoria criada por Edgar Codd em 1970. A Teoria Relacional tem por finalidade representar os
dados como uma coleção de relações, é definida por um conjunto de operações lógicas
(álgebra e cálculo relacional) que são a base da linguagem SQL. Os bancos de dados
18

relacionais são compostos de tabelas de dados que, por sua vez, são formadas por colunas que
correspondem a um fragmento diferente de dados e por linhas que correspondem a registros
individuais. A teoria relacional tem como ponto forte a possibilidade de definição de regras de
restrição de integridade. Estas regras definem os conjuntos de estados e mudanças de estado
consistentes do banco de dados, determinando os valores que podem e os que não podem ser
armazenados (HTMLSTAFF, 2006).

Conforme Korth e Silberschatz (1994), o modelo relacional representa dados e


relacionamentos entre eles por um conjunto de tabelas, cada uma tendo um número de colunas
com nomes únicos.

As primeiras implementações comerciais do modelo relacional foram


disponibilizadas no início da década de 80, com o SGBD Oracle e o sistema SQL/DS do
sistema operacional MVS, da IBM. Desde então, o modelo tem sido implementado em um
grande número de sistemas comerciais. Os SGBD’s mais conhecidos atualmente são o DB2 e
o Informix Dynamic Server (da IBM), o Oracle, e o SQL Server (da Microsoft) (NAVATHE,
2005).

1.1.2 Modelo Orientado a Objeto

Segundo Navathe (2005) o Modelo Orientado a Objetos foi proposto para atender as
necessidades das aplicações mais complexas, oferecendo flexibilidade para lidar com
requisitos sem que seja limitada pelos tipos de dados e linguagens de consulta disponíveis em
sistemas de bancos de dados tradicionais.

A criação do banco de dados orientado a objeto justifica-se também pelo aumento do


uso de linguagens de programação orientadas a objetos para o desenvolvimento de aplicações
de software como C++, SMALLTALK ou Java (KORTH/ SILBERSCHATZ, 1994).

O Modelo Orientado a Objeto é baseado no código e em dados encapsulados em uma


unidade, chamada objeto. A interface entre um objeto e o resto do sistema é definida como um
conjunto de mensagens. Os objetos que contêm os mesmos tipos de valores e os mesmo
métodos são agrupados em classes. Uma classe pode ser vista como uma definição de tipo
para objetos. A combinação de dados e código é uma definição de tipo similar ao conceito de
linguagem de programação de tipos de abstratos de dados. O único modo pelo qual um objeto
pode acessar o dado de um outro objeto é invocando o método do outro objeto, ou seja,
mandando uma mensagem ao objeto. Assim, a interface de chamada dos métodos de um
objeto define sua parte externa visível. A parte interna do objeto, as variáveis instância e o
19

código método, não são visíveis externamente, resultando em dois níveis de abstração de
dados. No modelo orientado a objetos, a distinção entre objetos individuais é mantida no nível
físico através da indicação de objetos identificadores distintos (KORTH/ SILBERSCHATZ,
1994).

A presente pesquisa se propõe a analisar o desempenho de SGBD’s relacionais,


portanto, a abordagem da teoria orientada a objetos fica restrita a esta seção. Para maiores
informações, consulte (NAVATHE, 2005), ou (KORTH/SILBERSCHATZ, 1994), ou ainda
(DATE, 1998).

1.2 Aplicações dos Bancos de Dados

As primeiras aplicações utilizando banco de dados mantinham os registros das


grandes organizações, como as corporações, universidades, hospitais e bancos. Nessas
aplicações existia um grande número de registros de estruturas semelhantes, mas também
havia diversos tipos de registros e diversos inter-relacionamentos entre eles. Esse tipo de
armazenamento dava margem a problemas como a mistura de relacionamentos conceituais,
redundância de dados, o armazenamento físico e a localização de registros no disco.

Apesar de prover acessos muito eficientes, destinados a consultas originais e


transações, para os quais o banco de dados foi projetado para executar, não oferecia
flexibilidade suficiente e eficiente para os acessos a registros quando novas consultas e
transações fossem necessárias (NAVATHE, 2005).

Os bancos de dados relacionais foram originalmente projetados para separar o


armazenamento físico dos dados da sua representação conceitual e prover uma fundamentação
matemática para os bancos de dados, introduziu linguagens de consultas de alto nível. Os
primeiros sistemas relacionais experimentais desenvolveram-se no fim dos anos 70
(NAVATHE, 2005). Com o desenvolvimento de novas técnicas de armazenamento e
indexação, e com o processamento aprimorado de consultas e otimização, seu desempenho
melhorou.

Assim, os bancos de dados relacionais tornaram-se dominantes para aplicações


tradicionais de bancos de dados. Os bancos de dados relacionais hoje existem na maioria dos
computadores, desde aqueles de uso pessoal até os grandes servidores.

Conforme Navathe (ibidem), o aparecimento de linguagens de programação


orientadas a objeto, nos anos 80, e a necessidade de armazenar e compartilhar os objetos
20

complexos estruturados conduziu o desenvolvimento dos bancos de dados orientados a objeto.


No início, os bancos de dados orientados a objetos foram considerados concorrentes diretos
dos bancos de dados relacionais, pois possuíam estruturas de dados mais gerais. Entretanto, a
complexidade do modelo e a falta de um padrão inicial contribuíram para seu uso limitado.
Hoje são usados principalmente em aplicações especializadas, como projetos de engenharia,
publicidade multimídia e sistemas para indústria.

1.3 Otimização dos Bancos de dados

Segundo Date (1998), a otimização de consultas é um desafio para os bancos de


dados relacionais, pois é necessária em ambientes computacionais de grande porte, para que o
sistema tenha um desempenho aceitável. A vantagem da otimização não se restringe ao fato
dos usuários se preocuparem em como redigir as solicitações de modo a tirar o melhor
desempenho do sistema, porque o otimizador pode fazer tão bem quanto um programador
humano, pois pode ter informações disponíveis em relação aos valores dos dados correntes e
também é capaz de avaliar uma gama muito grande de alternativas diferentes.

Existe um grande número de estratégias possíveis para processar uma consulta,


especialmente se a consulta for complexa. Logo, o objetivo geral do otimizador é escolher
uma estratégia para avaliar uma determinada expressão relacional.

Dada uma consulta, existe uma variedade de métodos para computar a resposta. O
sistema se responsabiliza em transformar a consulta como foi introduzida pelo usuário em
uma consulta equivalente que pode ser computada com mais eficiência. Esta otimização ou
aperfeiçoamento da estratégia para processar uma consulta é chamado de otimização de
consulta (KORTH/ SILBERSCHATZ, 1994).

Tendo em visa o fato de que a pesquisa se propõe à análise de desempenho dos


SGDB’s, avalia-se, também ao longo da pesquisa, a melhor escolha do otimizador de
consultas de cada um dos SGBD’s envolvidos.

Ao longo deste primeiro capítulo foram abordados os assuntos referentes a Bancos


de Dados. Inicialmente, relataram-se os modelos de dados, sendo ressaltadas as principais
características dos modelos Relacionais e Orientado a Objetos. Depois disso, foram abordadas
as aplicações dos bancos de dados. Levando-se em consideração o fato de que a pesquisa tem
por objetivo analisar o desempenho do SGBD, por fim, abordou-se a otimização dos bancos
de dados.
21

2 ORACLE

A escolha do SGBD Oracle para execução da pesquisa fundamenta-se no fato de ser


largamente utilizado, também por estar no mercado há um tempo considerável e ter boas
referências quanto ao seu desempenho. Alia-se a isso o fato de ter sido explorado na pesquisa
anterior (PLETSCH, 2005), como já mencionado, e ter resultados para que sejam avaliados
com os resultados da atual pesquisa.

Oracle é um SGBD que surgiu no final dos anos 70. Lançado por Larry Ellison e os
co-fundadores Bob Miner e Ed Oates, no intuito de oferecer ao mercado um modelo funcional
de banco de dados, baseado em um protótipo com capacidade de armazenar além de objetos
físicos3, também combinações entre eles, de memória e de processo. Até então, nenhuma
outra empresa havia se empenhado em comercializar esta tecnologia (ORACLE, 2002).

Neste capítulo são descritos um breve histórico da empresa, as principais


características da ferramenta, os recursos de aumento de desempenho e aspectos de segurança.

1.4 Histórico

A empresa Oracle foi fundada em 1977 e tem escritórios em mais de 145 países. Em
2004 empregava mais de 43000 profissionais no mundo inteiro. O seu principal produto é o
Sistema de Gestão de Banco de Dados Relacional Oracle.

A seguir, alguns fatos importantes relacionados com a Oracle.

1970- Edgar Cood publica sua teoria da modelagem de dados relacional;

1977- Software Development Laboratories (SDL), formada por Larry Ellison, Bob
Miner Ed Oates e Bruce Scott, é fundada;

1978- A SDL muda seu nome para Relational Software Inc. (RSI);
3
Os objetos físicos relacionam-se com a organização dos dados no disco, diferentemente dos objetos lógicos que
são constituídos por: banco de dados, tabelas, visões, colunas, linhas, etc (MACORATTI, 2006).
22

1979- A RSI lança sua primeira versão comercial que foi vendida à Base da Força
Aérea em Wright-Petterson. Esse é o primeiro SGBD comercial do mercado;

1981- A primeira ferramenta, Interactive Application Facility (IAF), ferramenta


Forms do Oracle, é criada;

1982- A RSI muda seu nome para Oracle Systems Corporation (OCS) e depois
simplifica o nome para Oracle Corporation.

1983- A versão 3, escrita em linguagem C (que torna portável, capaz de ser


executado em mainframes, minicomputadores e PC’s) é lançada. É o primeiro SGBD de 32
bits;

1984- Versão 4 é lançada. Torna-se o primeiro banco de dados com coerência de


leitura. Oracle portado para o PC (Personal Computer);

1985- Versões 5 e 5.1 são lançadas, Oracle torna-se o primeiro banco de dados de
servidor paralelo no VMS/VAX 4(Virtual Machine Systems/ Virtual Address eXtension);

1986- O Oracle Client/Server é introduzido; tornando-se assim o primeiro banco de


dados cliente/servidor. Oracle 5.1 é lançado;

1987- Oracle é considerada a maior empresa de BD. Iniciando o grupo Oracle


Applications. Passa a ser o primeiro banco de dados SMP5 (Symmetric Multi-Processing -
Multiprocessamento Simétrico) introduzido no mercado;

1988- Lançado o Oracle V6. Primeiro banco de dados que oferece bloqueio em nível
de registro, ou seja, controle de acesso simultâneo aos dados para uma linha específica
quando ela é atualizada, o bloqueio se mantém até a transação se efetivar ou desfazer as
alterações. A versão Oracle V6 tem o primeiro backup de banco de dados rodando. Introdução
de acesso via linguagem PL/SQL;

• 1992, lançado o Oracle V7;

• No ano de 1993 foram introduzidas ferramentas com interface gráfica de


desenvolvimento cliente/servidor do banco de dados Oracle. Oracle Applications
passou do modo de caracter para cliente/servidor;
4
VMS – Virtual Machine Systems, VAX – Virtual Address eXtension, os sistemas VMS/VAX estruturam os
dados de uma maneira totalmente incompatível com qualquer tipo de sistema Windows ou Unix. VAX são mini-
computadores criados em 1975 que rodam alguns terabytes de memória cujo sistema utilizado era VMS.
(WEBMYTHOLOGY/VAX, 2006)
5
Tecnologia que permite a um determinado sistema operacional distribuir tarefas, entre dois ou mais
processadores. Esse método, mais especificamente, permite que vários processadores compartilhem o
processamento de instruções requisitadas pelo sistema (WIKIPEDIA/SMP, 2006).
23

• Em 1995, Oracle oferece ao mercado o primeiro banco de dados de 64 bits;

• 1996, lançado o Oracle 7.3;

• No ano de 1997 o Oracle8 é apresentado; O Oracle Application Server é


apresentado, assim como aplicações para Web. Oracle é o primeiro banco de
dados para Web. Ferramentas Oracle BI (Business Intelligence), como
Discoverer, são introduzidas para warehousing. Primeira versão do banco de
dados Oracle que oferece ferramentas com suporte nativo para Java;

• Em 1998 o Oracle8 é o primeiro grande SGBD portado para Linux;

• Em 1999 é lançado o Oracle8i. Nesta versão há integração Java/XML nas


ferramentas de desenvolvimento. O BD Oracle8i é o primeiro banco de dados
com suporte nativo para XML;

• No ano 2000 é lançado o Oracle9i Applicarion Server. Neste mesmo ano é


lançado o E-Business, banco de dados sem fio com o OracleMobile, Oracle9i
Application Server Wireless e Internet File System (IFS);

• 2001 é o ano de lançamento do Oracle9i (9.1). Tornando-se o primeiro banco de


dados com Real Application Clusters (RAC);

• 2002, lançado o Oracle9i Release2 (9.2);

• No ano de 2003 é lançado Oracle10g.

Levando-se em consideração o fato de que várias aplicações encontradas no mercado


utilizam a versão Oracle9i, optou-se por fazer os testes utilizando esta tecnologia.

Na próxima seção são descritas as principais características do Banco de Dados


Oracle.

1.5 Características do Oracle

Esta seção tem como objetivo explorar características do Banco de Dados Oracle
relacionadas ao tratamento dos dados. Há outros subgrupos de características não abordados
neste trabalho, uma descrição completa pode ser encontrada no manual de referência da
Oracle (2002).

A maioria das referências a Banco de Dados diz respeito não apenas aos objetos
físicos, mas também à combinação entre objetos físicos, de memória e de processo. Os dados
24

de um banco de dados são armazenados em tabelas, que são definidas por suas colunas que
recebem um nome. Em seguida, os dados são armazenados como linhas na tabela, que podem
estar relacionadas entre si, esses relacionamentos podem ser reforçados pelo banco de dados.

Além dos dados em formato relacional, o Oracle (a partir do Oracle8) suporta as


estruturas Orientadas a Objeto (OO), tais como os tipos de dados abstratos e os métodos.
(LONEY, 2002).

A seguir, alguns dos principais componentes da estrutura de uma base de dados


Oracle. As tablespaces, datafiles e registros redo formam com outros componentes, um BD
Oracle. Por se tratarem da forma de armazenamento dos dados, são de interesse da pesquisa,
mas não fazem parte do foco principal. Para maiores informações sobre outros componentes
consulte o manual de referências Oracle (2002).

Os dados de um BD Oracle são armazenados em arquivos, independentemente se em


estruturas relacionais ou orientadas a objeto. Internamente existem estruturas de banco de
dados chamadas tablespaces (espaços de tabelas) que fornecem mapeamento lógico dos dados
nos arquivos e permitem que os diferentes tipos de dados sejam armazenados separadamente,
agrupando estruturas lógicas entre si. Cada banco de dados divide-se logicamente em um ou
mais tablespaces.

O tamanho dos arquivos de dados combinados que formam uma tablespace, ditam a
sua capacidade de armazenamento. A combinação da capacidade de armazenamento de todas
as tablespaces que formam um banco de dados define a capacidade total de armazenamento
desse.

As tablespaces são utilizadas basicamente para:

• Controlar a alocação de espaço em disco para os dados de um banco de dados;

• Assinalar quotas específicas de espaços para usuários;

• Controlar a disponibilidade dos dados;

• Executar operações parciais de cópia e recuperação de um banco de dados;

• Alocar o armazenamento dos dados entre diferentes dispositivos de


armazenamento para melhorar a performance de um banco de dados.
25

Cada tablespace é formado por um ou mais arquivos em um disco, chamado


datafiles. Um datafile pertence a apenas um tablespace, podendo ser redimensionados após
sua criação.

Todo banco de dados Oracle tem um ou mais datafiles físicos. Esses datafiles
contêm todos os dados desse banco de dados. Os dados das estruturas lógicas, tais como as
tabelas e os índices, são armazenados fisicamente nos datafiles alocados.

Os dados de um datafile são lidos conforme a necessidade. Durante a operação


normal do banco de dados eles são armazenados na memória cache6.

Além dos dados associados a uma tablespace, o Oracle possui outros arquivos de
sistema operacional associados, chamados de registros de redo on-line.

Os arquivos de registros redo on-line, também conhecidos como registros de


transação, são usados para recuperar as transações do BD em sua ordem adequada em caso de
pane, uma vez que as transações são registradas nestes arquivos. As informações do registro
redo são armazenadas externamente aos datafiles do BD. (LONEY, 2002).

Os arquivos redo são arquivos especiais do sistema operacional em que o Oracle


registra todas as alterações ou transações que acontecem no BD. Quando são feitas mudanças
no BD, essas alterações ocorrem na memória. O Oracle manipula essas informações na
memória por razões de desempenho. Uma operação de entrada/saída de disco é mais lenta do
que uma ação de memória. Como uma cópia das transações é sempre gravada nos registros de
redo on line, o Oracle pode levar tempo gravando no arquivo de dados original as mudanças
nos dados que ocorrem na memória. A última cópia de alteração nos dados é gravada no
arquivo de dados físicos.

Finalmente, o BD sempre pode ser recuperado a partir desses registros de transação.


Todo BD Oracle tem arquivos de redo logs on line que registram os dados submetidos a
commit, sendo sobregravados sempre que ocorre uma alteração de log (ORACLE, 2006).

Assim, até este momento, foram abordados os temas tablespace, datafile e arquivos
de redo, tendo em vista o fato de serem alguns dos principais componentes de um BD Oracle
e também estarem intimamente ligados à forma de armazenamento dos dados.

6
Pequena memória estática que aumenta o desempenho do processador, armazena os dados mais requisitados
(WIKIPEDIA, 2006).
26

1.6 Recursos para aumento de desempenho

Esta seção tem por finalidade apresentar os recursos de desempenho utilizados pelo
SGBD Oracle. Logo, são abordados conceitos como tabelas temporárias, stored procedures
(procedimentos armazenados), triggers (gatilhos), views (visões) e índices.

1.6.1 Tabelas temporárias

No SGBD Oracle, uma tabela temporária é uma tabela com vida útil de uma sessão7
ou transação8, ou seja, ela está vazia quando uma sessão ou transação começa e descarta os
dados ao fim de uma sessão ou transação. Logo, é correto afirmar que uma tabela temporária
é associada à transação, isso significa que ao término da transação os dados da tabela são
perdidos, porém sua descrição permanece gravada no BD mesmo após a mudança de sessão.

Dessa forma, o que é temporário é o armazenamento dos dados, esse tipo de tabela
elimina a necessidade de remover os dados ao término da transação, sendo muito útil na
geração de dados de trabalhos temporários.

Existem dois tipos de tabelas temporárias, as tabelas temporárias por transação e as


tabelas temporárias por sessão:

• Tabelas temporárias por transação são as tabelas associadas à transação, ou seja,


tabelas nas quais ao final da transação (commit ou rollback) os dados são
removidos ou liberados, porém a estrutura da tabela permanece gravada no BD
mesmo após a mudança de sessão;
• Tabelas temporárias por sessão são criadas com indicação de que os dados sejam
mantidos após o término da transação, ou seja, a tabela é temporária, porém seus
dados ficam disponíveis por toda a sessão independente da transação. Os dados
serão removidos ou liberados apenas com o fim da sessão (disconect e connect),
porém a estrutura da tabela permanece gravada no banco de dados mesmo após a
mudança de sessão (DEVMEDIA/ TABELAS TEMPORÁRIAS, 2006).
Conforme pode ser observado na Figura 4.
1) SQL> create global temporary table TEMP_PROD
2) (cod_prod number(5),
3) desc_prod varchar2(30),
4) dat_cadas date) on commit preserve rows;
5) Table created.

7
Sessão é o conjunto de procedimentos executados entre os comandos CONNECT e DISCONECT.
8
Transação é um conjunto de procedimentos executados em um BD visto pelo usuário como uma ação única.
27

6) SQL> insert into TEMP_PROD


7) values (100,'Computador',sysdate);
8) 1 row created.
9) SQL> select * from TEMP_PROD;
10) COD_PROD DESC_PROD DAT_CADAS
---------- ------------------------------ ---------
11) 100 Computador 18-MAR-05
12) SQL> commit;
13) Commit complete.
14) SQL> select * from TEMP_PROD;
15) COD_PROD DESC_PROD DAT_CADAS
16) no rows selected
---------- ------------------------------ ---------
17) 100 Computador 18-MAR-05
18) SQL> connect dados@data1w
19) Enter password: *****
20) Connected.
21) SQL> select * from TEMP_PROD;
22) no rows selected
23) SQL> desc TEMP_PROD;
24) Name Null? Type
------------------------------- -------- ----
25) COD_PROD NUMBER(5)
26) DESC_PROD VARCHAR2(30)
27) DAT_CADAS DATE

Figura 4: Tabelas temporarias por seção.

As principais características das tabelas temporárias são (DEVMEDIA/ TABELAS


TEMPORÁRIAS, 2006):

• Tem definição visível para todas as sessões, mas os dados são visíveis apenas
para sessão que os inclui;
• O comando LOCK não tem efeito em tabelas temporárias, uma vez que cada
sessão tem acesso exclusivo a seus dados;
• O comando TRUNCATE trunca somente os dados referentes à sessão do usuário;
• Os dados são criados na tablespace temporária do usuário;
• Operações de Rollback to Savepoint são suportadas, mas os dados não são
recuperáveis;
• Podem ser criados índices, mas estes também são temporários;
• Podem ser criadas triggers para tabelas temporárias assim como views que
utilizem simultaneamente tabelas temporárias e permanentes;
• Os utilitários IMPORT e EXPORT podem exportar e importar a definição de uma
tabela temporária, mas nenhum dado é exportado;
• É possível replicar a definição de uma tabela temporária, mas não é possível
replicar seus dados;
28

• Só podem ser executadas as operações ALTER TABLE, DROP TABLE,


CREATE INDEX quando não houver nenhuma seção ou transação fazendo
acesso a ela;
• Uma tabela temporária associada à transação é acessível por uma determinada
transação e suas transações filhas. Porém, uma tabela temporária associada à
transação não é acessível por duas transações simultâneas na mesma sessão,
apesar de poder ser usada por transações em diferentes sessões;
• Se uma transação do usuário faz INSERT na tabela temporária, nenhuma de suas
transações filhas pode usar a tabela temporária após isto;
• Se uma transação filha faz INSERT numa tabela temporária, ao fim da transação
filha, o dado associado à tabela temporária é removido. Após isto, tanto a
transação do usuário quanto qualquer outra transação podem fazer acesso à tabela
temporária.
Assim sendo, acredita-se que as tabelas temporárias desempenham um importante
papel no BD Oracle. O uso deste mecanismo por sessão ou transação deve ser analisado em
cada caso, tendo sempre em mente o objetivo de evitar problemas, mantendo-se tabelas
temporárias com volumes grandes armazenados no BD sem real necessidade.

1.6.2 Stored Procedures

Stored Procedures ou procedimentos armazenados são programas SQL escritos por


um programador e que são armazenados no servidor de BD e podem ser invocados por
aplicações clientes.

Procedures PL/SQL9 têm comportamento semelhante aos de outras linguagens de


programação, sendo introduzido pelas palavras reservadas CREATE PROCEDURE seguidas
por um nome de procedimento e seus parâmetros.

O número de parâmetros não é limitado e cada um deve ser seguido por um modo e
um tipo. Os modos possíveis são IN (somente leitura), OUT (somente escrita) e INOUT
(leitura e escrita).

Uma stored procedure pode ser escrito em diferentes linguagens, dependendo apenas
do suporte a linguagens que o servidor de BD oferece. No Oracle, por exemplo, são escritas
em PL/SQL.

9
PL/SQL é uma extensão da linguagem padrão SQL para o SGBD Oracle.
29

As principais motivações para a construção de stored procedures são (ORACLE,


2002):

• Modularização de funcionalidades que mais de uma aplicação cliente


necessitaria, facilitando o reaproveitamento de código;
• Separação de regra de negócio da aplicação cliente;
• Concentração de lógica de manipulação de dados no BD.

Sendo assim, pode-se afirmar que existe certo ganho de performance com a
utilização de stored procedures, pois estas transferem para dentro da base de dados rotinas que
necessitam processar grandes quantidades de dados armazenados, sem a necessidade de
transferir os dados entre as aplicações e o banco de dados.

1.6.3 Triggers

O conceito de trigger é parecido com stored procedure, mas com uma diferença
principal: uma trigger é disparada automaticamente quando certos eventos acontecem. Esses
eventos são baseados em tabelas e linhas, ou seja, a atualização de uma linha pode invocar
uma trigger.

As triggers são códigos PL/SQL armazenados dentro do BD, onde pode ser definido
um bloco PL/SQL para que seja executado automaticamente pelo BD. Assim, toda vez que
uma instrução SQL for aplicada para uma tabela específica o BD irá executar um determinado
evento automaticamente.

As triggers são usadas para realizar tarefas relacionadas com validações, restrições
de acesso, rotinas de segurança e consistência de dados. Desta forma estes controles deixam
de ser executados pela aplicação e são executados pelos triggers em determinadas situações
como:

• Mecanismos de validação envolvendo múltiplas tabelas;


• Criação de conteúdo de uma coluna derivada de outras colunas de tabela;
• Realizar análises e atualizações em outras tabelas com base em alterações e/ou
inclusões na tabela atual.

Como vantagens em se utilizar triggers em BD Oracle, podem-se citar:

• As triggers são ferramentas que contribuem com a manutenção da integridade no


BD, pois podem ser definidas para disparar antes que uma nova linha seja
30

inserida no BD. A trigger é capaz de determinar se a linha está completa e


consistente, se não estiver, a operação pode ser cancelada;
• Triggers são freqüentemente usadas quando uma linha é inserida para gerar o
valor da chave primária;
• Triggers podem ser usadas para escrever informação de estado em uma tabela
primária de dados para outra tabela.

A utilização de triggers impõe algumas limitações que são mencionadas a seguir


(ORACLE, 2002):

• Não é possível criar um trigger para uma visão;


• O resultado da execução de uma trigger é retornado para a aplicação que o
chamou;
• O comando WRITETEXT não ativa uma trigger;
• O comando TRUNCATE TABLE não pode ser reconhecido por um trigger;
• Os seguintes comandos não podem ser usados em uma trigger: ALTER
DATABASE, ALTER TRIGGER, ALTER PROCEDURE, ALTER TABLE, ALTER
VIEW, CREATE DATABASE, CREATE INDEX, CREATE PROCEDURE,
CREATE SCHEMA, CREATE TABLE, DROP DATABASE, DROP TABLE, DROP
PROCEDURE, DROP TRIGGER, DROP INDEX, GRANT, LOAD DATABASE,
TRUNCATE TABLE.

Assim, acredita-se que pelo fato de tanto triggers quanto stored procedures
fornecerem ao administrador de BD ou ao desenvolvedor benefícios de organização, suas
estruturas influenciam no seu desempenho e funcionalidade do SGBD, pois fornecem
métodos de armazenar os procedimentos como uma unidade de BD.

1.6.4 Views

Uma view ou visão é uma apresentação personalizada dos dados de uma ou mais
tabelas. Também pode ser vista como uma "consulta armazenada". As views não contêm ou
armazenam os dados e sim retiram das tabelas nas quais se baseiam, chamadas de tabelas base
das views, que podem ser tabelas ou views.

Assim como as tabelas, as views podem ser consultadas, atualizadas, inseridas e


excluídas com algumas restrições. Todas as operações executadas numa view afetam a tabela
base desta view.
31

No Oracle, uma view tem funcionamento semelhante a uma tabela. Utiliza comandos
SELECT, INSERT, UPDATE e DELETE, para recuperação e manipulação de dados, sem seu
armazenamento.

Este objeto tem suas linhas e colunas calculadas dinamicamente através de um


SELECT pré-estabelecido, a cada vez que é solicitado. Apenas sua definição é armazenada no
dicionário de dados.

Logo, pode ser tratada como uma tabela virtual, pois não possui linhas próprias, mas
as obtém em tempo de execução e as disponibiliza em memória para acesso em uma consulta.
A Figura 5 ilustra a sintaxe de criação de uma view no Oracle:

1) Create view estoque as


2) (select codprod,
3) descrição
4) from produtos
5) where pmedio < 1000);

Figura 5: Sintaxe de criação de uma view.

O comando REPLACE recria uma view já existente. É utilizado para alterar uma
view já existente sem a necessidade de apagá-la. É utilizado também para atribuir novas
permissões ou privilégios.

O comando DROP VIEW exclui uma view do dicionário de dados. Nenhum efeito
ocorrerá sobre as tabelas referenciadas, bastando para isso ter apenas o privilégio DROP
VIEW.

As vantagens da utilização das views no BD Oracle são:

• Economia de tempo, uma vez que a instrução é escrita e armazenada;


• Velocidade no acesso às informações, pois quando compilada, o conjunto de
dados é armazenado em uma tabela virtual;
• As views isolam do usuário a complexidade do BD, pois nomes e domínios
podem ser referenciados com literais e outros recursos. Isso proporciona a
capacidade de alterar a estrutura sem afetar a interação do usuário com o BD;
• Simplifica o gerenciamento de permissões do usuário, pois possibilitam a
concessão de permissões para que os usuários consultem dados somente através
de views. Isso protege as alterações na estrutura das tabelas base. Os usuários não
são interrompidos durante uma visualização de dados;
32

• Organizar dados a serem exportados para outros aplicativos, pois a view pode ser
criada com base em uma consulta complexa, para depois exportar os dados para
outro aplicativo para análise adicional.

Por fim, acredita-se que views podem influenciar no desempenho do SGBD.

1.6.5 Índices

Os índices são estruturas opcionais associadas às tabelas, as quais aumentam o


desempenho da recuperação de dados. Um índice Oracle tem a função de fornecer o caminho
mais rápido para os dados de uma tabela (ORACLE, 2002).

Ao processar uma solicitação, o Oracle pode utilizar algum ou todos os índices


disponíveis para localizar as linhas solicitadas. Os índices são úteis quando os aplicativos
consultam com freqüência um intervalo de linhas de uma tabela. São criados em uma ou mais
colunas de uma tabela. Depois de criado, é automaticamente atualizado e usado pelo Oracle.
As alterações nos BD’s como acréscimo, atualização ou exclusão de linhas são incorporadas
automaticamente a todos os índices relevantes com total visualização para usuários.

Os índices são independentes dos dados e podem ser excluídos e criados


separadamente e a qualquer momento, sem afetar as tabelas ou outros índices. Quando os
índices são excluídos, todos os aplicativos continuam funcionando, mas o acesso aos dados
indexados pode tornar-se mais lento, comprometendo o desempenho do SGBD.

Conforme descrito nesta seção, o uso ou não de índices pode influenciar no


desempenho do SGBD, dependendo muito da forma como são implementados no esquema de
BD’s.

1.7 Segurança

A Oracle9i oferece segurança em três camadas (LONEY, 2002), que foi aprimorada a
partir da versão anterior (Oracle8i) através de autenticação via “Proxy autenthication” e
integração com LDAP10.

A segurança de hospedagem dos dados é garantida através (i) do Virtual Private


Database (VPD), que possui um contexto de aplicação particionado (imposição de segurança
dependendo de qual aplicativo acessa os dados) e pool de conexões11 através de um contexto
de aplicação compartilhado; (ii) da auditoria rigorosa que permite definição de políticas de
10
Lightweight Directory Access Protocol- subconjunto do X.500DAP que não possui sobrecarga da pilha de
protocolos OSI.
33

auditoria que especifiquem condições de acesso aos dados que disparem um evento de
auditoria e utilizem manipulador de eventos flexível para notificação quando evento for
disparado, servindo como sistema de detecção de invasão para o banco de dados.12

O Oracle Label Security é um produto para rígido controle de acesso, que acrescenta
um rótulo às linhas de dados. Foi desenvolvido com base na tecnologia VPD do Oracle9i e
fornece uma dimensão de controle de acesso que não pode ser atingida facilmente usando os
dados de aplicativos existentes.

A criptografia inclui JCA (Java Cryptographic Architecture) e JCE (Java


Cryptographic Extensions), que suportam os algoritmos de criptografia e integridade de dados
populares (LONEY, 2002).

Por fim, foram abordados, ao longo deste capítulo, os assuntos referentes ao SGBD
Oracle. Inicialmente, um breve histórico que relata a evolução da empresa, depois foram
ressaltadas as principais características do SGBD Oracle. Levando-se em consideração o fato
de que a pesquisa tem por objetivo analisar o desempenho do SGBD, foram apresentados,
também, as formas de armazenamento e busca de dados que podem influenciar no resultado
final da pesquisa. E como último tópico, abordou-se a segurança que o produto oferece.

11
Pool de conexões são um conjunto de conexões livres a um recurso remoto que são usadas quando necessário.
Evita consumir muito tempo e estabelecer conexões muitas vezes. (WIKIPEDIA/POOL, 2006)
12
Apesar de segurança não influenciar diretamente no desempenho (depende dos recursos disponibilizados por
cada SGBD), abordou-se o assunto por ser uma característica comum a todos e também relevante quando da
escolha de SGBD pela empresa cliente.
3 SQL SERVER

O SQL Server é um Sistema Gerenciador de Banco de Dados, considerado, de bom


desempenho, integrado com os sistemas operacionais Windows. Foi projetado para tirar
proveito do sistema operacional Windows, tornando possível que vários componentes comuns
desse sistema operacioanal forneçam funcionalidade adicional para o SQL Server.
(MICROSOFT, 2006).

Por se tratar de um SGBD bem conceituado e não ter sido explorado na pesquisa que
serve como base para este trabalho, o SQL Server foi incluído neste estudo, com intuito de
que se faça comparação de seu desempenho frente aos testes que são apresentados no
trabalho. Por isso, o SQL Server será matéria de estudo deste capítulo, abordando a sua
história, suas características, os recursos de aumento de desempenho e a segurança.

1.8 Histórico

A primeira versão do SQL Server foi lançada em 1988, projetada para plataforma
OS/2 (Operating System/2)13 e desenvolvido em conjunto pela Microsoft e Sybase. Durante os
primeiros anos da década de 1990, a Microsoft começou a desenvolver uma nova versão do
SQL Server para plataforma NT. Enquanto a versão estava sendo desenvolvida, a Microsoft
decidiu que o SQL Server deveria estar totalmente integrado com o sistema operacional NT.

A evolução do banco de dados SQL Server nos últimos anos, pode ser descrita:

• Em 1988 a Mycrosoft lança a primeira versão do SQL Server em parceria com a


Sybase;
• Em 1989 chega o segundo padrão SQL o SQL-89;

13
OS/2 é um sistema operacional da IBM, concebido para linha de computadosres PS/2 e depois adaptado a PC’s
comuns (WIKIPEDIA / OS/2. 2006).
• No ano de 1992 a Microsoft assumiu a responsabilidade pelo futuro do SQL
Server para o NT, a Microsoft lança o ODBC14 com o objetivo de criar uma
camada intermediária entre os SGBD’s. Neste ano é lançado o Microsoft Access;
• Ainda no ano de 1992 chega terceiro padrão SQL, o SQL-92;
• Em 1993, Windows NT 3.1 e SQL Server 4.2 para NT foram lançados,
combinado interface fácil de usar com banco de dados de alto desempenho, o que
tornou a Microsoft o segundo fornecedor mais popular de software high-end
(topo de linha) de banco de dados relacional;
• Em 1994, a Microsoft e a Sysbase encerram formalmente sua parceria;
• Em 1995, a Microsoft lança a versão 6.0, melhorando a performance e inclui
replicação de dados no produto;
• Em 1996, a Microsoft lançou a versão 6.5 do SQL Server que trouxe
aprimoramentos significativos à tecnologia existente e novos recursos;
• Em 1997, a Microsoft lançou a versão 6.5 do Entreprise Edition;
• Em 1998, a Microsoft lançou a versão 7.0 do SQL Server, que trouxe a
atualização completa do mecanismo de banco de dados;
• Em 2000, a Microsoft lançou o SQL Server 2000 que foi construída sobre a
estrutura do SQL Server 7.0, esta nova versão traz alterações no mecanismo de
banco de dados, tornando-se largamente utilizado para comércio eletrônico (e-
business) e iniciativa de data warehouse e continua definindo padrão para
desempenho, facilidade de uso e funcionalidade “fora da caixa” (SPENIK,
SLEDGE, 2001);
• Foi previsto para o final de 2005 o lançamento da versão mais atual do BD SQL
Server, SQL Server 2005 ou YUKON, mas ocorreu no início de 2006
(MICROSOFT, 2006).
Tendo em vista que várias das aplicações encontradas no mercado rodam em SQL
Server 2000, os testes são aplicados nessa versão.

1.9 Características do SQL Server

A principal característica do SGBD SQL Server é ter sido projetado para tirar
proveito do sistema operacional Windows, com isso, tornando possível que vários

14
Open Data Base Connectivity é uma tecnologia padrão de programação para acesso a banco de dados por meio
de uma biblioteca de funções pré-definida (WIKIPEDIA/ODBC, 2006).
componentes comuns do Windows forneçam funcionalidade adicional para o SQL Server
(MICROSOFT, 2006).

Devido aos diversos recursos oferecidos pelo sistema operacional, este SGBD
consegue oferecer SMP (Symmetric Multi-Processing - Multiprocessamento Simétrico);
portabilidade; independência de rede e confiabilidade. Uma das desvantagens do Banco de
Dados SQL Server é ser implementado apenas para sistemas operacionais Microsoft.

O SMP permite ao SQL Server aumentar o desempenho pelo uso de processadores


adicionais. O SQL Server pode executar automaticamente uma consulta, paralelamente, em
dois ou mais processadores. Isso ocorre sem interação com o usuário, aliviando também
administradores das complexidades de gerenciamento de múltiplos processadores.

A independência de rede se dá pelo fato de que os sistemas operacionais Windows


suportam vários tipos diferentes de protocolos de rede. Esse nível de suporte se estende à
conectividade do SQL Server, permitindo escolher o protocolo de rede que se ajusta às
necessidades presentes e futuras (SPENIK, SLEDGE, 2001).

Nos testes foi utilizada a versão SQL Server 2000 Standard Edition. Optou-se por
essa versão por ser indicada pelo fabricante para pequenas e médias bases.

1.10 Recursos de aumento de desempenho

Esta seção tem por finalidade apresentar os recursos de desempenho utilizados pelo
SGBD SQL Server. Logo, são tratados conceitos como tabelas temporárias, stored
procedures, triggers, views e índices.

1.10.1 Tabelas temporárias

No SQL Server, as tabelas temporárias são utilizadas quando é necessário reunir


vários registros de várias tabelas em uma única seleção e exibi-las em outras aplicações.
É fundamental em aplicações cliente/servidor, onde vários usuários acessam a
mesma procedure ao mesmo tempo.
A tabela temporária existe apenas enquanto a procedure está sendo executada, após a
execução da mesma ela é automaticamente eliminada.
As tabelas temporárias do SQL Server têm as seguintes características (a Figura 6
expressa a sintaxe de criação dessas tabelas):
• Não são armazenadas no banco de dados de produção e sim no tempdb15;
• Seus nomes são iniciados com #;
• São visíveis apenas ao usuário da conexão;
• São eliminadas quando a conexão é encerrada;
• Todos os comandos de criação, alteração e exclusão são os mesmos das tabelas
normais;
• Comandos para os dados são iguais aos comandos das tabelas normais.

1) CREATE TABLE #Temp(Codigo INT NULL, Nome VARCHAR(40)


NULL)

Figura 6: Sintaxe de criação de uma tabela reporária em SQL Server.

É importante ressaltar que tabelas temporárias podem ser criadas com o mesmo
nome em conexões diferentes, o fato de estarem em conexões distintas garante que uma não
interfira na outra. O SQL Server consegue fazer este controle, pois no banco tempdb é criada a
tabela com um nome conectado com um identificador.
Pelo fato das tabelas temporárias não ocuparem espaço no BD, pois não ficam
armazenadas quando não são mais necessárias, acredita-se que a utilização deste recurso pode
representar ganho de desempenho ao SGBD.

1.10.2 Stored Procedures

Os procedimentos armazenados em SQL Server são uma coleção de instruções


implementadas com linguagem T-SQL (Transact-SQL no SQL Server 2000 e 2005), que uma
vez armazenadas ou salvas, ficam dentro do servidor de uma forma pré-compilada,
aguardando que um usuário do banco de dados faça sua execução.

A sintaxe básica de uma stored procedure no SQL Server é apresentada na Figura 7:

15
O tempdb é um banco de dados de sistema utilizado pelo SQL Server. Ele armazena objetos temporários como
tabelas e procedures criados por todas as conexões de usuários e tabelas de trabalho criadas pelo próprio SQL
Server. (MCDBABRASIL, 2006)
Figura 7: Sintaxe Básica de Stored Procedure.

Existem tipos de Stored Procedures para SQL Server 2000 e 2005, são eles:

• System Stored Procedures ou Procedimentos Armazenados de Sistema são


criados no momento de instalação e ficam armazenados no banco de dados
chamado master, junto com as entidades e outros procedimentos próprios do
sistema;
• Local Stored Procedure ou Procedimentos Armazenados Locais são criados em
bancos de dados de usuários individuais, já no SQL Server 2005, tem o nome de
Stored Procedures Temporárias Locais, que iniciam com um sinal de # e somente
a conexão que criou poderá executá-la. No SQL Server 2005 existem os
Procedimentos Temporários Globais, que podem ser utilizados de forma global,
ou seja, por qualquer usuário da conexão e iniciam com ##. Ao ser encerrada a
conexão, os dois procedimentos são eliminados;
• Extended Stored Procedure ou Procedimentos Armazenados Extendidos são
comuns as duas versões do SGBD. Executam funções internas e do sistema
operacional e iniciam com “xp_”;
• User-Defined Stored Procedure ou Procedimentos Armazenados Definidos pelo
Usuário são criados em bancos de dados pelo próprio usuário, são utilizados para
realizar tarefas repetitivas, facilitando a manutenção e alteração uma vez que
estão em um único ponto da aplicação/ Banco de Dados.

As vantagens do uso de stored procedures são:

• Modularidade, ou seja, uma vez que se tem o procedimento dividido das outras
partes do software, basta alterar suas operações para obter modificações por toda
a aplicação;
• Uma vez passado o parâmetro para o servidor, chamando o procedimento
armazenado, as operações ocorrem usando o processamento do servidor e no
final deste, é retornado ou não os resultados de uma transação, sendo assim, não
há muito tráfego pela rede;
• Existe ganho de rapidez na execução, pois stored procedures salvas no servidor,
ficam somente aguardando, já em uma posição de memória cache, serem
chamadas para executar uma operação, ou seja, como estão pré-compiladas, as
ações já estão pré-carregadas, dependendo somente dos valores dos parâmetros.
Após a primeira execução, se tormam ainda mais rápidas;
• Segurança nos dados, pois possibilitam ocultar a complexidade do banco de
dados para usuário, deixando que sejam acessados somente dados pertinentes ao
tipo de permissão atribuída ao usuário ou mesmo declarando se o Stored
Procedure é público ou proprietário (DEVMEDIA, 2006).

Ao final desta etapa, conclui-se que existe ganho de performance com a utilização de
stored procedures, pois estas transferem para dentro da base de dados rotinas de
processamento de dados armazenados, sem a necessidade de transferir os dados entre as
aplicações e o banco de dados.

1.10.3 Triggers

Assim como no Oracle, as triggers no SQL Server são disparadas quando ocorre um
evento.
A seguir é ilustrada a sintaxe de uma trigger no SQL Server16:
1) Create Trigger Nome_Trigger
2) On [ALL Server | Database]
3) With [Opções]
4) [For | After]
5) Eventos [ .... ]
6) As
7) Rotinas SQL

Figura 8: Sintaxe de uma trigger em SQL Server.

Sendo que:

Nome_trigger - O nome da trigger dentro do banco de dados / Servidor;

16
Detalhes conceituais de Triggers, Views, Stored Procedures estão no capítulo 2.
All Server - Usado para especificar que a trigger será executada em todos os bancos
de dados do Servidor;

Database - Usada para especificar que a trigger será usada somente no banco de
dados em que foi criado;

Opções - Pode ser usada com a opção Encryption (criptografar o código) ou Execute
As (para executar trigger com outro perfil de usuário de banco).

Rotinas SQL - São os comandos SQL que a trigger executa ao ser invocada.

For / After - Funcionam como gerenciadores de execução, para executar assim que a
alteração for efetuada ou depois que a alteração for concluída.

Eventos - São eventos que irão invocar a trigger.

Pelo fato de que triggers fornecem métodos de armazenar procedimentos, trazendo


benefícios de organização, podem influenciar no desempenho do SGBD.

1.10.4 Views

Na criação de views o SQL Server verifica a existência de objetos que contêm


referências em uma definição de view. O nome da view deve seguir o padrão de regra de
identificadores. A especificação do nome do proprietário da view é opcional, quando for
pública deve ser declarado “dbo.nome_entidade”. Não pode ser atribuído à view um nome já
utilizado em outro objeto do mesmo BD.
A seguir, é apresentada a sintaxe de uma view do SQL Server:
1) USE NOME_DO_BANCO
2) GO
3) CREATE VIEW dbo.viewAniversariante
4)(nome, sobrenome, data_nascimento)
5) AS
6) SELECT nome, sobrenome, CONVERT(char(8),
data_nascimento, 2)
7) FROM usuario AS u INNER JOIN jovens AS j
8) ON u.usuario_no = j.usuario_no
9) GO.

Figura 9: Sintaxe de View no SQL Server

Desta forma, acredita-se que uma view pode influenciar no desempenho do SGBD,
como já mencionado no capítulo anterior.
1.10.5 Índices

O SQL Server acessa seus dados de duas formas, varrendo todas as páginas
começando do início da tabela e extraindo o pedido da query ou usando índices.

Os índices, em SQL Server, são classificados em:

• Índices Clusterizados (aglomerados), ou seja, onde a última camada de índice é a


página atual, em que os dados são fisicamente ordenados de forma ascendente.
Logo existe apenas um índice clusterizado por tabela. A ordenação tanto fisica
dos dados como do índice é a mesma. Um índice clusterizado é bastante parecido
com uma agenda de telefone, onde ficam as iniciais do alfabeto e, logo em
seguida, os nomes e telefones das pessoas;
• Índices Não Clusterizados, ou seja, quando o índice não é clusterizado, a
contrução é feita por heap. O SQL usa as linhas como identificador de índices.
Chama-se heap porque na sua tradução significa amontoado. Pelo motivo dos
dados não terem uma ordem lógica, são gravados nas páginas que tem espaço
disponível. Esse tipo de índice é muito usado quando é necessário encontrar uma
informação de várias formas diferentes. A ordem do left-level de um índice desse
tipo é diferente da ordenação física, podendo ter até 249 índices não cluster por
tabela. É parecido com um livro, onde os dados ficam num lugar e o índice em
outro.

O SQL Server usa a chave clusterizada na página de índice para colocar o ponto do
índice, e uma chave (clustering key) armazenando o local da informação. Tabelas que contêm
índice cluster e não cluster são comuns. Primeiro cria-se o índice clusterizado para organizar
os dados em ordem ascendente e depois se cria o índice não clusterizado nas colunas que
forem necessárias (GERVAZONI, 2006).

O SQL Server oferece uma ferramenta chamada Index Tunning Wizard (ITW) que
tem a função de analisar as queries e criar os índices apropriados nos lugares certos. O ITW
pode ser usado sempre que uma nova tabela for criada ou mesmo em tabelas antigas. O ITW
pode prover um relatório das propostas de troca ou criação de índices como:

• Índices já usados corretamente e índices recomendados;


• Melhora da performance para as 100 queries mais expressivas.

Não é recomendado usar o ITW quando:


• Tabelas têm referências cruzadas, e não existem na base de dados;
• Tabelas de sistemas.

Conforme afirmado anteriormente, neste mesmo tópico do capítulo 2, acredita-se que


os índices podem influenciar, também, no desempenho do SGBD, inclusive no SQL Server.

1.11 Segurança

Sabe-se que segurança é uma preocupação de toda a indústria e vem exigindo


esforços de colaboração, pois as bases de dados podem estar sujeitas a uma diversidade de
riscos. Com base nas informações do fabricante, esta seção tem por objetivo esclarecer os
principais recursos do SQL Server para garantir segurança aos clientes17.

Para tanto, o SQL Server valida os usuários em dois níveis: autenticação de login e
validação de permissões para contas de usuário no banco de dados (MICROSOFT, 2006).

A autenticação identifica o usuário que está usando uma conta de login e verifica a
capacidade do usuário em se conectar ao SQL Server. Se a autenticação for bem-sucedida, o
usuário se conectará ao SQL Server.

O usuário deve ter, então, permissão para acessar os banco de dados no servidor. O
administrador do banco de dados atribui permissões específicas ao banco de dados para as
contas de usuário para que os mesmos sejam acessados no servidor. As permissões controlam
as atividades que o usuário pode executar no BD do SQL Server.

Dentro de cada base de dados, são atribuidas permissões às contas de usuários para a
execução (ou restrição) de certas ações. O SQL Server aceita comandos após o acesso bem-
sucedido do usuário ao BD.

O SQL Server executa as seguintes etapas ao validar as permissões:

1. Quando o usuário executa uma ação, o cliente envia as instruções Transact-SQL


ao SQL Server;
2. Quando o SQL Server recebe uma instrução Transact-SQL, ele verifica se o
usuário tem permissão para executar uma instrução;
3. Em seguida, ele executa uma das duas ações:

17
Apesar de segurança não influenciar diretamente no desempenho (depende dos recursos disponibilizados por
cada SGBD), abordou-se o assunto por ser uma característica comum a todos e também relevante quando da
escolha de SGBD pela empresa cliente.
o Se o usuário não tiver as permissões adequadas, o SQL Server retornará um
erro;
o Se o usuário tiver as permissões adequadas, o SQL Server executará a ação.

Neste capítulo foram abordados os assuntos referentes ao SGBD SQL Server. Um


breve histórico foi apresentado, a evolução da empresa, depois foram ressaltadas algumas
características do SGBD SQL Server. Levando-se em consideração de que a pesquisa tem por
objetivo analisar o desempenho do SGBD, foram apresentados, inclusive, os recursos de
aumento de desempenho que podem influenciar no resultado final da pesquisa. Por fim, foram
tratadas as tecnologias que garantem segurança do produto.
4 MYSQL

A rapidez talvez seja a característica mais marcante do sistema gerenciador de banco


de dados relacional MySQL. Desenvolvido pela MySQL AB, é um software livre muito usado
na Web. O SGBD MySQL tem utilização simples, aceita comandos SQL para manipulação
dos dados e dispõe de comandos extras para manipulação do ambiente (MYSQL, 2006).

Neste capítulo são abordados: a história da empresa, as principais características da


ferramenta, os recursos de aumento de desempenho e de segurança.

1.12 Histórico

O MySQL surgiu a partir da necessidade da equipe, que criou o SGBD, de utilizar


algum mecanismo que permitisse a conexão de tabelas criadas na linguagem SQL para um
determinado fim. A princípio, o grupo iria utilizar uma versão limitada de um banco de dados,
mas logo perceberam que esta ferramenta não era rápida o suficiente para atender às
necessidades do projeto. Então, buscou-se uma solução própria. Nascia o MySQL.

1.13 Características do MySQL

O MySQL é um BD gratuito, eficiente e otimizado para aplicações Web. Por esta


razão ele possui menos recursos, como por exemplo, triggers que não existem no MySQL .
Segundo o manual de referência (MYSQL, 2006), esses recursos não permitiriam que o
MySQL fosse tão rápido.

O MySQL também oferece uma versão comercial. Esse SGBD é multi-plataforma,


sendo compatível com os sistemas operacionais Windows, Linux, e BSD, entre outros. As
tabelas criadas podem ter tamanho de até 4 GB. Mesmo estando disponível em diversos
sistemas operacionais, tem deficiência ou mesmo a inexistência de alguns recursos
importantes.
45

As características principais seguem a seguir:

• Suporte total a multi-threads usando threads no kernel. Isso significa que é


possível usar múltiplas CPU’s;
• Escrito em C e C++;
• Tabelas de disco B-tree com compressão de índices;
• Tabelas hash em memória que são usadas como tabelas temporárias.

Algumas das deficiências conhecidas do MySQL, segundo o Manual de Referência,


são:

• Recursos como Subselects, Foreign keys, Views e Triggers, estão em fase de


testes;
• O MySQL aceita parenteses na parte FROM, mas os ignora sem aviso;
• Fazendo um LOCK TABLE e FLUSH TABLES não garante que não existam
transações não terminadas em progresso na tabela;
• Em instruções UPDATE, colunas são atualizadas da esquerda para direita.
Quando se referencia uma coluna atualizada, pode-se obter um valor atualizado
em vez do valor original;
• Em uma consulta, não se pode referir a uma mesma tabela temporária mais de
uma vez;
• RENAME não funciona em tabelas temporárias.

Por se tratar de um SGBD de boa reputação quanto ao seu desempenho e também por
não ter sido incluído na pesquisa que serve como base para este trabalho, aliado ao fato de ser
um sistema que faz parte do grupo de softwares livres, foi incluído nesta pesquisa.

Em relação às deficiências apontadas pelo manual de referência do SGBD MySQL,


assim como as vantagens de se utilizar um sistema Open Source18, foram aplicados testes com
base na avaliação do desempenho, que será obtido levando-se em consideração as funções
oferecidas na versão escolhida para aplicação dos testes.

18
O software chamado Open source, ou em português código aberto, é um tipo de software cujo código fonte é
público. O software de código aberto respeita as 4 liberdades definidas pela Free Software Foundation, porém,
não estabelece certas restrições como as contidas na GPL. É advogado pela Iniciativa do Código Aberto (Open
Source Initiative). (WIKIPEDIA/OPENSOURCE, 2006).
46

1.14 Recursos de aumento de desempenho

Esta seção tem por finalidade apresentar os recursos de desempenho utilizados pelo
SGBD MySQL. Assim, são abordados conceitos como tabelas temporárias, stored procedures,
triggers, views e índices.

1.14.1 Tabelas temporárias

O MySQL possui uma característica um pouco diferente dos outros SGBD’s, uma
vez que no MySQL é possível escolher o tipo da tabela no momento da criação da mesma. O
formato de armazenamento dos dados, bem como alguns recursos do banco de dados são
dependentes do tipo de tabela escolhido.

No caso das tabelas temporárias basta acrescentar ao script de criação da tabela a


solicitação de “TEMPORARY”, como pode ser observado a seguir:

1) CREATE TEMPORARY TABLE A (index (codrem, codref))

Figura 10: Sintaxe de criação de table temporária no MySQL

Segundo o manual de referência, no MySQL as tabelas temporárias devem ser do


tipo:

• Tabelas heap são armazenadas em memória e por isso são extremamente rápidas,
por outro lado seu conteúdo é volátil, uma vez que não são gravadas em disco.
Caso haja uma queda do SGBD, os dados desta tabela são perdidos. Além disso,
é necessário um processo para dar a “carga inicial” nos dados quando o servidor
de banco iniciar a sua execução. A principal aplicação das tabelas heap é para
tabelas que são consultadas com muita freqüência, mas que não sofrem muitas
altelações.

1.14.2 Stored Procedure

Uma Stored Procedure é um conjunto de comandos SQL que podem ser


armazenados no servidor, conforme já escrito anteriormente, evitando o reenvio de comandos
individuais o que melhora o desempenho já que menos informações são trocadas pelo cliente
e o servidor.
47

O ponto negativo da utilização de stored procedures está no fato de que existe um


aumento de carga no sistema do servidor de banco de dados, uma vez que a maior parte do
trabalho é feita no servidor e menor parte é feita na aplicação.

Pelo fato de não ser necessário reescrever toda a consulta e sim só fazer referência a
stored procedure, existe ganho de desempenho da aplicação, pois a consulta só é analisada
pelo servior uma vez, diminuindo assim o volume de informações enviadas entre o servidor e
o cliente (MYSQL, 2006).

O stored procedure permite a existência de bibliotecas de funções no servidor do


banco de dados. No entanto, as linguagens de aplicações modernas permitem que isso seja
feito internamente com uso de classes.

Podem ser utilizadas com sucesso quando:

• Várias aplicações clientes são escritas em linguagens diferentes ou funcionam em


diferentes plataformas, mas precisam realizar as mesmas operações de banco de
dados;

• Existe necessidade de ambiente mais consistente e seguro possível, os


procedures podem assegurar que cada operação seja registrada de forma
apropriada.

A melhora no desempenho do SGBD justifica a utilização de stored procedures,


mesmo que haja maior carga no sistema do servidor do banco de dados.

1.14.3 Triggers

Conforme o manual de referência (MYSQL, 2006), o MySQL não suporta triggers,


mas estão sendo implementados para versões futuras.

1.14.4 Views

Segundo em (MYSQL, 2006), as views são muito úteis para permitir o acesso a uma
série de tabelas, e limitar o acesso a esta tabela. As views também podem ser usadas para
restringir o acesso aos registros (um subconjunto de uma tabela em particular). Contudo,
MySQL não suporta esse recurso, mas views estão sendo implementadas.

1.14.5 Índices
48

Os índices são utilizados para encontrar registros rapidamente. Sem um índice o


MySQL (bem como todos os outros SGBDs) precisa iniciar com o primeiro registro e depois
ler através de toda a tabela até que ele encontre os registros relevantes. Quanto maior a tabela,
maior será o custo. Com o índice, o MySQL obtém uma posição para procurar no meio do
arquivo de dados sem ter que varrer todos os registros. Os índices são atualizados nas
seguintes situações:

• Para encontrar rapidamente os registros que coincidem com uma cláusula


WHERE;
• Para recuperar registros de outras tabelas ao realizar joins;
• Para encontrar o valor máximo ou mínimo para uma coluna indexada específica,
trocando as expressões por constantes;
• Para ordenar ou agrupar uma tabela se a ordenação ou o agrupamento for feito
em um prefixo mais à esquerda de uma chave útil. A chave é lida na ordem
invertida se todas as partes da chave forem seguidas por DESC;

Algumas vezes o MySQL não utiliza índice, mesmo que algum estiver disponível.
Por exemplo, quando o uso do índice necessita que o MySQL acesse mais de 30% dos
registros das tabela, logo, a varredura da tabela poderá ser mais rápida já que necessitará de
menos pesquisas em disco. Mesmo assim, se a consulta estiver fazendo uso de LIMIT para
recuperar somente parte dos registros, o MySQL irá utilizar o índice de qualquer forma,
porque irá acessar poucos recursos e retornar o resultado rapidamente (MYSQL, 2006)

Sendo assim, acredita-se que a utilização ou não dos índices influenciam no


desempenho do SGBD.

1.15 Segurança

Pensando na segurança do BD, o MySQL possui um mecanismo que permite limitar


o acesso de um usuário a apenas um banco, tabela ou coluna, além de poder controlar o acesso
de acordo com o host (servidor) a partir de onde está sendo feita a conexão com o servidor. É
possível conceder privilégios diferentes para cada host de onde o usuário possa estabelecer a
conexão19.

19
Apesar de segurança não influenciar diretamente no desempenho (depende dos recursos disponibilizados por
cada SGBD), abordou-se o assunto por ser uma característica comum a todos e também relevante quando da
escolha de SGBD pela empresa cliente.
49

O MySQL armazena os dados dos usuários em quatro tabelas que são localizadas no
banco de dados MySQL. Essas tabelas são a user, db, tables_priv e columns_priv. A tabela
user armazena informações de todos os usuários do banco e os privilégios globais do usuário.
A tabela db armazena os privilégios dos usuários específicos de um banco de dados. As
tabelas tables_priv e columns_priv armazenam os privilégios associados a tabelas e colunas,
respectivamente.

Para criar os usuários e conceder privilégios no MySQL, utiliza-se o comando


GRANT (comando da linguagem SQL). Ao executar um comando GRANT para um usuário
que não existe, o mesmo será criado. Um GRANT para um usuário que já existe adicionará os
novos privilégios aos já concedidos anteriormente.

Com base nesta proposta, os recursos disponibilizados pelo MySQL proporcionam


segurança no acesso aos dados, uma vez que sejam armazenadas as informações corretas
pertinentes a cada usuário.

Ao final deste capítulo, ressalta-se que foram abordados os assuntos referentes ao


SGBD MySQL. Como realizado com os outros SGBD’s, foi relatada a evolução da empresa,
depois foram abordadas algumas características do SGBD MySQL. Levando-se em
consideração o fato de que a pesquisa tem por objetivo analisar o desempenho do SGBD,
foram apresentados, ao longo do capítulo, os recursos de aumento de desempenho que podem
influenciar no resultado final da pesquisa. Por fim, abordou-se as tecnologias que garantem
segurança do produto.
5 CRITÉRIOS DE AVALIAÇÃO

A utilização de um grande número de recursos dos SGBD’s em cada instrução


executada faz com que exista necessidade de avaliar o desempenho dos sistemas envolvidos.
A importância na simulação dos casos específicos justifica-se quando existe o acesso
simultâneo ao banco de dados, ou volumes de dados diferentes, ou ainda, em situações em
que as arquiteturas de hardware e o tipo de acesso ao banco de dados podem influenciar no
desempenho da aplicação (GULUTZAN, 2002).

Neste capítulo são apresentados os principais critérios de avaliação de desempenho


dos SGBDR’s (SGBD Relacionais), considerando as situações que podem comprometer a
performance de um banco de dados.

Uma vez que, o presente trabalho se propõe a dar continuidade a pesquisa


anteriormente iniciada por Edson Luis Pletsch (2005), os critérios de avaliação são buscados
na pesquisa já realizada.

1.1 Consultas

Em se tratando de banco de dados, quando se fala em consultas ou processo de trazer


os dados armazenados no banco de dados, refere-se aos selects. Os selects são as instruções
mais executadas nos bancos de dados, já que são utilizados sempre que for necessário
recuperar informações armazenadas no banco de dados. Numa consulta, são utilizados vários
comandos, que em sua maioria influenciam diretamente na performance. A seguir são tratados
alguns desses comandos.

1.1.1 Join

Um join combina colunas de duas ou mais tabelas se as linhas possuírem campos de


correspondência, tornando possível buscar os dados da tabela A referente ao registro 1 da
51

tabela B. Uma vez que a integridade é garantida pelo sistema gerenciador de banco de dados,
o join torna-se um recurso importante dos sistemas relacionais, pois elimina a necessidade de
ter informações repetidas nas tabelas, porque busca os dados sempre na tabela original.

O SQL suporta dois tipos de junções:

• Inner Join: que retorna todos os pares com correspondentes de linhas das duas
tabelas e descarta as linhas sem correspondentes em ambas as tabelas.
• Outer Join: retorna todas as linhas normalmente retornadas pela operação inner
join, mais as linhas da tabela esquerda ou da direita que atendam à condição.

Em se tratando de desempenho, é um dos maiores delimitadores, uma vez que o


sistema precisa de um tempo razoável para relacionar as tabelas envolvidas.

Desta forma, o desempenho do SGBD é diretamente ligado ao seu otimizador e a


forma que esse utilizará para executar o select requerido, se essa for escrita de maneira
otimizada.

1.1.2 Ordenação das operações na cláusula WHERE

A cláusula where permite retornar linhas para as quais a expressão designada é


avaliada como verdadeira. No caso da operação DELETE são excluídas, no caso da expressão
UPDATE são atualizadas.

Portanto, a ordenação das operações em uma cláusula where interfere diretamente no


desempenho de uma consulta, uma vez que os diferentes SGBD’s não avaliam a cláusula
where da mesma maneira.

1.1.3 Order By

A cláusula Order By é um elemento opcional da consulta que permite especificar a


ordem em que as linhas são retornadas, porém interfere diretamente no desempenho. O
melhor caminho para busca, que pode tornar a consulta mais rápida, depende do otimizador.

Com o uso do Order By o sistema ordena a consulta de acordo com os critérios


especificados na query. Desse modo, se a busca já for ordenada com a utilização dos índices,
o sistema não terá que ordenar o resultado.
52

1.1.4 Comandos de soma

Os comandos de sumarização, como o group by, que tem função de agrupar


resultado em subconjuntos que possuem valores correspondentes em uma ou mais colunas,
count, que conta quantos registros são retornados, sum, que retorna a soma dos registros, min,
retorna o registro com valor mínimo e max, que retorna o registro com o valor máximo.
Possuem custo de desempenho, pois agrupam o resultado de acordo com os critérios
especificados na query e calculam as funções definidas. Depende-se novamente do otimizador
do SGBD, que deverá escolher o caminho mais curto para executar o select.

1.1.5 Subselects

Ao se referir aos Subselects, tratam-se de consultas realizadas dentro de outras


consultas. Processo que se faz necessário no momento de conectar o valor de uma coluna com
um conjunto de valores retornados em uma outra consulta.

Por se tratar de duas consultas, tem um impacto negativo no desempenho de uma


query, na busca do melhor desempenho, deve ser utilizado com cuidado. Mais uma vez, o
otimizador do SGBD tem grande importância na eficiência de sua execução.

1.1.6 Union

O operador union computa o conjunto formado pela união das linhas retornadas
pelos comandos select envolvidos na consulta. Uma linha está presente no conjunto dos
dois conjuntos de resultados se estiver presente em pelo menos um dos dois conjuntos de
resultados. Os dois comandos select que representam os operadores diretos do operador
union devem produzir o mesmo número de colunas, e as colunas correspondentes devem ser
de tipos de dados compatíveis.

O resultado do comando union contém linhas duplicadas quando a opção all for
especificada.

Pelo fato de influenciar diretamente no resultado da query, o otimizador do SGBD


tem grande importância na eficiência de sua execução.
53

1.1.7 Distinct

A cláusula distinct tem a função de eliminar os dados duplicados entre as linhas


retornadas na consulta, preservando apenas a primeira linha de cada conjunto de linhas onde
as expressões fornecidas forem iguais.

Este comando também interfere no desempenho da consulta, pois manipula o


resultado em busca de um novo resultado mais resumido e específico. Logo, oferecem
impacto no desempenho da consulta.

1.1.8 Outros comandos

Existem outros comandos que interferem no desempenho de uma consulta, pois de


alguma forma manipulam o resultado dela, em busca de um novo resultado, mais resumido ou
específico. Como exemplo desses comandos é possível citar o intersect, in e exists juntos
com o operador not.

1.2 Otimização

Uma das otimizações mais básicas é manter dados utilizando menor espaço possível,
fornecendo melhoria no desempenho, porque é mais rápida uma vez que a memória principal
é menos usada. A indexação também exige menos recursos se for feita em colunas menores.

São listadas abaixo, técnicas que podem ser importantes na melhoria de performance
na tabela minimizando espaços de armazenagem:

• Utilização de tipos menores sempre que possível;


• Para obter tabelas menores, é importante utilizar tipos inteiros menores sempre
que possível;
• Declaração de colunas como NOT NULL, quando possível. Este recurso representa
o ganho de um bit por coluna;
• Índice primário de uma tabela deve ser o mais curto possível;
• Criação de índices somente quando realmente necessários;

Em algumas situações, pode ser benéfico dividir uma tabela que é varrida
freqüentemente em duas.
54

1.3 Controle de concorrência

O controle de acesso concorrente aos registros dos bancos de dados é um recurso


importante, uma vez que já não é mais a aplicação a responsável pela integridade dos dados.
O controle de concorrência garante o bloqueio, quando necessário, de atualização em uma
mesma aplicação, quando dois usuários tentem alterar e os dados simultaneamente. Nesta
situação, o sistema deve bloquear a alteração do segundo usuário, permitindo que esse apenas
consulte os dados.

O controle de concorrência representa custo ao SGBD, pois requer processamento.


Pode ser feito na tabela utilizada ou no registro, com bloqueio para inclusão, alteração e
deleção no momento da solicitação.

O travamento da tabela é mais simples e também mais rápido, mas o bloqueio de


toda a tabela, pode prejudicar o acesso dos demais usuários aos outros registros dessa tabela.
Para travar apenas o registro que está sendo utilizado, utiliza-se mais tempo, pois se trata de
um processo mais trabalhoso, mas não causa nenhum prejuízo no acesso dos demais usuários
aos outros registros dessa tabela.

1.4 INSERT, UPDATE e DELETE

Os comandos insert, update e delete alteram o conteúdo do banco de dados, logo,


tem impacto no desempenho do SGBD, pois em cada alteração são utilizados recursos que
podem comprometer o desempenho do banco.

O custo ao SGBD ocorre quando, por exemplo, uma tarefa exigir a validação de
regras definidas para o registro que será atualizado, como check constraints, registros
dependentes ou validação de chave primária, ou quando a tabela que terá os registros
atualizados possuir índices. O acesso simultâneo dos dados dispara o controle de
concorrência, que também tem influência no desempenho do SGBD.

1.5 Trigger’s

Conforme já mencionado nas seções 2.3.3 e 3.3.3, uma trigger (gatilho) permite que
uma determinada seqüência de comandos seja acionada na ocorrência de algum evento que
pode ser um update, insert ou delete. Sua importância justifica-se pelo fato de ser uma
rotina que pode ser executada automaticamente a cada alteração determinada pelo
programador, poupando-lhe o trabalho de incorporar a ação à aplicação e tecnicamente é mais
55

rápida que uma execução controlada pela aplicação. Porém, deve-se avaliar o custo da
execução e do controle desses processos para o SGBD, e também qual a diferença no custo de
desempenho que uma trigger representa de um SGBD para outro.

1.6 Views

Uma view (visão) é uma tabela virtual utilizada para recuperação e manipulação de
dados, não possui linhas próprias e não armazena dados, os obtém em tempo de execução
disponibilizando as linhas em memória, conforme já citado nos capítulos 2.3.4, 3.3.4 e 4.3.4.

O comportamento do SGBD pode sofrer influência quando a execução de uma view


for simultânea a um processo de consulta, inserção, alteração ou deleção, fazendo-se
necessária a simulação.

1.7 Tamanho do Banco de Dados

O tamanho do banco de dados é outro fator que pode causar diferença na


performance do SGBD avaliado. A tendência de o sistema apresentar problemas na
manipulação de um grande volume de dados é menor quando se trata de um SGBD completo
e robusto.

Sendo assim, o capítulo apresentou os critérios utilizados nos testes deste estudo.
Foram descritos alguns conceitos e retomados outros já mencionados em capítulos anteriores.
Finalmente, o próximo capítulo trata dos detalhes referentes ao experimento realizado nesta
pesquisa.
6 AMBIENTE DE TESTES

Nesse capítulo são descritos o ambiente utilizado para os testes, os passos para a sua
montagem e as dificuldades encontradas para que fosse possível instalar e configurar as bases
de dados. Criou-se uma base de dados que é utilizada pelos SGBD’s, com instalação em
Windows XP Professional.

1.8 Arquitetura do ambiente de testes

O ambiente de testes é composto por dois microcomputadores, conectados por uma


rede de 100 Mbps. Um foi definido como servidor, ficando dedicado aos SGBD’s. Cabe
ressaltar que cada SGBD é executado isoladamente. No servidor foi instalado o sistema
operacional Windows XP Professional com o sistema de arquivos NTFS.

Na estação são executados os softwares para a execução dos testes. Para o SQL
Server é utilizado o software Query Analyzer. O MySQL disponibiliza uma ferramenta Shell
SQL simples denominada mysql, que é utilizada na pesquisa. Para o Oracle é utilizado o
PL/SQL Developer 4.0.0.395. Na estação está instalado unicamente o sistema operacional
Windows XP Home Edition.

Na Figura 8 está representada a estrutura do ambiente de testes e na Tabela 1 a


configuração de cada microcomputador utilizado nos testes.
57

Figura 11: Estrutura do Ambiente de Testes.

Tabela 1: Configuração das Máquinas.

Computador Configuração
Servidor Processador AMD Athlon 2000+
Memória 512MB RAM DDR 266, HD 80 GB 7.200
RPM, Windows XP Professional
Computador Processador AMD Duron 750 MHz
Memória 256MB RAM PC 133, HD 20 GB 5.400
RPM, Windows XP Home Edition
SGBD’s ORACLE - Versão Oracle 9i
SQL Server - Versão SQL Server 2000
MySQL - Versões MySQL 3.23 e MySQL5.0
58

1.9 Instalação dos SGBDRs

Após ter sido instalado o Windows no servidor, o próximo passo foi a instalação dos
SGBD’s, que transcorreu de forma tranqüila.

Nos próximos tópicos são relatadas algumas particularidades de cada SGBD.

1.9.1 MySQL

A instalação do MySQL foi simples tanto na Versão 3.23 quanto na Versão 5.0, sendo
esse um SGBD enxuto que tem como uma de suas principais características a simplicidade.
As duas versões possuem um instalador de fácil utilização, sendo que esse já vem
compilado e adiciona automaticamente um script de inicialização do SGBD ao carregar o
sistema operacional.

1.9.2 SQL Server

A instalação do SQL Server no sistema operacional Windows foi simples. O único


fato que dificultou a instalação e configuração do SQL Server, é que ele vem bloqueado para
o acesso em rede, exigindo sua configuração inicial.

1.9.3 Oracle

A instalação do Oracle transcorreu de forma tranqüila. Uma característica que deve


ser levada em consideração ao instalar e carregar as bases de dados é a estrutura do banco de
dados. O Oracle inicia um serviço, alocando no mínimo cerca de 100 MB de memória RAM
para cada BD disponível para o uso do sistema. Ou seja, se o sistema for configurado para
iniciar uma base na inicialização do sistema operacional, o mesmo teria 100 MB da sua
memória comprometida somente com a base, desconsiderando a carga do próprio SGBD e
dos outros dispositivos do sistema operacional. Logo, optou-se por iniciar somente uma BD
para testes do Oracle, evitando que o computador utilize a memória virtual e comprometa o
desempenho.

1.10 Criação das bases de dados

A próxima etapa da criação do ambiente de testes foi definir a estrutura e popular a


base de dados. Para isso, foi utilizada parte de uma base de dados existente com mais de 300
tabelas. Destas foram aproveitadas somente 10, uma vez que, seria desnecessário ter um
59

número muito grande de tabelas, na escolha foram priorizadas tabelas com um grande número
de registros.

As tabelas fazem parte de um módulo de controle de estoque de empresa produtora


de calçados. A tabela central é a ITEM_ESTOQUE, onde é gravado o cadastro de cada item.
Todas as outras tabelas, de alguma forma, direta ou indiretamente, se relacionam com essa.

O modelo relacional da base de dados utilizada nos testes está na Figura 9.

Figura 12: Modelo Relacional da base de testes.

Na Tabela 2 está a base criada, com as suas tabelas e números de registros. Sendo
que a base de dados sugerida representa uma base de médio porte.

Tabela 2: Base de dados Media.

TABELAS REGISTROS
60

TIPO 5
ITEM_VENDIDO 370.322
ESTOQUE 120.133
GRUPO 5
GRUPO_DESCONTO 12
INDISPONIVEL 253
ITEM_ESTOQUE 100.863
ITEM_INVENTARIO 10.500
ITEM_PEDIDO 16.433
ITEM_RELACAO 112.112
ITEM_REVENDA 16.958
ITEM_SUBSTITUIDO 56

Na Tabela 3 estão as chaves primárias e únicas das tabelas utilizadas. A Tabela 4


mostra todos os índices da base de dados.

Tabela 3: Chaves Primárias e Chaves Únicas.


Chave Tabela Campos Prim/
Única
TIPO_PK TIPO EMPRESA
P
CATEGORIA
ITEM_VEND_PK ITEM_VENDIDO EMPRESA
REVENDA
ITEM_ESTOQUE P
ANO
MÊS
ESTOQUE_PK ESTOQUE EMPRESA
REVENDA
ITEM_ESTOQUE P
ANO
MÊS
GRUPO_PK GRUPO MARCA
P
GRUPO
INDISPONIVEL_PK INDISPONIVEL EMPRESA
REVENDA
P
ITEM_FABRICA
DTA_INDISPONIBILIDADE
ITEM_ESTO_PK ITEM_ESTOQUE EMPRESA
P
ITEM_ESTOQUE
ITEM_INVENT_PK ITEM_INVENTARIO EMPRESA
REVENDA P
ITEM_ESTOQUE
ITEM_PED_PK ITEM_PEDIDO EMPRESA
REVENDA
P
PEDIDO
ITEM_ESTOQUE
ITEM_RELACAO_PK ITEM_RELACAO EMPRESA
P
ITEM_PUBLICO
ITEM_REVENDA_PK ITEM_REVENDA EMPRESA
REVENDA P
ITEM_ESTOQUE
SUBSTITUIDO_PK ITEM_SUBSTITUIDO EMPRESA
ITEM_ESTOQUE P
DTA_ALTERACAO

Tabela 4: Índices.
Índice Tabela Campos Único
61

Fk_Indisponivel Indisponivel Empresa


Item_Fabrica 
Indispo_Contato_Fk Indisponivel Empresa
Revenda
Contato

Indisponível_Pk Indisponível Empresa
Revenda
Item_Fabrica 
Dta_Indisponibilidade
Index Tipo_Pk Tipo Empresa
Categoria 
Item_Vendido_Fk Item_Vendido Empresa
Revenda
Item_Estoque

Index Item_Vendido_Pk Item_Vendido Empresa
Revenda
Item_Estoque
Ano

Mes
Estoque_Fk Estoque Empresa
Revenda
Item_Estoque

Estoque_inic_Pk Estoque Empresa
Revenda
Item_Estoque
Ano

Mes
Grupo_desc_Pk Grupo_Desconto Grupo_Desconto

Index Grupo_Pk Grupo Marca, Grupo

Item_Est_Item_Fk Item_Estoque Grupo_Desconto

Itemes_itemest_Substit_Fk Item_Estoque Empresa
Item_Estoque_Substituto 
Itemest_Codfabricante_Uk Item_Estoque Empresa
Item_Estoque_Pub 
Itemest_Tipo_Fk Item_Estoque Empresa
Categoria 
Itemest_Grupo_Fk Item_Estoque Marca
Grupo 
Itemest_Itemest_Fk Item_Estoque Empresa
Item_Estoque_Anterior 
Index Itemest_Pk Item_Estoque Empresa
Item_Estoque 
Iteminv_Itemrev_Fk Item_Inventario Empresa
Revenda
Item_Estoque

Index Iteminv_Pk Item_Inventario Empresa
Revenda
Item_Estoque

Itemped_Itemest_Fk Item_Pedido Empresa
Item_Estoque 
Index Itemped_Pk Item_Pedido Empresa
Revenda
Pedido 
Item_Estoque
Itemrel_Itemest_Fk Item_Relacao Empresa
Item_Estoque 
Index Itemrel_Pk Item_Relacao Empresa
Item_Publico 
Itemrev_Itemest_Fk Item_Revenda Empresa
Item_Estoque 
Itemrev_Pk Item_Revenda Empresa
Revenda
Item_Estoque

Itemsub_Itemest_Fk Item_Substituido Empresa
Item_Estoque 
Itemsub_Pk Item_Substituido Empresa
Item_Estoque
Dta_Alteracao

7 EXECUÇÃO DOS TESTES

O principal objetivo desse trabalho é aplicar o que foi estudado, observando os


resultados dos critérios de avaliação citados no capítulo 5 e em quais SGBD’s é obtido o
melhor desempenho. Esse capítulo descreve os testes realizados seguindo os critérios
definidos por Pletsch (2005) em seu trabalho.

1.11 Os Testes

Assim como na pesquisa apresentada por Pletsch (ibidem), na execução dos testes
seguiu-se uma metodologia definida de forma a não benificiar apenas um dos SGBD’s,
obtendo-se assim, resultados imparciais. Para evitar esse tipo de ocorrência, foi seguida a
seguinte metodologia:

 Cada um dos testes foi executado 5 vezes, realizando-se a média dessas execuções,
com o intuito de se evitar o comprometimento do resultado em virtude de um
resultado ruim ou bom. Totalizados todos os testes realizados, tem se um resultado
com centenas de execuções, com testes que duram de milésimos de segundos até
horas;
 Sempre que um SGBD é testado, tem-se somente esse SGBD ativo no sistema,
para garantir que outros aplicativos não interfiram no desempenho do teste em
questão;
 A cada nova bateria de testes, como na troca dos testes de deletes para updates,
é reiniciada a máquina servidora, para evitar que alguma informação encontrada na
memória interfira no resultado. Porém, durante a bateria de testes, como na troca
do primeiro teste de delete para o segundo, não é reiniciada a máquina servidora,
pois assim também é testada a capacidade de recuperação rápida de uma
63

informação que foi solicitada recentemente, o que é uma realidade nos ambientes
computacionais;
 O Banco de Dados originalmente está otimizado pelos aplicativos de otimização
de cada SGBD;
 Antes de executar um novo tipo de testes, é restaurada a base de dados no seu
estado original. Isto porque, mesmo fazendo o rollback após os comandos que
alteram algo na base de dados, em alguns SGBD’s isso afeta o desempenho das
consultas futuras, em virtude da área de rollback deixada pela transação anterior;
 Todos os testes estão representados em segundos.

1.12 Selects

Os testes foram iniciados baseados no comando select. Foram efetuados 6


selects, executados individualmente e obtido a sua média na base de dados utilizada para o
teste.

Alguns SGBD’s disponibilizam um recurso que mostra os primeiros resultados


obtidos antes que a consulta esteja concluída, dando a impressão de que o comando tenha sido
concluído antes de realmente ter completado a pesquisa. Para se evitar problemas com este
recurso, em todas as selects desenvolvidas é utilizada em sua estrutura a cláusula count(*),
order by ou group by, isso para evitar que os resultados dos testes sejam influenciados por
esse recurso. A cláusula count faz com que o sistema conte todos os registros atingidos pela
select, a cláusula order by ordena o resultado e o group by agrupa os resultados de acordo
com os critérios estipulados na select. Todas essas clausulas exigem que a consulta esteja
encerrada para exibir o seu valor.

Nos testes foram testados recursos como join, left outer join, right outer
join, group by, order by, subquerys, concatenação de campos e comandos de
sumarização, como count e sum. Como não é possível desenvolver uma consulta que teste
exclusivamente um recurso, procurou-se distribuir os recursos de maneira coerente entre as
selects.

1.12.1 Select 1

A primeira select tem como objetivo testar um join entre tabelas, junto com o
comando group by e o de sumarização sum. Ele utiliza 4 tabelas ligadas entre si com chaves
64

estrangeiras, percorrendo os registros na base de dados. A primeira select está apresentada


na Figura 13.
1) select EI.revenda
2) , T.des_categoria
3) , sum(EI.val_estoque) TOTAL
4) from ITEM_ESTOQUE IE,
5) ESTOQUE E,
6) TIPO T,
7) ITEM_REVENDA IR
8) where IR.empresa = E.empresa
9) and IR.revenda = E.revenda
10) and IR.item_estoque = E.item_estoque
11) and IE.empresa = IR.empresa
12) and IE.item_estoque = IR.item_estoque
13) and T.empresa = IE.empresa
14) and T.categoria = IE.categoria
15) group by EI.revenda
16) , T.des_categoria;

Figura 13: Select 1.

Tendo em vista os resultados desse select, pode-se observar a deficiência do da


versão MySQL 3.23 em trabalhar com grandes volumes de dados e também a superioridade
do Oracle nessas condições. Observou-se também resultados bastante próximos entre MySQL
5.0 e SQL server. Os resultados da execução dessa select estão representados na Tabela 5.

Tabela 5: Resultado dos Testes da Select 1.

Consulta Oracle SQL Server MySQL 5.0 MySQL 3.23


Select 1 2,030 7,13 9,003 53,630

1.12.2 Select 2

O segundo teste é baseado no primeiro select, também tem como objetivo testar um
join entre tabelas, mas nessa não é utilizado o group by, ao invés disso, foi utilizado o
comando count. Adicionou-se mais uma tabela na select, como pode ser observado na linha
6 da Figura 10, totalizando 5 tabelas ligadas entre si com chaves estrangeiras, sendo que as
duas maiores tabelas da base de dados estão nessa consulta. A segunda select está
apresentada na Figura 14.
65

1) select count(*) TOTAL


2) from ITEM_ESTOQUE IE,
3) ESTOQUE E,
4) TIPO T,
5) ITEM_REVENDA IR,
6) ITEM_VENDIDO IV
7) where IR.empresa = E.empresa
8) and IR.revenda = E.revenda
9) and IR.item_estoque = E.item_estoque
10) and IE.empresa = IR.empresa
11) and IE.item_estoque = IR.item_estoque
12) and IV.empresa = IR.empresa
13) and IV.revenda = IR.revenda
14) and IV.item_estoque = IR.item_estoque
15) and T.empresa = IE.empresa
16) and T.categoria = IE.categoria;

Figura 14: Select 2.

Os resultados dessa select demonstram a deficiência do MySQL 3.23 em manejar


com volumes de dados maiores e também a superioridade do Oracle nessas condições.
Observou-se mais uma vez a superioridade da versão do MySQL 5.0, retornando resultados
num tempo bastante próximo ao SQL Server. Os resultados da execução dessa select estão
representados na Tabela 6.

Tabela 6: Resultado dos Testes da Select .

Consulta Oracle SQL Server MySQL 5.0 MySQL 3.23


Select 2 9,108 24,106 24,209 70,235

1.12.3 Select 3

Na terceira select são utilizadas 4 tabelas, sendo que todas são de pequeno ou
médio porte, com nenhuma a ultrapassando 130.000 registros. Nessa consulta é utilizado o
comando order by para garantir a execução completa da consulta antes de exibir os
resultados. A terceira select está representada na Figura 15. A Figura 16 ilustra o plano de
execução desta consulta.
66

select ir.empresa
, ir.revenda
, ir.item_estoque
, ir.val_estoque
, gd.pct_desconto
, t.des_categoria
from ITEM_REVENDA IR,
ITEM_ESTOQUE IE,
GRUPO_DESCONTO GD,
TIPO T
where IR.empresa = IE.empresa
and IR.item_estoque = IE.item_estoque
and IE.grupo_desconto = GD.grupo_desconto
and IE.empresa = T.empresa
and IE.categoria = T.categoria
order by IR.empresa
, IR.revenda
, IR.item_estoque;

Figura 15: Select 3.

Nos resultados dessa select, novamente é observada uma deficiência do MySQL


3.23, sendo que Oracle mais uma vez esteve na frente, seguido pelo SQL Server. Neste teste a
versão do MySQL 5.0 obteve resultados mais próximos aos resultados do MySQL 3.23. O
resultado pode ser explicado pelo plano de execução da consulta, uma vez que tanto na versão
MySQL 3.23 quanto na versão MySQL 5.0 os índices da tabela ITEM_ESTOQUE não foram
utilizados. Os resultados da execução dessa select estão representados na Tabela 7.

Figura 16: Plano de execução Select 3.

Tabela 7: Resultado dos Testes da Select 3.

Consulta Oracle SQL Server MySQL 5.0 MySQL 3.23


Select 3 0,555 3,102 5,298 5,630

1.12.4 Select 4
67

Na quarta select são utilizadas 5 tabelas, sendo que todas são de pequeno ou médio
porte, com nenhuma ultrapassando 120.000 registros. A estrutura dessa consulta é semelhante
a select 3, porém nessa não foi utilizado o order by, diferente disso, foi utilizado o
comando count. A quarta select está representada na Figura 17.
1) select count(*)
2) from ITEM_REVENDA IR,
3) ITEM_ESTOQUE IE,
4) GRUPO_DESCONTO GD,
5) TIPO T,
6) GRUPO GR
7) where IR.empresa = IE.empresa
8) and IR.item_estoque = IE.item_estoque
9) and IE.grupo_desconto = GD.grupo_desconto
10) and IE.empresa = T.empresa
11) and IE.categoria = T.categoria
12) and IE.marca = GR.marca
13) and IE.grupo = GR.grupo;

Figura 17: Select 4.

Nos resultados dessa select novamente é observada uma deficiência da versão do


MySQL 3.23 na base de dados utilizada, sendo que Oracle mais uma vez esteve na frente. Os
resultados obtidos pela versão do MySQL 5.0 estão próximas aos resultados do SQL Server.
Os resultados da execução dessa select estão representados na Tabela 8.

Tabela 8: Resultado dos Testes da Select 4.

Consulta Oracle SQL Server MySQL 5.0 MySQL 3.23


Select 4 0,465 1,238 1,998 3,230

1.12.5 Select 5

A quinta select utiliza 5 tabelas, sendo que todas são de pequeno ou médio porte,
com nenhuma a ultrapassar 120.000 registros. Nessa consulta é utilizado o comando order
by para garantir a execução completa da consulta antes de exibir os resultados. Também é
testado nessa consulta o uso do comando left outer join. A quinta select está
representada na Figura 18.
68

1) select IE.empresa
2) , IE.item_estoque
3) , GR.des_grupo,
4) IN.dta_indisponibilidade,
5) IN.quantidade
6) from ITEM_RELACAO IR,
7) GRUPO GR,
8) INDISPONÍVEL IN,
9) ITEM_ESTOQUE IE left outer join
10) ITEM_PEDIDO IP on
11) (IE.empresa = IP.empresa
12) and IE.item_estoque = IP.item_estoque)
13) where IE.empresa = 1
14) and IE.empresa = IR.empresa
15) and IE.item_estoque = IR.item_estoque
16) and GR.marca = IE.marca
17) and GR.grupo = IE.grupo
18) and IN.empresa = IE.empresa
19) and IN.item_fabrica = IE.item_estoque_pub
20) order by IE.empresa
21) , IE.item_estoque;

Figura 18: Select 5.

Nos resultados dessa select novamente é observada uma deficiência do MySQL


3.23 na base de dados utilizada, sendo que Oracle mais uma vez esteve na frente. Mais uma
vez os resultados do MySQL 5.0 estiveram bem próximos dos resultados do SQL Server. Os
resultados da execução dessa select estão representados na Tabela 9.

Tabela 9: Resultado dos Testes da Select 5.

Select Oracle SQL Server MySQL 5.0 MySQL 3.23


Select 5 1,203 2,207 3,753 4,029

1.12.6 Select 6

A sexta select utiliza 5 tabelas, sendo que todas são de pequeno ou médio porte,
com nenhuma a ultrapassar 120.000 registros. A estrutura dessa consulta é semelhante a
select 5, porém nessa não foi utilizado o order by, diferente disso, foi utilizado o comando
count. A sexta select está representada na Figura 19.
69

1) select count(*)
2) from ITEM_RELACAO IR,
3) GRUPO GR,
4) INDISPONIVEL IN,
5) ITEM_ESTOQUE IE left outer join
6) ITEM_PEDIDO IP on
7) (IE.empresa = IP.empresa
8) and IE.item_estoque =
IP.item_estoque)
9) where IE.empresa = 1
10) and IE.empresa = IR.empresa
11) and IE.item_estoque = IR.item_estoque
12) and GR.marca = IE.marca
13) and GR.grupo = IE.grupo
14) and IN.empresa = IE.empresa
15) and IN.item_fabrica = IE.item_estoque_pub;

Figura 19: Select 6.

Os resultados dessa select demonstram praticamente o mesmo que a select 5, com


uma pequena melhora no desempenho em todos os SGBD’s, demonstrando que o comando
count possui um menor custo em termos de desempenho que o order by. Os resultados da
execução dessa select estão representados na Tabela 10.

Tabela 10: Resultado dos Testes da Select 6.

Select Oracle SQL Server MySQL 5.0 MySQL 3.23


Select 5 0,896 2,006 2,103 3,882

1.12.7 Selects – Resumo dos Resultados

Os selects demonstram a superioridade do SGBD Oracle sobre os demais sistemas,


sendo que ele foi superior em quase todos os testes. O SQL Server e o MySQL 5.0
demonstraram um bom desempenho se comparados com o MySQL 3.23, que obteve
resultados inferiores aos demais.

1.13 Deletes

O segundo teste realizado é o de deletes sem acesso concorrente. Essa seção é


composta por 10 deletes, todos sendo executados em seqüência e obtendo-se a média na base
de dados utilizada para o teste. A decisão de fazer a execução dos 10 deletes seqüencialmente
e não uma execução para cada delete foi tomada pela rapidez que esses comandos eram
executados na base de dados, conforme também mencionado por Pletsch (2005), o que torna
muito difícil a análise do seu tempo. Na Tabela 11 estão descritos todos os deletes executados
nesse ponto dos testes.
70

Tabela 11: Teste de Deletes.

Nº. Delete
1 1) delete from ITEM_RELACAO
2) where item_relacao.item_estoque in
3) (select IE.item_estoque
4) from ITEM_ESTOQUE IE
5) where item_relacao.empresa = IE.empresa
6) and item_relacao.item_estoque = IE.item_estoque
7) and IE.grupo_desconto <> '*');

2 1) delete from ITEM_INVENTARIO


2) where ITEM_INVENTARIO.item_estoque in
3) (select IR.item_estoque
4) from ITEM_ESTOQUE IE,
5) ITEM_REVENDA IR
6) where IE.empresa = 1
7) and IE.categoria = 10
8) and IE.grupo_desconto <> '*'
9) and ITEM_INVENTARIO.empresa = IR.empresa
10) and ITEM_INVENTARIO.revenda = IR.revenda
11) and ITEM_INVENTARIO.item_estoque = IR.item_estoque
12) and IR.empresa = IE.empresa
13) and IR.item_estoque =
IE.item_estoque);
3 1) delete from ESTOQUEINICIAL
2) where ESTOQUEINICIAL.item_estoque in
3) (select IR.item_estoque
4) from ITEM_ESTOQUE IE,
5) ITEM_REVENDA IR
6) where IE.empresa = 1
7) and IE.categoria = 10
8) and IE.grupo_desconto <> '*'
9) and ESTOQUE.empresa = IR.empresa
10) and ESTOQUE.revenda = IR.revenda
11) and ESTOQUE.item_estoque = IR.item_estoque
12) and IR.empresa = IE.empresa
13) and IR.item_estoque = IE.item_estoque);

4 1) delete from ITEM_VENDIDO


2) where ITEM_VENDIDO.item_estoque in
3) (select IR.item_estoque
4) from ITEM_ESTOQUE PIE,
5) ITEM_REVENDA PIR
6) where IE.empresa = 1
7) and IE.categoria = 10
8) and IE.grupo_desconto <> '*'
9) and ITEM_VENDIDO.empresa = IR.empresa
10) and ITEM_VENDIDO.revenda = IR.revenda
11) and ITEM_VENDIDO.item_estoque = IR.item_estoque
12) and IR.empresa = IE.empresa
13) and IR.item_estoque =
IE.item_estoque);

5 1) delete from ITEM_REVENDA


2) where ITEM_REVENDA.item_estoque in
3) (select IE.item_estoque
4) from ITEM_ESTOQUE IE
5) where IE.empresa = 1
6) and IE.categoria = 10
71

7) and IE.grupo_desconto <> '*'


8) and ITEM_REVENDA.empresa = PIE.empresa
9) and ITEM_REVENDA.item_estoque = IE.item_estoque);
6 1) Delete from ITEM_PEDIDO
2) where ITEM_PEDIDO.item_estoque in
3) (select IE.item_estoque from ITEM_ESTOQUE IE
4) where IE.empresa = 1
5) and IE.categoria = 10
6) and IE.grupo_desconto <> '*'
7) and ITEM_PEDIDO.empresa = IE.empresa
8) and ITEM_PEDIDO.item_estoque = IE.item_estoque);

7 1) delete from INDISPONIVEL


2) where INDISPONIVEL.item_fabrica in
3) (select IE.item_estoque_pub
4) from ITEM_ESTOQUE IE
5) where IE.empresa = 1
6) and IE.categoria = 10
7) and IE.grupo_desconto <> '*'
8) and INDISPONIVEL.empresa = IE.empresa
9) and INDISPONIVEL.item_fabrica =
IE.item_estoque_pub);

8 1) delete from ITEM_SUBSTITUIDO


2) where ITEM_SUBSTITUIDO.item_estoque in
3) (select IE.item_estoque from ITEM_ESTOQUE IE
4) where IE.empresa = 1
5) and IE.categoria = 10
6) and IE.grupo_desconto <> '*'
7) and ITEM_SUBSTITUIDO.empresa = IE.empresa
8) and ITEM_SUBSTITUIDO.item_estoque = IE.item_estoque);
9 1) delete from ITEM_ESTOQUE
2) where empresa = 1
3) and categoria = 10
4) and grupo_desconto <> '*'
5) and ITEM_ESTOQUE.item_estoque not in
6) (select I2.item_estoque_substituto from item_estoque
I2
7) where ITEM_ESTOQUE.empresa = I2.empresa
8) and ITEM_ESTOQUE.item_estoque =
I2.item_estoque_substituto);

10 1) delete from ESTOQUE


2) where qtd_contabil < 1
3) and ESTOQUE.item_estoque not in
4) (select IR.item_estoque from ITEM_REVENDA IR
5) where ESTOQUE.empresa = IR.empresa
6) and ESTOQUE.revenda = IR.revenda
7) and ESTOQUE.item_estoque = IR.item_estoque
8) and IR.demanda_media > 1);

Através dos deletes é testada a rapidez em apagar os registros da BD e também o


quanto o SGBD precisa em termos de tempo de processamento para controlar que a exclusão
feita não afete a integridade referencial da BASE DE DADOS.

1.13.1 Deletes - Resultados


72

Na base de dados proposta o Oracle foi novamente mais rápido que o SQL Server e o
MySQL, tanto na versão 3.23 quanto na versão 5.0. O que pode ser observado foi que os
resultados dos testes no MySQL 5.0 ainda estão mtuito próximos dos resultados obtidos pelo
SQL Server, observando-se que nos deletes 4 obteve resultado superior ao SQL Server e no
delete 8 observou-se resultado superior tanto do Oracle, quanto do SQL Server. Como pode
ser observado na Tabela 12, que apresenta os resultados dos deletes em segundos:

Tabela 12: Resultados dos Testes de Deletes

Neste stestes foi verificado, que no Oracle há um aumento da tablespace de Undo,


pois ao final da terceira bateria de testes do comando delete, o tamanho dessa tablespace
estava com 6,4 GB enquanto toda a área de dados somada com a área de índices não ocupava
mais de 1 GB. Conforme também observado nos testes feitos por Pletsch (2005). Isso ocorre
pelo fato do Oracle reter a informação de rollback mesmo depois do comando commit ou
rollback ser executado. Com intuito de evitar problemas com o limite do próprio HD,
define-se que a tablespace de Undo poderia ter no máximo 2GB para as base de dados
propostas e o tempo de retenção do Undo foi estipulado 3 minutos após o commit ou
rollback.

1.14 Updates

O terceiro teste realizado é o de updates. Essa parte do teste é composta de 10


updates, todos sendo executados em seqüência e obtendo-se a média na base de dados
proposta para o teste. A decisão de fazer a execução dos 10 updates seqüencialmente e não
uma execução para cada update foi tomada pela rapidez que esses comandos são executados,
73

o que torna muito difícil a análise do se tempo. Na Tabela 13 estão descritos todos os updates
executados nesse ponto dos testes.

Tabela 13: Teste de Updates.

Nº. Update
1 1) update TIPO
2) set des_categoria = 'TESTE DE UPDATE',
3) identificacao = 'A'
4) where empresa = 1
5) and categoria = 10;

2 1) update ITEM_VENDIDO
2) set class_abc = 'A'
3) where demandabalcao + demandaoficina +
demandatelemark > 10;

3 1) update ITEM_VENDIDO
2) set class_abc = 'B'
3) where demandabalcao + demandaoficina +
demandatelemark
4) between 5 and 9;

4 1) update ITEM_VENDIDO
2) set class_abc = 'C'
3) where demandabalcao + demandaoficina +
demandatelemark
4) between 1 and 4;

5 1) update ESTOQUE
2) set val_estoque = 0
3) where ESTOQUE.qtd_contabil < 1
4) and ESTOQUE.item_estoque not in
5) (select IR.item_estoque from ITEM_REVENDA IR
6) where ESTOQUE.empresa = IR.empresa
7) and ESTOQUE.revenda = IR.revenda
8) and ESTOQUE.item_estoque = IR.item_estoque
9) and IR.demanda_media > 5);

6 1) update ITEM_VENDIDO
2) set class_abc = 'D'
3) where demandabalcao + demandaoficina +
demandatelemark < 1;

7 1) update ESTOQUE
2) set preco_publico = preco_publico * 1.15,
3) base_icms_retido = base_icms_retido * 1.15,
4) preco_custo = preco_custo * 1.13
5) where qtd_contabil > 0;
8 1) update ITEM_ESTOQUE
2) set preco_custo = preco_custo * 1.15
3) where ITEM_ESTOQUE.grupo in
4) (select GR.grupo from GRUPO PGR
5) where EC_ITEM_ESTOQUE.marca = PGR.marca
6) and EC_ITEM_ESTOQUE.grupo = PGR.grupo
7) and GR.calc_custo_reposicao = 'S');

9 1) update GRUPO_DESCONTO
74

2) set pct_desconto_venda = pct_desconto;

10 1) update INDISPONIVEL
2) set quantidade = quantidade + 1
3) where contato is null;

Através dos updates é testada a rapidez em alterar os registros da base de dados e


também o quanto o SGBD precisa em termos de tempo de processamento para controlar que a
alteração feita não afete a integridade referencial da base de dados.

1.14.1 Updates - Resultados

Os updates, como os deletes, demonstraram uma superioridade considerável do


Oracle, conforme pode ser observado na Tabela 14.

Tabela 14: Resultados dos Testes de Updates.

Como já descrito anteriormente, foram executadas cinco baterias para cada teste
proposto e no caso de comandos que alteram o conteúdo da base de dados, foi executado o
comando rollback ao final de cada bateria. Nesse momento detectou-se uma anormalidade
tanto no SQL Server quanto no MySQL nas duas versões testadas, pois a última bateria do
comando update ficou muito mais demorada que a primeira, provando que mesmo utilizando
o rollback, é deixado alguma “sujeira” na base de dados, comprometendo o desempenho na
execução de comandos futuros.
75

1.15 Inserts

O quarto teste realizado é o de inserts. O procedimento é composto de 1 script,


com 1.000 inserções, executado em seqüência e obtendo-se a média na base de dados
utilizada para o teste.

Através dos inserts é testada a rapidez em inserir os registros na BD e também o


quanto o SGBD precisa em termos de tempo de processamento para controlar que as
inserções feitas não afetem a integridade referencial e as regras de primary key, unique key
e checks constraints da BD.

1.15.1 Inserts - Resultados

Os inserts demonstram a superioridade do SGBD Oracle sobre os demais sistemas,


sendo que ele foi superior a todos os testes. O SQL Server demonstrou um bom desempenho.
Já o MySQL 5.0 obteve um resultado bastante próximo ao resultado do SQL Server, podendo
ser considerado um bom desempenho, porém o MySQL 3.23, obteve resultados inferiores aos
demais.

Tabela 15: Resultados dos Testes de Inserts.

Observou-se também um tempo superior aos outros testes uma vez que o
processamento transcorreu na máquina cliente e não diretamente no servidor.

1.16 Resultados Finais

Com base nos resultados obtidos em cada um dos testes propostos, pode-se observer
superioridade do SGBD Oracle na maioria dos testes. Num primeiro momento em que se
utilizou apenas a versão MySQL 3.23, observou-se uma diferença muito grande entre os
resultados, sendo que este sempre apresentava desempenho muito inferior tanto ao Oracle
quanto ao SQL Server. Por este motivo, buscou-se a aplicação dos mesmos testes em versão
mais recente do produto.

As mudanças nos resultados foram consideráveis, uma vez que a versão do MySQL
5.0 obteve resultados muito próximos aos resultados obtidos pelos SQL Server. Ou seja,
resultados satisfatórios. Tendo em vista o fato de que a ferramenta MySQL 5.0 é bem mais
76

acessível financeiramente em ralação ao Oracle e ao SQL Server, e que obteve um resultado


inferior, porém parecido, com tais ferramentas, pode ser considerada uma boa opção para
bases de dados com volume próximo à base testada.
CONCLUSÃO

Os SGBD's têm sido escolhidos pelas organizações como meio de armazenamento


para sua base de dados, garantindo integridade e controle de transações, uma vez que a
importância da informação e o volume cada vez maior de dados têm exigido preocupação.
Atualmente existem vários SGBD's no mercado, dentre os quais foram apresentados o Oracle,
o MySQL e o SQL Server. Com o intuito de dar continuidade a pesquisa iniciada por Pletsch
(2005), propôs-se a pesquisa de desempenho de SGBD's.

Os SGBD's têm a sua participação no desempenho total do sistema, pois a maneira


como uma instrução SQL é interpretada pelo otimizador pode fazer diferença no tempo de
execução de um processo. Considerando este fato, julga-se importante avaliar as situações em
que os SGBD's apresentam comportamento diferente em termos de desempenho. Esta
avaliação foi realizada nos SGBD's Oracle, SQL Server e MySQL.

Os resultados apresentaram diferenças consideráveis entre os sistemas. Isso


demonstra que cada otimizador possui uma maneira diferente de avaliar uma determinada
instrução e que não existe um conjunto de regras pré-definidas para uma escrita otimizada de
instruções SQL que pode ser utilizada em todos os SGBD's.

Em termos de desempenho pode-se afirmar que o MySQL 3.23 pode ser considerado
quando a aplicação não envolve grandes volumes de dados, levando em conta a sua facilidade
de uso, o fato de ser gratuito e o desempenho razoável na base de dados médias proposta.

O SQL Server e o MySQL 5.0 obtiveram um resultado satisfatório e bem superior ao


MySQL 3.23, quanto ao seu desempenho, os resultados dos testes aplicados mostraram
diferenças se comparado com o Oracle, mas tais diferenças podem ser desconsideradas
quando da necessidade de se optar por um produto mais barato.
78

O Oracle teve um resultado bom quanto ao seu desempenho em todos os testes


aplicados. Pode ser indicado como a escolha ideal, mas em virtude de seu custo, é
recomendado principalmente para aplicações em organizações que tenham uma base de dados
com grande volume de dados.

As dificuldades encontradas na pesquisa foram na execução dos testes, uma vez que
não existe uma documentação que relata porque um determinado otimizador escolhe um
caminho, ocorrendo casos onde o resultado pode ser diferente do esperado em um
determinado SGBD. Também foram encontradas dificuldades considerando-se que a
pesquisadora não conhecia muitos recursos daa linguagem SQL, assim como o funcionamento
dos SGBD's.

Com base na pesquisa de Pletsch (2005), mais uma vez observou-se superioridade do
SGBD Oracle frente ao demais SGBD's, levando-se em consideração o tamanho da base de
dados utilizada. Como sugestão para trabalhos futuros fica um estudo mais detalhado dos
resultados, detalhando os porquês dos resultados discrepantes (Oracle e MySQL), comparação
dos resultados do Oracle nas duas pesquisas e a inclusão de outros SGBD's nos testes.
REFERÊNCIAS BIBLIOGRÁFICAS

ABBEY, Michael. ABRAMSON, Iam. CORY, Mike. Oracle 9i – Guia Introdutório. Rio de
Janeiro: Campus, 2002.

CYRAN, Michele. Oracle 8i – Designing and Tuning for Performance. Oracle Corporation,
1999.

DATE, C. J. Introdução a Sistemas de Bancos de Dados . Rio de Janeiro: Campus, 1990.

DEVMEDIA, Analisando desempenho de consultas utilizando Oracle SQL Developer .


Disponível em: <http://www.devmedia.com.br/articles/viewcomp.asp?comp=1810>
Acesso em: 18 out. 2006.

DEVMEDIA, Tabelas temporárias no Banco de dados Oracle . Disponível em:


<http://www.devmedia.com.br/articles/viewcomp.asp?comp=1915> Acesso em: 18 out.
2006

ELMASRI, Ramez. NAVATHE, Shamkant. Sistema de Banco de Dados, Person, SP, 2005.

FERREIRA, Paulo; Aula 1- Conceitos Fundamentais, 2006.

GERVAZONI, SQL Server: Views Indexadas. Disponível em: <


http://www.linhadecodigo.com.br/artigos.asp?id_ac=602&pag=2> Acesso em: 15 out.
2006.

GULUTZAN, Peter; PELZER, Trudy. Ajustes de Desempenho em "Consultas Simples" na


SQL . SQL Magazine, Rio de Janeiro: ed. 11, ano 1, p. 24-31, 2004.

GULUTZAN, Peter; PELZER, Trudy. SQL Performance Tuning. New York: Addison-Wesley
, 2002.

GUNDERLOY, Mike, JORDEN, Joseph L. Dominando o SQL Server 2000. São Paulo:
Markon Books, 2001.

HEUSER,Carlos A., Projeto de Banco de Dados, Editora Sagra & Luzzato, Porto Alegre,
1999.

HTMLSTAFF, Teoria Relacional. Disponível em: < http://www.htmlstaff.org/ver.php?id=393


> Acesso em: 23 out. 2006.
IMASTERS, Entendendo tabelas temporárias. Disponível em: <
http://www.imasters.com.br/artigo/3727> Acesso em: 01 nov 2006.

LONEY, Kevin. THERIAULT, Marlene. Oracle 9i: O Manual do DBA . Rio de Janeiro:
Campus, 2002.

KORTH, Henry. SILBERSCHATZ, Abraham. Sistema de Banco de Dados, Marron, SP, 1994.

MACORATTI, SQL Server- Usando a Linguagem de definição de dados . Disponível em:


<http://www.macoratti.net/sql_ddl.htm > Acesso em: 18 out 2006

MACORATTI, SQL-Triggers. Disponível em: < http://www.macoratti.net/sql_trig.htm >


Acesso em: 18 out 2006

MATOS, Gladstone. Guia rápido da SQL. SQL Magazine. Rio de Janeiro: ed. 1, ano 1, p. 08-
11, 2003.

MELLO, Ronaldo S. Banco de Dados I. Disponível em:


<http://www.inf.ufsc.br/~ronaldo/ine5613/1-introducao.pdf > Acesso em: 11 dez 2006

MCDBABRASIL, Otimizando a Utilização de TEMPDB. Disponível em: <


http://www.mcdbabrasil.com.br/modules.php?name=News&file=print&sid=222 > Acesso
em: 20 out. 2006.

MICROSOFT, White Papers Sobre o SQL Server 2005. Disponível em: <
http://www.microsoft.com/brasil/sql/techinfo/whitepapers/default.mspx> Acesso em: 27
out. 2006.

MySQL Manual. Disponível em: < http://dev.mysql.com/doc/mysql/pt/index.html>. Acesso


em: 20 out. 2006.

NIEMIEC, Richard J. Oracle 9i Performance Tuning – Dicas e Técnicas . Rio de Janeiro.


Campus, 2003.

ORACLE CORPORATION. Oracle 9i Database Reference 2(9.2). Redwood Shores: Oracle


Press, 2002.

ORACLE, Technology Products. Disponível em: < http://www.oracle.com> Acesso em: 10


set. 2006.

PLETSCH, Edson Luis. Avaliação de Técnicas de desempenho em Sistemas Gerenciadores de


Bancos de Dados Relacionais. Novo Hamburgo: 2005. Projeto de Diplomação
(Bacharelado em Ciência da Computação) – ICET Feevale, 2005.

REZENDE, Ricardo. Conceitos Fundamentais de Banco de Dados – Parte 2 . Disponível em:


<http://www.sqlmagazine.com.br/Colunistas/RicardoRezende/03_ConceitosBD_P2.asp>.
Acesso em: 01 nov. 2006

SOUKUP, Ron. Desvendando o Microsoft SQL Server 6.5 . Rio de Janeiro: Campus, 1998.
SQL SERVER, Microsoft. SQL Server 2000 Descrição Geral . Disponível em:
<http://www.microsoft.com/portugal/sql/evaluation/overview/default.mspx>. Acesso em:
16 set. 2006.

SUEHRING, Steve. MySQL, a Bíblia. Rio de Janeiro: Elsevier, 2002.

UFPA, Orientação a Objetos. Disponível em: <


http://cultura.ufpa.br/clima/bdoo/tutorial_marta.pdf > Acesso em: 23 out. 2006.
UNIOESTE, Uma reflexão sobre Banco de Dados Orientados a Objetos. Dispinível em: <
http://conged.deinfo.uepg.br/artigo4.pdf > Acesso em: 20 out 2006.
WILDT, Daniel. SQL – Desvendando os comandos Insert, Delete e Update. SQL Magazine,
Rio de Janeiro: ed. 2, ano 1, p. 11-13, 2003.

WIKIPEDIA, SMP. Poll de conexões. OS/2. Disponível em: < http://www.wikipedia.com.br>


Acesso em: 10 out 2006.

WIKIPEDIA, OPENSOURCE. Disponível em: <pt.wikipedia.org/wiki/Open_Source>.


Acesso em: 20 dez 2006.