Você está na página 1de 13

Análise de desempenho entre os bancos de dados SQL Sever x Oracle

Publicado em: 14/08/2009

Compartilhe

1. Introdução

Atualmente no universo corporativo, a necessidade constante de gestores de tomar decisões cruciais para os bons negócios das empresas, faz da
informação seu bem mais precioso. Nos dias de hoje, com o grande e cada vez maior volume de dados, se torna imprencidível escolher um bom sistema
de banco de dados, pois fatores como o tratamento, segurança e principalemte velocidade na busca destas informações pode determinar o sucesso ou
fracasso de uma oraganização.

Este artigo destaca os dois principais sistemas de bancos de dados, o MS SQL Server da empresa Microsoft e o Oracle da empresa Oracle Corporation. O
presente trabalho tem como meta mostrar alguns conceitos sobre estes bancos, e principalmente realizar testes de desempenho, utilizando a linguagem
SQL (Structured Query Language) em um sistema computacional comum a todos, tanto no quesito hardware como no sistema operacional utilizado.

O principal motivo deste artigo não é mostrar qual sistema de banco de dados é melhor, mas sim apresentar algumas caracteristicas que os definem e
fazem cada empresa adotar um ou outro, pois se deve ponderar inúmeras outras características antes de escolher um sistema gerenciador de banco de
dados (SGBD), tais como: o custo de implementação e suporte, manutenção, recursos existentes de cada banco e etc.

Vale lembrar, que no mercado de banco de dados, existem também outras opções de bons SGBD´s, como: MySQL, Firebird, DB2 entre outros.

Tem-se então como objetivo, demonstrar como estes dois SGBD´s (SQL Server e Oracle), tratam e manipulam suas informações, e também verificar o
tempo de resposta em várias consultas, com um grande volume de dados, para um melhor e imparcial resultado.

2. O uso dos bancos de dados nas empresas brasileiras

De acordo com uma pesquisa de mercado, realizada no ano de 2005, nos meses de abril e maio, pelo grupo Impacta (Impacta, 2005), onde o objetivo
desta pesquisa era medir o percentual no uso da infra-estrutura em tecnologia nas grandes empresas do Brasil, neste caso foram entrevistadas duas
mil empresas, tinha-se como meta avaliar tanto o quesito do uso de sistemas operacionais, números de equipamentos, número de servidores e
também, empresas que utilizam ERP e quais são os gerenciadores de banco de dados mais utilizados por estas companhias.

O SBGD Oracle liderou a pesquisa com 59% das implementações nas companhias entrevistadas, logo em seguida, com 53% aparece o SQL Server,
outros sistemas de banco de dados como Progress, Access e DB/2, aparecem com 8%, 7% e 6.5%, respectivamente, observando-se uma diferença
significativa, quando comparado com os dois primeiros já mencionados.

Nesta mesma pesquisa, observou-se que grande número das empresas não possuíam nenhum tipo de software de ERP, destas empresas o SQL Server
é a preferência com 58.3% e logo depois aparece o Oracle com 38.9%.

Na figura 1, é detalhado o resultado total, incluindo os demais sistemas de banco de dados mencionados pelas empresas nesta pesquisa (Impacta,
2005).

Figura 1. Gráfio que detalha o resultado da pesquisa no uso dos SBGD´s no Brasil(Impacta 2005)

3. MS SQL Sever

O MS SQL Server é um sistema gerenciador de banco de dados relacional (SGBDR), desenvolvido e comercializado pela empresa Microsoft, atualmente
sua última versão é o MS SQL Server 2008 (Agnaldo, 2007).

O SQL Server teve sua origem no final dos anos 80, com o nome de Sybase SQL Server, isso devido a uma parceira de desenvolvimento junto à
empresa Sybase. As duas companhias desenvolveram juntas até o SQL Server 4.0 para o Windows NT, a partir desta versão, o SQL Server teve seu
desenvolvimento apenas pela Microsoft.

Abaixo segue um cronograma histórico do desenvolvimento deste SGBD (Agnaldo, 2007):

• 1988 » Microsoft, Sybase e Aston-Tate criam o SQL Server para os sistemas OS/2;
• 1990 » Microsoft e Sybase lançam o SQL Server 1.1 com suporte ao Windows 3.0;
• 1991 » Surge o SQL Server 1.11, versão de manutenção;
• 1992 » Microsoft e Sybase lançam uma versão do SQL Server para o Windows NT;
• 1995 » A Microsoft, já assumindo o total desenvolvimento sem parceria, lança o SQL Server 6.0;
• 1996 » É lançado a versão 6.5 do SQL Server com recursos para internet, e ganhou o certificado do padrão ANSI SQL;
• 1998 » É lançado o SQL Server 7.0, o primeiro a incorporar interface gráfica;
• 2000 » O SQL Server 2000, foi o primeiro que teve uma versão para a plataforma IA64 (64 bits) da Intel;
• 2005 » Surge o SQL Server 2005, é lançado com grande integração a plataforma Dot Net e com as ferramentas de desenvolvimento, como o
Microsoft Visual Studio;
• 2008 » É lançado a versão do SQL Server 2008, com características de goverança e compressão de dados e suporte pra informações geo-
espaciais.

3.1 Características do SQL Server 2005 Express Edition

Como este será o sistema utilizado na realização dos testes deste artigo, nas linhas que se seguem são apresentadas algumas características deste
produto.

O SQL Server Express é um sistema de banco de dados baseado nas tecnologias existentes no SQL Server 2005, é um software gratuito, mas apenas
sua distribuição é free e não o seu código fonte, ele é de fácil instalação e administração, projetado principalmente para ser um servidor de produtos,
como um Web Server, ou também como um cliente stand-alone, neste caso, a aplicação não depende de uma rede para obter acesso aos dados
(Pinheiro, 2005).

Esta versão do SQL Server pode criar bases de dados de até 4 GB de tamanho, esta limitação é apenas para o arquivo de dados, é compativel com
outras edições do SQL Server 2005, possui integração com o Visual Studio 2005, o que torna o desenvolvimento de aplicações que o utilizam como base
de dados mais simples (SQL Server, 2005).

Outra característica é que este sistema suporta até o número máximo de 50 instâncias na mesma máquina, desde que cada instância seja nomeada
com um nome diferente, e por default, na instalação do SQL Server Express a instância é criada com o nome de SQLEXPRESS.

Esta versão suporta várias funcionalidades do SQL Server 2005 como (Pinheiro, 2005):

• Stored procedures, que são um conjunto de instruções executadas dentro do banco de dados;
• Views, que é uma tabela virtual gerada a partir do resultado de uma instrução SELECT;
• Cursor, que permite que seu código SQL faça uma varredura numa tabela;
• T-SQL language support;
• Service Broker (as a client only);
• Advanced Query Optimizer entre outras.

Mas por outro lado, existem algumas funcionalidades que esta versão não suporta, como por exemplo (Pinheiro, 2005):

• SQL Agent, que é um serviço do Microsoft Windows que executa tarefas administrativas agendadas, que são chamadas de trabalhos;
• Full text search;
• DTS, que é uma ferramenta para exportar e importar dados para arquivos de excel, txt entre outros;
• OLAP Services / Data Mining;
• English Query;
• Em máquinas multiprocessadas, o engine do SQL Server Express reconhece apenas um processador.

4. Oracle

O Oracle é um SGBD (sistema gerenciador de banco de dados) que surgiu no fim da década de 70, criado por Larry Ellison e os co-fundadores da
empresa Oracle Corporation, Bob Miner e Ed Oates. Deve-se destacar, que Ellison se empenhou na oportunidade que outras empresas de tecnologia da
época não perceberam, o grande potencial de negócios no modelo de banco de dados relacional, tornando a Oracle como uma das maiores empresas de
software para gerenciamento de informações (Oracle,2009).

A seguir segue um cronograma da evolução deste SGBD: (Legatti, 2007)

• 1978 » Oracle 1: escrito em Assembly;


• 1979 » Oracle 2: 1º SGBDR comercial;
• 1981 » Oracle3: Reescrito em C com características de Commit, Rollbacks;
• 1984 » Oracle 4: possuía leituras mais consistentes;
• 1986 » Oracle 5: versão cliente/servidor;
• 1988 » Oracle 6: características como Row-level locking, Online backup;
• 1992 » Oracle 7: Integridade referencial Stored procedures e functions, cost based optmizer(CBO);
• 1997 » Oracle 8: All-your-data Database Particionamento;
• 1999 » Oracle 8i:Evolução do método CBO, database resource manager, novos tipos de índice e características como o Internet Database Java e
XML;
• 2001 » Oracle 9i: Gerenciamento dinâmico da SGA, coleta de estatística mais eficiente, monitores de utilização de memória (views) e Real
application cluster;
• 2003 » Oracle 10g:Coleta automática de estatísticas, fim do método RBO, SQL Profile, gerenciamento automático da SGA e Workload
Repository;
• 2007 » Oracle 11g: Real application testing,evolução dos recursos do 10g e gerenciamento total de memória.

4.1 Características do Oracle 10g Express Edition

Pensando em atender pequenas e médias empresas, na construção de softwares, não se preocupando com gastos em licenças de bancos de dados, a
Oracle lançou no mercado o sistema Oracle 10g Express Edition, chamados por muitos de Oracle XE.

O Oracle 10g Express Edition é uma versão gratuita para distribuição, mas como o SQL Server, não possui seu código fonte aberto, para o
desenvolvimento e claro, para seu uso comercial.

Este SGBD é um banco leve e foi desenvolvido utilizando o mesmo código base do Oracle Database Server 10g Release 2.

Outras características do Oracle XE que merecem destaque são (Gayer, 2006):

• A linguagem PL/SQL foi preservada com total compatibilidade com a versão comercial;
• Como o SQL Server Express Edition, o tamanho máximo da base de dados é de 4Gb(incluindo a tablespace System);
• Os componentes de conectividade como ODBC, JDBC, OLE DB, PHP, Call Interface C e C++, Data Provider para Dot Net fazem parte desta
versão;
• Disponível para Windows e Linux, mas apenas na plataforma de 32 bits;
• Pode-se administrá-lo utilizando a ferramenta de administração e desenvolvimento web, o Oracle HTMLDB;
• E independente que o servidor tenha mais de um processador, este sistema utiliza apenas uma CPU e aloca somente 1 Gb de memória.

5. Performance

A performance de um banco está relacionada principalmente no tempo de resposta de suas operações tentando atender a expectativa do usuário
(Murara, 2008).

No mundo corporativo atual, a informação tem um valor crucial nas atividades de todas as empresas, por isso, deve-se haver sempre uma preocupação
no desempenho dos sistemas de banco de dados utilizados, até mesmo para reduzir o investimento de hardware e software, minimizar o tempo de
resposta, principalmente na busca de informações, melhorando a produtividade no trabalho e aumentando a credibilidade e os bons negócios das
empresas.

A preocupação no desempenho de um banco de dados deve mobilizar todas as pessoas envolvidas na construção de um sistema. Esta responsabilidade
é tanto dos DBA´s, como dos administradores de sistemas, desenhistas e arquitetos de aplicação e também dos desenvolvedores da aplicação que
extrairá as informações do banco.

É claro, que na questão de desempenho e na otimização de consultas, outros fatores necessitam ser considerados, por exemplo, a escolha do sistema
operacional e sua correta configuração podem melhorar em torno de até 50% o desempenho de um banco de dados. Há também a necessida de
identificar quais são as consultas mais lentas e ajustar o hardware que suportará o sistema como um todo (Duarte, 2004).

Independente se o sistema de banco de dados esteja sendo executado em uma máquina, com o hardware mais potente do mercado, o desempenho
poderá sofrer influências negativas através de consultas mal escritas, inadequadas, chamadas também por consultas de fuga ( Pilecki, 2007).

Segundo Craig Mullins, 80% dos problemas de desempenho em um banco de dados, são causados por códigos SQL ineficientes, mas existem outros
fatores que implicam na lentidão de consultas em um banco de dados, tais como (Gervazoni, 2005):

• A falta, desatualização ou índices mal criados;


• A estrutura e baixa comunicação na rede utilizada;
• Memória insuficiente no servidor;
• A falta e desatualização de estatísticas e etc.

6.Plano de execução

O plano de execução determina a sequência de operações (físicas e lógicas), que o banco executa para realizar as consultas e criar o conjunto de
resultados desejados. O otimizador de consultas, que é um mecanismo pertencente ao banco de dados, no processo de otimizar uma consulta gera o
plano de execução.

Este processo leva em conta alguns determinantes fatores, como ( Pilecki, 2007):

• As tabelas envolvidas e como é a condição dos joins;


• A utilização de índices;
• Os predicados de pesquisa existentes nas consultas;
• A lista de colunas retornadas.

É importante destacar, que em consultas complexas, o otimizador de consulta não avaliará todas as possibilidades possíveis, mas sim, tentará encontrar
um plano que seja bom para determinadas consultas. Isto se deve, porque o custo às vezes de avaliar todas as possibilidades para gerar o melhor plano
pode comprometer o ganho de desempenho, por isso é de suma importância entender este processo e suas limitações (Pilecki, 2007).
O SQL Server busca as informações de sua base de duas formas, através de table scan, onde é feito uma varredura por toda a tabela, ou por uso de
índices (Gervazoni, 2005).

Mesmo que a tabela acessada tenha ou não índices criados, o SQL Server guarda as estatísticas de cada campo, principalmente dos mais acessados,
porque para montar seu plano de execução o otimizador utiliza-se destas estatísticas.

Isto porque, antes do otimizador do SQL Server, optar por utilizar ou não um índice de uma tabela, este consulta as estatísticas dos campos a fim de
encontrar o método mais rápido para trazer as informações desejadas, pois mesmo com a correta criação de um índice, pode acarretar em um não
rendimento no momento da consulta (Gervazoni, 2005).

O otimizador de consulta do SQL Server, se baseia em custo, este tenta gerar o plano de execução com o menor custo estimado. Esta estimativa é
baseada nas estatísticas de dados disponível para o otimizador quando este avalia as tabelas envolvidas na consulta. Portanto é importante manter as
estatísticas atualizadas, se não, o otimizador não terá informações necessárias para aperfeiçoar uma consulta e neste caso será gerado um plano com
estimativas erradas (Pilecki, 2007).

Na instalação do SQL Server, existe a opção de criar e atualizar automaticamente as estatísticas, mas com esta opção, as atualizações são realizadas
depois que haja o acúmulo de algumas modificações, e também leva em consideração o tamanho das tabelas em até 8Mb, acima deste valor, o
intervalo aumenta, mas estas atualizações podem ser realizadas manualmente (Gervazoni, 2005).

Já o Oracle, possui algumas maneiras de acessar os dados de uma tabela, como a leitura seqüencial (full table scan), busca pelo identificador do
registro (ROWID scan), busca pelo índice (index scan, cluster scan e hash scan) e busca por amostragem (sample table scan) (Ronconi,2005).

Para determinar qual Será a melhor maneira de realizar uma consulta, o banco de dados Oracle examina quais as formas disponíveis para a operação.
O Oracle analisa as cláusulas From e Where da consulta, e em seguinda, como o SQL Server, o seu otimizador gera os planos de execução e verifica
qual é o plano que possui o menor custo para obter o resultado desejado.

Um dos fatores que podem influenciar a escolha do plano de execução do Oracle são as Hints (dicas), determinadas pelos desenvolvedores, assim, o
otimizador não gerará um conjunto de planos de execução, apenas utilizará a dica inserida pelo desenvolvedor.

E também como o SQL Server, outro tipo de influência que o otimizador de consulta do Oracle pode sofrer, é o valor das estatísticas de tabelas e
índices, pois esta, armazena informações da quantidade de registros, blocos e tamanho médio dos registros, então, caso estas estatísticas estejam
desatualizadas, o otimizador poderá gerar planos inadequados não auxiliando no processo de otimização das consultas (Ronconi,2005).

Como visto anteriormente, tanto o otimizador do SQL Server, como o do Oracle, se baseiam em uso de estatísticas para gerar o melhor plano de
execução para uma determinada consulta.

Segue abaixo alguns dos motivos que levam a atualização destas estatísticas (Gervazoni, 2005):
• Inserção de inúmeros registros;
• A remoção de muitos registros;
• Quando a tabela for truncada;
• E quando houver muitas alterações nos Key values de índices.

Portanto, é importante que os desenvolvedores e administradores de banco de dados, verifiquem se as estatísticas estão sendo atualizadas
periodicamente.

7. Ambiente de testes

Como o intuito deste trabalho é realizar alguns testes de performance, entre o SQL Server e o Oracle, realizando algumas consultas de diferentes níveis
de dificuldades, atualizações e remoções de dados, com o objetivo de medir o tempo de resposta destes SGBD´s, se faz necessário detalhar como será
o ambiente de testes, o sistema operacional utilizado, hardware e dificuldade encontradas.

Na figura 2 está representado o DER (Diagrama de entidade e relacionamento) onde se baseará a formulação dos códigos SQL utilizados para os testes
e na tabela 1 a configuração do computador e dos sistemas utilizados.

Tabela 1: Configuração do computador e dos SGBD´s


Figura 2. O diagrama de entidade relacionamento

Para que as tabelas não fossem criadas junto com outras tabelas de sistemas existentes, tanto na instalação do SQL Server como no Oracle, estas
foram projetadas em cima dos conceitos de table space para o Oracle e de filegroups para o SQL Server.

Teve-se a preocupação de criar todo o ambiente de testes, para que este seja o mais semelhante para as duas plataformas, assim, toda a estrutura foi
desenvolvida no Oracle, onde logo depois foi exportado um arquivo. SQL com os códigos de inserts para serem corrigidos algumas peculiaridades
existentes de cada banco (como o caso do comando to_date do Oracle, para o convert(datetime) do SQL Server) para serem devidamente inseridos no
SQL Server.

Na população das tabelas foi desenvolvido um script, como mostra a figura 3, para cada tabela, nele foi utilizado um comando pertencente a linguagem
Oracle, o Random, com este comando, pode-se gerar vários valores aleatórios para algumas colunas. Na tabela 2 é detalhado as tabelas e os números
de registros pertencentes a cada uma.

Tabela 2. Número de registros das tabelas do teste


É importante mencionar a dificuldade encontrada para replicar estes dados no SQL Server, pois os arquivos exportados do Oracle tiveram que ser
divididos em arquivos com 50 mil regitros, pois acima deste valor o Management Studio Express não conseguia executar o comando de insert nas
tabelas.

No final deste processo, os dois bancos possuíam o mesmo número e as mesmas informações.
Figura 3. Script de população da tabela Empregado

Como forma de não beneficiar nenhum dos SGBD´s na realiazação dos testes e obter resultados imparciais, foram seguidos alguns paramâtros, como:

• No momento em que um SGBD for testado, o outro será desabilitado para não interfirir no desempenho do primeiro;
• Para cada teste realizado, o computador sera reiniciado;
• A mesma consulta será realizada três vezes seguidas, tirando a sua média, assim, pode-se medir a diferença de tempo da primeira execução
com as demais;
• Não será alterado os métodos de otimização utilizados pelos próprios otimzadores de cada banco;
• Os resultados dos testes, apresentados nas tabelas de resultados, se apresentam em segundos.

Abaixo na tabela 3, segue os códigos utilizados nos testes:

Tabela 3. Comandos SQL utilizados nos testes.