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

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.

Tabela 4. Código SQL do Update

Tabela 5. Código SQL do delete

8. Resultados alcançados

Seguindo os critérios de avaliação e códigos SQL´s descritos acima, obtiveram-se os seguintes resultados, que são detalhados na tabela 6.

Tabela 6. Resultado obtido pelo Oracle e SQL Server

A partir destes resultados, observa-se uma relativa superioridade do Oracle nas consultas 1, 2, 5 e 7, sendo mais rápido em 77.54%, 61.12%, 11.68% e 61.64% respectivamente, em relação ao SQL Server, no entanto, o SQL Server obteve um resultado superior ao Oracle nas consultas 3, 4 e 5 com uma diferença percentual de 16.42%, 26.12% e 28.58% respectivamente.

Nota-se que nas sete consultas realizadas, o Oracle apresentou-se mais ágil em quatro, e nas que o SQL Server teve um melhor desempenho, a diferença entre os dois SGBD´s foi menor em comparação as do Oracle.

Fica assim evidenciado, que os otimizadores de consultas do Oracle e SQL Server possuem formas diferentes de processar a mesma consulta, mas ambos suportaram bem os testes e obtiveram resultados semelhantes confirmando a qualidade de cada um.

Em relação ao teste de update, que afetou 226.898 mil registros, e de delete, que apagou 102.439 mil registros, o SQL Server obteve um desempenho bem mais significativo em relação ao tempo apresentado pelo Oracle.

No update realizado, o sistema da Microsoft, foi 83.49% mais rápido e no teste do delete, O SQL Server novamente obteve um melhor resultado com 36.44%.

Assim sendo, em um balanço geral de todos os testes realizados, o SQL Server foi o SGBD que apresentou um melhor desempenho em relação ao Oracle.

9.Conclusão

Os sistemas gerenciadores de bancos de dados (SGBD) têm um papel fundamental nas organizações, como forma de garantir o tratamento, a integridade e a segurança das informações, que a cada dia necessita de um cuidado especial devido ao seu grande e cada vez maior volume de dados.

No mercado de banco de dados existem várias opções de SGBD`s, mas neste trabalho foram destacados os dois principais, o Oracle e o SQL Server. Com o objetivo de mostrar algumas caracteristicas peculiares destes bancos, como o tempo de resposta, no momento de execução de vários comandos SQL (Select´s, Update e Delete).

E o resultado alcançado com este artigo, mostrou uma equiparidade entre os bancos na execução dos selects, e uma superioridade do SQL Server nos testes de update e delete. Claro, que num ambiente corporativo em produção, existe outros inúmeros fatores críticos que podem influenciar o desempenho de um banco de dados, a infra-estrutura do tráfego de rede entre o servidor e as máquinas clientes, o grande números de clientes acessando a mesma base de dados ao mesmo tempo, o hardware que compõe este ambiente, índices utilizados, enfim o desempenho de um SGBD não depende apenas de si mesmo para garantir uma boa performance.

Como esperado, os dois bancos, tanto Oracle como SQL Server, obtiveram resultados semelhantes, reforçando o potencial destes SGBD´s.

Portanto, uma empresa para escolher seu sistema de banco de dados, deve examinar muito mais que o valor de seu desempenho, mas também o seu custo de implementação e suporte, seus recursos etc, e ter em mente, que o melhor SGBD é aquele que consegue atender as necessidades existentes, da melhor maneira pelo menor custo possível.

10. Referências

AGNALDO. SQL Server. Disponível em: <http://www.50minutos.com.br/SQL-server/> Acesso em: 06 de junho de 2009.

MURARA, Sandro. Evolução dos Métodos de Otimização de Performance em Banco de Dados Oracle. Disponível em <www.inf.ufsc.br/erbd2008/palestras/sandro/SandroSGM.pps> Acesso em: 30 de maio de 2009.

DUARTE, Eber. Introdução aos mecanismos de otimização. Disponivel em: <http://www.SQLmagazine.com.br/Colunistas/eber/14_mySQLotimizacao.asp> Acesso em: 01 de junho de 2009.

GAYER, Ricardo. Oracle Free. Disponível em: <http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=2317> Acesso em: 04 de junho de 2009.

GERVAZONI, Thiago. SQL Server: Melhorando a performance através das estatísticas. Disponível em: <http://www.linhadecodigo.com.br/Artigo.aspx?id=704> Acesso em: 02 de junho de 2009.

GRUPO IMPACTA. Uso da Infra-estrutura em TI nas grandes empresas do Brasil. Disponível em: < http://www.torque.com.br/index.php?modulo=entrevistas&secao=especiais&codEntrevista=306&pagina=1&sequencia=1&codCategoria=4> Acesso em: 11 de junho de 2009.

LEGATTI, Eduardo. A evolução dos bancos de dados Oracle. Disponível em: < http://eduardolegatti.blogspot.com/2007/04/evoluo-dos-bancos-de-dados-oracle.html> Acesso em: 15 de junho de 2009.

MICROSOFT. SQL Server 2005 Express Edition. Disponível em: <http://www.microsoft.com/SQLserver/2005/en/us/express.aspx> Acesso em: 11 de junho de 2009.

MULLINS, Craing. A DB2 for z/OS Performance Roadmap. Disponível em: <http://www.craigmullins.com/zos.htm> Acesso em: 02 de junho de 2009.

ORACLE BRASIL. A história do Oracle: Inovação, Liderança e Resultados. Disponível em: <http://www.oracle.com/global/br/corporate/story.html> Acesso em: 04 de junho de 2009.

PILECKI, Maciej. Como otimizar o desempenho da consulta do SQL Server. Disponível em: <http://technet.microsoft.com/pt-br/magazine/2007.11.SQLquery.aspx> Acesso em: 03 de junho de 2009.

PINHEIRO, Nilton. Conhecendo o SQL Server 2005 Express Edition. Disponível em: <http://www.mcdbabrasil.com.br/modules.php?name=Sections&op=viewarticle&artid=22> Acesso em: 07 de junho de 2009.

RONCONI, Vinícius. Como o Oracle recupera os dados. Disponível em: <http://www.linhadecodigo.com.br/ArtigoImpressao.aspx?id=768> Acesso em: 03 de junho de 2009.

Banco de Dados - SQL Server

Leia também