Com o passar do tempo, mais empresas estão migrando para, ou pelo menos avaliando, o Banco de Dados SQL do Azure como uma alternativa ao alto custo de execução do SQL Server no local.
Verificando a compatibilidade
Um dos primeiros aspectos de mover seu banco de dados para o Banco de Dados SQL do Azure é verificar a compatibilidade e a Microsoft oferece vários maneiras de fazer isso para o Banco de Dados SQL do Azure V12 (doravante referido apenas como 'V12'). Um desses métodos é usar o SQL Server Data Tools for Visual Studio (SSDT), que usa as regras de compatibilidade mais recentes para detectar incompatibilidades V12. No SSDT, você pode importar seu esquema de banco de dados e criar um projeto para uma implantação V12 e, se alguma incompatibilidade for encontrada, ela poderá ser corrigida no SSDT e sincronizada de volta ao banco de dados de origem. Você também pode usar uma ferramenta de linha de comando chamada SqlPackage que pode gerar um relatório de problemas de compatibilidade (e sempre verifique se você tem a versão mais recente). O SQL Server Management Studio é outra maneira de fazer isso, usando o recurso Exportar Aplicativo da Camada de Dados, que pode detectar e relatar erros na tela. Se nenhum erro for detectado, você poderá migrar seu banco de dados para a V12. Se forem detectadas incompatibilidades, elas poderão ser corrigidas usando o SSMS antes da migração.
O Data Migration Assistant é uma ferramenta autônoma (facilmente confundida com o SQL Server Migration Assistant) que pode ser usada para ajudar a reduzir o esforço de atualização e substitui o SQL Server 2016 Upgrade Advisor Preview. O DMA também pode recomendar melhorias de desempenho e confiabilidade. Outra ferramenta, SQL Azure Migration Wizard (SAMW), é uma ferramenta Codeplex que usa regras de compatibilidade do Banco de Dados SQL do Azure V11 para detectar incompatibilidades V12. O SAMW também pode concluir a migração para a V12 e corrigir alguns problemas de compatibilidade. Algo a ser observado ao usar o SAMW é que ele pode detectar incompatibilidades que não precisam ser corrigidas.
Migrando dados
Depois que seu banco de dados for aprovado na verificação de compatibilidade, você deverá determinar o melhor método para migrar. Alguns dos métodos mais comuns incluem usar o Assistente de Migração do SSMS, exportar para um BACPAC, usar replicação transacional ou criar scripts manuais nos bancos de dados e inserir seus dados.
Usar o Assistente de Migração do SSMS é ótimo para bancos de dados SQL Server 2005 e superiores que são de pequeno a médio porte. Você pode ativar este assistente no SSMS 2016, clicando com o botão direito do mouse em um banco de dados, escolha Tarefas e, em seguida, Implantar Banco de Dados no Banco de Dados SQL do Microsoft Azure. No SSMS 2014, é chamado Deploy Database to Windows Azure SQL Database. O uso desse assistente permite especificar o banco de dados a ser migrado, conectar-se à sua assinatura do Azure, escolher o local do arquivo .bacpac, o novo nome do banco de dados e para qual camada migrar. Quando você clicar em concluir, o assistente extrairá e validará o esquema e exportará os dados. Depois que os dados forem exportados, ele criará um plano de implementação e começará a importar os dados para o novo banco de dados V12.
Muito semelhante ao SSMS Migration Wizard é o Export Data-tier Application. Para selecionar essa opção, clique com o botão direito do mouse no banco de dados, escolha Tarefas e, em seguida, Exportar aplicativo da camada de dados. Nas configurações de exportação, você especifica onde deseja criar o arquivo .bacpac. Você pode salvá-lo localmente ou salvá-lo diretamente em sua conta de armazenamento do Azure. Há também uma guia avançada onde você pode selecionar quais tabelas incluir. Isso é útil se seu banco de dados local contiver cópias de tabelas que você não deseja migrar para a V12. Quando você escolher Concluir, ele exportará seus dados. Em seguida, você pode se conectar ao servidor do Azure por meio do SSMS e optar por importar aplicativo da camada de dados. Você especificará o local do arquivo, o nome do banco de dados e a camada do Banco de Dados SQL do Azure. Quando você escolher concluir, o banco de dados começará a importar. Esse método oferece um pouco mais de controle sobre o processo, pois separa a exportação da importação. Ele também oferece a opção de armazenar o arquivo .bacpac em sua conta de armazenamento do Azure para que o processo de importação mais vulnerável não dependa de sua conexão com a Internet. Uma opção ao usar o Assistente de Migração do SSMS ou o Aplicativo de Camada de Dados de Exportação é criar uma VM do Azure com SQL Server e configurar o envio de logs. Isso preparará seu banco de dados na nuvem do Azure para ajudar a minimizar o tempo de importação do banco de dados. Quando chegar a hora de fazer a migração, basta restaurar os backups de log finais no secundário e remover o envio de logs. Para colocar o banco de dados online, execute uma restauração com recuperação. Isso basicamente eliminará o tempo necessário para copiar seu banco de dados do data center para o data center do Azure.
A replicação transacional é outro método para ajudar a reduzir o tempo de inatividade da migração para a V12. É a melhor opção se você tiver uma janela de manutenção extremamente pequena para mudar para a V12, se o banco de dados puder oferecer suporte à replicação transacional. A configuração da replicação transacional requer chaves primárias para cada tabela publicada, o que pode ser problemático para muitos bancos de dados. A configuração da replicação transacional também pode ser complicada, pois você precisa configurar o banco de dados de distribuição, configurar o publicador e o assinante e monitorar os trabalhos.
Você também pode migrar manualmente usando o assistente Gerar scripts e criando scripts do esquema e/ou dados do banco de dados. Você pode criar um banco de dados vazio no Azure e importar seu esquema e/ou dados executando o script. Ouvi falar de algumas pessoas usando esse método para criar o banco de dados vazio e inserir manualmente seus dados uma tabela por vez usando o SSMS e um servidor vinculado. Esse método pode funcionar para você, mas também pode ser muito complicado se você tiver muitas construções de esquema, como relacionamentos de chave estrangeira e colunas de identidade, caso em que os outros métodos acima seriam mais confiáveis e eficientes. Outras considerações sobre migração
Ao planejar a migração de bancos de dados locais para a V12, o tamanho do banco de dados é um fator importante na duração da migração. A exportação do banco de dados, a transferência dos dados e a importação aumentarão proporcionalmente ao tamanho do banco de dados.
Outro grande fator no tempo de restauração/importação ao mover seus bancos de dados para a V12 é a camada de desempenho que você está restaurando também. O processo de restauração/importação requer muita potência, portanto, para ajudar a agilizar sua migração, você deve considerar a restauração para um nível de desempenho mais alto. Quando o banco de dados está online, você pode facilmente e rapidamente descer para uma camada menor que atenda às suas necessidades diárias de desempenho. Ser capaz de alterar os níveis de desempenho com alguns cliques do mouse é um dos grandes benefícios do Banco de Dados SQL do Azure.
Monitoramento
Uma parte importante da administração de qualquer banco de dados é o monitoramento. Se você não está monitorando algo, você não pode medi-lo. Se você não sabe quais são suas métricas quando as coisas estão funcionando normalmente, como você saberá quais coisas são piores quando o desempenho é degradado? Com bancos de dados locais, temos ferramentas com as quais estamos familiarizados:SQL Server Management Studio, Monitor de desempenho, Gerenciador de tarefas, DMVs e assim por diante. Quando movemos nossos bancos de dados para a V12, perdemos a capacidade de monitorar da perspectiva do sistema operacional, e outros conceitos também mudam um pouco. Agora temos essa métrica chamada DTU para trabalhar, que significa Database Transaction Units. Pense nisso como uma combinação de CPU, dados e E/S de log de transações e memória. O Portal do Azure inclui um gráfico de monitoramento cujo padrão é ter a porcentagem de DTU verificada e você pode editar esse gráfico para incluir métricas adicionais, como:
- Bloqueado pelo firewall
- % de CPU
- Limite de DTU
- DTU usado
- E/S de dados %
- Tamanho do banco de dados %
- Impasses
- Conexões com falha
- Armazenamento OLTP na memória %
(visualização)
- Log de E/S %
- Sessões %
- Conexões bem-sucedidas
- Tamanho total do banco de dados
- Trabalhadores %
No mínimo, eu adicionaria porcentagem de CPU, porcentagem de E/S de dados, deadlocks e porcentagem de tamanho do banco de dados. Atualmente, este gráfico exibe a hora anterior de utilização de recursos.
O monitoramento por DMVs não mudou muito, além de ter alguns novos DMVs relacionados a métricas de banco de dados individuais e como calcular o tamanho do banco de dados. Um dos meus artigos anteriores aqui, Introdução ao ajuste de desempenho no Banco de Dados SQL do Azure, aborda algumas das diferenças nos scripts comuns usados para coletar latências de disco e estatísticas de espera em relação ao Banco de Dados SQL do Azure.
Ferramentas de terceiros também começaram a incluir ganchos no Banco de Dados SQL do Azure, como SentryOne com DB Sentry. O DB Sentry oferece a capacidade de monitorar o desempenho e gerenciar eventos que estão ocorrendo em seu sistema. Um recurso interessante é a função Top SQL que permite que você veja as consultas que têm mais impacto em seu desempenho geral para que você possa ajustar/corrigir quaisquer problemas com essa consulta. Outra é traçar o DTU ao longo do tempo e visualizá-lo em um painel junto com outras métricas importantes.
 Principais SQL no cliente SentryOne |  Uso de DTU no DB Sentry Dashboard |
Essas métricas são armazenadas em um banco de dados dedicado, fornecendo a capacidade de linha de base e tendência de desempenho ao longo do tempo, o que é muito melhor do que os gráficos limitados que você obtém atualmente no Portal do Azure.
Resumo
Há muitos benefícios em migrar para o Banco de Dados SQL do Azure V12, se seu banco de dados for compatível, então aproveite uma das ferramentas disponíveis para verificar sua compatibilidade com a V12. Se seu banco de dados for compatível ou puder ser facilmente modificado para se tornar compatível, você poderá migrar facilmente para o Banco de Dados SQL do Azure V12 e começar a testar e comparar seus aplicativos e cargas de trabalho.
