Conectar o DatabaseSpy a uma base de dados SQL Azure na nuvem

Dicas e técnicas para facilitar a implementação do banco de dados SQL Azure, da Microsoft, em ambientes de produção, foram os temas principais na conferência Tech-Ed, que teve lugar em Nova Orleães, em junho. O SQL Azure é construído com base nas tecnologias do Microsoft SQL Server e foi concebido para fornecer um serviço de base de dados altamente disponível e escalável, alojado pela Microsoft na nuvem. Os programadores que implementam bases de dados no SQL Azure não precisam de instalar, configurar, aplicar atualizações ou gerir qualquer software de base de dados relacional, apenas a estrutura e o conteúdo das suas próprias bases de dados. A redundância automática e a tolerância a falhas estão integradas e não é necessária nenhuma administração física.

Pode criar uma cadeia de ligação manual e utilizar a sintaxe e os tipos de dados do SQL Server para conectar o DatabaseSpy e outras ferramentas da Altova a bases de dados SQL Azure, permitindo realizar tarefas típicas de desenvolvimento e manutenção de bases de dados. Este artigo do blog estabelece uma ligação a uma base de dados SQL Azure a partir do DatabaseSpy e demonstra várias operações típicas que poderá querer realizar ao migrar uma base de dados existente para a nuvem. Para reproduzir estes passos por conta própria, precisará de uma conta SQL Azure, ou de um nome de utilizador e senha criados por um utilizador com uma conta SQL Azure. Para obter mais informações sobre como configurar uma conta SQL Azure, visite o site da Microsoft Página inicial do SQL Azure. Será também necessário instalar o SQL Server Native Client 10.0 (ou uma versão mais recente). O SQL Azure não funciona exatamente como um servidor SQL local, por isso não podemos usar o assistente de conexão com o SQL Server da Altova. Em vez disso, utilizaremos uma ligação ODBC.

Não vamos detalhar todos os aspetos do processo de criação de uma nova cadeia de ligação aqui. Pode copiar e colar uma cadeia de ligação existente na janela que aparece acima.

Depois de se conectar ao SQL Azure pela primeira vez, um ficheiro de projeto do DatabaseSpy permite guardar todas as suas configurações de ligação, juntamente com scripts SQL frequentemente utilizados, ficheiros de design de bases de dados e comparações de bases de dados, num único ficheiro para poder carregá-los novamente mais tarde. A captura de ecrã abaixo mostra um novo projeto do DatabaseSpy com duas bases de dados conectadas simultaneamente: Sakila no MySQL e Sakila na nuvem no SQL Azure.

A Microsoft disponibiliza diversas ferramentas de conversão para ajudar os utilizadores a migrar bases de dados existentes para a plataforma SQL Azure. Utilizamos o SQL Server Migration Assistant for MySQL da Microsoft para converter a nossa base de dados de exemplo local MySQL Sakila para a nossa conta SQL Azure. O DatabaseSpy permite aos utilizadores abrir várias conexões simultaneamente, mesmo para bases de dados de diferentes tipos. A funcionalidade de comparação de bases de dados do DatabaseSpy torna-o uma ferramenta ideal para verificar os resultados da conversão do Sakila. Primeiro, vamos abrir uma comparação de esquemas de base de dados e selecionar algumas tabelas da base de dados MySQL para o lado esquerdo da comparação.

Depois de selecionarmos as tabelas correspondentes na versão SQL Azure, as tabelas são abertas numa janela de comparação de esquemas de base de dados.

Quando clicamos no botão verde "Comparar" no canto superior esquerdo da janela, o DatabaseSpy compara as estruturas do banco de dados, destaca as diferenças e gera um resumo na janela de mensagens.

Algumas diferenças representam definições de tipos de dados que variam entre as bases de dados. Por exemplo, o tipo "unsigned small int" do MySQL não tem um equivalente exato no SQL Server, pelo que a ferramenta de conversão substituiu o tipo "int" pela coluna "film_id" na tabela "film". Além disso, o tipo de dados "year" atribuído à coluna "release_year" no MySQL foi convertido para "smallint" no SQL Azure. Acredito que isto tornará a versão do SQL Azure da base de dados mais compatível com versões futuras, uma vez que poderá acomodar filmes lançados até o ano 32.767, em vez de 2155, que é o valor máximo do tipo de dados "year" no MySQL! Podemos comparar os dados contidos nas duas bases de dados através de uma seleção no menu de contexto do botão direito, abrindo as tabelas selecionadas numa nova janela de comparação de dados.

A comparação dos dados mostra que o conteúdo das tabelas não é idêntico.

Quando abrimos a janela de resultados, verificamos que a coluna de descrição não foi migrada corretamente.

Ao analisarmos a janela de comparação de esquemas de base de dados, podemos verificar que o comprimento da coluna de descrição foi definido como zero. Isso explica as setas vermelhas que apontam da coluna de descrição no MySQL para a coluna de descrição no SQL Azure na janela de resultados. Não é possível copiar qualquer texto para uma coluna com um comprimento definido como zero. Em vez disso, vamos abrir a versão do SQL Azure da tabela de filmes numa nova janela de design.

Podemos aumentar o tamanho do campo de descrição na janela de Propriedades e, em seguida, executar o script resultante para aplicar a alteração.

Em seguida, quando repetimos a comparação dos dados, verificamos que os dados foram convertidos, mas o comprimento de campo definido anteriormente como zero tornou os dados invisíveis.

Problemas de Latência Pode utilizar o DatabaseSpy para analisar problemas de latência entre a base de dados na nuvem e a cópia local. Como vimos na comparação de dados acima, as tabelas de filmes nas duas bases de dados contêm 1.000 linhas de dados idênticos. Podemos executar repetidamente instruções SELECT para obter os dados do SQL Azure e da base de dados MySQL local, a fim de medir o tempo de resposta. A janela de mensagens do editor SQL do DatabaseSpy exibe o tempo de execução.

A execução da instrução SELECT mencionada acima, repetida cinco vezes consecutivas na versão SQL Azure do banco de dados sakila, gerou resultados que variaram entre 60,632 segundos e 63,851 segundos. A execução da mesma instrução SELECT para a mesma tabela de filmes no banco de dados MySQL local resultou no seguinte:

A repetição do teste para a versão local gerou tempos semelhantes. A principal conclusão para os desenvolvedores é que a sua aplicação, que utiliza uma base de dados, provavelmente precisará de ter em conta a latência à medida que transfere os seus dados para a nuvem. Experimente a sua própria ligação ao SQL Azure com um período de teste gratuito do Altova DatabaseSpy.