SQL Server no Linux é possível?

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:

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:

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.

 Um grande abraço, pessoal, e até
a próxima.