Gerenciar metadados ao disponibilizar um banco de dados em outro servidor
Aplica-se a:
SQL Server
Este artigo é relevante nas seguintes situações:
Configurando as réplicas de disponibilidade de um grupo de disponibilidade Always On.
Configurando o espelhamento de banco de dados para um banco de dados.
Ao se preparar para alterar funções entre servidores primários e secundários em uma configuração de envio de logs.
Restaurando um banco de dados para outra instância do servidor.
Anexar uma cópia de um banco de dados em outra instância do servidor.
Realizar a atualização do mecanismo de base de dados usando o método - migrar para uma nova instalação.
Migração de bancos de dados para o SQL do Azure (Máquina Virtual ou Instância Gerenciada).
Alguns aplicativos dependem de informações, entidades e/ou objetos que estão fora do escopo de um único banco de dados de usuário. Normalmente, um aplicativo tem dependências nos bancos de dados master e msdb e também no banco de dados do usuário. Qualquer coisa armazenada fora de um banco de dados de usuário que seja necessária para o funcionamento correto desse banco de dados deve ser disponibilizada na instância do servidor de destino. Por exemplo, os logons de um aplicativo são armazenados como metadados no banco de dados master e devem ser recriados no servidor de destino. Se um plano de manutenção de aplicativo ou banco de dados depender de trabalhos do SQL Server Agent, cujos metadados são armazenados no banco de dados msdb, você deverá recriar esses trabalhos na instância do servidor de destino. Da mesma forma, os metadados de um gatilho no nível do servidor são armazenados em master.
Ao mover o banco de dados de um aplicativo para outra instância do servidor, você deve recriar todos os metadados das entidades e objetos dependentes em master e msdb na instância do servidor de destino. Por exemplo, se um aplicativo de banco de dados usa gatilhos no nível do servidor, apenas anexar ou restaurar o banco de dados no novo sistema não é suficiente. O banco de dados não funcionará como esperado, a menos que você recrie manualmente os metadados para esses gatilhos no banco de dados master.
Informações, entidades e objetos armazenados fora dos bancos de dados de usuários
O restante deste artigo resume os possíveis problemas que podem afetar um banco de dados que está sendo disponibilizado em outra instância do servidor. Talvez seja necessário recriar um ou mais dos tipos de informações, entidades ou objetos listados na lista a seguir. Para ver um resumo, selecione o link para o item.
Definições de configuração do Server
Definições de configuração do servidor
O SQL Server 2005 (9.x) e versões posteriores instalam e iniciam seletivamente os principais serviços e recursos. Isso ajuda a reduzir a área de superfície atacada de um sistema. Na configuração padrão de novas instalações, muitos recursos não são habilitados. Se o banco de dados depender de qualquer serviço ou recurso desativado por padrão, esse serviço ou recurso deverá ser habilitado na instância do servidor de destino.
Para obter mais informações sobre essas configurações e como habilitá-las ou desabilitá-las, consulte Opções de configuração do Server (SQL Server).
Credenciais
Uma credencial é um registro que contém as informações de autenticação necessárias para se conectar a um recurso fora do SQL Server. A maioria das credenciais consiste em um login e senha do Windows.
Para obter mais informações sobre esse recurso, consulte Credenciais (Mecanismo de Banco de Dados).
Observação
As contas proxy do SQL Server Agent usam credenciais. Para saber o ID de credencial de uma conta proxy, use a tabela do sistema sysproxies.
Consultas entre bancos de dados
As opções de banco de dados DB_CHAINING e TRUSTWORTHY estão DESATIVADAS por padrão. Se qualquer um deles estiver definido como ON para o banco de dados original, talvez seja necessário habilitá-los no banco de dados na instância do servidor de destino. Para obter mais informações, consulte ALTER DATABASE (Transact-SQL).
As operações de anexar e desanexar desativam o encadeamento de propriedade entre várias bases de dados. Para obter informações sobre como ativar o encadeamento, consulte a opção de configuração do servidor para encadeamento de propriedade cruzada de bases de dados
Para obter mais informações, consulte também Configurar um Banco de Dados Espelho para Utilizar a Propriedade "Trustworthy" (Transact-SQL)
Propriedade do banco de dados
Quando um banco de dados é restaurado em outro computador, o logon do SQL Server ou o usuário do Windows que iniciou a operação de restauração torna-se o proprietário do novo banco de dados automaticamente. Quando o banco de dados é restaurado, o administrador do sistema ou o novo proprietário do banco de dados pode alterar a propriedade do banco de dados.
Consultas distribuídas e servidores vinculados
Consultas distribuídas e servidores vinculados são suportados para aplicativos OLE DB. As consultas distribuídas acessam dados de várias fontes de dados heterogêneas no mesmo computador ou em computadores diferentes. Uma configuração de servidor vinculado permite que o SQL Server execute comandos em fontes de dados OLE DB em servidores remotos. Para obter mais informações sobre esses recursos, consulte Servidores vinculados (Mecanismo de Banco de Dados).
Dados criptografados
Se o banco de dados que você está disponibilizando em outra instância do servidor contiver dados criptografados e se a chave mestra do banco de dados estiver protegida pela chave mestra de serviço no servidor original, talvez seja necessário recriar a criptografia da chave mestra de serviço. A chave mestra de banco de dados é uma chave simétrica usada para proteger as chaves privadas de certificados e chaves assimétricas em um banco de dados criptografado. Quando criada, a chave mestra do banco de dados é criptografada usando o algoritmo Triple DES e uma senha fornecida pelo usuário.
Para habilitar a descriptografia automática da chave mestra do banco de dados em uma instância do servidor, uma cópia dessa chave é criptografada usando a chave mestra de serviço. Essa cópia criptografada é armazenada no banco de dados e em master. Normalmente, a cópia armazenada no master é atualizada silenciosamente sempre que a chave mestra é alterada. O SQL Server tenta primeiro descriptografar a chave mestra do banco de dados com a chave mestra de serviço da instância. Se essa descriptografia falhar, o SQL Server procurará no repositório de credenciais credenciais de chave mestra que tenham o mesmo GUID de família do banco de dados para o qual ele requer a chave mestra. Em seguida, o SQL Server tenta descriptografar a chave mestra do banco de dados com cada credencial correspondente até que a descriptografia seja bem-sucedida ou não haja mais credenciais. Uma chave mestra que não é criptografada pela chave mestra de serviço deve ser aberta usando a instrução OPEN MASTER KEY e uma senha.
Quando um banco de dados criptografado é copiado, restaurado ou anexado a uma nova instância do SQL Server, uma cópia da chave mestra do banco de dados criptografada pela chave mestra de serviço não é armazenada em master na instância do servidor de destino. Na instância do servidor de destino, você deve abrir a chave mestra do banco de dados. Para abrir a chave mestra, execute a seguinte instrução: OPEN MASTER KEY DECRYPTION BY PASSWORD ='password'. Recomendamos que você habilite a descriptografia automática da chave mestra do banco de dados executando a seguinte instrução: ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY. Esta instrução ALTER MASTER KEY provisiona a instância do servidor com uma cópia da chave mestra do banco de dados criptografada com a chave mestra de serviço. Para obter mais informações, consulte ABRIR CHAVE MESTRE (Transact-SQL) e ALTERAR CHAVE MESTRE (Transact-SQL).
Para obter informações sobre como habilitar a descriptografia automática da chave mestra do banco de dados de um banco de dados espelho, consulte Configurar um banco de dados espelho criptografado.
Para obter mais informações, consulte também:
Mensagens de erro definidas pelo usuário
As mensagens de erro definidas pelo usuário residem na vista de catálogo sys.messages. Esta vista de catálogo é armazenada em master. Se um aplicativo de banco de dados depender de mensagens de erro definidas pelo usuário e o banco de dados for disponibilizado em outra instância do servidor, use sp_addmessage para adicionar essas mensagens definidas pelo usuário na instância do servidor de destino.
Notificações de eventos e eventos WMI (Instrumentação de Gerenciamento do Windows) (no nível do servidor)
Server-Level Notificações de Eventos
As notificações de eventos no nível do servidor são armazenadas em msdb. Portanto, se um aplicativo de banco de dados depender de uma notificação de evento no nível do servidor, essa notificação de evento deverá ser recriada na instância do servidor de destino. Para exibir as notificações de eventos em uma instância do servidor, use a vista de catálogo sys.server_event_notifications. Para obter mais informações, consulte Notificações de Eventos.
Além disso, as notificações de eventos são entregues usando o Service Broker. As rotas para mensagens de entrada não são incluídas no banco de dados que contém um serviço. Em vez disso, rotas explícitas são armazenadas em msdb. Se o serviço usa uma rota explícita no banco de dados msdb para rotear mensagens de entrada para o serviço, quando você anexa um banco de dados em uma instância diferente, você deve recriar essa rota.
Eventos de Instrumentação de Gerenciamento do Windows (WMI)
O Provedor WMI para Eventos de Servidor permite que você use a Instrumentação de Gerenciamento do Windows (WMI) para monitorar eventos no SQL Server. Qualquer aplicativo que dependa de eventos no nível de servidor expostos por meio do provedor WMI no qual um banco de dados depende deve ser definido como o computador da instância do servidor de destino. O provedor de eventos WMI cria notificações de eventos com um serviço de destino definido em msdb.
Observação
Para obter mais informações, consulte WMI Provider for Server Events Concepts.
Para criar um alerta WMI usando o SQL Server Management Studio
Como funcionam as notificações de eventos para um banco de dados espelhado
A entrega entre bancos de dados de notificações de eventos que envolvem um banco de dados espelhado é remota, por definição, porque o banco de dados espelhado pode fazer failover. O Service Broker fornece suporte especial para bancos de dados espelhados, na forma de rotas espelhadas . Uma rota espelhada tem dois endereços: um para a instância do servidor principal e outro para a instância do servidor espelho.
Ao configurar rotas espelhadas, você torna o roteamento do Service Broker ciente do espelhamento de banco de dados. As rotas espelhadas permitem que o Service Broker redirecione conversas de forma transparente para a instância atual do servidor principal. Por exemplo, considere um serviço, Service_A, que é hospedado por um banco de dados espelhado, Database_A. Suponha que você precise de outro serviço, Service_B, que é hospedado por Database_B, para ter um diálogo com Service_A. Para que essa caixa de diálogo seja possível, Database_B deve conter uma rota espelhada para Service_A. Além disso, Database_A deve conter uma rota de transporte TCP não espelhada para Service_B, que, ao contrário de uma rota local, permanece válida após o failover. Essas rotas permitem que os ACKs retornem após um failover. Como o serviço do remetente é sempre nomeado da mesma maneira, a rota deve especificar a instância do broker.
O requisito de rotas espelhadas aplica-se independentemente de o serviço no banco de dados espelhado ser o serviço iniciador ou o serviço de destino:
Se o serviço de destino estiver na base de dados espelhada, o serviço iniciador deve ter uma rota espelhada de retorno ao destino. No entanto, o alvo pode ter uma rota regular de volta ao iniciador.
Se o serviço do iniciador estiver no banco de dados espelhado, o serviço de destino deverá ter uma rota espelhada de volta ao iniciador para entregar confirmações e respostas. No entanto, o iniciador pode ter uma rota regular para o alvo.
Procedimentos armazenados estendidos
Importante
Esse recurso será removido em uma versão futura do SQL Server. Evite usar esse recurso em novos trabalhos de desenvolvimento e planeje modificar aplicativos que atualmente usam esse recurso. Em vez disso, use integração CLR.
Os procedimentos armazenados estendidos são programados usando a API de Procedimento Armazenado Estendido do SQL Server. Um membro do sysadmin função de servidor fixa pode registrar um procedimento armazenado estendido com uma instância do SQL Server e conceder permissão aos usuários para executar o procedimento. Os procedimentos armazenados estendidos só podem ser adicionados ao banco de dados master.
Os procedimentos armazenados estendidos são executados diretamente no espaço de endereçamento de uma instância do SQL Server e podem produzir vazamentos de memória ou outros problemas que reduzem o desempenho e a confiabilidade do servidor. Você deve considerar o armazenamento de procedimentos armazenados estendidos em uma instância do SQL Server separada da instância que contém os dados referenciados. Você também deve considerar o uso de consultas distribuídas para acessar o banco de dados.
Importante
Antes de adicionar procedimentos armazenados estendidos ao servidor e conceder permissões EXECUTE a outros usuários, o administrador do sistema deve examinar cuidadosamente cada procedimento armazenado estendido para garantir que ele não contenha código prejudicial ou mal-intencionado.
Para obter mais informações, consulte GRANT Object Permissions (Transact-SQL), DENY Object Permissions (Transact-SQL)e REVOKE Object Permissions (Transact-SQL).
Propriedades do Motor Full-Text para o SQL Server
As propriedades são definidas no Full-Text Engine por sp_fulltext_service. Verifique se a instância do servidor de destino tem as configurações necessárias para essas propriedades. Para obter mais informações sobre estas propriedades, consulte FULLTEXTSERVICEPROPERTY (Transact-SQL).
Além disso, se os componentes dos separadores de palavras e lematizadores ou os filtros de pesquisa de texto completo componente tiverem versões diferentes nas instâncias do servidor original e de destino, o índice de texto completo e as consultas podem comportar-se de forma diferente. Além disso, o dicionário de sinônimos é armazenado em arquivos específicos da instância. Você deve transferir uma cópia desses arquivos para um local equivalente na instância do servidor de destino ou recriá-los em uma nova instância.
Observação
Quando você anexa um banco de dados do SQL Server 2005 (9.x) que contém arquivos de catálogo de texto completo em uma instância do servidor SQL Server, os arquivos de catálogo são anexados de seu local anterior junto com os outros arquivos de banco de dados, o mesmo que no SQL Server 2005 (9.x). Para obter mais informações, consulte Atualizar Full-Text Pesquisar.
Para obter mais informações, consulte também:
Empregos
Se o banco de dados depender de trabalhos do SQL Server Agent, será necessário recriá-los na instância do servidor de destino. Os empregos dependem do seu ambiente. Se você planeja recriar um trabalho existente na instância do servidor de destino, a instância do servidor de destino pode ter que ser modificada para corresponder ao ambiente desse trabalho na instância do servidor original. Os seguintes fatores ambientais são significativos:
O login usado pelo trabalho
Para criar ou executar trabalhos do SQL Server Agent, você deve primeiro adicionar quaisquer logons do SQL Server exigidos pelo trabalho à instância do servidor de destino. Para obter mais informações, consulte Configurar um usuário para criar e gerenciar trabalhos do SQL Server Agent.
Conta de inicialização do serviço SQL Server Agent
A conta de inicialização do serviço define a conta do Microsoft Windows na qual o SQL Server Agent é executado e suas permissões de rede. O SQL Server Agent é executado como uma conta de usuário especificada. O contexto do serviço do Agente afeta as configurações da tarefa e do seu ambiente de execução. A conta deve ter acesso aos recursos, como compartilhamentos de rede, exigidos pelo trabalho. Para obter informações sobre como selecionar e modificar a conta de inicialização do serviço, consulte Select an Account for the SQL Server Agent Service.
Para funcionar corretamente, a conta de inicialização do serviço deve ser configurada para ter as permissões corretas de domínio, sistema de arquivos e registro. Além disso, um trabalho pode exigir um recurso de rede compartilhado que deve ser configurado para a conta de serviço. Para obter informações, consulte Configurar contas de serviço e permissões do Windows.
O serviço SQL Server Agent, que está associado a uma instância específica do SQL Server, tem sua própria seção do Registro e seus trabalhos normalmente têm dependências em uma ou mais das configurações nessa seção do Registro. Para se comportar como pretendido, um trabalho requer essas configurações do Registro. Se você usar um script para recriar um trabalho em outro serviço do SQL Server Agent, seu registro pode não ter as configurações corretas para esse trabalho. Para que os trabalhos recriados se comportem corretamente em uma instância do servidor de destino, os serviços do SQL Server Agent original e de destino devem ter as mesmas configurações do Registro.
Atenção
Alterar as configurações do Registro no serviço SQL Server Agent de destino para lidar com um trabalho recriado pode ser problemático se as configurações atuais forem exigidas por outros trabalhos. Além disso, a edição incorreta do registo pode danificar gravemente o seu sistema. Antes de fazer alterações no Registro, recomendamos que você faça backup de todos os dados valiosos no computador.
Proxies do Agente do SQL Server
Um proxy do SQL Server Agent define o contexto de segurança para uma etapa de trabalho especificada. Para que um trabalho seja executado na instância do servidor de destino, todos os proxies necessários devem ser recriados manualmente nessa instância. Para obter mais informações, consulte Criar um proxy do Agente do SQL Server e Solucionar problemas de trabalhos multisservidores que utilizam proxies.
Para obter mais informações, consulte também:
Gerenciamento de logins e trabalhos após a troca de função (SQL Server) (para espelhamento de banco de dados)
Configurar contas de serviço e permissões do Windows (quando você instala uma instância do SQL Server)
Configurar o SQL Server Agent (quando você instala uma instância do SQL Server)
Para exibir trabalhos existentes e suas propriedades
Criar um emprego
Práticas recomendadas para usar um script para recriar um trabalho
Recomendamos que você comece criando scripts para um trabalho simples, recriando o trabalho no outro serviço do SQL Server Agent e executando o trabalho para ver se ele funciona como pretendido. Isso permitirá que você identifique incompatibilidades e tente resolvê-las. Se um trabalho com script não funcionar como pretendido em seu novo ambiente, recomendamos que você crie um trabalho equivalente que funcione corretamente nesse ambiente.
Logins
Fazer logon em uma instância do SQL Server requer um logon válido do SQL Server. Esse logon é usado no processo de autenticação que verifica se a entidade de segurança pode se conectar à instância do SQL Server. Um usuário de banco de dados para o qual o logon correspondente do SQL Server é indefinido ou está incorretamente definido em uma instância do servidor não pode fazer logon na instância. Diz-se que esse usuário é um usuário órfão do banco de dados nessa instância do servidor. Um usuário de banco de dados pode ficar órfão se depois que um banco de dados for restaurado, anexado ou copiado para uma instância diferente do SQL Server.
Para gerar um script para alguns ou todos os objetos na cópia original da base de dados, pode usar o Assistente para Gerar Scripts e, na caixa de diálogo Escolher Opções de Script, definir a opção Criar Scripts para Logins como True.
Observação
Para obter informações sobre como configurar logins para um banco de dados espelhado, consulte Configurar contas de login para espelhamento de banco de dados ou grupos de disponibilidade Always On (SQL Server) e Gestão de logins e tarefas após a mudança de função (SQL Server).
Permissões
Os seguintes tipos de permissões podem ser afetados quando um banco de dados é disponibilizado em outra instância do servidor.
CONCEDER, REVOGAR ou NEGAR permissões em objetos do sistema
CONCEDER, REVOGAR ou NEGAR permissões na instância do servidor (permissões no nível do servidor)
Definir, Revogar, e Negar Permissões em Objetos do Sistema
As permissões em objetos do sistema, como procedimentos armazenados, procedimentos armazenados estendidos, funções e exibições, são armazenadas no banco de dados master e devem ser configuradas na instância do servidor de destino.
Para gerar um script para alguns ou todos os objetos na cópia original da base de dados, pode utilizar o Assistente para Gerar Scripts e, na caixa de diálogo Escolher Opções de Script, defina a opção Script Object-Level Permissões como True.
Importante
Se você criar scripts de logins, as senhas não serão roteirizadas. Se você tiver logons que usam a Autenticação do SQL Server, será necessário modificar o script no destino.
Os objetos do sistema são visíveis na exibição do catálogo sys.system_objects. As permissões em objetos do sistema são visíveis na vista de catálogo sys.database_permissions na base de dados master. Para obter informações sobre como consultar essas exibições de catálogo e conceder permissões de objeto do sistema, consulte GRANT System Object Permissions (Transact-SQL). Para obter mais informações, consulte REVOKE System Object Permissions (Transact-SQL) e DENY System Object Permissions (Transact-SQL).
Conceder, revogar e negar permissões em uma instância de servidor.
As permissões no escopo do servidor são armazenadas no banco de dados master e devem ser configuradas na instância do servidor de destino. Para obter informações sobre as permissões de servidor de uma instância de servidor, consulte a exibição de catálogo sys.server_permissions, para informações sobre entidades de servidor, consulte a exibição de catálogo sys.server_principals, e para informações sobre associação de funções de servidor, consulte a exibição de catálogo sys.server_role_members.
Para obter mais informações, consulte CONCEDER Permissões do Servidor (Transact-SQL), REVOGAR Permissões do Servidor (Transact-SQL)e NEGAR Permissões do Servidor (Transact-SQL).
Server-Level permissões para um certificado ou chave assimétrica
As permissões no nível do servidor não podem ser concedidas diretamente a um certificado ou chave assimétrica. Em vez disso, as permissões no nível do servidor são concedidas a um logon mapeado que é criado exclusivamente para um certificado específico ou chave assimétrica. Portanto, cada certificado ou chave assimétrica que requer permissões ao nível do servidor requer seu próprio logon mapeado por certificado ou logon mapeado por chave assimétrica . Para conceder permissões no nível do servidor para um certificado ou chave assimétrica, conceda as permissões para seu login mapeado.
Observação
Um login mapeado é usado apenas para autorização de código assinado com o certificado correspondente ou chave assimétrica. Os logins mapeados não podem ser usados para autenticação.
O login mapeado e suas permissões residem em master. Se um certificado ou chave assimétrica residir em um banco de dados diferente de master, você deverá recriá-lo em master e mapeá-lo para um login. Se você mover, copiar ou restaurar o banco de dados para outra instância do servidor, deverá recriar seu certificado ou chave assimétrica no banco de dados master da instância do servidor de destino, mapear para um logon e conceder as permissões necessárias no nível do servidor para o logon.
Para criar um certificado ou uma chave assimétrica
Para mapear um certificado ou uma chave assimétrica para um de login
Para atribuir permissões ao de login mapeado
Para obter mais informações sobre certificados e chaves assimétricas, consulte Encryption Hierarchy.
Propriedade de Confiança
A propriedade de banco de dados TRUSTWORTHY é usada para indicar se essa instância do SQL Server confia no banco de dados e no conteúdo dele. Quando um banco de dados é anexado, por padrão e por segurança, essa opção é definida como OFF, mesmo que tenha sido definida como ON no servidor original. Para obter mais informações sobre esta propriedade, consulte a propriedade TRUSTWORTHY do banco de dados e, para obter informações sobre como ativar esta opção, consulte ALTER DATABASE (Transact-SQL).
Configurações de replicação
Se você restaurar um backup de um banco de dados replicado para outro servidor ou banco de dados, as configurações de replicação não poderão ser preservadas. Nesse caso, você deve recriar todas as publicações e assinaturas depois que os backups forem restaurados. Para facilitar esse processo, crie scripts para suas configurações de replicação atuais e, também, para habilitar e desabilitar a replicação. Para ajudar a recriar as configurações de replicação, copie estes scripts e altere as referências de nome de servidor para que funcionem na instância do servidor de destino.
Para obter mais informações, consulte Backup e Restauração de Bancos de Dados Replicados, Espelhamento e Replicação de Banco de Dados (SQL Server), e Envio e Replicação de Logs (SQL Server).
Aplicativos do Service Broker
Muitos aspetos de uma aplicação do Service Broker são transferidos com a base de dados. No entanto, alguns aspetos do aplicativo devem ser recriados ou reconfigurados no novo local. Por padrão e por segurança, quando um banco de dados é anexado de outro servidor, as opções para is_broker_enabled e is_honoor_broker_priority_on são definidas como OFF. Para obter informações sobre como definir essas opções ON, consulte ALTER DATABASE (Transact-SQL).
Procedimentos de arranque
Um procedimento de inicialização é um procedimento armazenado marcado para execução automática e executado sempre que o SQL Server é iniciado. Se o banco de dados depender de quaisquer procedimentos de inicialização, eles deverão ser definidos na instância do servidor de destino e configurados para serem executados automaticamente na inicialização.
Triggers (a nível do servidor)
Os gatilhos DDL disparam procedimentos armazenados em resposta a vários eventos de Data Definition Language (DDL). Esses eventos correspondem principalmente a instruções Transact-SQL que começam com as palavras-chave CREATE, ALTER e DROP. Certos procedimentos armazenados do sistema que executam operações semelhantes a DDL também podem disparar gatilhos DDL.
Para obter mais informações sobre esse recurso, consulte DDL Triggers.
Ver também
Bases de dados contidas
copiar bancos de dados para outros servidores
Anexação e desanexação de banco de dados (SQL Server)
Failover para um Secundário de Envio de Logs (SQL Server)
Alternância de Papel Durante uma Sessão de Espelhamento de Banco de Dados (SQL Server)
Configurar um Banco de Dados Espelho Criptografado
SQL Server Configuration Manager
Solucionar problemas de usuários órfãos (SQL Server)
Migrar para uma nova instalaçãoVisão geral da migração: SQL Server para SQL Server em VMs do Azure