Tutorial: Migrar a Base de Dados do Azure para MySQL – Servidor Único para Servidor Flexível online com o DMS através do portal do Azure
Nota
Este artigo poderá conter referências ao termo slave (secundário), um termo que a Microsoft já não utiliza. Quando o termo for removido do software, iremos removê-lo deste artigo.
Pode migrar uma instância da Base de Dados do Azure para MySQL – Servidor Único para a Base de Dados do Azure para MySQL – Servidor Flexível com o Azure Database Migration Service (DMS), um serviço totalmente gerido criado para permitir migrações contínuas de várias origens de bases de dados para plataformas de dados do Azure. Neste tutorial, realizamos uma migração online de um banco de dados de exemplo de um banco de dados do Azure para servidor único MySQL para um servidor flexível MySQL (ambos executando a versão 5.7) usando uma atividade de migração DMS.
Nota
A migração on-line do DMS agora está disponível para o público em geral. O DMS suporta a migração para as versões do MySQL 5.7 e 8.0 e também suporta a migração de servidores MySQL de versões inferiores (v5.6 e superior) para servidores de versões superiores. Além disso, o DMS oferece suporte para migrações entre regiões, entre grupos de recursos e entre subscrições, para que possa selecionar uma região, um grupo de recursos e uma subscrição para o servidor de destino diferente do especificado para o servidor de origem.
Neste tutorial, irá aprender a:
- Implemente as melhores práticas para criar um servidor flexível para cargas de dados mais rápidas usando o DMS.
- Crie e configure um servidor flexível de destino.
- Crie uma instância DMS.
- Crie um projeto de migração MySQL no DMS.
- Migre um esquema MySQL usando DMS.
- Executar a migração.
- Monitorizar a migração.
- Execute as etapas pós-migração.
- Implemente as práticas recomendadas para executar uma migração.
Pré-requisitos
Para concluir este tutorial, precisa de:
Crie ou use uma instância existente do Banco de Dados do Azure para MySQL – Servidor Único (o servidor de origem).
Para concluir a migração online com êxito, verifique se os seguintes pré-requisitos estão em vigor:
- Use a ferramenta de linha de comando MySQL de sua escolha para verificar se log_bin está ativado no servidor de origem executando o comando: MOSTRAR VARIÁVEIS COMO 'log_bin'. Se log_bin não estiver habilitado, crie uma réplica de leitura para sua instância do Servidor Único e exclua-a. Esta operação definirá o parâmetro log_bin como ON e, em seguida, você poderá acionar a operação de migração.
- Certifique-se de que o usuário tenha permissões "REPLICATION CLIENT" e "REPLICATION SLAVE" no servidor de origem para ler e aplicar o bin log.
- Se você estiver visando uma migração online, configure o parâmetro binlog_expire_logs_seconds no servidor de origem para garantir que os arquivos binlog não sejam limpos antes que a réplica confirme as alterações. Recomendamos pelo menos dois dias para começar. Após uma substituição bem-sucedida, você pode redefinir o valor.
Para concluir a migração de um esquema com êxito, no servidor de origem, o utilizador que executa a migração tem que ter os seguintes privilégios:
- Privilégio "SELECT" no nível do servidor na origem.
- Ao migrar modos de exibição, o usuário deve ter o privilégio "SHOW VIEW" no servidor de origem e o privilégio "CREATE VIEW" no servidor de destino.
- Se migrar gatilhos, o usuário deve ter o privilégio "TRIGGER" no servidor de origem e de destino. Além disso, os gatilhos só são migrados durante a substituição, você deve ser capaz de ver os gatilhos criados após a transferência concluída com êxito.
- Ao migrar rotinas (procedimentos e/ou funções), o usuário deve ter os privilégios "CREATE ROUTINE" e "ALTER ROUTINE" concedidos no nível do servidor no destino.
- Se migrar eventos, o usuário deve ter o privilégio "EVENT" no servidor de origem e de destino.
- Se migrar usuários/logins, o usuário deve ter o privilégio "CREATE USER" no servidor de destino.
- Privilégio "DROP" no nível do servidor no destino, para descartar tabelas que já possam existir. Por exemplo, ao tentar novamente uma migração.
- Privilégio "REFERÊNCIAS" no nível do servidor no destino, a fim de criar tabelas com chaves estrangeiras.
- Se migrar para o MySQL 8.0, o usuário deve ter o privilégio "SESSION_VARIABLES_ADMIN" no servidor de destino.
- Privilégio "CRIAR" no nível do servidor no destino.
- Privilégio "INSERT" no nível do servidor no destino.
- Privilégio "UPDATE" no nível do servidor no destino.
- Privilégio "DELETE" no nível do servidor no destino.
Limitações
À medida que se prepara para a migração, considere as seguintes limitações.
Ao migrar objetos que não são de tabela, o DMS não suporta mudar o nome das bases de dados.
Ao migrar para um servidor de destino com bin_log habilitado, certifique-se de habilitar log_bin_trust_function_creators para permitir a criação de rotinas e gatilhos.
Atualmente, o DMS não suporta a migração da cláusula DEFINER para objetos. Todos os tipos de objetos com definidores na origem são removidos e, após a migração, o definidor predefinido para todos os objetos que suportam uma cláusula de definidor e que são criados durante a migração do esquema, será definido como o início de sessão utilizado para executar a migração.
Atualmente, o DMS só suporta a migração de um esquema como parte do movimento de dados. Se nada estiver selecionado para o movimento de dados, a migração do esquema não ocorrerá. A seleção de uma tabela para migração de esquema também a seleciona para movimentação de dados.
O suporte para a migração online está limitado ao formato ROW binlog .
A migração online suporta agora a replicação de instruções DDL ao migrar para um servidor de destino da Base de Dados do Azure para MySQL - Servidor Flexível v8.0 ou v5.7.
- A replicação de instruções é suportada para bases de dados, tabelas e objetos de esquema (vistas, rotinas, acionadores) selecionados para migração de esquema ao configurar uma atividade de migração do Azure DMS. As instruções de definição e administração de dados para bancos de dados, tabelas e objetos de esquema que não estiverem selecionados não serão replicadas. A seleção de todo um servidor para migração irá replicar instruções para quaisquer tabelas, bases de dados e objetos de esquema criados no servidor de origem após a conclusão da carga inicial.
- A replicação de instruções do Azure DMS dá suporte a todas as instruções de Definição de Dados listadas aqui, com exceção dos seguintes comandos:
- Instruções LOGFILE GROUP
- Instruções SERVER
- Declarações do SISTEMA DE REFERÊNCIA ESPACIAL
- Instruções TABLESPACE
- A replicação de instruções do Azure DMS dá suporte a todas as instruções de Administração de Dados – Gerenciamento de Contas listadas aqui, com exceção dos seguintes comandos:
- DEFINIR FUNÇÃO PADRÃO
- DEFINIR PALAVRA-passe
- A replicação de instruções do Azure DMS dá suporte a todas as instruções de Administração de Dados – Manutenção de Tabela listadas aqui, com exceção dos seguintes comandos:
- REPAIR TABLE
- ANALYZE TABLE
- TABELA DE SOMA DE VERIFICAÇÃO
Melhores práticas para criar um servidor flexível para carregamentos de dados mais rápidos com o DMS
O DMS suporta migrações entre regiões, recursos e subscrições, pelo que pode selecionar a região, o grupo de recursos e a subscrição adequados para o servidor flexível de destino. Antes de criar o servidor flexível de destino, considere a seguinte documentação de orientação de configuração para ajudar a garantir carregamentos de dados mais rápidos com o DMS.
Selecione o tamanho da computação e a camada de computação para o servidor flexível de destino com base na camada de preços do servidor único de origem e VCores com base nos detalhes da tabela a seguir.
Escalão de Preço do Servidor Único VCores de Servidor Único Tamanho da Computação do Servidor Flexível Escalão de Computação do Servidor Flexível Básico 1 1 Fins Gerais Standard_D16ds_v4 Básico 1 2 Fins Gerais Standard_D16ds_v4 Finalidade geral 1 4 Fins Gerais Standard_D16ds_v4 Finalidade geral 1 8 Fins Gerais Standard_D16ds_v4 Fins Gerais 16 Fins Gerais Standard_D16ds_v4 Fins Gerais 32 Fins Gerais Standard_D32ds_v4 Fins Gerais 64 Fins Gerais Standard_D64ds_v4 Otimizada para Memória 4 Crítico para a Empresa Standard_E4ds_v4 Otimizada para Memória 8 Crítico para a Empresa Standard_E8ds_v4 Otimizada para Memória 16 Crítico para a Empresa Standard_E16ds_v4 Otimizada para Memória 32 Crítico para a Empresa Standard_E32ds_v4 1 Para a migração, selecione Computação vCores de uso geral 16 para o servidor flexível de destino para migrações mais rápidas. Dimensione novamente para o tamanho de computação pretendido para o servidor de destino após a conclusão da migração ao seguir a recomendação de tamanho de computação na secção Executar atividades pós-migração mais à frente neste artigo.
A versão do MySQL do servidor flexível de destino tem de ser maior ou igual à do servidor único de origem.
A menos que você precise implantar o servidor flexível de destino em uma zona específica, defina o valor do parâmetro Zona de Disponibilidade como 'Sem preferência'.
Para conectividade de rede, no separador Rede, se o servidor único de origem tiver ligações privadas ou pontos finais privados configurados, selecione Acesso Privado. Caso contrário, selecione Acesso Público.
Copie todas as regras de firewall do servidor único de origem para o servidor flexível de destino.
Copie todas as etiquetas de nome/valor do servidor único para o servidor flexível durante a criação.
Criar e configurar o servidor flexível de destino
Com essas práticas recomendadas em mente, crie seu servidor flexível de destino e configure-o.
Crie o servidor flexível de destino. Para obter etapas guiadas, consulte Guia de início rápido: criar uma instância do Banco de Dados do Azure para MySQL com o portal do Azure.
Configure o novo servidor flexível de destino da seguinte maneira:
- O usuário que executa a migração requer as seguintes permissões:
- Certifique-se de que o usuário tenha permissão "REPLICATION_APPLIER" ou "BINLOG_ADMIN" no servidor de destino para aplicar o bin log.
- Verifique se o usuário tem a permissão "REPLICATION SLAVE" no servidor de destino.
- Verifique se o usuário tem permissão "REPLICATION CLIENT" e "REPLICATION SLAVE" no servidor de origem para ler e aplicar o bin log.
- Para criar tabelas no destino, o usuário deve ter o privilégio "CREATE".
- Ao migrar uma tabela com opções de partição "DATA DIRECTORY" ou "INDEX DIRECTORY", o usuário deve ter o privilégio "FILE".
- Ao migrar para uma tabela com uma opção "UNION", o usuário deve ter os privilégios "SELECT", "UPDATE" e "DELETE" para as tabelas mapeadas para uma tabela MERGE.
- Se estiver migrando modos de exibição, você deve ter o privilégio "CREATE VIEW". Tenha em mente que alguns privilégios podem ser necessários, dependendo do conteúdo das exibições. Consulte os documentos do MySQL específicos para sua versão para "CREATE VIEW STATEMENT" para obter detalhes.
- Se migrar eventos, o usuário deve ter o privilégio "EVENT".
- Se migrar gatilhos, o usuário deve ter o privilégio "TRIGGER".
- Se estiver migrando rotinas, o usuário deve ter o privilégio "CREATE ROUTINE".
- Configure os parâmetros do servidor no servidor flexível de destino da seguinte maneira:
- Defina a versão TLS e require_secure_transport parâmetro do servidor para corresponder aos valores no servidor de origem.
- Defina o parâmetro sql_mode server para corresponder aos valores no servidor de origem.
- Configure os parâmetros do servidor no servidor de destino para corresponder a quaisquer valores não padrão usados no servidor de origem.
- Para garantir carregamentos de dados mais rápidos ao usar o DMS, configure os seguintes parâmetros de servidor conforme descrito.
- max_allowed_packet – definido como 1073741824 (ou seja, 1 GB) para evitar problemas de conexão devido a linhas grandes.
- slow_query_log – defina como OFF para desativar o log de consulta lenta. Isto eliminará a sobrecarga causada pelo registo de consultas lentas durante o carregamento de dados.
- innodb_buffer_pool_size – só pode ser aumentada dimensionando a computação para o Banco de Dados do Azure para o servidor MySQL. Aumente a escala do servidor para 64 vCore General Purpose SKU a partir da camada de preços do portal durante a migração para aumentar o innodb_buffer_pool_size.
- innodb_io_capacity & innodb_io_capacity_max - Altere para 9000 a partir dos parâmetros do Servidor no portal do Azure para melhorar a utilização de E/S para otimizar a velocidade de migração.
- innodb_write_io_threads - Mude para 4 a partir dos parâmetros do Servidor no portal do Azure para melhorar a velocidade da migração.
- Configure as réplicas no servidor de destino para corresponder àquelas no servidor de origem.
- Replique os seguintes recursos de gerenciamento de servidor do servidor único de origem para o servidor flexível de destino:
- Atribuições de funções, Funções, Negar atribuições, administradores clássicos, Controle de acesso (IAM)
- Bloqueios (somente leitura e exclusão)
- Alertas
- Tarefas
- Alertas de integridade de recursos
- O usuário que executa a migração requer as seguintes permissões:
Configurar o DMS
Com seu servidor flexível de destino implantado e configurado, você precisará configurar o DMS para migrar seu único servidor para um servidor flexível.
Registar o fornecedor de recursos
Para registrar o provedor de recursos Microsoft.DataMigration, execute as etapas a seguir.
Antes de criar sua primeira instância do DMS, entre no portal do Azure e pesquise e selecione Assinaturas.
Selecione a subscrição que pretende utilizar para criar a instância DMS e, em seguida, selecione Fornecedores de recursos.
Procure o termo "Migração" e, em seguida, para Microsoft.DataMigration, selecione Registrar.
Criar uma instância do DMS (Serviço de Migração de Banco de Dados)
No portal do Azure, selecione + Criar um recurso, procure o termo "Serviço de Migração de Banco de Dados do Azure" e selecione Serviço de Migração de Banco de Dados do Azure na lista suspensa.
No ecrã Azure Database Migration Service, selecione Criar.
Na página Selecionar cenário de migração e Serviço de Migração de Banco de Dados, em Cenário de migração, selecione Banco de Dados do Azure para MySQL-Servidor Único como o tipo de servidor de origem e, em seguida, selecione Banco de Dados do Azure para MySQL como tipo de servidor de destino e selecione Selecionar.
Na página Criar Serviço de Migração, na guia Noções básicas, em Detalhes do projeto, selecione a assinatura apropriada e, em seguida, selecione um grupo de recursos existente ou crie um novo.
Em Detalhes da instância, especifique um nome para o serviço, selecione uma região e verifique se o Azure está selecionado como o modo de serviço.
À direita de Nível de preço, selecione Configurar camada.
Na página Configurar, selecione o nível de preço Premium com 4 vCores para sua instância DMS e selecione Aplicar.
O escalão Premium do DMS com 4 vCores é gratuito durante 6 meses (183 dias) a contar da data de criação do serviço do DMS antes de começar a incorrer em custos. Para obter mais informações sobre custos DMS e níveis de preços, consulte a página de preços.
Em seguida, precisamos especificar a VNet que fornecerá à instância DMS acesso ao servidor único de origem e ao servidor flexível de destino.
Na página Criar Serviço de Migração, selecione Avançar: Rede >>.
Na guia Rede, selecione uma VNet existente na lista ou forneça o nome da nova VNet a ser criada e selecione Revisar + Criar.
Para obter mais informações, consulte o artigo Criar uma rede virtual usando o portal do Azure..
[! IMPORTANTE]
Sua rede virtual deve ser configurada com acesso ao servidor único de origem e ao servidor flexível de destino, portanto, certifique-se de:Crie uma regra de firewall no nível de servidor ou configure pontos de extremidade de serviço VNET para o Banco de Dados do Azure de origem e de destino para servidores MySQL para permitir que a VNet para o Serviço de Migração de Banco de Dados do Azure acesse os bancos de dados de origem e destino.
Certifique-se de que suas regras do NSG (Grupo de Segurança de Rede) da rede virtual não bloqueiem a porta de saída 443 do ServiceTag para ServiceBus, Armazenamento e Azure Monitor. Para obter mais informações sobre a filtragem de tráfego VNet NSG, consulte Filtrar tráfego de rede com grupos de segurança de rede.
Nota
Para adicionar tags ao serviço, avance para a guia Tags selecionando Next : Tags. Adicionar tags ao serviço é opcional.
Navegue até o separador Rever + criar , reveja as configurações, veja os termos e, em seguida, selecione Criar.
A implantação de sua instância do DMS agora começa. A mensagem Implantação está em andamento aparece por alguns minutos e, em seguida, a mensagem muda para Sua implantação está concluída.
Selecione Ir para recurso.
Identifique o endereço IP da instância do DMS na página de visão geral do recurso e crie uma regra de firewall para o servidor único de origem e o servidor flexível de destino que permita listar o endereço IP da instância do DMS.
Criar um projeto de migração
Para criar um projeto de migração, execute as etapas a seguir.
No portal do Azure, selecione Todos os serviços, procure Azure Database Migration Service e selecione Azure Database Migration Services.
Nos resultados da pesquisa, selecione a instância do DMS que você criou e selecione + Novo Projeto de Migração.
Na página Novo projeto de migração, especifique um nome para o projeto, na caixa de seleção Tipo de servidor de origem, selecione Banco de Dados do Azure Para MySQL – Servidor Único, na caixa de seleção Tipo de servidor de destino, selecione Banco de Dados do Azure Para MySQL - Servidor Flexível, na caixa de seleção Tipo de atividade de migração, selecione Migração de dados online e selecione Criar e executar atividade.
Nota
Selecionar Criar projeto somente como o tipo de atividade de migração criará apenas o projeto de migração, você poderá executar o projeto de migração posteriormente.
Configurar o projeto de migração
Para configurar seu projeto de migração DMS, execute as etapas a seguir.
Na tela Selecionar origem, localize o servidor com base na assinatura, no local e no grupo de recursos. O nome de usuário é preenchido automaticamente e, em seguida, fornece a senha para o servidor de origem.
Selecione Avançar : Selecione o destino>> e, na tela Selecionar destino, localize o servidor com base na assinatura, no local e no grupo de recursos. O nome de usuário é preenchido automaticamente e, em seguida, fornece a senha para o servidor flexível de destino.
Selecione Avançar : Selecione bancos de dados>> e, na guia Selecionar bancos de dados, em Opções de migração do servidor, selecione Migrar todos os bancos de dados aplicáveis ou, em Selecionar bancos de dados, selecione os objetos de servidor que deseja migrar.
Nota
Agora há uma opção Migrar todos os bancos de dados aplicáveis quando selecionada, essa opção migrará todos os bancos de dados e tabelas criados pelo usuário. Como o Banco de Dados do Azure para MySQL - Servidor Flexível não oferece suporte a bancos de dados de casos mistos, os bancos de dados de casos mistos na origem não serão incluídos para uma migração online.
Na seção Selecionar bancos de dados, em Banco de Dados de Origem, selecione o(s) banco(s) de dados a ser migrado(s).
Os objetos não tabelados no(s) banco(s) de dados especificado(s) serão migrados, enquanto os itens que você não selecionou serão ignorados. Você só pode selecionar os bancos de dados de origem e de destino cujos nomes correspondam aos do servidor de origem e de destino.
Se você selecionar um banco de dados no servidor de origem que não exista no servidor de destino, ele será criado no servidor de destino.
Selecione Avançar : Selecione tabelas>> para navegar até a guia Selecionar tabelas .
Antes de a guia ser preenchida, o DMS busca as tabelas do(s) banco(s) de dados selecionado(s) na origem e no destino e, em seguida, determina se a tabela existe e contém dados.
Selecione as tabelas que deseja migrar.
Se a tabela de origem selecionada não existir no servidor de destino, o processo de migração online garantirá que o esquema da tabela e os dados sejam migrados para o servidor de destino.
O DMS valida suas entradas e, se a validação for aprovada, você poderá iniciar a migração.
Depois de configurar a migração de esquema, selecione Revisar e iniciar a migração.
Nota
Você só precisa navegar até a guia Configurar configurações de migração se estiver tentando solucionar problemas de migrações com falha.
Na guia Resumo, na caixa de texto Nome da atividade, especifique um nome para a atividade de migração e revise o resumo para garantir que os detalhes de origem e destino correspondam ao que você especificou anteriormente.
Selecione Iniciar migração.
É apresentada a janela de atividade da migração e o Estado da atividade é A inicializar. O Status muda para Em execução quando as migrações de tabela são iniciadas.
Monitorize a migração
Depois que a atividade Carga Inicial for concluída, navegue até a guia Carga Inicial para exibir o status de conclusão e o número de tabelas concluídas.
Depois que a atividade Carregamento Inicial for concluída, você será navegado para a guia Replicar alterações de dados automaticamente. Você pode monitorar o progresso da migração à medida que a tela é atualizada automaticamente a cada 30 segundos.
Selecione Atualizar para atualizar a exibição e visualizar os segundos atrás da fonte como e quando necessário.
Monitore os segundos atrás da fonte e, assim que se aproximar de 0, prossiga para iniciar a substituição navegando até a guia do menu Iniciar substituição na parte superior da tela de atividade de migração.
Siga as etapas na janela de substituição antes de estar pronto para executar uma substituição.
Depois de concluir todas as etapas, selecione Confirmar e, em seguida, selecione Aplicar.
Executar atividades pós-migração
Quando a migração terminar, certifique-se de que conclui as seguintes atividades pós-migração.
Realize testes de sanidade da aplicação relativamente à base de dados de destino para certificar a migração.
Atualize a cadeia de ligação para apontar para o novo servidor flexível.
Elimine o servidor único de origem depois de garantir a continuidade da aplicação
Se você escalou o servidor flexível de destino para uma migração mais rápida, reduza-o selecionando o tamanho da computação e a camada de computação para o servidor flexível com base na camada de preços do servidor único de origem e VCores, com base nos detalhes da tabela a seguir.
Escalão de Preço do Servidor Único VCores de Servidor Único Tamanho da Computação do Servidor Flexível Escalão de Computação do Servidor Flexível Básica 1 Expansível Standard_B1s Básica 2 Expansível Standard_B2s Fins Gerais 4 Fins Gerais Standard_D4ds_v4 Fins Gerais 8 Fins Gerais Standard_D8ds_v4 Para limpar os recursos do DMS, execute os seguintes passos:
No portal do Azure, selecione Todos os serviços, procure Azure Database Migration Service e selecione Azure Database Migration Services.
Selecione a instância do serviço de migração nos resultados da pesquisa e, em seguida, selecione Eliminar serviço.
Na caixa de diálogo de confirmação, na caixa de texto INTRODUZA O NOME DO SERVIÇO DE MIGRAÇÃO DE BASES DE DADOS, especifique o nome da instância e, em seguida, selecione Eliminar.
Melhores práticas de migração
Ao realizar uma migração, certifique-se de considerar as seguintes melhores práticas.
Como parte da descoberta e avaliação, considere a SKU do servidor, a utilização da CPU, o armazenamento, os tamanhos das bases de dados e a utilização de extensões como alguns dos dados críticos para ajudar nas migrações.
Execute migrações de teste antes de migrar para produção:
- As migrações de teste são importantes para garantir que abrange todos os aspetos da migração da base de dados, incluindo o teste de aplicações. A melhor prática é começar a executar uma migração a integridade para fins de teste. Depois de uma migração recém-iniciada entrar na fase Replicar Alterações de Dados com um atraso mínimo, utilize apenas o Servidor Flexível de destino para executar cargas de trabalho de teste. Utilize este destino para testar a aplicação para garantir o desempenho e os resultados esperados. Se estiver a migrar para uma versão mais elevada do MySQL, teste a compatibilidade da aplicação.
- Após a conclusão do teste, pode migrar as bases de dados de produção. Neste ponto, tem de finalizar o dia e a hora da migração de produção. Idealmente, existe uma baixa utilização da aplicação neste momento. Todas as partes interessadas que têm de ser envolvidas devem estar disponíveis e prontas. A migração da produção requer um acompanhamento próximo. Para uma migração online, a replicação deve ser concluída antes de executar a substituição, de modo a evitar a perda de dados.
Redirecione todas as aplicações dependentes para aceder à novo base de dados primária e tornar o servidor de origem apenas de leitura. Em seguida, abra as aplicações para utilização em produção.
Depois que a aplicação começar a ser executada no servidor flexível de destino, monitorize o desempenho da base de dados atentamente para ver se é necessário um ajuste do desempenho.
Conteúdos relacionados
- O que é o Banco de Dados do Azure para MySQL - Servidor Flexível?
- O que é o Azure Database Migration Service?
- Problemas conhecidos com migrações para o Banco de Dados do Azure para MySQL
- Solucionar problemas e erros comuns do Serviço de Migração de Banco de Dados do Azure (clássico)
- Resolver problemas de erros do DMS ao ligar às bases de dados de origem