Desempenho_sgbd

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 minicomputadores 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) 2) 3) 4) 5)

7

SQL> create global temporary table TEMP_PROD (cod_prod number(5), desc_prod varchar2(30), dat_cadas date) on commit preserve rows; Table created.

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

8

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) 3)

(select codprod, 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;

•

13

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

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 (ebusiness) 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 bemsucedido 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 Servidor Computador SGBD’s

Configuração Processador AMD Athlon 2000+ Memória 512MB RAM DDR 266, HD 80 GB 7.200 RPM, Windows XP Professional Processador AMD Duron 750 MHz Memória 256MB RAM PC 133, HD 20 GB 5.400 RPM, Windows XP Home Edition 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 ITEM_VENDIDO ESTOQUE GRUPO GRUPO_DESCONTO INDISPONIVEL ITEM_ESTOQUE ITEM_INVENTARIO ITEM_PEDIDO ITEM_RELACAO ITEM_REVENDA ITEM_SUBSTITUIDO

5 370.322 120.133 5 12 253 100.863 10.500 16.433 112.112 16.958 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

TIPO_PK

TIPO

ITEM_VEND_PK

ITEM_VENDIDO

ESTOQUE_PK

ESTOQUE

GRUPO_PK

GRUPO

INDISPONIVEL_PK

INDISPONIVEL

ITEM_ESTO_PK

ITEM_ESTOQUE

ITEM_INVENT_PK

ITEM_INVENTARIO

ITEM_PED_PK

ITEM_PEDIDO

ITEM_RELACAO_PK

ITEM_RELACAO

ITEM_REVENDA_PK

ITEM_REVENDA

SUBSTITUIDO_PK

ITEM_SUBSTITUIDO

Campos EMPRESA CATEGORIA EMPRESA REVENDA ITEM_ESTOQUE ANO MÊS EMPRESA REVENDA ITEM_ESTOQUE ANO MÊS MARCA GRUPO EMPRESA REVENDA ITEM_FABRICA DTA_INDISPONIBILIDADE EMPRESA ITEM_ESTOQUE EMPRESA REVENDA ITEM_ESTOQUE EMPRESA REVENDA PEDIDO ITEM_ESTOQUE EMPRESA ITEM_PUBLICO EMPRESA REVENDA ITEM_ESTOQUE EMPRESA ITEM_ESTOQUE DTA_ALTERACAO

Prim/ Única P

P

P

P P P P

P P P P

Tabela 4: Índices. Índice

Tabela

Campos

Único

61 Fk_Indisponivel

Indisponivel

Grupo_desc_Pk

Grupo_Desconto

Empresa Item_Fabrica Empresa Revenda Contato Empresa Revenda Item_Fabrica Dta_Indisponibilidade Empresa Categoria Empresa Revenda Item_Estoque Empresa Revenda Item_Estoque Ano Mes Empresa Revenda Item_Estoque Empresa Revenda Item_Estoque Ano Mes Grupo_Desconto

Indispo_Contato_Fk

Indisponivel

Indisponível_Pk

Indisponível

Index Grupo_Pk

Grupo

Marca, Grupo

Item_Est_Item_Fk

Item_Estoque

Grupo_Desconto

Itemes_itemest_Substit_Fk

Item_Estoque

Itemest_Codfabricante_Uk

Item_Estoque

Itemest_Tipo_Fk

Item_Estoque

Itemest_Grupo_Fk

Item_Estoque

Itemest_Itemest_Fk

Item_Estoque

Index Itemest_Pk

Item_Estoque

Iteminv_Itemrev_Fk

Item_Inventario

Index Iteminv_Pk

Item_Inventario

Itemped_Itemest_Fk

Item_Pedido

Index Itemped_Pk

Item_Pedido

Empresa Item_Estoque_Substituto Empresa Item_Estoque_Pub Empresa Categoria Marca Grupo Empresa Item_Estoque_Anterior Empresa Item_Estoque Empresa Revenda Item_Estoque Empresa Revenda Item_Estoque Empresa Item_Estoque Empresa Revenda Pedido Item_Estoque Empresa Item_Estoque Empresa Item_Publico Empresa Item_Estoque Empresa Revenda Item_Estoque Empresa Item_Estoque Empresa Item_Estoque Dta_Alteracao

Index Tipo_Pk

Tipo

Item_Vendido_Fk

Item_Vendido

Index Item_Vendido_Pk

Item_Vendido

Estoque_Fk

Estoque

Estoque_inic_Pk

Estoque

Itemrel_Itemest_Fk

Item_Relacao

Index Itemrel_Pk

Item_Relacao

Itemrev_Itemest_Fk

Item_Revenda

Itemrev_Pk

Item_Revenda

Itemsub_Itemest_Fk

Item_Substituido

Itemsub_Pk

Item_Substituido

                          

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) 2) 3) 4) 5) 6) 7) 8) 9) 10) 11) 12) 13) 14) 15) 16)

select , , from

EI.revenda T.des_categoria sum(EI.val_estoque) TOTAL ITEM_ESTOQUE IE, ESTOQUE E, TIPO T, ITEM_REVENDA IR where IR.empresa = E.empresa and IR.revenda = E.revenda and IR.item_estoque = E.item_estoque and IE.empresa = IR.empresa and IE.item_estoque = IR.item_estoque and T.empresa = IE.empresa and T.categoria = IE.categoria group by EI.revenda , 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 Select 1

Oracle 2,030

SQL Server 7,13

MySQL 5.0 9,003

MySQL 3.23 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 Select 2

Oracle 9,108

SQL Server 24,106

MySQL 5.0 24,209

MySQL 3.23 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 , , , , , from

where and and and and order , ,

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

IE.empresa IE.item_estoque GD.grupo_desconto T.empresa T.categoria

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 Select 3

1.12.4 Select 4

Oracle 0,555

SQL Server 3,102

MySQL 5.0 5,298

MySQL 3.23 5,630

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 8) and IR.item_estoque 9) and IE.grupo_desconto 10) and IE.empresa 11) and IE.categoria 12) and IE.marca 13) and IE.grupo

= = = = = = =

IE.empresa IE.item_estoque GD.grupo_desconto T.empresa T.categoria GR.marca 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

Select 4

0,465

SQL Server 1,238

MySQL 5.0 1,998

MySQL 3.23 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) 2) 3) 4) 5) 6) 7) 8) 9) 10) 11) 12) 13) 14) 15) 16) 17) 18) 19) 20) 21)

select IE.empresa , IE.item_estoque , GR.des_grupo, IN.dta_indisponibilidade, IN.quantidade from ITEM_RELACAO IR, GRUPO GR, INDISPONÍVEL IN, ITEM_ESTOQUE IE left outer join ITEM_PEDIDO IP on (IE.empresa = IP.empresa and IE.item_estoque = IP.item_estoque) where IE.empresa = 1 and IE.empresa = IR.empresa and IE.item_estoque = IR.item_estoque and GR.marca = IE.marca and GR.grupo = IE.grupo and IN.empresa = IE.empresa and IN.item_fabrica = IE.item_estoque_pub order by IE.empresa , 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

Select 5

1,203

SQL Server 2,207

MySQL 5.0 3,753

MySQL 3.23 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 Select 5

Oracle 0,896

SQL Server 2,006

MySQL 5.0 2,103

MySQL 3.23 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); 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);

3

4

5

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 7) and IE.categoria 8) and IE.grupo_desconto 9) and ITEM_VENDIDO.empresa 10) and ITEM_VENDIDO.revenda 11) and ITEM_VENDIDO.item_estoque 12) and IR.empresa 13) and IR.item_estoque IE.item_estoque); 1) 2) 3) 4) 5) 6)

delete from ITEM_REVENDA where ITEM_REVENDA.item_estoque in (select IE.item_estoque from ITEM_ESTOQUE IE where IE.empresa = 1 and IE.categoria = 10

= 1 = 10 <> '*' = IR.empresa = IR.revenda = IR.item_estoque = IE.empresa =

71

6

7) and IE.grupo_desconto <> '*' 8) and ITEM_REVENDA.empresa = PIE.empresa 9) and ITEM_REVENDA.item_estoque = IE.item_estoque); 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); 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);

9

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 ser executado. Com intuito de evitar problemas com o limite do próprio HD,

rollback

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) 2) 3) 4) 5)

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) 2) 3) 4) 5) 6) 7) 8) 9)

6

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

7

1) 2) 3) 4) 5) 1) 2) 3) 4) 5) 6) 7)

8

9

update TIPO set des_categoria = 'TESTE DE UPDATE', identificacao = 'A' where empresa = 1 and categoria = 10;

update ESTOQUE set val_estoque = 0 where ESTOQUE.qtd_contabil < 1 and ESTOQUE.item_estoque not in (select IR.item_estoque from ITEM_REVENDA IR where ESTOQUE.empresa = IR.empresa and ESTOQUE.revenda = IR.revenda and ESTOQUE.item_estoque = IR.item_estoque and IR.demanda_media > 5);

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

1) update GRUPO_DESCONTO

74 2) set 10

pct_desconto_venda = pct_desconto;

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: Acesso em: 18 out. 2006. DEVMEDIA, Tabelas temporárias no Banco de dados Oracle . Disponível em: 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 http://www.imasters.com.br/artigo/3727> Acesso em: 01 nov 2006.

em:

<

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: 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. 0811, 2003. MELLO, Ronaldo S. Banco de Dados I. Disponível em: 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: . 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: . 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: . Acesso em: 20 dez 2006.