31 de janeiro de 2012 Banco de Dados, Desenvolvimento de Software, Mercado

Qual é o melhor Banco de Dados: ORACLE ou SQL SERVER?

Olá pessoal,

Estou escrevendo este artigo para fazer um comparativo e comentar sobre algumas vantagens e recursos dos 2 bancos de dados (BDs) mais utilizados nas grandes empresas do Brasil: Oracle e SQL Server, conforme pesquisa realizada em 2005 pelo Grupo Impacta (ver Figura 1). Embora a pesquisa de 2005 não seja tão recente, ela foi a mais confiável e concisa que eu encontrei para demonstrar a nossa realidade (o que temos nas empresas brasileiras).


Figura 1 – BDs mais utilizados nas grandes empresas brasileiras (Grupo Impacta 2005)

Conheço os 2 BDs que vou comentar neste artigo, porém conheço muito melhor o BD Oracle, por isso gostaria que os profissionais que estiverem lendo este artigo, deixem comentários que possam acrescentar mais detalhes sobre o SQL Server e recursos que existem nele e que não tenham itens correspondentes no Oracle.

Seguem abaixo as principais características de cada BD:

SQL Server:

– SGBD comercializado atualmente pela Microsoft. Nasceu em 1988, a partir de uma parceria entre Microsoft, Sybase e Aston-Tate;

– Última versão: SQL Server 2008;

– Custo de uma licença da versão Enterprise por CPU: aprox. U$ 28.000 por CPU;

– Pode ser instalado somente em SO Windows;

– Possui ferramentas de administração com interface gráfica excelentes, que possibilitam um gerenciamento mais fácil e produtivo. Ex.: SQL Server Management Studio 2008;

– Como toda ferramenta Microsoft, o BD SQL Server em geral, é mais fácil de administrar e de programar do que em Oracle.

– 2 recursos que acho bastante interessantes em SQL Server e que não existem correspondência no Oracle, são:

a) Divisão lógica de uma instância contendo vários BDs. No Oracle temos apenas vários schemas. O SQL Server possui uma camada extra onde cada BD pode conter vários usuários ou schemas. Desse modo, podemos organizar e gerenciar melhor schemas correlacionados, pertencentes a uma mesma aplicação, em um BD isolado dos demais schemas do BD;

b)  Possui um schema do sistema chamado MODEL que serve como template para schemas de usuários. Se por exemplo, o schema MODEL tiver 2 tabelas e uma visão, ao criar um novo schema de usuário, ele será criado com estes mesmos objetos.

Oracle:

–  SGBD comercializado atualmente pela Oracle, que nasceu em 1979 e que foi o primeiro BD relacional comercializado no mundo;

– Última versão: Oracle Database 11G;

– Custo de uma licença da versão Enterprise por CPU: U$ 47.500 (até 2 core);

– Pode ser instalado em múltiplas plataformas desde 1985. Entre as principais, podemos citar: Unix, Linux, HP/UX, BIM AIX, IBM VMS e Windows;

– Possui ferramentas de administração com interface gráfica menos amigáveis que as do SQL Server. Isso vem mudando e melhorando a cada nova versão do Oracle. No 10G, o Enterprise Manager possui muitos recursos e sua interface gráfica evoluiu muito, mas ainda acho que as ferramentas da Microsoft são mais intuitivas e mais produtivas. No Oracle o DBA costuma gerenciar muitas atividades do BD através de conjuntos de scripts;

– Possui uma documentação muito bem detalhada, o que de início até assusta, mas permite que você conheça muito bem o BD e todos os seus recursos;

– Possui mais recursos de segurança e performance que o SQL Server. Exemplos:

a) Por padrão, o Oracle não commita transações. Isso permite que você desfaça as alterações de uma instrução SQL, caso ela tenha sido submetido erroneamente. No SQL, por padrão as intruções SQL são auto-commitadas, o que facilita o trabalho geral dos desenvolvedores, mas que dificulta o trabalho de recuperação por danos acidentais e o controle transacional;

b) Por padrão, o Oracle permite efetuar leitura consistente de dados. Esse recurso permite que um usuário “B” leia os dados de uma linha de uma tabela, no mesmo momento em que ela está sendo alterada por um usuário “A”, sem que o usuário “B” visualize os dados que estão sendo alterados pelo “A”. Não há bloqueio de leitura nem risco do usuário “B” visualizar os dados que ainda não foram commitados pelo usuário “A”. No SQL Server esse não é o comportamento padrão do BD, portanto, desenvolvedores inexperientes poderão desenvolver aplicações com sérios problemas de performance no acesso concorrente, se não tiverem os conhecimentos necessários para contornar bloqueios de leitura aos dados;

c) Arquitetura mais flexível e com mais recursos para otimização de performance. No Oracle é possível criar e gerenciar diversas estruturas de memória no BD. É possível, por exemplo, definir estruturas de armazenamento com tamanhos de blocos que podem variar de 2k à 32k. No SQL Server só é possível criar estruturas de armazenamento de 8k. Em Oracle, sistemas OLAP e índices em geral, são otimizados com tamanhos de blocos maiores (32k);

d) Possui Packages, que são objetos que permitem (entre diversos outros benefícios) agrupar e encapsular código de stored procedures e funções;

e) Possui Sequences (que já li em alguns blogs que será implementado no SQL Server 2012). Sequences possuem muito mais recursos do que colunas de auto-incremento, existentes em SQL Server, para definir valores de chaves-primárias. Um exemplo que posso citar é o cache de Sequences, que permite otimizar a performance de inserções que necessitam de um valor único para compor a chave-primária (ver artigo http://www.fabioprado.net/2010/09/cache-em-oracle-sequences.html;

f) O Oracle possui mais tipos de índices que o SQL Server. Índices permitem otimizar consultas em BD. 2 exemplos que vou citar no Oracle que não existem itens correspondentes no SQL Server são: índices BITMAP (que permitem otimizar consultas em colunas com baixa cardinalidade) e índices Baseados em função (que permitem indexar funções em colunas);

g) Permite criar um ou mais processos chamados listeners, que são utilizados para conectar clientes remotos ao BD. Uma das vantagens de ter este tipo de processo é que a conexão ao BD pode ser distribuída entre diversos listeners, ou seja, podemos configurar múltiplos listeners para grupos menores de usuários, para ouvir em portas diferentes, com o objetivo de evitar gargalos de conexão ao BD quando temos muitos usuários (normalmente mais de 200 conexões por segundo) se conectando ao mesmo tempo;

h) O Oracle possui um modelo de controle de acesso concorrente chamado multiversion read consistency (MVRC) que é um dos melhores modelos do mercado para permitir um controle de acesso concorrente com menor contenção de linhas e consequentemente, melhor performance quando há acesso concorrente aos dados. No Oracle o controle de bloqueios é realizado através da gravação de indicadores de bloqueio no nível das linhas, já no SQL Server existe um componente chamado Lock Manager para fazer o mesmo trabalho. No Lock Manager há uma sobrecarga maior para gerenciar uma grande qtde. de bloqueios, que consequentemente pode degradar a performance de atualizações e acessos concorrentes.

CONCLUSÃO:

A percepção que eu tenho é que a Microsoft tem um histórico de manter o foco na entrega de produtos mais fáceis de se utilizar e de gerenciar. A Oracle, por sua vez, tem foco na entrega de produtos com mais segurança e com vasta gama de recursos.

Ambos são ótimos BDs e cada um tem suas vantagens e desvantagens. O SQL Server tem a principal vantagem de ter um custo menor, aproximadamente metade do preço de um Oracle. no SQL Server existem algumas funcionalidades (Ex.: Particionamento de tabelas) que também existem no Oracle, mas que no SQL Server não precisa de licença adicional, enquanto que, no Oracle, é necessário adquirir licenças adicionais (Options), o que torna o produto Oracle mais caro ainda. Outra vantagem do SQL Server é a facilidade de uso e gerenciamento. Eu, particularmente, quando comecei a trabalhar com Oracle, achava tudo muito difícil. As ferramentas do SQL Server eram mais produtivas e mais intuitivas.

O Oracle tem um custo mais alto que o SQL Server e é mais difícil de administrar, porém é um produto que possui mais recursos de segurança e performance, que podem ser muito importantes e cruciais para empresas que possuem aplicações críticas e que possuem muitos dados e muitos usuários concorrentes, em geral.

Para finalizar, vou responder agora a questão que é o título deste artigo: Qual é o melhor BD: Oracle ou SQL Server?

R.: Bom… isso depende da necessidade! De um modo geral, acredito que o SQL Server é mais indicado para pequenas e médias empresas ou pequenas e médias aplicações, devido ao custo menor desse BD e porque normalmente as aplicações que são executadas nestes ambientes possuem menor quantidade e complexidade de requisitos. O Oracle, por sua vez, é mais indicado para grandes empresas ou grandes aplicações, que possuem requisitos de negócios mais complexos e críticos, e que possuem grana para pagar pelos recursos de segurança e performance adicionais que este BD oferece.

Por hoje é só! Deixem seus comentários!

Referências:

[]s

Fonte: http://www.fabioprado.net/2012/01/qual-e-o-melhor-banco-de-dados-oracle.html

CONTEÚDOS RELACIONADOS

15 Comentários

Gilberto Hermínio
3

Olá Amigo! Ótimo artigo!
Mas, você saberia me dizer s esta pesquisa levou em conta também as pequenas e micro empresa ?

Wellington
5

Fabio,
Bastante interessante seu artigo e entendo que por não conhecer afundo o SQL Server algumas informações que você divolgou cabem argumentação ou mesmo correção.
1º – A questão sobre auto commit do sql server e configurável e mesmo assim não acredito ser um fator de avaliação pois um programa bem escrito deve prever esse tipo de situação, por exemplo ao utilizar um sql plus e realizar um insert se você fechar a tela as transações serão “comitadas” mesmo sem o comando explícito, então também seria um ponto de falha ? No sql server mesmo que você não mude a configuração padrão você também pode (ou diria deve) implantar procedimentos em Transactions para determinar oque deve ou não ser feito rollback em caso de problemas.
2º A questão sobre o acesso a um mesmo dado por duas pessoas em uma tabela mesmo no oracle é uma configuração que deve ser implantada pois o lock visa garantir integridade na informação e isso é em qualquer SGDB, e no sql SQL Server (desde os primórdios) existe um recurso chamado “read uncommited” que desde o SQL Server 2000 poderia ser utilizado o comando (nolock) após o nome da tabela que se está consultando e sao somente um mais mesmo 500 transações podem acessar a informação enquanto ela está sendo atualizada.
3º Indices – No SQL Server OLTP existem basicamente 3 tipos de indexes = fulltextsearch, clustered indexes e nonclustered indexes, desses o fulltextsearch aplica-se a campos text (não campos char/varchar) e é otimizado para pesquisas em campos que guardam informações como por exemplo código html, o index clustered é aplicado juntamente com a PK mas também pode ser aplicado em qualquer campo onde o mesmo organiza fisicamente a Tabela, ou seja, uma tabela com campos data será organizada de forma mais coerente e o retorno será mais rápido. por ultimo existe o index nonclustered que é o equivalente ao index do Oracle (lembrando que um index bitmap não é aplicado em quaquer situação)
4ºValores – os valores que você informou estão comparando um SQL Enterprise com um Oracle Standard e nessa situação o SQL Server além de vir com o SGDB também está incluso o B.I., o Integration Services (Ferramente de ETL para qq Bando de Dados) o Reporting Services e o Notification Services além de uma licença ser independente da qtd de Core (isso no SQL 2008).
5º Documentação – descordo de você, a microsoft é a melhor a nivel de documentação, inclusive 70% vem junto com o SQL no Books online, ja o metalink confunde mais que ajuda em alguns casos em que um problema tem 3 ou 4 notas de resolução.
Poderia continuar argumentando diversos situações aqui mas eu estaria escrevendo um outro artigo, não quero dizer que o Oracle é melhor ou pior, mas sou DBA e ja trabalho com os 2 a mais de 8 anos e no final das contas a unica diferença entre o ORACLE e o SQL Server é na situação em que o o RAC faz a migração dos dados em real time (que para ambientes críticos faz toda a diferença) e o ASM que foi lançado antes da compra da SUN para tentar melhorar suas leituras e gravações em disco quanto a administração da Area de Dados (lembre-se que o SQL é otimizado pela própria microsoft para Leitura dos Dados assim como um ORACLE no ORACLE LINUX tende a ter uma performane melhor), a questão do SO também é discutível pois apesar de ser instalado em LINUX somente o RED HAT (PAGO), SUSI (PAGO) e ORACLE LINUX (PAGO) são homologados e tem suporte da ORACLE e acredito que isso deve mudar pois a ORACLE tende e vai cada vez mais forçar a utilização do seu próprio SO oque acaba por ser o caminho seguido pela Microsoft.
No final das contas os 2 são equivalentes para 95% das situações pois não são poucos os que implantam Cluster com RAC AtixoXAtivo no Oracle (haja licença) e é sim mais uma questão de Gosto x Necessidade x Custo. Administro SQL Server de 10mb a 10TB e desde que a instalação e manutenção seja feita corretamente o Banco terá uma performance equivalente a de um ORACLE com situação equivalente.
Somente como adendo eu vejo muito menos problemas em SQL Server do que nos ORACLEs e não pense que a culpa é da ORACLE mas sim da instalação incorrreta que por poder ser feito em muitos S.O’s acaba por gerar mais um problema que uma vantagem.
Fico a disposição para conversarmos mais e espero ter esclarecido algumas coisas. Não pensem que sou defençor de Tecnologia Mirosoft eu acho o Oracle Fantástico e somente fiz os comentários acima para que seja de conhecimento oque o SQL Server e particularmente se procurarmos no MySQL que agora é da Oracle provavelmente também fara se ja não faz as mesmas coisas que o Oracle e o SQL Server.

Fábio Prado
6

Wellington,
Muito bom os seus comentários e obrigado por abrir essa discussão. É muito bom que profissionais experientes deixem seus comentários para abrirmos um debate e aprendermos mais. Agora vamos a minha réplica.
1- Eu, particularmente, acho ruim o auto commit no SQL Server. Muita gente começa a programar sem nem saber direito o que é um COMMIT, portanto, para o desenvolvedor inexperiente, eu acho um perigo o AUTO-COMMIT. Eu já fui um desenvolvedor inexperiente e acredito que todo mundo que começa a programar não sabe fazer um programa bem escrito! Quanto ao sair do SQL Plus e fazer um auto-commit, não vejo problemas, pois se vc está saindo é pq já fez tudo o que tinha ser feito (não precisará desfazer nada).
2- Mais uma vez eu entro aqui na questão do desenvolvedor inexperiente. Já programei com dot net acessando SQL Server 2000 e quando comecei a programar eu não conhecia o hint NOLOCK, portanto, toda aplicação que eu desenvolvia, inicialmente, ocasionava locks (desnecessários) nas leituras. O recurso de leitura consistente do Oracle evita isso! No SQL Server o desenvolvedor tem que ter mais conhecimentos para evitar os locks nas leituras e a gente vê que no mercado, muita gente que começa a trabalhar sai desenvolvendo sistemas sem ter estes conhecimentos. Estou mentindo???
3- O fulltextsearch do SQL Server corresponde ao índice Oracle Text. O índice nonclustered corresponde ao índice btree ou normal do Oracle. O indice clustered coresponde a tabelas IOT do Oracle. Acabou os índices do SQL Server? No Oracle existem ainda: indices baseados em função (bitmap ou btree), indices bitmap, indices de chave-reversa (btree), indices Spatial e outros
4- O valor que eu passei do Oracle não é do Standard, é do Enterprise Edition (veja aqui a lista de preços: http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf). De qq forma, concordo que o SQL Server nos dá muito mais recursos por um preço menor!
5- A Microsoft tem uma documentação online, com base de conhecimentos onde vc joga uma palavra e ele te dá um monte de opções de pesquisa para resolver seu problema??? A documentação do Oracle é bem extensa, o metalink tem muita coisa, por isso pode parecer confuso, pois ao pesquisar um termo, ele te dará uma série de resultados para vc identificar qual é aquele semelhante ao seu problema e que irá te ajudar! Eu conheço o Books online e sinceramente acho bastante fácil de entender mas tbém acho bem mais superficial que a documentação da Oracle.
Qto aos demais comentários há espaço para escrevermos muita coisa, mas acho melhor parar por aqui senão vamos ter que ter tempo para escrever vários artigos dentro dos comentários! Eu concordo com não existir melhor ou pior, cada um tem sua aplicação de acordo com a necessidade. Só não posso concordar que SQL SErver tem tantos recursos quanto o Oracle. A gente pode ver isso claramente na parte dos índices!
[]s

Fábio Prado
9

William, tem mais de 100% na soma pq uma empresa normalmente tem mais um de SGBD. A empresa pode ter um Oracle e um SQL Server, neste caso, ela aparece nas 2 barras correspondentes do gráfico, ok?

Audrey Cristina
12

Muito interessante o seu artigo. Estávamos essa semana discutindo o mesmo assunto na empresa em que trabalho.
Entendo que alguns problemas do SQLServer podem ser resolvidos alterando a configuração, como é o caso do auto commit, mas concordo que o Oracle é um banco de dados mais robusto e portanto mais indicado para grandes aplicações.
Uma coisa que me encomoda no Oracle é a questão da Tabela Mutante, que já poderia ter sido resolvido pela Oracle. Essa semana tivemos um problema com a Tabela Mutante, que para ser resolvido acarretaria soluções que nos fizeram desistir de utilizar o trigger e tratamos o problema de uma forma que também não me agradou muito.

Fábio Prado
13

Audrey, primeiramente obrigado pelos comentários, mas eu tenho uma opinião diferente da sua. Eu acho que o erro “mutating is table” é ótimo para evitar alterações que poderiam gerar problemas. Pense que o Oracle é um BD que prioriza a segurança dos dados. Quer um exemplo: não é meio estranho alterar os dados via update e dentro de uma trigger disparada por este comando vc alterar os mesmos dados? Eu acho estranho e sei que problemas deste tipo poderiam ser resolvidos de outra forma (mostro isso nos treinamentos de PL/SQL que eu leciono), então concordo que o erro “mutating is table” ou “tabela mutante” (na tradução grotesca), deva mesmo acontecer. De qq forma, há meios de contornar esse erro. Entre no fórum do site glufke.net/oracle e pesquise por lá que vc irá encontrar.
[]s

Audrey Cristina
14

Fábio,
Eu sei que tem tratamento para tabelas mutantes e usamos isso. mas cada caso é um caso e exitem outras implicações que não indicam o tratamento nesse caso.
Não estávamos tentando dar update em um dado que sofreu update e sim efetuar uma série de validações para ver se um conjunto de situações não aconteceria antes de salvar esse dado.
A tabela mutante ocorre quando fazemos select na tabela que sofreu update. Embora, na literatura o exemplo seja apenas com relação a faze update em um dado que sofreu update.

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!