Arquivar por categoria Banco de Dados

Formas de integração SQLite3 / PHP 5.4

Durante a migração de um site para um novo servidor constatamos algumas incompatibilidades. O banco utilizado é o SQLite. O site foi desenvolvido utilizando a API procedural de interface com o sistema de gerenciamento de banco de dados (SQLite)  que foi descontinuada na versão 5.4 do php (que é a versão do novo servidor).

Para solucionar este problema o site teve que ser adaptado para utilizar uma outra API mais atualizada, a Pdo_Sqlite, orientada a objetos. Assim nos deparamos com outra incompatibilidade: a API anterior trabalhava com a versão 2 do banco SQLite enquanto a nova trabalha com a versão 3, ou seja, a API Pdo_Sqlite não tem compatibilidade com a versão 2 do banco, que é o que estava sendo utilizado no site até então.

Assim a solução foi converter o banco da versão 2 para a versão 3, isso foi possível graças ao ótimo (e gratuito) programa SQLiteadmin que gerencia e atualiza qualquer versão do SQLite.

 

Nenhum comentário.

SQL SERVER – Como Procurar uma string em todas as tabelas

/* original script by Narayana Vyas Kondreddi, 2002 */
/* adapted by Oliver Holloway, 2009 */
/* these lines can be replaced by use of input parameter for a proc */
declare @search_string varchar(1000);
set @search_string = ‘digite aqui o que esta procurando‘;
/* create results table */
create table ##string_locations (
table_name varchar(1000),
field_name varchar(1000),
field_value varchar(8000)
)
;
/* special settings */
set nocount on
;
/* declare variables */
declare
@table_name varchar(1000),
@field_name varchar(1000)
;
/* variable settings */
set @table_name = ”
;
set @search_string = QUOTENAME(‘%’ + @search_string + ‘%’,””)
;
/* for each table */
while @table_name is not null
begin
set @field_name = ”
set @table_name = (
select MIN(QUOTENAME(table_schema) + ‘.’ + QUOTENAME(table_name))
from INFORMATION_SCHEMA.TABLES
where
table_type = ‘BASE TABLE’ and
QUOTENAME(table_schema) + ‘.’ + QUOTENAME(table_name) > @table_name and
OBJECTPROPERTY(OBJECT_ID(QUOTENAME(table_schema) + ‘.’ + QUOTENAME(table_name)), ‘IsMSShipped’) = 0
)
/* for each string-ish field */
while (@table_name is not null) and (@field_name is not null)
begin
set @field_name = (
select MIN(QUOTENAME(column_name))
from INFORMATION_SCHEMA.COLUMNS
where
table_schema = PARSENAME(@table_name, 2) and
table_name = PARSENAME(@table_name, 1) and
data_type in (‘char’, ‘varchar’, ‘nchar’, ‘nvarchar’, ‘text’, ‘ntext’) and
QUOTENAME(column_name) > @field_name
)
/* search that field for the string supplied */
if @field_name is not null
begin
insert into ##string_locations
exec(
‘select ”’ + @table_name + ”’,”’ + @field_name + ”’,’ + @field_name +
‘from ‘ + @table_name + ‘ (nolock) ‘ +
‘where patindex(‘ + @search_string + ‘,’ + @field_name + ‘) > 0′ /* patindex works with char & text */
)
end
;
end
;
end
;
/* return results */
select table_name, field_name, field_value from ##string_locations (nolock)
;
/* drop temp table */
–drop table ##string_locations
;

Nenhum comentário.

Como selecionar o último registro de cada Grupo MySql

Criando as tabelas de usuários e incluindo informações
CODE
create table `usuario` (
idusuario integer unsigned not null auto_increment,
nome varchar(30),
primary key (idusuario)
) engine=InnoDb;

insert into `usuario`
(nome) values
(“Paulo”),
(“Joao”),
(“Maria”);

create table `noticias` (
idnoticia integer unsigned not null auto_increment,
idusuario integer unsigned default 0,
noticia varchar(50) not null default ”,
datahora timestamp,
primary key (idnoticia)
) engine=InnoDb;

Incluindo algumas notícias…
CODE
insert into `noticias`
(idusuario, noticia, datahora)
values
(1, “Morreu o gato da vovó”, “2009/08/01 10:15:20″),
(1, “O ônibus atrasou hoje”, “2009/08/02 12:25:20″),
(1, “Vovó chora no enterro do gatinho”, “2009/08/03 10:35:00″),
(2, “Preço do Trigo abaixa 5%”, “2009/08/01 10:00:00″),
(2, “Aumenta o Consumo de Carne”, “2009/08/06 18:15:00″),
(3, “Encontrada a cura para a gripe A”, “2009/07/31 18:00:00″),
(3, “Procura-se Susan desesperadamente”, “2009/08/04 10:00:00″);

Selecionando a notícia mais recente de cada usuário. Isso, depois,
será uma subquery.

CODE
select max(datahora), idusuario
from `noticias`
group by idusuario

Agora que sei qual é a notícia mais recente de cada usuário,
ligo as notícias e usuários com essa subquery…
Aí vai um exemplo:

CODE
select a.idusuario, a.noticia, a.datahora
from `noticias` as a
inner join
(select max(datahora) as datahora, idusuario
from `noticias`
group by idusuario
) as b
on (a.idusuario=b.idusuario and a.datahora=b.datahora)

1 Comentário

Como realizar consultas de registros aleatórios em bancos de dados?

Maneiras Corretas de Ordernação!

No Mysql
select * from tabela order by rand()

No SQL SERVER
select * from tabela order by newid()

No PostGreSQL
Select * from tabela order by random()

No Oracle
Select coluna from (select coluna from tabela order by dbms_random.value) where rownum = 1

Nenhum comentário.

SQL – Paginação

Em MySQL a sintaxe é:
SELECT campo1, campo2 FROM tabela ORDER BY campo1 LIMIT 50,100

Em Firebase/Interbase a sintaxe é:
SELECT campo1, campo2 FROM tabela ORDER BY campo1 ROWS 50 TO 100

Em MS SQL Server a sintaxe é:
SELECT * FROM (SELECT campo1, ROWNUM qtd_linhas FROM table) WHERE qtd_linhas BETWEEN 50 AND 100;

Em PostgreSQL a sintaxe é:
SELECT campo1, campo2 FROM tabela ORDER BY campo1 LIMIT 50 OFFSET 50

Em ORACLE 8i a sintaxe é:
SELECT * FROM (SELECT * FROM tabela) WHERE ROWNUM >= 50 AND ROWNUM <= 100

Nenhum comentário.

Replicação do SQL Server para o MySQL: Parte 06

Olá pessoal! Neste artigo veremos a última parte da criação de uma replicação entre o SQL Server e o MySQL: a verificação da replicação.

  • Passo 8: Verificando a replicação

Após a execução com sucesso do passo 7, que descreve com detalhes a criação do assinante para a publicação, a replicação já está operacional, ou seja, os dados já estão sendo replicados do SQL Server. Para confirmar a replicação, basta executar o comando SHOW TABLES dentro do MySQL e verificar que a tabela MSrepl7, uma tabela auxiliar à replicação, e a tabela TB_MSSQL_MYSQL foram criadas corretamente. Além de verificar a criação das tabelas, podemos enviar uma instrução SELECT para verificar os dados. A Figura 8.1 mostra esta verificação por meio do acesso remoto no Putty, que é um cliente Windows para o SSH instalado no Linux.

Figura 8.1 Verificando as tabelas criadas pela replicação.Figura 8.1 Verificando as tabelas criadas pela replicação.

Devemos lembrar que a replicação criada é do tipo Transacional e que, neste modo, o MySQL deve apenas receber os dados e não modificá-los. Deste modo, toda a modificação nos dados realizada no SQL Server será replicada em poucos instantes para o MySQL. Para provar esta afirmação, vamos realizar um INSERT, um DELETE e um UPDATE na tabela TB_MSSQL_MYSQL do SQL Server, como a Figura 8.2 mostra.

Figura 8.2. Modificando os dados da tabela TM_MSSQL_MYSQL.Figura 8.2. Modificando os dados da tabela TM_MSSQL_MYSQL.

Após executar as três instruções devemos aguardas alguns segundos para verificar se estas modificações já foram replicadas para o MySQL. É importante lembrar que a replicação transacional vai replicar APENAS as três instruções, economizando a banda da rede. A primeira instrução executada no SQL Server faz a inserção de uma nova linha na tabela TB_MSSQL_MYSQL, com os valores 4 para a coluna ID e o caracter D para a coluna NAME. A segunda instrução apaga a primeira linha da tabela, cunho valor da coluna ID é 1. A terceira instrução coloca o caractere A para a coluna NAME na linha em que a coluna ID for igual a 2. Verificando o conteúdo da tabela TB_MSSQL_MYSQL no MySQL por meio de uma instrução SELECT, mostrado na Figura 8.3, podemos verificar que a replicação está funcionado corretamente.

Figura 8.3. Verificando a replicação dos dados no MySQL.Figura 8.3. Verificando a replicação dos dados no MySQL.

Com isso terminamos de criar a replicação do SQL Server para o MySQL como ela foi especificada. Com este tipo de replicação o MySQL pode ser utilizado como um servidor de backup dos dados, ou até mesmo como uma alternativa de acesso quando o SQL Server não estiver disponível.

Como comentário final gostaria de deixar claro que não devemos pensar em tecnologias de bancos de dados diferentes como inimigas. Esta seqüência de artigos mostrou que não é preciso enxergar o SQL Server vs. MySQL, mas sim enxergar que estas tecnologias podem trabalhar bem em conjunto. Ao invés de encarar diferentes bancos de dados como inimigos, do tipo SQL Server x MySQL, podemos imaginar SQL Server + MySQL, onde os dois bancos de dados colaboram para atender as nossas necessidades.

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

1 Comentário

Replicação do SQL Server para o MySQL: Parte 05

Olá pessoal. Dando continuidade à seqüência de artigos que ensinam como montar uma replicação do SQL Server para o MySQL, veremos nesta quinta parte como criar a assinatura para a publicação criada na sexta parte.

  • Passo 07: Assinando a publicação

Após a criação da publicação, descrita em detalhes no passo 6, devemos criar uma assinatura para esta publicação. O processo de criação de uma assinatura (subcription) geralmente é executado nos assinantes (subscribers), pois devem ser deles a iniciativa de receber os dados. Contudo, na publicação entre o SQL Server e o MySQL, e em todo tipo de replicação que envolve fontes de dados que não sejam o SQL Server, devemos configurar a assinatura diretamente no servidor de publicação.

Para iniciar a criação da assinatura devemos utilizar a janela Create and Manage Publications on PICHILIANI, que é mesma janela utilizada para a criação da publicação. Como descrito no passo 6, para acessar esta janela devemos acionado a opção Wizards… partir do Menu Tools do Enterprise Manager. Na janela de assistentes disponíveis devemos expandir o tópico Replication e escolher a opção Create Publication Wizard e clicar no botão OK. Porém, desta vez já existe a publicação chamada From SQL Server to MySQL, que aparece quando expandimos o nome do servidor. Devemos selecionar a publicação e clicar no botão Push new subscription…, como a Figura 7.1 mostra.

Figura 7.1. Selecionando a publicação From SQL Server to MySQL.Figura 7.1. Selecionando a publicação From SQL Server to MySQL.

A próxima tela do assistente apresenta a janela de boas vidas, que podemos pular apertando o botão Avançar >. Em seguida, o assistente pergunta qual será o assinante que deseja assinar a publicação. Para que o nome do servidor MySQL, identificado pelo DSN TesteMySQL parece na lista de possíveis servidores devemos seguir corretamente todas as etapas descritas no passo 5, onde habilitamos esta fonte de dados para participar em alguma replicação como assinante. Caso todas as etapas do passo 5 tenha sido seguidas corretamente e mesmo assim a fonte de dados não aparecer nesta segunda janela do assistente de criação de assinatura, basta fechar e abrir novamente o Enterprise Manager.

Nesta segunda tela do assistente devemos selecionar a fonte de dados TesteMySQL (MySQL ODBC 3.51 Driver), que deve estar dentro do item Enabled Subscribers, e clicar no botão Avançar >, como a Figura 7.2 mostra.

Figura 7.2. Selecionando o assinante da publicação.Figura 7.2. Selecionando o assinante da publicação.

A próxima tela do assistente pergunta qual é o nome do banco de dados, do assinante, que vai receber os dados da replicação. No nosso exemplo o nome do banco de dados é MSSQL_MYSQL, que foi criado no MySQL no passo 3. Basta digitar MSSQL_MYSQL no campo Subscription database name e clicar no botão Avançar >, como mostra a Figura 7.3, para seguirmos adiante no assistente.

Figura 7.3. Especificando o nome do banco de dados do assinante.Figura 7.3. Especificando o nome do banco de dados do assinante.

Na próxima tela do assistente devemos configurar a freqüência em que os dados da nossa publicação serão enviados para esta assinatura. Para suportar ambientes onde não há conectividade constante entre o Publicador/Distribuidor o SQL Server permite a criação de um horário pré-determinando e recorrente para o envio de dados da publicação. Nestes casos o SQL Server cria um agendamento específico para o job que envia os dados da replicação para os assinantes.

Como a especificação da replicação que estamos montando diz que os dados devem ser replicados o mais cedo possível, devemos escolher a primeira opção deta tela, Continuously – provides minimal latency between when an action occours at the Publishers and is propagated to the Subscriber, o que indica que a replicação será contínua e a latência será mínima. É importante lembrar que esta opção requer uma conexão constante entre o Publicador/Distribuidor e os assinantes e que esta configuração de latência é específica da assinatura e não da publicação. A Figura 7.4 mostra a opção da opção de menor latência para a assinatura que estamos criando.

Figura 7.4. Configurando a latência da assinatura.Figura 7.4. Configurando a latência da assinatura.

A penúltima tela do assistente de criação de publicação pergunta a respeito do que fazer no início da replicação. Como estamos utilizando uma replicação do tipo Transacional, podemos escolher se desejamos criar a estrutura das tabelas/view do artigo ou não. Como no nosso exemplo criamos apenas o banco de dados no MySQL, devemos marcar a opção Yes, initialize the schema and data e também a opção Star the Snapshot Agent to begin the initialization process imediately. Com estas duas opções marcadas, como na Figura 7.5, ao término do assistente de criação da assinatura a estrutura da tabela TB_MSSQL_MYSQL será criada no MySQL e os dados já começaram a ser enviados continuamente.

Figura 7.5. Configurando a inicialização do schema e dos dados.Figura 7.5. Configurando a inicialização do schema e dos dados.

Por fim o assistente de criação da assinatura mostra o status do serviço SQLServerAgent, responsável pela execução de jobs no SQL Server. Como todo o processo de replicação do SQL Server envolve jobs, é necessário manter o serviço SQLServerAgente ativado tanto no Publicador como no Distribuidor. No nosso exemplo, o servidor PICHILIANI assume os papeis de Publicador e o Distribuidor e por isso deve manter o serviço SQLServerAgent ativado. A Figura 7.6 apresenta a tela de confirmação de ativação deste serviço.

Figura 7.6. Janela de ativação do serviço SQLServerAgent.Figura 7.6. Janela de ativação do serviço SQLServerAgent.

A última tela do apenas apresenta um sumário do que foi configurado. Ao clicar no botão Finish todas as configurações da assinatura são realizadas e a publicação começa a todo vapor. A Figura 7.7 apresenta a janela de criação da assinatura após o término do assistente.

Figura 7.7. Término do assistente de criação da assinatura.Figura 7.7. Término do assistente de criação da assinatura.

Com o término do passo 7 a assinatura da publicação está pronta e funcionando. O próximo e último passo envolve a verificação da replicação de dados por meio da execução de instruções no SQL Server e no MySQL.

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

Nenhum comentário.

Replicação do SQL Server para o MySQL: Parte 04

Olá pessoal. Continuamos a falar sobre replicação do SQL Server para o MySQL, descrevendo os passos para criar uma publicação Transacional. É nesta parte que especificamos qual tabela do SQL Server será replicada, por meio da criação da publicação.

Passo 6: Criando a Publicação

Criar uma publicação no SQL Server envolve a configuração de qual banco de dados e tabelas serão utilizadas na publicação. É importante notar que podemos criar uma publicação APENAS se já tivermos configurado os servidores que agiram como Publicador e o Distribuidor. Neste nosso exemplo de replicação tanto o Publicador como o Distribuidor são a mesma máquina, chamada PICHILIANI.

Para iniciar a criação da publicação iremos utilizar o assistente de Publicação do SQL Server. Este assistente nos guiará durante todos os passos da publicação e deve ser acionado a partir do Menu Tools, opção Wizards… do Enterprise Manager. Na janela de assistentes disponíveis devemos expandir o tópico Replication e escolher a opção Create Publication Wizard e clicar no botão OK, como a Figura 6.1 mostra.

Figura 6.1. Escolha do assistente de criação de Publicação.Figura 6.1. Escolha do assistente de criação de Publicação.

Após a escolha do assistente Create Publication Wizard o SQL Server apresenta uma tela muito útil para o gerenciamento de publicações. Esta tela, apresentada na Figura 6.2, mostra cada banco de dados do servidor. Quando se expande o banco de dados são mostradas as publicações relacionadas, tornando fácil o gerenciamento de diversas publicações. Para o nosso exemplo, basta selecionar o banco de dados REPL_MSSQL_MYSQL e clicar no botão Create Publication… Como esta tela, apresentada na Figura 6.2, é utilizada para gerenciar as publicações, também vamos utilizá-la para criar a assinatura futuramente. Outros botões permitem a realização de tarefas relacionadas às publicações, como a alteração de propriedades ou a geração de scripts da publicação.

Figura 6.2. Janela de criação e configuração de publicações.Figura 6.2. Janela de criação e configuração de publicações.

Ao clicar no botão Create Publication…, com o banco de dados REPL_MSSQ_MYSQL selecionado, a janela de boas vindas do assistente para criação de uma nova publicação é apresentada. Como esta tela é apenas informativa, podemos clicar no botão Avançar > para chegarmos à tela apresentada na Figura 6.3. Nesta tela devemos apenas confirmar para qual banco de dados que será criada a publicação, que no exemplo chama-se REPL_MSSQ_MYSQL. Após confirmar o banco de dados, basta clicar em Avançar > para seguirmos com o assistente.

Figura 6.3. Janela de escolha do banco de dados que vai receber a Publicação.Figura 6.3. Janela de escolha do banco de dados que vai receber a Publicação.

A próxima tela apresenta os três tipos de replicação disponíveis, junto com uma pequena explicação. Uma pequena descrição de cada tipo é apresentada em seguida:

Replicação Snapshot: Este tipo de replicação envia toda a estrutura e os dados no momento da sincronização. Por sempre toda a estrutura e os dados este tipo de replicação geralmente é a que mais consome largura de banda e a que mais demora. É utilizada em ambientes onde os servidores que recebem os dados, os assinantes, fazem modificações nos dados que não devem ser encaminhadas e, por esta característica, a cada sincronia a base de dados deve ser completamente recriada pela replicação.

Replicação Transacional: Este é o tipo de replicação mais utilizado, pois inicialmente é feita uma sincronia da estrutura para recriar o ambiente nos assinantes. A cada novo sincronia apenas os dados que foram inseridos/modificados/excluídos do Publicador são replicados para o assinante, na forma de transações. Por replicar apenas a diferença entre dados, esta replicação é consome menos recursos e é mais fácil de gerenciar. No nosso exemplo utilizaremos este tipo de replicação. Notem que, por padrão, a replicação Transacional não permite que os assinantes modifiquem os dados, ou seja, a base de dados do assinante é somente para leitura. Porém existe como habilitar a modificação dos dados para o assinante, mas não a sua propagação para o Publicador.

Replicação Merge: A replicação Merge é o tipo de replicação onde tanto os Assinantes como os Publicadores podem modificar os dados e encaminha-los para qualquer direção. Este tipo de replicação pode resultado em conflitos nos dados, pois a modificação em um determinado dado por um Publicador e por um Assinante pode ser diferente, gerando um conflito. Em geral, este tipo de replicação é a que dá mais trabalho para gerenciar e que pode ser substituída pela criação de duas replicações do tipo Merge.

Aqui foi apresentada apenas uma explicação simples de replicação. Para mais informações recomendo fortemente a leitura do tópico de replicação no Books OnLine, a documentação eletrônica oficial da Microsoft.

Como citado anteriormente, a replicação que utilizaremos neste exemplo é do tipo Transacional, como mostrada na Figura 6.4.

Figura 6.4 Escolhendo a replicação Transacional.Figura 6.4. Escolhendo a replicação Transacional.

A próxima janela do assistente permite a especificação do tipo de assinante que estará envolvido nesta replicação. Aqui é importante lembrar que estamos acessando o MySQL por meio de um driver ODBC e por isso devemos marcar apenas a opção Heterogeneous data sources, such as Oracle or Microsoft Access; or servers running earlier versions of SQL Server, como a Figura 6.5 mostra.

Figura 6.5. Especificando fontes de dados heterogêneas na replicação.Figura 6.5. Especificando fontes de dados heterogêneas na replicação.

Na próxima etapa do assistente devemos definir um artigo, que nada mais é do que quais tabelas ou views estarão envolvidas na publicação. Um artigo pode conter várias tabelas e views, assim como uma tabela ou uma view pode estar em diferentes artigos. Para o nosso exemplo, só existe a tabela TB_MSSQL_MYSQL no banco de dados REPL_MSSQ_MYSQL e por isso devemos selecionar a opção Show do lado esquerdo da janela para mostrar a tabela TB_MSSQL_MYSQL no lado direito. Também devemos selecionar a tabela no lado esquerdo. Esta janela é apresentada na Figura 6.6, que também permite a escolha de opções avançadas da publicação quando se clica no botão Article Defaults.

Uma pequena nota: se a tabela que selecionarmos para a publicação não possuir uma chave primária ela não poderá ser incluída no artigo, ou seja, ela não poderá ser replicada. Esta é uma exigência da replicação do tipo Transacional e, como a tabela TB_MSSQL_MYSQL, criada no passo 2, contém uma chave primária na coluna ID podemos seguir adiante com o assistente.

Figura 6.6. Escolha de tabelas e views para o artigo da publicação.Figura 6.6. Escolha de tabelas e views para o artigo da publicação.

Em seguida, o assistente de publicação pergunta qual será o nome desta publicação o e qual é a descrição dela. Para facilitar, coloquei o nome desta replicação como From SQL Server to MySQL, porém pode-se colocar um nome padronizado. Também aconselho a colocação de uma descrição que contenha alguns detalhes sobre a publicação, como a Figura 6.7 mostra.

Figura 6.7. Colocando o nome e a descrição da Publicação.Figura 6.7. Colocando o nome e a descrição da Publicação.

Já estamos quase no final da criação da Publicação. Porém falta definir ainda se a publicação vai conter algum filtro. Este filtro permite que apenas algumas linhas da tabela, filtradas por uma cláusula WHERE, sejam envolvidas na publicação. Também pode-se especificar quais colunas podem ser envolvidas na replicação.

Imagem a seguinte situação: uma tabela grande contendo várias colunas precisa ser replicação da matriz para várias filiais. Porém cada filial deve receber apenas os seus dados que lhe pertencem. Uma técnica para resolver este problema de filtro de dados é a criação de uma coluna na tabela indicando qual dado deve ser replicado para qual filial. Em segunda, especifica-se um filtro como uma cláusula WHERE na replicação.

Para o nosso exemplo não utilizaremos filtros e, devido a isso, a opção No, create the publication as specified deve ser marcada, como a Figura 6.8 mostra.

Figura 6.8. Indicando que a publicação não contém filtros.Figura 6.8. Indicando que a publicação não contém filtros.

Com isso terminamos o assistente de criação de publicação. Ao clicar no botão Finish da última tela o SQL Server automaticamente já começa a criação dos jobs e depois objetos de bancos de dados necessários para a publicação, passo que é mostrado na Figura 6.9. Quando o SQL Server terminar de criar os objetos somos automaticamente redirecionados para a janela apresentada na Figura 6.2, porém agora a Publicação que acabamos de ser criada está selecionada. Notem que nada foi replicado ainda, pois nenhum assinante resolver assinar a publicação ainda.

Figura 6.9. Criação dos objetos da publicação.Figura 6.9. Criação dos objetos da publicação.

Com o término do passo 6 a publicação já está pronta para ser assinada. O próximo passo que veremos envolve a criação de uma assinatura para a publicação que foi criada no passo 6.

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

Nenhum comentário.

Replicação do SQL Server para o MySQL: Parte 03

Olá pessoal. Neste artigo vamos dar continuidade à seqüência de passos necessários para montar a replicação de dados entre o SQL Server e o MySQL. Nesta etapa veremos como configurar o acesso do SQL Server ao MySQL, por meio do driver ODBC. Para mais informações sobre a especificação da replicação, aconselho aos leitores verem as partes anteriores desta série que explica como replicar dados entre o SQL Server e o MySQL.

Passo 4: Criando o DSN

Antes de começar a configuração do ODBC que permitirá o SQL Server acessar o MySQL, é necessário instalar o driver ODBC chamado MySQL-Conector/ODBC versão 3.51.12, que é livre e pode ser baixado a partir do link http://dev.mysql.com/downloads/connector/odbc/3.51.html.

Uma vez que este driver esteja instalado e configurado, estamos quase prontos para configurar o acesso. Mas antes é necessário tomar as devidas atitudes para garantir a conectividade entre o servidor que está executando o Windows, do SQL Server, e o servidor que está executando o Linux, do MySQL.

Em termos de rede, o servidor Windows foi configurado com o endereço I.P. 192.168.1.3 e o servidor Linux foi configurado com o endereço I.P. 192.168.1.5. Deve-se verificar que os dois servidores se enxergam normalmente, ou seja, que há conectividade entre eles. Fazer o famoso teste do ping é o suficiente para verificar esta conectividade. Em seguida, deve-se verificar se há algum firewall entre o servidor Windows e o Linux. O driver ODBC utiliza a porta padrão 3306 TCP para se conectar ao MySQL. Esta porta deve estar liberada em quaisquer firewall que exista entre o servidor Windows e o servidor Linux.

Também é necessário configurar o MySQL para que ele aceite conexões provenientes do servidor Windows. Para realizar esta configuração, é necessário se conectar ao Linux, como o passo 2 desta série de colunas mostrou, e executar a instrução GRANT da Listagem 4.1, que concede o acesso remoto ao servidor MySQL. Notem que é necessário trocar o valor <sua_senha> do comando apresentado na Listagem 4.1 pela senha do usuário root.

grant all on *.* to root@(192.168.1.3) identified by "(<sua_senha>";

Listagem 4.1 Comando que permite o acesso remoto ao MySQL.

A partir deste ponto já podemos configurar o driver ODBC no Windows para que ele acesse o MySQL. Com o driver já instalado, devemos acessar o ícone Fontes de Dados (ODBC), que se encontra dentro do Painel de Controle e do ícone Tarefas Administrativas. Em seguida, devemos clicar na aba Fontes de dados do usuário e escolher o botão Adicionar…, que apresentará a tela da Figura 4.1.

Figura 4.1 Escolha do driver ODBC.Figura 4.1 Escolha do driver ODBC.

Na janela apresentada, é necessário escolher a opção MySQL ODBC 3.51 Driver, que já está selecionada na Figura 4.1. Utilizando esta opção dizemos ao Windows que desejamos criar um novo DSN (Data Source Name) que utiliza o driver ODBC para o MySQL. Clicando no botão Concluir temos a janela de configuração do driver ODBC, que deve ser preenchida de acordo com os valores apresentados na Figura 4.2.

Figura 4.2. Janela de configuração do Driver ODBC.Figura 4.2. Janela de configuração do Driver ODBC.

Os campos Data Source Name, Server, User e Password devem ser preenchidos para que possamos escolher um banco de dados no campo Database. É aconselhável clicar no botão Test para verificar se a conexão foi realizada com sucesso e, caso negativo, pode-se clicar no botão Diagnostics >> para verificar qual é a mensagem de erro que foi retornada pelo MySQL. Deste modo, criado um DSN chamado TestMySQL que aponta para o banco de dados REPLICA_MYSQL, que será o destino dos dados utilizados na replicação.

Passo 5: Habilitando o DSN

Após a criação do DSN que utiliza o driver ODBC para acessar o MySQL é preciso indicar para o SQL Server que este DSN pode ser utilizado em uma replicação. Para realizar este passo é preciso acessar a janela de configurações do servidor, através do clique com o botão direto do mouse no nome do servidor dentro do Enterprise Manager, e escolher a opção Propriedades, como a Figura 5.1 mostra.

Figura 5.1 Acessa as propriedades do servidor.Figura 5.1 Acessando as propriedades do servidor.

Com a janela de configurações do servidor aberta, apresentada na Figura 5.2, devemos selecionar a aba Replication e clicar no botão Configure… Esta nova janela contém as propriedades do Publicador e do Distribuidor e devemos clicar na aba Subscribers para indicar que o DSN chamado TesteMySQL poderá ser utilizado como assinante. A Figura 5.3 apresenta a janela de propriedades do Publicador e do Distribuidor, com a aba Subscribers selecionada.

Figura 5.2. Janela de propriedades do servidor.Figura 5.2. Janela de propriedades do servidor.

Figura 5.3 Janela de propriedades do Publicador e Distribuidor.Figura 5.3 Janela de propriedades do Publicador e Distribuidor.

A partir da janela apresentada na Figura 5.3, devemos clicar no botão New… para habilitar um possível novo assinante para o Publicador. Não é preciso selecionar o assinante PICHILIANI na lista, basta clicar no botão New…

A tela apresentada após o clique no botão New… mostra todos os tipos de assinantes que o SQL Server 2000 suporta: SQL Server Database, Microsoft Jet 4.0 database (Microsoft Access), OLE DB data source e ODBC Data Source. Devemos escolher a última opção, ODBC Data Source, conforme a Figura 5.4, e clicar no botão OK.

Figura 5.4. Habilitando um novo tipo de assinante.Figura 5.4. Habilitando um novo tipo de assinante.

Para finalizar a habilitação do novo assinante basta escolher o nome DSN TesteMySQL e especificar o login root com a sua senha na janela de configuração do DSN escolhido, de acordo com a Figura 5.5. Após clicar no botão OK da janela apresentada na Figura 5.5 basta selecionar o assinante TesteMySQL e clicar nos botões OK das duas janelas abertas até agora. Com esta configuração o SQL Server estará pronto para utilizar o MySQL apontado pelo DSN TesteMySQL como um assinante de uma publicação.

Figura 5.5. Especificando a conexão do DSN TesteMySQL.Figura 5.5. Especificando a conexão do DSN TesteMySQL.

Com o término do passo 5 a replicação já pode ser configurada. O próximo passo que veremos envolve a criação da publicação no SQL Server, onde especificaremos qual tabela deverá ser replicada e como.

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

2 Comentários

Replicação do SQL Server para o MySQL: Parte 02

Olá pessoal. Neste artigo continuamos a seqüência de passos necessários para montar a replicação de dados entre o SQL Server e o MySQL. Desta vez veremos o passo que cria o banco de dados no SQL Server, cujos dados serão replicados para o MySQL, e o passo que cria o banco de dados no MySQL, que receberá os dados do SQL Server. Para mais informações sobre a especificação da replicação aconselho aos leitores verem a primeira parte desta série de colunas.

  • Passo 2: Criando o Banco de dados no SQL Server
  •  

Neste passos criaremos um banco de dados no SQL Server que será replicado para o MySQL. Para simplificar, apenas uma tabela será criada. Esta tabela conterá duas colunas: a coluna ID, que é do tipo de dados INT e também é chave primária, e a coluna NAME, que é do tipo de dados VARCHAR(50). Aqui precisamos tomar cuidado com os tipos de dados utilizados, pois esta tabela será recriada no MySQL. Como regra, devemos sempre utilizar tipos de dados compatíveis entre os bancos de dados envolvidos na replicação.

Para criar o banco de dados e a tabela devemos nos conectar ao servidor PICHILIANI por meio da ferramenta Query Analyser e utilizar a instrução da Listagem 2.1, que cria o banco de dados REPL_MSSQL_MYSQL, a tabela TB_MSSQL_MYSQL e insere quatro linhas nesta tabela.

CREATE DATABASE REPL_MSSQL_MYSQLGOUSE REPL_MSSQL_MYSQLGO
CREATE TABLE TB_MSSQL_MYSQL(    ID INT PRIMARY KEY,     NAME VARCHAR(50))GO
INSERT TB_MSSQL_MYSQL VALUES(1,"A")INSERT TB_MSSQL_MYSQL VALUES(2,"B")
INSERT TB_MSSQL_MYSQL VALUES(3,"C")INSERT TB_MSSQL_MYSQL VALUES(4,"D")GO
SELECT * FROM TB_MSSQL_MYSQLGO

Listagem 2.1. Criação do banco de dados.

A figura 2.1 mostra a codificação da Listagem 2.1 no Query Analyser.

Figura 2.1 Codificação do código que cria a base de dados.Figura 2.1 Codificação do código que cria a base de dados.

Após a criação da base de dados é necessário clicar como botão direito do mouse sobre a pasta Databases do Enterprise Manager e escolher a opção Refresh, pois só desta maneira o novo banco de dados, chamado de REPL_MSSQL_MYSQL, será apresentado na interface gráfica.

  • Passo 3: Criando o Banco de dados no MySQL

Para criar o banco de dados no MySQL que receberá os dados do SQL Server é necessário fazer o logon no Linux e se conectar no MySQL. A Figura 3.1 apresenta o logon do usuário root no MySQL por meio do cliente de SSH chamado putty. Notem que não é obrigatório a utilização do login root para acessar o Linux e o MySQL, porém o login root será utilizado tanto no SSH como no MySQL para tornar mais fácil a explicação da replicação.

Figura 3.1 Logon no Linux por meio do SSH.Figura 3.1 Logon no Linux por meio do SSH.

Em seguida é necessário acessar o MySQL no Linux por meio do programa mysql. Uma vez conectado, devemos utilizar os comandos da listagem 3.1 para criar uma base de dados nova chamada MSSQL_MYSQL com todas as configurações padrões. Esta base de dados irá receber os dados do SQL Server por meio da replicação. Não precisamos criar manualmente a tabela que foi criada no SQL Server, pois a replicação se encarregará desta tarefa quando ela for iniciada.

CREATE DATABASE MSSQL_MYSQL;

Listagem 3.1 Comando para a criação da base de dados no MySQL

A Figura 3.2 apresenta a criação da base de dados no MySQL por meio do comando da listagem 3.1. Notem que na Figura 3.1 o comando connect; e show databases; também foram utilizados, apenas para conectar no MySQL e visualizar quais bancos de dados já existiam, respectivamente.

Figura 3.2. Criando o banco de dados no MySQL.Figura 3.2. Criando o banco de dados no MySQL.

Com isso terminamos a criação do banco de dados no SQL Server, que será a fonte de dados, e do banco de dados no MySQL, que será o destino dos dados.

Na próxima coluna veremos como configurar o acesso do Windows para o Linux, por meio do driver ODBC.

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

Nenhum comentário.