(por Marcelo Medrado)
Em todos estes anos trabalhando com bancos de dados, havia sempre um questionamento recorrente sobre qual o melhor SGBD do mercado. E o mais engraçado é que, da mesma forma que se observa conversas sobre times de futebol, bandas prediletas e religião, sempre existem opiniões que tangem ao fanatismo ao se defender o seu “banco de dados predileto”.
Mesmo evoluindo minha carreira juntamente com o Oracle há várias versões, confesso que me esforço para não ser xiita em nenhum momento e sempre me mantenho informado sobre os seus concorrentes. Vejo que o mercado evoluiu bastante e hoje nós já possuímos diversos “players” que não só fazem bonito como já incomodam os gigantes Oracle, DB2 e MS SQLServer.
Dos SGBDs que me aprofundei mais, gostaria de fazer um paralelo entre os dois bancos de dados mais usados no mundo: Oracle 10g e MS SQLServer 2005.
“Mas pera lá, por que você não está comparando o Oracle 11g com o SQL 2008?”, podem me perguntar alguns. A resposta é simples: Por que o parque instalado de bancos Oracle 10g e MSSQL 2005 é muito superior ao do seus irmãos mais “modernos”. Da mesma forma, as colocações feitas aqui são baseadas na percepção empírica de como as tão divulgadas funcionalidades de cada um deles funcionam de verdade na vida real.
É importante ressaltar que eu pretendo pontuar vantagens reais em relação aos dois produtos. Não farei nenhum tipo de comparação sobre características pouco aproveitadas como a possibilidade de se poder criar 32.000 colunas no Oracle contra “somente” 1024 do SQLServer 2005 (apesar de quê tenho uma curiosidade mórbida de descobrir se alguém, por algum motivo, trocou o seu SGBD por não conseguir satisfazer seus desejos masoquistas se criar tabelas com mais de 1024 colunas). Da mesma forma, partirei do princípio que esta comparação envolve ambientes de tamanho médio com máquinas low-end pois não só a limitação do sistema operacional da Microsoft como a própria estrutura do seu banco de dados não permite que o mesmo seja executado em ambientes maiores, com servidores high-end e aplicações extremamente complexas e críticas. Vamos aos tópicos:
Concorrência, Locks e Versionamento
Um dos grandes saltos do SQL Server 2005 em relação às versões anteriores foi o trabalho feito em relação à concorrência no acesso às informações. Uma das grandes reclamações pré-2005 era justamente sobre falta de eficiência neste quesito. Na prática, metade dos problemas de qualquer grande base em SQL Server 2000 se resumia a locks.
Nesta nova versão, o SGBD da Microsoft adotou um novo nível de isolamento chamado “Snapshot Isolation”. Trocando em miúdos o MS SQLServer (finalmente) agora tem a capacidade de criar versionamento de linha - um recurso que garante que se crie uma fotografia do banco no início de uma transação independente dos inserts, deletes e updates até que a mesma chegue ao fim.
No Oracle, não existe tal funcionalidade porém este comportamento pode ser simulado através do Flashback Database e também de consultas baseadas em timestamp, que são capazes de trazer informações como elas “eram” num tempo passado (obviamente, respeitando-se os limites parametrizáveis de retenção).
Ambas as bases agora trabalham com locks em todos os níveis - tabela, linha e coluna - porém o SQL Server 2005 possui uma controversa funcionalidade que permite que se habilite uma forma de consultar dados ainda não efetivados de outras transações.
Reorganização Online de Dados e Índices
Historicamente, o MSSQL Server possuía poucas possibilidades de reorganização em comparação aos seus grandes concorrentes DB2 e Oracle. Basicamente, índices podiam ser reorganizados, sempre com a necessidade de um lock exclusivo. A partir da versão analisada, o SQL já permite reorganização de índices sem a geração de locks, mesmo gerando um overhead de processamento razoável.
O Oracle já possui diversas funcionalidades relacionadas à reorganização de tabelas e índices. Na prática, pode-se mover uma tabela inteira no Oracle sem bloqueá-la gerando um pequeno lock apenas no momento da finalização do processo. Além disso, o Oracle 10g trouxe a possibilidade de se compactar/reorganizar tabelas movendo os blocos de forma contígua e liberando o espaço final, reduzindo fragmentação e espaço utilizado na tablespace.
Estratégias de Backup, Manutenção e Recovery
É impressionante a simplicidade de se executar tarefas no MSSQL Server 2005. Digo, com propriedade, que quem já está acostumado à dureza das scripts complexas em diferentes plataformas necessárias ao Oracle vai se sentir “nas nuvens” ao criar uma rotina de backup e manutenção no Management Studio do SGBD da Microsoft. As rotinas são criadas em forma de fluxo, como num diagrama gerado no Visio, onde você diz graficamente o que você quer, como você quer e como a rotina deve se comportar de acordo com o status de execução de cada tarefa. Simplesmente Perfeito. Em compensação, as possibilidades de backup me pareceu insuficiente para todos os cenários existentes e demasiadamente frágil.
Diferente do Oracle, não existe uma separação completa entre logs e dados, estes logs não podem ser movidos ou armazenados pois se acumulam num grande arquivo e não há a possibilidade de se manter backups redundantes. Em outras palavras, ao se fazer um backup FULL de sua base de dados, automaticamente os anteriores são invalidados. As estratégias de backup incremental são bem eficientes e úteis e satisfazem qualquer necessidade de bancos pequenos a médios. Para piorar o quadro, não existe nenhuma metodologia de exportação lógica de informações, possibilitando a restauração de uma única tabela ou usuário.
O Oracle, por sua vez, possui inúmeras possibilidades de backup diferentes. Desde as metodologias de backup físico online (cópia dos datafiles e criação de backupsets) até as diferentes formas de se gerenciar estas estruturas (automaticamente, através da flash_recovery_area que faz a gestão automática da retenção dos arquivos ou manualmente, através de scripts manuais gerenciados pelo DBA). Para alívio de alguns (e desespero de outros) as rotinas de backup na versão 10g podem ser configuradas através do Database Console, ferramenta web de administração que reúne diversas funcionalidades.
Em se tratando de recuperação, o MSSQL Server 2005 possui maior flexibilidade pois cada banco de dados possui informações de consistência próprios o que permite que bancos diferentes sejam recuperados de backups diferentes (feitos em momentos diferentes, inclusive). Por outro lado, existem diversas técnicas de recuperação (além de parâmetros não-documentados) que fazem qualquer cenário de catástrofe recuperável bastando que se mantenha uma estratégia de backup eficiente.
A ferramenta de exportação de dados lógicos do Oracle também é um show à parte: Ela possibilita que você gere um arquivo contendo todas as informações lógicas necessárias para se restaurar a base de dados inteira, em plataformas e arquiteturas diferentes.
Ambas as bases oferecem funcionalidades à parte: Anexar bases avulsas (MSSQL), transportar tablespaces entre arquiteturas diferentes (Oracle), Voltar toda uma base de dados a um momento específico do tempo (Oracle), Migrar planilhas do Excel e bases do Access de forma transparente (MSSQL), entre outras. A cada nova versão, mais flexível se tornam as técnicas de movimentação de dados.
Espelhamento
O SQL Server 2005 possui uma nova modalidade de espelhamento Ativo-Passivo semelhante ao Oracle Dataguard, através de aplicação de logs de transação. A sua simplicidade e eficiência impressionam até aos fans mais inveterados da Oracle pois pode ser implementado com alguns bocados de cliques. Para que o failover seja automático, é necessário criar uma terceira instância, chamada de forma nada criativa de “testemunha”. Este terceiro membro, tem a “nobre missão” de monitorar as bases e controlar automaticamente quem está ativo e quem está inativo/sincronizando.
No Oracle, o Dataguard faz as honras, com sua complexidade e sofisticação colocando à prova o conhecimento de qualquer DBA (de fato, existe uma certificação Oracle somente para esta funcionalidade). Ele não só faz o simples espelhamento de instância no modo ativo-passivo como pode ser usado como base para relatórios e outras diversas funcionalidades que seriam dignas de um post exclusivo neste blog.
Desenvolvimento
Confesso que fui surpreendido com o poder da linguagem Transact SQL (ou T-SQL para os íntimos) embarcada no MSSQL Server 2005. Ela não só possui todos os requisitos para se desenvolver qualquer tipo de programação estruturada nas procedures e funções como também possui uma compatibilidade nativa com toda a estrutura .NET possibilitando a escrita de procedimentos diversas linguagens (como C# e Visual FoxPro) de forma transparente. Da mesma forma, pode-se utilizar todas as APIs do Windows dentro das procedures e funções, algo que somente um SGBD e um sistema operacional com mesmo “pai e mãe” poderiam proporcionar. Funcionalidades como TRY/CATCH (comparável ao EXCEPTION do PL/SQL do Oracle), operadores relacionais, PIVOT, ROW_NUMBER e várias outras funções de ranking de linha. Existe também um suporte nativo ao XML que deixa o XML DB do Oracle com inveja.
O Oracle, por sua vez, vem evoluindo desde a versão 8i no quesito “funções analíticas” e hoje existem quase 100 funções suficientemente poderosas para enfrentar a facilidade do T-SQL. Ironicamente, até hoje o Oracle ainda não implementou a função PIVOT, disponível apenas na utilização de pacotes especiais na option OLAP, instalada separadamente.
Funcionalidades Exclusivas do Oracle 10g
LogMiner:
Esta funcionalidade provê uma forma de extrair todas as DMLs e DDLs executadas na base de dados historicamente, através dos logs de transação. É muito utilizado em auditorias, replicação ou criação de scripts de rollback. Apesar do MSSQL Server 2005 não ter algo semelhante, existem ferramentas de terceiros que podem interpretar os arquivos de log. Da mesma forma uma funcionalidade avançada chamada DDL Notification Event permite que eventos sejam disparados sempre que DDLs e DMLs sejam executados.
Flashback Query:
Outra fantástica funcionalidade do Oracle 10g que permite que consultas sejam feitas num cenário de tempo anterior ao atual. Isso quer dizer que pode-se consultar dados que estavam na tabela X na noite anterior. Da mesma forma, pode-se habilitar a recuperação de um objeto deletado, da mesma forma que se faz na lixeira do Windows. É o Oracle Recycle Bin.
Auditoria:
Com novas extensões do parâmetro AUDIT_TRAIL, todas as queries executadas podem ser auditadas incluindo as bind variables. No MSSQL Server, somente o SQL Trace pode fornecer alguma informação desta natureza mas não mostra bind variables e gera um grande overhead na performance do banco de dados.
Funcionalidades Exclusivas do MSSQL Server 2005
Identity:
Uma das funcionalidades mais úteis que o Oracle NÃO POSSUI é o campo identity numa tabela. Campos assim têm a capacidade de auto-incrementar a primary key de forma prática e simples. As sequences do Oracle são extremamente úteis e poderosas mas geram grandes sobrecargas de administração em ambientes mais complexos. Na prática, a única forma de simular isto no Oracle é criando triggers de auto-incremento.
Notification Services:
Esta funcionalidade possibilita a implementação de sistemas de notificação que disponibilizam, de forma personalizada, informações em tempos determinados, para qualquer dispositivo. Esta informação pode incluir alerta de reposição de estoque, alerta de produto indisponível e qualquer outra informação “consultável” no banco de dados. O fato dele ser integrado com o Windows possibilitando executar DLLs, e softwares, enviar e-mails e SMSs faz do Notification Services uma ferramenta poderosa.
Reporting Services:
É um serviço de geração de relatórios capaz de criar belos PDFs e com uma excelente IDE. Apesar do Reporting Services não chegar aos pés do Oracle Reports rodando sobre o Oracle IAS, o fato dele estar integrado ao SGBD é uma vantagem considerável.
Resumo da Ópera
Não subestime o poder das funcionalidades do MSSQL Server 2005. Trata-se de um banco de dados amadurecido e robusto que possui diversos atrativos ligados à simplicidade da administração, usabilidade e interface superiores e a praticidade de estar intrísecamente ligado ao sistema operacional.
Infelizmente, a comparação termina por aí. Testes atuais mostram que o Oracle possui performance semelhante ao MSSQL 2005 em plataformas Windows e seu desempenho cresce exponencialmente em plataformas UNIX e arquiteturas RISC. A possibilidade muito superior de customização de memória e parâmetros relacionados a I/O, uso de blocos de leitura e escrita, cursores e processos fazem do Oracle um banco de dados muito mais completo e robusto, portanto que se pague o preço referente ao seu custo.
Que me desculpem os DBAs Xiitas, mas eu não consigo visualizar um cenário onde existam requisitos técnicos que façam o MSSQL SQLServer uma escolha melhor para um ambiente. Notem que eu disse “requisitos técnicos”. A utilização de tecnologia Microsoft em todo parque, o conhecimento prévio da tecnologia, a limitação técnica da infraestrutura de servidores, a integração com o .NET e o custo menor de administração fazem do MSSQL Server 2005 uma excelente opção.
A Polo-iT hoje oferece administração de bases de dados Oracle e SQL Server, por um custo x benefício inigualável com monitoramento reativo e pró-ativo 24x7.
Qual deles você escolhe?
Marcelo Medrado é DBA Oracle há 9 anos além de trabalhar com dimensionamento de hardware e desenvolvimento de aplicações. Como sócio da Polo-iT, atua no DBA Center prestando consultoria a clientes Oracle e SQLServer e faz parte do núcleo de desenvolvimento das ferramentas de monitoria de bancos de dados da empresa.