Estudo Comparativo dos Sistemas Gerenciadores de Bancos de Dados: Oracle, SQL Server e PostgreSQL

Rodrigo de Carvalho Santos, Lus Augusto Mattos Mendes (Orientador) Departamento de Cincias da Computao Faculdade de Cincias da Computao e Comunicao Social (FACICS) Universidade Presidente Antnio Carlos Campus Magnus Campolide MG
rosjdr@gmail.com,luisaugustomendes@yahoo.com.br

Resumo. As propriedades ACID1 determinam parmetros desejveis em sistemas de banco de dados. No entanto, nem todo SGBD2 implementa as 4 propriedades, o que pode ser catastrfico em algumas aplicaes e imperceptvel em outras. Resta ento ao administrador do Banco de Dados conhecer as caractersticas e decidir qual o melhor SGBD destinado sua aplicao. Este artigo apresenta os resultados de um estudo comparativo entre trs SGBDs no que tange as propriedades ACID, desempenho e nvel de isolamento das transaes. Palavras chave: SGBD, Transao, Benchmark, Atomicidade, Consistncia, Isolamento, Durabilidade, Desempenho.

1 - Introduo
Atualmente os sistemas de informao invadem as empresas tornando-as cada vez mais dependentes da tecnologia e, principalmente, da informtica. Partindo desse quesito os sistemas de informao so constitudos por um software ou programa que gerencia todas as atividades para o qual ele foi desenvolvido e um banco de dados para armazenar os dados manipulados pelo sistema. Antes, arquivos binrios eram utilizados para armazenar informaes de uma empresa. Conforme esse volume de informaes cresce, torna-se necessrio encontrar novas solues que do melhor estabilidade e maior segurana s informaes armazenadas. Essas e outras caractersticas tornaram popular o uso dos chamados SGBDs (Sistema Gerenciador de Banco de Dados)[1]. Um SGBD um software de computador capaz de armazenar, organizar e oferecer alguma segurana s cada vez mais valiosas informaes de uma empresa [1]. Ao desenvolver um sistema, o administrador do banco de dados precisa decidir qual ser o SGBD utilizado para gerenciar os dados da aplicao. Existem vrias opes de SGBDs e estes so classificados por categorias. Para este estudo foram selecionados os SGBDs Oracle, SQL Server e PostgreSQL, por serem classificados como SGBDs da mesma categoria, serem SGBDs para grandes bancos de dados e alm disso, serem utilizados em grande fatia de mercado. O objetivo geral deste artigo mostrar a compatibilidade dos SGBDs citados anteriormente no que tange as propriedades ACID (Atomicidade, Consistncia,
- Acrnimo utilizado para representar as propriedades Atomicidade, Consistncia, Isolamento e Durabilidade. 2 - Sigla utilizada para designar Sistema Gerenciador de Banco de Dados.
1

Isolamento e Durabilidade), desempenho e performance medidos atravs de benchmark e nveis de isolamento. A seo 2 deste artigo descreve o que um SGBD, os principais conceitos e as principais caractersticas desejveis em um sistema de banco de dados. A seo 2.1 define o conceito de transao em um banco de dados. As propriedades ACID so apresentadas na seo 2.2 e explicadas em detalhes nas sees 2.3, 2.4, 2.5 e 2.6. A seo 3.1 descreve o SGBD Oracle e suas principais caractersticas. Na seo 3.2 apresentado o SQL Server, um SGBD desenvolvido pela Microsoft e utilizado em aplicaes de grande porte. A seo 3.3 apresenta o PostgreSQL, um SGBD de cdigo aberto desenvolvido e aperfeioado por vrios programadores atravs da Internet. Na seo 4 deste artigo, realizado um estudo de caso com os SGBDs citados, um ambiente de trabalho definido, as mtricas utilizadas so apresentadas levando em conta o Benchmark TPC-C, um padro de comparao entre os trs SGBDs traado e os resultados obtidos durante o estudo de caso so apresentados. A seo 5 apresenta as consideraes finais sobre o levantamento terico e resultados obtidos atravs de benchmark3. A seo 6 do artigo apresenta as referncias bibliogrficas.

2 SGBDs
Um sistema gerenciador de banco de dados uma coleo de dados inter-relacionados e uma coleo de programas para acesso a estes dados. Sucintamente, um SGBD deve proporcionar um ambiente eficiente para recuperao e armazenamento das informaes do banco de dados [1]. As funcionalidades de um bom SGBD vo muito alm das quatro propriedades atomicidade, consistncia, isolamento e durabilidade representadas pela sigla ACID[2]. Manter o controle de redundncia tarefa do projetista do banco de dados. Evitar que uma mesma informao seja gravada em diferentes tabelas, ajuda a manter a consistncia dos dados e a economizar espao em disco. No entanto, algumas vezes convm implementar a redundncia controlada para agilizar o processamento das consultas ao banco de dados. Este tipo de redundncia controlada pode ser especificado durante o projeto de banco de dados e forado pelo SGBD sempre que um arquivo for atualizado para manter a consistncia dos dados [2]. Segurana e um subsistema de autorizao so outras caractersticas bem vistas em um bom SGBD. O controle de usurios deve ser feito de forma que garanta acesso restrito a determinadas tarefas para alguns usurios ou grupos de usurios. Essas restries devem ser garantidas automaticamente pelo SGBD. Diferentes usurios podem ter acesso e controle a diferentes bancos de dados e reas de configurao dentro de um SGBD. O SGBD deve possuir estruturas de dados especializadas para aumentar a velocidade de pesquisa no disco dos registros desejados. O SGBD deve oferecer suporte a um tipo de arquivos auxiliares chamados indexes4 que so utilizados com o objetivo de acelerar o desempenho de um SGBD ao processar uma consulta [2].
- Benchmark Carga de testes que simula o comportamento do mundo real para testar hardware ou software de computador. 4 index arquivo de ndices do banco de dados
3

Um componente do SGBD chamado subsistema de backup e recuperao dos subsistemas responsvel por oferecer facilidades para restaurao de falhas de hardware ou de software[2]. O SGBD deve fornecer mltiplas interfaces para os diferentes tipos de usurios que acessam os bancos de dados. Desde usurios casuais que desejam executar uma consulta aos dados DBA's que definem regras e implementam projetos em um SGBD, cada um deve ter uma interface de comunicao especfica com o SGBD. Em um banco de dados, se encontram desde relacionamentos simples relacionamentos complexos entre os dados. O SGBD deve ter a capacidade de representar a variedade de relacionamentos complexos entre os dados [2]. Durante o projeto do banco de dados o DBA deve especificar algumas restries de integridade dos dados [2]. O SGBD deve oferecer mecanismos para forar as restries de integridade definidas no projeto. O SGBD deve permitir inferncias e aes usando as regras. Em alguns casos, necessrio realizar restries ou clculos para determinar algum valor implcito no banco de dados. Por exemplo, podem existir regras que calculem quando a quantidade de produtos de um estoque est abaixo do valor mnimo. Estas regras podem ser declaradas no SGBD e serem disparadas automaticamente por diferentes aplicaes. Desta forma, determinar quais produtos estariam abaixo da quantidade mnima desejada seria uma funo executada da mesma forma por vrias aplicaes diferentes [2].

2.1 - Transaes
Ao executar uma ao que envolva leitura e escrita no banco de dados, toda a ao uma nica tarefa do ponto de vista do usurio. Assim, alguns respeitados livros de banco de dados definem transao como uma unidade lgica de execuo de programas que acessa e, possivelmente, atualiza vrios itens de dados[2]. Todos os dados armazenados no banco de dados devem estar ntegros aps a execuo de qualquer transao. Para uma melhor compreenso deste conceito pode-se imaginar uma operao simples de venda de um produto e atualizao da quantidade de estoque do produto em um banco de dados. Suponha que uma operao A seja responsvel por realizar a venda do produto e, que uma operao B seja responsvel por atualizar a quantidade de produtos no estoque. Se uma operao C que calcula a quantidade de produtos no estoque for executada aps a execuo da operao A e antes da operao B, ela ir retornar um valor inconsistente dos dados, j que, a quantidade do estoque ainda no foi atualizada pela operao B. Ou ainda, se por algum fator externo a operao A no for executada a operao B poder atualizar a quantidade de estoque do produto fazendo com que alguns produtos desapaream do banco de dados. Para solucionar este problema as operaes A e B devem ser consideradas uma nica transao. Ou as operaes A e B so executadas corretamente ou nenhuma delas ser executada. Para garantir a integridade dos dados, um SGBD deve manter as 4 propriedades chamadas de propriedades ACID [2].

2.2 - Propriedades ACID

O modelo ACID um dos mais antigos e mais importantes conceito da teoria de banco de dados. Este modelo a sigla para as propriedades atomicidade, consistncia, isolamento e durabilidade. Estas propriedades asseguram que um banco de dados continuar consistente aps a execuo de uma transao [2]. Atomicidade a propriedade que trata da transao de forma atmica, todas as instrues dentro de uma transao so tratadas de forma indivisvel, como um tomo. A atomicidade implementa o tudo ou nada em um banco de dados, ou todas as modificaes de uma transao so executadas com sucesso, ou nenhuma delas executada. Consistncia a propriedade que assegura que todas as modificaes sero efetuadas no banco de dados se forem consistentes, isto , se os dados de uma transao forem vlidos a transao efetuada, seno toda a transao ser cancelada. Isolamento a propriedade responsvel por garantir que cada transao no banco de dados seja executada de forma isolada. Caso duas transaes A e B sejam efetuadas no banco de dados por usurios diferentes ao mesmo tempo, o isolamento garante que A ser executada antes de B ou vice-versa. O isolamento no garante qual ser a transao executada primeiro mas garante que uma transao no interfira em outra. Durabilidade consiste em que toda transao bem sucedida no seja perdida. Caso uma transao seja executada com sucesso at o fim todas as suas modificaes so gravadas permanentemente no banco de dados e no sero perdidas mesmo que haja alguma falha fsica no equipamento.

de suma importncia que se defina claramente o que so operaes no banco de dados e instrues de aplicao. Deve-se compreender como operaes em banco de dados apenas as instrues de leitura e escrita. Entenda que um banco de dados um arquivo armazenado em algum tipo de memria secundria, por exemplo um hd. Para realizar clculos com as informaes gravadas em um banco de dados o processador precisa que estas informaes estejam armazenadas em memria principal. Para transferir ento os dados da memria secundria para a memria principal, o sistema realiza uma operao de leitura no arquivo de banco de dados gravado no hd. Aps realizar os clculos com os dados que estavam na memria principal o sistema realiza uma operao de escrita para gravar os dados no hd do computador [2]. Para facilitar o entendimento da aplicao de cada uma das propriedades ACID pode-se imaginar um sistema simples de venda e atualizao de estoque. Considere uma transao (T) que dever fazer a venda de 3 itens de um produto X em um sistema de banco de dados. A transao inicialmente realiza uma consulta quantidade de produtos disponveis no estoque atravs de uma leitura na tabela de produtos. Com a operao de leitura os dados so transferidos do disco para a memria principal do computador, ento, a transao subtrai 3 da quantidade de produtos em estoque. Conforme se pode observar na Tabela 1, neste momento foi executada a linha 2 da transao T que uma instruo de aplicao, portanto, a quantidade em estoque do produto na tabela X permanece inalterada. Na linha 3 da transao T, realizada uma operao de escrita na tabela X. Conforme se observa na Tabela 1 esta uma operao de banco de dados e aps ser concluda, a quantidade em estoque do produto alterada

para 97. Em seguida, uma instruo de leitura realizada na venda Y para transferir os dados gravados em disco da venda para a memria principal. Atravs de uma instruo de aplicao, descrita na linha 5 da Tabela 1, o sistema adiciona 3 quantidade de itens do produto na venda Y e s ento, executa a gravao dos dados que estavam em memria principal no arquivo de banco de dados, como mostra a operao de escrita na linha 6 da Tabela 1.
Tabela 1: Transaes com operaes de leitura e escrita

Linha de tempo da Transao 1 2 3 4 5 6

Transao (T) leitura(x); x:= x 3; escrita(x); leitura(y); y:= y+3; escrita(y)

Operaes no banco de dados X

Instrues de aplicao

Produto (X) / Qtde em estoque 100 100 97 97

Venda (Y) / Qtde vendida 0 0 0 0 0 3

x X X x X

97 97

2.3 - Atomicidade
A idia da propriedade de atomicidade executar todas as operaes da transao ou no executar nenhuma delas. Na transao descrita anteriormente, imagine se houvesse uma falha no sistema aps a operao de escrita(X) na linha 3 e no fosse garantida a propriedade de atomicidade. A retirada de 3 itens seria feita no estoque X mas, a quantidade do item em Y no seria includa. Como resultado, 3 itens teriam desaparecido do estoque, gerando um estado inconsistente dos dados. A propriedade de atomicidade tratada em um SGBD por um componente chamado de componente de gerenciamento de recuperao.

2.4 - Consistncia
A preservao da consistncia geralmente considerada responsabilidade do programador que codifica os programas de banco de dados, ou do mdulo do SGBD que garante as restries de integridade [2]. Os conceitos de consistncia e integridade em banco de dados esto intimamente relacionados. Uma vez que, o SGBD trabalha com um banco de dados em um estado previamente consistente e possui mecanismos para garantir a integridade dos dados, por exemplo a validao de atributos de um determinado tipo, os dados sero gravados de forma correta e isto leva o banco de dados a um novo estado consistente. Para garantir ento a consistncia dos dados, o SGBD deve realizar uma prvia validao dos dados e s ento inserir os dados em uma tabela. Considere uma tabela de empregados onde um de seus atributos o campo data de admisso do tipo date. Se tentar cadastrar um empregado com a data de admisso 32/01/2008, o SGBD ir retornar um erro e os dados no sero gravados na tabela de empregados, visto que se

tentou cadastrar uma data inexistente. Este tipo de restrio imposta pelo SGBD devido a tipao dos dados. Em outro caso, suponha que a data atual seja 20/11/2008, se cadastrar um empregado com a data de admisso 20/11/2015 o SGBD aceitar o cadastro sem restries j que a data de admisso cadastrada no fere a tipao dos dados. Mas, no possvel no mundo real cadastrar um empregado em 20/11/2008 com data de admisso em 20/11/2015. Este tipo de restrio impercepitvel ao SGBD mas deve ser tratado pelo programador do banco de dados atravs de triggers5, stored procedures6 ou outras formas de restrio para manter a consistncia dos dados armazenados com a realidade.

2.5 - Isolamento
Em um banco de dados onde muitas transaes so executadas, uma transao A no pode interferir no resultado de uma transao B ou vice-versa. Uma soluo simples e de fcil implementao para este problema seria executar uma transao aps a outra. Facilmente percebe-se que esta soluo comprometeria muito o desempenho das operaes do banco de dados [2]. Executar transaes de forma concorrente uma tarefa difcil para o sistema de banco de dados. Proporcionar a execuo de transaes uma a uma, simplifica muito a implementao do sistema de banco de dados [2]. Por outro lado, alguns fatores tornam de suma importncia a implementao de concorrncia em um sistema de banco de dados. Sabe-se que o processador e o disco em um computador podem executar tarefas distintas simultaneamente, dessa forma, uma transao A pode utilizar recursos de leitura e escrita no disco, enquanto uma transao B pode realizar clculos atravs do processador. Este fato aumenta consideravelmente o desempenho de um sistema de banco de dados [2]. Outro fato relevante a possibilidade de haver vrias transaes no sistema sendo executadas de forma simultnea. Executar as transaes seqencialmente pode fazer com que uma transao rpida tenha que esperar que uma transao demorada termine sua execuo. Para exemplificar esta idia, imagine uma transao A que consulta os dados de um cliente e uma transao B que acresce 30% (trinta por cento) ao preo de todos os produtos em estoque. Caso a tabela de estoque possua muitos itens a transao A ter que esperar toda a transao B ser executada, o que geraria uma demora excessiva na resposta da transao A. Quando o sistema executa vrias transaes concorrentes a consistncia dos dados deve ser preservada [2]. Para controlar a execuo das transaes concorrentes o sistema de banco de dados dispe de uma gama de mecanismos chamados de esquemas de controle de concorrncia. Em suma, os esquemas de controle de concorrncia verificam as transaes concorrentes e ordena-as, gerando escalas de execuo. O objetivo destes esquemas gerar escalas de execuo que garantam a consistncia dos dados e aproveitem da melhor forma possvel os recursos computacionais.
Triggers so gatilhos ou trechos de cdigo em linguagem SQL que podem ser executados no SGBD para realizar uma funo especfica antes, durante ou aps a execuo de uma transao. 6 Stored Procedures so um conjunto de instrues que so executadas dentro do banco de dados [3].
5

A SQL92 define ainda, quatro nveis de isolamento. Cada nvel especifica os tipos de erros que no so permitidos. Os nveis mais altos incluem as restries previstas nos nveis mais baixos[4]. Na Tabela 2 se especifica os quatro diferentes nveis de isolamento, seu nome e os possveis problemas que podem ocorrer em cada nvel.
Tabela 2 Nveis de Isolamento e problemas tratados

Nvel 0 1 2 3

Isolamento Read uncommited Read commited Repeatable read Serializable

Dirty Read Possvel Impossvel Impossvel Impossvel

Nonrepeatable Read Possvel Possvel Impossvel Impossvel

Phantom Read Possvel Possvel Impossvel Impossvel

O nvel de isolamento zero read uncommited (leitura no efetivada) previne outras transaes de modificar dados alterados por transaes que ainda no foram efetivadas. As outras transaes so bloqueadas de modificar os dados at que a transao seja efetivada ou cancelada. Porm, este nvel de isolamento, permite que outras transaes leiam dados que foram modificados por outras transaes ainda no efetivadas [4]. O nvel de isolamento um read commited (leitura efetivada) previne o problema de dirty read7 (leitura suja)[4]. Essas leituras acontecem quando uma transao modifica um registro em uma tabela e uma segunda transao l estes dados. Se a primeira transao no for efetivada, os dados voltaro ao seu estado original o que torna os dados lidos pela segunda transao invlidos. No nvel dois repeatable read (leituras repetitveis) tratado o problema de Nonrepeateable read (leituras no repetitveis)[5]. Essas leituras acontecem quando uma transao l um registro e ento uma outra transao modifica aquele registro. Se a segunda transao for efetivada, as prximas leituras da primeira transao geram resultados diferentes do original. O problema chamado phantom read (leitura fantasma) tratado no nvel trs serializable (serializvel)[4]. Os fantasmas ocorrem quando uma transao retorna um conjunto de registros que satisfaam a uma condio. Ento, uma transao modifica os dados de alguns registros. Se a primeira transao repetir a pesquisa com as mesmas condies de busca ter um conjunto diferente de dados.

2.6 Durabilidade
Ao implementar a durabilidade em um banco de dados o componente de gerenciamento de recuperao tambm conhecido como esquema de recuperao, pode optar por trabalhar com um esquema chamado de cpias shadow8. Este esquema pressupe que somente uma transao executada por vez e que o banco de dados um arquivo no disco. Ao atualizar o banco de dados uma cpia do
7 8

- Expresso em ingls utilizada para representar o problema de leituras sujas em um banco de dados. Shadow Tcnica que consiste na criao de uma sombra do arquivo de banco de dados.

arquivo gerada e as atualizaes so feitas nesta nova cpia.Um ponteiro mantido no disco aponta para a cpia corrente do banco de dados. Se a transao for executada com sucesso, o ponteiro ir apontar para a nova cpia do arquivo e depois a cpia antiga apagada. Caso a transao seja abortada devido a alguma falha, o ponteiro permanecer na cpia antiga, que no sofreu alteraes como pode se observar na Figura 1.

Figura 1 Tcnica Shadow implementada pelo gerenciamento de recuperao

Em casos reais, um banco de dados um arquivo no disco com vrias tabelas que podem ser acessadas por diversos usurios ao mesmo tempo. Como vrios usurios realizam diferentes transaes concorrentes ao mesmo tempo no banco de dados, falhas podem ocorrer durante a execuo de uma ou mais operaes. Para corrigir e evitar este problema, o SGBD dispe de um sistema de recuperao. O sistema de recuperao pode e deve trabalhar de uma forma mais eficiente realizando a classificao de cada tipo de falha como falha da transao, queda do sistema ou falha de disco. Dois tipos de erros podem levar o sistema a uma falha de transao, erros lgicos que impedem uma transao de continuar sua execuo adequada devido a uma entrada invlida ou ainda um dado no encontrado. Uma queda do sistema pode ocorrer por diversos fatores como falta de energia eltrica, falha de hardware no computador e outros que podem levar o banco de dados a parar de funcionar temporariamente. Para recuperar-se de uma possvel queda do sistema, o SGBD pode acessar o arquivo de log do sistema quando voltar a funcionar e verificar quais transaes foram executadas com sucesso at o final mas, no foram gravadas no disco. Desta forma o SGBD efetiva as transaes pendentes tornando-as durveis [2]. Uma falha de disco pode ocorrer devido a um problema fsico no disco onde os dados esto armazenados, este tipo de falha pode ser recuperado atravs da restaurao de um backup executado previamente.[2] Quando o sistema classifica suas possveis falhas e sabe como cada uma afeta os dados, o SGBD pode utilizar os chamados algoritmos de recuperao para recuperar os dados a um estado consistente.

3 Sistemas de mercado analisados 3.1 Oracle

O SGBD Oracle comeou a ser desenvolvido partir do final da dcada de 70 e encontra-se atualmente na verso 11g. O Oracle oferece ferramentas que facilitam a vida do programador ao implementar bancos de dados[5]. A Oracle disponibiliza para programadores e DBAs diferentes verses do SGBD. Cada verso se adapta melhor realidade da empresa e possui limitaes de software, como limite para o tamanho da base de dados, e limitaes de hardware como por exemplo a quantidade de processadores ou memria do servidor [6]. Para instalar o SGBD Oracle 10g Express Edition necessrio no mnimo 32MB (trinta e dois megabytes), de espao no mesmo disco onde o sistema operacional est instalado, para instalar o jre9 e oracle universal installer10. recomendado 512MB (quinhentos e doze megabytes) de memria RAM e um processador superior a 1200Mhz( mil e duzentos megahertz). O SGBD usa ainda cerca de 100MB para os arquivos de sistema e aconselhvel instalar em sistemas de arquivos NTFS. Caso se opte por fazer a instalao em sistemas de arquivos FAT32 as exigncias so um pouco maiores [6]. Um dos mais recentes e importantes casos de sucesso na implantao da base de dados Oracle o da editora Gailivro [7]. No mercado h mais de dezoito anos o objetivo da editora era conhecer cada vez mais seus clientes e implantar uma base de dados confivel para estudar o histrico de vendas. Segundo o diretor da empresa Agostinho Lisboa, aps a implantao da base de dados Oracle os funcionrios da empresa tm um acesso mais rpido s informaes que necessitam e os diretores tm uma maior e melhor viso de seus clientes.

3.2 SQL SERVER

De um modo geral o SQL Server um SGBD poderoso e confivel, que oferece muitos recursos desejveis em um bom SGBD. Dentre as principais caractersticas do SQL Server destacam-se a alta disponibilidade, desempenho e escalabilidade, segurana, gerenciamento e produtividade [8]. Para funcionar corretamente o SQL Server requer um processador superior a 600Mhz, no mnimo 192 megabytes de memria RAM e acima de 350 megabytes de espao disponvel em disco. O SGBD pode ser instalado em diversas verses do Windows XP, Windows 2000 e Windows 2003 mas, no compatvel com outros sistemas operacionais [8]. Dos casos de sucesso de implantao do SQL Server observa-se com sucesso a atualizao do sistema do banco Nossa Caixa no estado de So Paulo. O banco teve um aumento de cento e dezenove mil transaes eletrnicas em 2002 para um milho e setecentos mil transaes em 2007 [9]. Para atender a este crescimento, uma operao de atualizao do sistema foi iniciada em 2007 e como principais benefcios do novo sistema observa-se o aumento do nmero de transaes por segundo, melhor desempenho na estrutura, facilidade de gesto e aumento na segurana [9].

3.3 PostgreSql
- Java runtime environment - Instalador universal da Oracle utilizado para manipular componentes de software e criar bancos de dados [5]
10 9

O PostgreSQL pode ser instalado em um computador pessoal com 8MB de memria RAM e 100MB de espao em disco, os sistema tambm oferece suporte a diversos sistemas operacionais como MAC OS X, Windows, Linux, Sun Solaris e outros. Dentre as principais caractersticas do SGBD PostgreSQL destacam-se o suporte a triggers, stored procedures, suporte a transaes, controle de integridade referencial, no h limite quanto ao nmero de usurios, oferece controle de transaes concorrentes e suporte nativo s quatro propriedades ACID [10]. Um grande sucesso de implantao do PostgreSQL a ser citado a adoo do SGBD pela BASF (Diviso de produtos para agricultura na Amrica do Norte). Esta empresa vende cerca de US$29 bilhes de dlares por ano e tem cerca de 92.000 (noventa e dois mil) empregados ao redor do mundo. Com o objetivo de se tornar lder de mercado, a empresa desenvolveu um projeto de vendas on line para atender cerca de 25.000 (vinte e cinco mil usurios) simultneos e pretendia-se um tempo de resposta mximo entre 3 e 5 segundos [11]. Dentre os principais requisitos no projeto da BASF estavam o uso de banco de dados relacional com suporte a transaes ACID, stored procedures, triggers e replicao. A empresa avaliou os SGBDs Oracle e SQL Server entre outros e optou pelo PostgreSQL por sua licena livre, manuteno e suporte [11].

4 - Estudo de Caso
Realiza-se um estudo de caso, em um ambiente de testes padronizado e considerando as caractersticas comuns entre SGBDs, para que deste modo, o programador de banco de dados possa se orientar melhor na escolha do SGBD para sua aplicao.

4.1 Ambiente de Teste

Os chamados sistemas de processamento de transaes (OLTP) so empregados para registrar os dados de uma empresa. Estes sistemas so empregados em reas de mercado completamente distintas como sistemas bancrios ou sistemas de controle de vendas e reservas de passagens areas mas, possuem algumas caractersticas em comum dentre as quais destacam-se o suporte a grande quantidade de usurios, restries sobre o tempo de resposta, disponibilidade vinte e quatro horas e sete dias por semana do sistema e um forte padro de acesso a dados definido por meio de transaes [12]. Um dos mais utilizados e respeitados testes para medir desempenho em Sistemas de bancos de dados o TPC-C. A TPC (Transaction Processing Performance) uma organizao mantida pelos principais fabricantes de hardware e desenvolvedores de sistemas de bancos de dados do mundo para fins de teste de Benchmark em sistemas de bancos de dados [13]. O ambiente de testes do TPC-C simula um ambiente de pedidos que entra no sistema e sua distribuio. Sucintamente, o teste calcula quantas transaes de pedidos o SGBD pode realizar por minuto, simulando o acesso de uma grande quantidade de usurios simultaneamente espalhados ao redor do mundo[13]. Uma companhia fictcia criada com vrios armazns e pontos de venda associados geograficamente distribudos. Cada armazm tem dez pontos de venda associados e cada ponto de venda tem trs mil clientes. Todos os armazns mantm

estoque para os cem mil artigos comercializados pela companhia. Na Figura 2 o ambiente de teste simulado pelo benchmark TPC-C est representado [13].

Figura 2 Ambiente de testes TPC-C

4.2 Anlise de Desempenho

O Benchmark TPC-C leva em conta caractersticas desejveis em um sistema de banco de dados como as propriedades ACID alm do desempenho alcanado pelos SGBDs. Para medir o desempenho de um SGBD em um ambiente OLTP o TPC-C indica o ndice tpmc que representa quantitativamente quantas transaes so realizadas por minuto no banco de dados. Durante os testes cinco transaes de tipos e complexidades diferentes so executadas em nove tabelas distintas que constituem o banco de dados durante o tempo de 20 minutos [13]. Para cada transao executada tambm calculado o tempo de resposta e ao final do teste o TPC-C indica o tempo mdio de resposta para o SGBD avaliado. Ao avaliar as propriedades ACID o Benchmark TPC-C leva em conta os mais importantes requisitos de cada uma delas. No manual tcnico do TPC-C as caractersticas desejveis para cada propriedade, a carga de trabalho que compe as transaes de Benchmark e todas as frmulas utilizadas para calcular tempos de respostas e outros podem ser encontrados [13].

4.3 Estudo Comparativo

Com base nas propriedades ACID, nveis de isolamento e desempenho, realizou-se um estudo comparativo entre os SGBDs Oracle, SQL Server e PostgreSQL. A Tabela 3 apresenta as propriedades ACID implementadas em cada SGBD.
Tabela 3 Comparativo de Propriedades ACID

SGBD Oracle SQL Server

Atomicidade x x

Consistncia x x

Isolamento x x

Durabilidade X X

PostgreSQL

A atomicidade implementada nos trs SGBDs atravs dos comandos BEGIN, COMMIT e ROLLBACK. Estes comandos definem blocos de transao, ou seja, todos os comandos colocados aps um comando BEGIN podem ser efetivados com o comando COMMIT ou cancelados com um comando ROLLBACK, tratando todos os comandos como uma nica operao. Caso um comando BEGIN seja executado em qualquer um dos SGBDs e no seja encontrado um comando COMMIT ou ROLLBACK por decorrncia de uma falha do sistema, o sistema de recuperao do SGBD se encarrega de restaurar o banco de dados ao estado que estava antes do incio da transao. A consistncia dos dados mantida nos trs SGBDs atravs da tipao dos dados e restries de integridade impostas pelo programador. Quando se fala de tipao dos dados significa que nos trs SGBDs encontram-se tipos de dados bem definidos. Como exemplo pode-se imaginar que em nenhum dos trs SGBDs os usurios conseguiriam armazenar uma cadeia de caracteres em um campo do tipo inteiro. As restries impostas pelo programador do banco de dados so restries de integridade referencial dos dados, suportadas pelos trs SGBDs ou validao dos dados para manter a consistncia com o mundo real, tambm suportado pelos trs SGBDs. A consistncia dos dados ainda pode ser implementada atravs de triggers ou stored procedures ou ainda atravs do comando CHECK que pode ser utilizado para verificar valores vlidos para cada atributo nos trs SGBDs. O isolamento das transaes implementado e podem ser definidos nveis de isolamento diferentes para cada transao nos trs SGBDs. Assim, os trs SGBDs definem nveis de isolamento diferentes e cabe ao programador do banco de dados definir qual ser o melhor nvel de isolamento para cada transao. Os trs SGBDs possuem ainda um sistema de recuperao que possibilita a implementao da durabilidade dos dados. Uma vez que uma transao efetivada, os dados so mantidos. Se uma transao no efetivada, todas as suas alteraes sero perdidas. A Tabela 4 mostra os resultados obtidos em uma anlise de desempenho levando em considerao a quantidade de usurios e o ndice tpmc obtido pelo Benchmark TPCC. Os trs SGBDs foram instalados no sistema operacional Windows XP da Microsoft, e o programa Benchmark Factory 5.7.1 foi utilizado para simular a carga de trabalho TPC-C. A conexo com os SGBDs foi feita via driver ODBC fornecido pelos fabricantes em suas homepages.
Tabela 4 Resultado obtido atravs do Benchmark Factory

1 usurio Oracle SQL Server PostgreSQL 1,328 1,490 1,479

8 usurios 12,590 12,614 11,952

10 usurios 14,815 14,908 14,735

100 usurios 141,236 141,537 140,335

Os resultados dos testes realizados pelo programa Benchmark factory mostram o desempenho de cada SGBD quando instalados em um computador e com toda a carga de trabalho TPC-C simulada atravs de software. Realizou-se o teste em 4 situaes diferentes com nmeros pequenos de usurios e o SQL Server obteve melhor resultado em todos os casos, em segundo lugar aparece o SGBD Oracle e em terceiro o PostgreSQL. Observa-se ainda que para um usurio o PostgreSQL foi mais eficiente que o Oracle mas menos eficientes nas outras situaes. A organizao TPC divulgou em 15/09/2008 os resultados mais recentes obtidos atravs do Benchmark TPC-C realizados no ambiente padro criado pela organizao. Todos os testes de Benchmark realizados pela TPC so auditados e acompanhados pelas principais empresas desenvolvedoras de SGBD do mundo e outros membros da organizao, afim de legitimar os resultados obtidos [13]. A Tabela 5 mostra uma parte dos resultados obtidos nos testes dos SGBDs Oracle, PostgreSQL e SQL Server instalados em um servidor UniSys modelo ES7000 [13].
Tabela 5 Resultados oficiais TPC-C

Servidor Oracle SQL Server PostgreSQL UniSys ES7000 UniSys ES7000 UniSys ES7000

tpmC/Windows 291413 309036.53 298534 -

tpmC/Linux 322805 325685

No ambiente de testes do TPC-C o SQL Server foi superior quando comparado com o Oracle e o PostgreSQL rodando em um servidor Windows. Porm, em servidores com sistema operacional Linux no possvel instalar o SGBD SQL Server. O PostgreSQL superou o Oracle em ambos os casos. Nos SGBDs Oracle e PostgreSQL o nvel de isolamento pode ser definido pelo programador de banco de dados atravs do comando SET TRANSACTION antes de realizar a transao. No SQL Server o comando SET TRANSACTION ISOLATION LEVEL e tambm deve ser definido antes de uma transao. No Oracle e no PostgreSQL so possveis duas opes para os comandos SET TRANSACTION conforme observa-se na Tabela 6. Isto implica que em ambos os casos possvel dois nveis de isolamento diferentes, read commited e serializable [14]. Na Tabela 6 apresentado um estudo comparativo entre os SGBDs no que tange suas opes de isolamento.
Tabela 6 Comparao de Nveis de Isolamento

Isolamento Read uncommited Read commited Repeatable read Serializable

Oracle x x

SQL Server x x x x

PostgreSQL X X

Snapshot

Quando compara-se os nveis de isolamento o SQL Server o mais completo e que oferece mais opes de configurao ao programador. As opes read uncommited, read commited, repeatable read e serializable esto disponveis para serem utilizadas junto ao comando SET TRANSACTION ISOLATION LEVEL. Alm destas, o SQL Server tem a opo snapshot que especifica que a transao pode reconhecer apenas modificaes que estavam efetivadas antes do incio da transao e modificaes efetivadas por outras transaes aps o incio da transao atual no so vistas [15].

5 Consideraes Finais
Antes de decidir qual SGBD o melhor, necessrio que se tenha definido bem qual ser o ambiente onde ele ser aplicado. Observa-se que em casos onde o nmero de usurios pequeno ou o sistema operacional utilizado o Windows, se obtm uma melhor performance quando a opo escolhida o SQL Server. Ainda considerando apenas o desempenho o PostgreSQL apresenta melhores resultados que o Oracle quando se opta pelo sistema operacional Linux. Entretanto, deve-se considerar outras caractersticas importantes em um SGBD como seu comportamento em relao s propriedades ACID e nveis de isolamento que podem ser implementados. Simular um ambiente de software para teste e avaliao de todas as propriedades possveis de um SGBD uma tarefa bastante complicada. Em situaes reais, ocorrem possveis problemas como queda de energia que so de difcil implementao. Conclui-se que no h um SGBD que atenda a todos os projetos de forma melhor que os demais. Deve-se estudar o desempenho e as necessidades de cada projeto em relao s propriedades ACID para tomar a deciso de qual SGBD utilizar. Para trabalhos futuros, sugere-se temas como: implementao de um software para simulao e teste das propriedades ACID, implementao de um software para demonstrao dos diferentes efeitos em diferentes nveis de isolamento ou anlise de log dos SGBDs por tempo determinado.

6 - Bibliografia
[1] SILBERSCHATZ, Abraham; KORTH, Henry F. e SUDARSHAN, S. Sistema de Banco de Dados. So Paulo. Makron Books, 1999. [2] ELMASRI, Ramez. Sistemas de banco de dados / Ramez Elmasri e Shamkant B. Navathe. So Paulo. Pearson Addison Wesley, 2005. [3] PICHILIANI, Mauro. Criao e Uso de Stored Procedures. Disponvel em: <http://imasters.uol.com.br/artigo/223/sql_server/criacao_e_uso_de_stored_procedur es/>. Acesso em 29/10/2008 [4] SYBASE. SQL Server Reference Manual. Disponvel em: <http://manuals.sybase.com/onlinebooks/group-asarc/srg1100e/sqlref/@ebtlink;pt=16395;lang=pt?target=%25N%15_70685_START_RESTART_N%25>. Acesso em 07/11/2008

[5] ORACLE, Brasil. A Histria do Oracle: Inovao, Liderana e Resultados. Disponvel em: <http://www.oracle.com/global/br/corporate/story.html>. Acesso em 17/10/2008 [6] PRASS, Fbio; PRASS, Fernando. Oracle e Delphi uma viso geral do melhor dos bancos de dados. Disponvel em: <http://www.devmedia.com.br/articles/viewcomp.asp?comp=1311&hl=*oracle*>. Acesso em 17/10/2008 [7] ORACLE, PME. Gailivro implementa Oracle como base de um programa de gesto integrada de informao. Disponvel em: <http://www.oracle.com/global/pt/pmes/references/case_study_gailivro_30_agosto_ 06.pdf>. Acesso em 20/11/2008. [8] MICROSOFT CORPORATION. SQL Server 2005. Disponvel em: <http://www.microsoft.com/brasil/servidores/sql/2005/prodinfo/overview/default.ms px>. Acesso em 12/11/2008. [9] MICROSOFT BRASIL. Casos de Sucesso Nossa Caixa Nossa Caixa amplia nmero de transaes a partir do SQL Server 2005. Disponvel em: <http://www.microsoft.com/brasil/Casos/interna.aspx?id=588>. Acesso em 20/11/2008. [10] The Postgre Global Development Group. Documentao do PostgreSQL 8.0.0. Rio de Janeiro, 2005. [11] MILANI, Andr. PostgreSQL Guia do Programador. Disponvel em: <http://novatec.com.br/livros/postgre/capitulo9788575221570.pdf>. Acesso em 10/11/2008 [12] MENDES, Marcelo; MACIEL, Paulo. Anlise de Desempenho de Sistemas OLTP utilizando o Benchmark TPC-C. Disponvel em: <http://www.cin.ufpe.br/~tg/2006-1/mrnm.pdf>. Acesso em 16/11/2008. [13] TRANSACTION PROCESSING PERFORMANCE COUNCIL (TCP). Standard Specification Revision 5.9. Junho, 2007. [14] ORACLE. Oracle Database SQL Reference. Disponvel em: <http://downloadeast.oracle.com/docs/cd/B14117_01/server.101/b10759/statements_10005.htm> Acesso em 21/11/2008. [15] MICROSOFT BRASIL. Set Transaction Isolation Level (Transact-SQL). Disponvel em: <http://msdn.microsoft.com/pt-br/library/ms173763.aspx>. Acesso em 22/11/2008.