SQL Server no Linux é possível?

hospedagemCompartilhada_megaSQL_linux Olá, pessoal. Neste artigo vou apresentar um estudo que tenta responder a uma das perguntas mais freqüentes em fóruns de bancos de dados: o SQL Server pode ser executado no Linux? Vou apresentar algumas idéias, discutir conceitos e mostrar até onde é possível trabalhar utilizando estes dois produtos em conjunto: o SQL Server e o Linux.

Podemos imaginar um cenário onde uma empresa adquire um software do tipo ERP que pode ser executado em diversas plataformas, porém requer obrigatoriamente o SQL Server como banco de dados. Se isto é ou não uma venda casada, fica o assunto para um próximo artigo. Por enquanto vamos nos preocupar em estudar alguma solução para este cenário onde é preciso, de alguma maneira, evitar que a empresa compre licenças e possa testar o seu ERP diretamente no Linux.

Neste cenário, é preciso instalar a parte servidora do SQL Server para que o software possa ser utilizado. A parte cliente do banco de dados já está programada na aplicação. Aliás, se alguém precisar executar a parte cliente do SQL Server no Linux já existem alternativas. Já discuti aqui no iMasters o uso de um driver JDBC como mecanismo de conexão ao SQL Server e também o uso do freeTDS como alternativas para a conexão de aplicações que rodam no Linux em um servidor SQL Server. Além disso, existem outras abordagens como o uso de ODBC que podem ser executadas na plataforma Unix sem problemas com unixODBC.

O primeiro aspecto a ser estudado quando se fala em SQL Server no Linux é a documentação do fabricante. De acordo com a documentação oficial do SQL Server fornecida pela Microsoft, ele pode ser executado apenas na plataforma Windows e em diversos servidores (Windows 98, 2000, 2003 etc.) dependendo da versão (7, 2000, 2005, 2008, 2008 R2) e da edição (Standard, Developer, Enterprise, MSDE etc.).

Posto isso, podemos avaliar a primeira alternativa e a mais viável: o uso de virtualização. Nesta técnica é preciso utilizar no Linux um software de virtualização como o Xen ou VMWare, por exemplo, e instalar o Windows e o SQL Server dentro deste servidor virtual. Depois desta instalação é preciso configurar a rede e pode-se utilizar o SQL Server no Linux rodando sobre um Windows virtualizado. Para casos onde é preciso apenas realizar alguns testes é possível utilizar as versões de avaliação do Windows e do SQL Server, que vão expirar em um período determinado e que podem ser úteis para testes. Contudo, estas versões de avaliação não requerem licença e geralmente têm algum tipo de limitação nos recursos dos software, como quantidade de memória máxima alocada, limite de uso de processadores, etc.

A próxima técnica que pode permitir a utilização do SQL Server no Linux de forma nativa é o uso do WINE  (Wine is not na emulator). A idéia é que este software crie todo o ambiente para executar aplicações Windows no Linux sem emular todo o sistema operacional.

O primeiro passo no estudo da emulação de alguma versão do SQL Server no Linux me levou ao repositório de aplicações no site do WINE, onde podemos verificar se é possível ou não rodar certa aplicação no WINE. Pesquisando no site, encontrei esta tentantiva de execução do SQL Server no Linux, postada em março de 2009, indicando que não seria possível executar o SQL Server MSDE SP3 no WINE. A descrição do erro diz respeito a um problema com a instalação do serviço. Resolvi arregaçar as mangas e fazer eu mesmo um teste com o WINE.

Depois de instalar o WINE  em um Linux Ubutu 8.04, chamado ubutu01, eu peguei os arquivos binários, os arquivos de dados e as entradas do registro (o registry do Windows) de uma instância padrão do SQL Server MSDE SP3 instalado previamente em um Windows XP e joguei tudo no Linux que continha o WINE, junto com a aplicação das chaves no registro. Além disso, também configurei o WINE utilizando o poderoso WineTools para instalar os componentes necessários no Linux: DCOM, MDAC, IE6, .NET framework, Windows Commom Controls e outros. Tudo ocorreu sem problemas até este ponto.

Apesar de não seguir a instalação do produto como o recomendado, eu iniciei o serviço do SQL Server MSDE no modo console utilizando o arquivo sqlservr.exe com o parâmetro -c dentre outros. Contudo, infelizmente não consegui executar o serviço com sucesso, como visto na Figura 1:

 

Figura1

Figura 1: Tentativa de executar o SQL Server 2000 MSDE pelo WINE

Pelo log de erros do SQL Server, mostrado na Figura 1, podemos ver dois erros: um problema de autenticação do NTLMSP, responsável pela comunicação e autenticação com o Windows, e um com a biblioteca de rede SSNETLIB, que foi o motivo pelo qual o serviço não iniciou completamente. Pesquisando um pouco, descobri que a biblioteca SSNETLIB.dll é um dos componentes do SQL Server que fazem parte das bibliotecas de rede do servidor e que fazem chamadas diretas à API do sistema operacional Windows Sockets 2, entre outras. Tentei de tudo: registrar a DLL, instalar outras versões do SQL Server, modificar as bibliotecas de redes pelas chaves do registro, mas não consegui passar deste ponto.

O curioso é que mesmo com iniciativas da Microsoft para interoperabilidade, como a criação de vários laboratórios de interoperabilidades específicos para isso, parece que não há nenhum interesse na portabilidade do SQL Server. Há, inclusive, até piadinhas de primeiro de abril falando sobre uma suposta versão do SQL Server para Linux utilizando a biblioteca Mono.

Além disso a comunidade de código livre também não apresentou muito interesse nesta linha de interoperabilidade, apesar de já existirem casos onde diversos jogos e softwares do Office são executados no WINE. Caso alguém se interesse por continuar o esforço, basta colocar um comentário no final do artigo.

Mas o estudo não acaba aqui. Vou comentar algumas outras abordagens que talvez possam ser interessantes para aqueles que desejam, de alguma, forma migrar do SQL Server para outro banco de dados. Algumas destas abordagens requerem modificação na aplicação no banco de dados utilizado e talvez possam não ser adequadas ao cenário descrito no começo do artigo.

Uma das alternativas interessantes é a utilização de um banco de dados que possa emular o comportamento do SQL Server de forma adequada, mais especificamente o comportamento da linguagem T-SQL, o dialeto do SQL utilizado SQL Server. Neste ponto podemos pensar no Access e também na utilização do arquivo .mdf de dados do SQL Server diretamente acoplado à aplicação no que é conhecido por SQL Server 2005 Express Edition Edition User Instances  ou pelo acrônimo RANU (Run As Normal User). Para acoplar diretamente a instalação do SQL Server a um software, eu recomendo este link que explica os detalhes deste acoplamento.

Uma outra abordagem interessante é a utilização de outro banco de dados que possua alguma compatibilidade com o T-SQL. Existem diversas alternativas que podem ser mais adequadas, porém esperava encontrar algo como o Fyracle, que é o uso do Firebird com um módulo próprio para compatibilidade com o Oracle. O mais próximo disso que encontrei foi o DotNetFirebird que possui muitas similaridades com o Access e o MSDE. Outros bancos acopláveis que talvez possuam uma compatibilidade maior com o SQL Server podem ser o SQLLite e o Sharphsql.

Outro caminho interessante seria a conversão em tempo real das instruções SQL enviadas pela aplicação para um outro banco de dados. Algo como o MySQL Proxy, que já discuti em um artigo anterior, e que possui a capacidade de captar, interpretar e modificar em tempo real as instruções enviadas pela aplicação antes delas chegarem ao banco de dados. Contudo, não encontrei nenhum software ou projeto que não precise modificar o código fonte e que faça esta tradução de instruções em tempo real. Aqui temos uma boa oportunidade para um novo projeto que talvez tenha algum mercado. Alguém se candidata?

Se observarmos o ponto de vista de conversão, podemos encontrar uma infinidade de ferramentas, aplicações, middlewares e softwares que permitem a conversão de um banco de dados para outro, com destaque especial para o MySQL e o PostgreSQL, considerados os principais bancos de dados de código livre. Estas ferramentas transformam os objetos e os dados de um banco para outro de forma off-line, ou seja, é preciso converter e trocar um banco de dados por outro. Esta opção é recomendada, mas aqui vou destacar algumas ferramentas que podem auxiliar apenas na migração das instruções.

Uma das várias ferramentas gráficas existentes que podem auxiliar na conversão das instruções entre diferentes bancos de dados é o SwissSQL Console, cuja interface é mostrada na Figura 2:

 

Figura2

Figura 2: Interface gráfica do SwissSQL Console

Notem que a interface da Figura 2 apresenta dois painéis para a digitação das instruções e que no segundo painel, mais abaixo, existem diversas abas com os nomes de alguns bancos de dados. Na parte inferior é mostrado o resultado também com as diversas abas para os bancos de dados. Esta ferramenta tem o potencial de auxiliar muito os desenvolvedores que desejam converter instruções, seja para mudar o banco de dados ou para criar uma aplicação que suporte diferentes bancos de dados (multi-banco), assim como um potencial enorme para ensinar a novos desenvolvedores a diferenças entre os dialetos da linguagem SQL.

Uma alternativa ao SwissSQL Console de código livre e voltada para o Linux é o conjunto de scripts chamado SQL Translator. Esta ferramenta permite converter todos os comandos de um arquivo .sql diretamente pela linha de comando, além de converter o esquema do banco de dados e gerar código automaticamente, entre outras funcionalidades.

Do ponto de vista de aplicação, é comum encontrar uma camada a mais de software que encapsula os detalhes da instrução SQL e da interação da aplicação com o banco de dados. Existem diversos mecanismos, APIs, frameworks, aplicações, bibliotecas e outros recursos que separam o desenvolvedor da instrução que é enviada para o banco de dados como objetivo de criar aplicações que não dependam diretamente de um banco de dados específico. Esta prática é muito comum, principalmente quando se fala em aplicações web que utilizem mecanismo de mapeamento e persistência de objetos e que muitas vezes nem utilizam um banco de dados propriamente dito. Já existe, inclusive, alguns design patterns que facilitam a implementação deste tipo de camada de software.

Sem entrar em uma discussão mais profunda do uso de camadas de software para separar o acesso aos dados, eu cito o SwissSQL API para Java como uma API que permite este tipo de programação multi-banco. Porém, existem várias soluções que seguem esta linha de raciocínio.

Com isso termino aqui este pequeno estudo que mostrou algumas abordagens e idéias para a integração do SQL Server no Linux. Apesar de existirem diversas alternativas, vale a pena lembrar que os fatores técnicos são apenas um dos aspectos a serem considerados, pois deve-se levar em conta questões como proficiência no banco de dados, acordo de licença, política, idealismo, filosofia, regras e outros fatores que acabam norteando as escolhas das ferramentas e recursos técnicos utilizados no que diz respeito a banco de dados.

 

Fonte: Desmonta&CIA

Anúncios

About Desmonta&CIA

Somos um blog que busca informar aos apaixonados por tecnologia tudo sobre o mundo de TI.

One response to “SQL Server no Linux é possível?”

  1. david says :

    Bom artigo. Quer dizer que você pode instalar o MSDE no ubuntu com vinho?
    Estou tentando, mas eu tenho muitos problemas.
    se possível contacto comigo.
    obrigado

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: