Copiar uma cópia transacionalmente consistente de um banco de dados no Banco de Dados SQL do Azure

Aplica-se a: do Banco de Dados SQL do Azure

O Banco de Dados SQL do Azure fornece vários métodos para criar uma cópia de um banco de dados existente no mesmo servidor lógico do Banco de Dados SQL do Azure ou em um servidor lógico diferente. Você pode copiar um banco de dados usando o portal do Azure, PowerShell, CLI do Azure ou Transact-SQL.

Observação

Microsoft Entra ID era anteriormente conhecido como Azure Ative Directory (Azure AD).

Visão geral

Uma cópia de banco de dados é um instantâneo transacionalmente consistente do banco de dados de origem no momento em que a solicitação de cópia é iniciada. Você pode selecionar o mesmo servidor lógico ou um servidor lógico diferente para a cópia. Além disso, você pode optar por manter a redundância de backup e o tamanho de computação do banco de dados de origem ou usar uma redundância de armazenamento de backup diferente e/ou tamanho de computação dentro da mesma camada de serviço. Também é possível copiar um banco de dados na camada de serviço Standard para a camada Standard ou General Purpose, e um banco de dados na camada de serviço Premium para a camada Premium ou Business Critical.

Após a conclusão da cópia, o novo banco de dados é um banco de dados totalmente funcional e independente do banco de dados de origem. Os logons, usuários e permissões no banco de dados copiado são gerenciados independentemente do banco de dados de origem. A cópia é criada usando a tecnologia de replicação geográfica. Quando a propagação da réplica estiver concluída, o link de replicação geográfica será encerrado automaticamente. Todos os requisitos para usar a replicação geográfica se aplicam à operação de cópia do banco de dados. Consulte de visão geral da replicação geográfica ativa para obter detalhes.

Observação

O portal do Azure, o PowerShell e a CLI do Azure não suportam a cópia de banco de dados para uma subscrição diferente.

Cópia de banco de dados para bancos de dados Hyperscale

Para bases de dados no nível de serviço Hyperscale, a base de dados alvo determina se a cópia é uma cópia rápida ou uma cópia de tamanho de dados mais lenta:

  • Cópia rápida: Quando a cópia é feita na mesma região da origem, a cópia é criada a partir dos instantâneos dos blobs, esta cópia é uma operação rápida.

  • Cópia baseada no volume de dados: Quando a base de dados de destino está numa região diferente da origem, ou se a redundância do armazenamento de cópias de segurança da base de dados (Local, Zonal, Geo) da base de dados de destino difere da base de dados de origem, a operação de cópia é uma operação mais lenta baseada no volume de dados. O tempo de cópia não é diretamente proporcional ao tamanho porque os dados do servidor de páginas são copiados em paralelo.

Inícios de sessão na cópia da base de dados

Quando você copia um banco de dados para o mesmo servidor lógico, os mesmos logons podem ser usados em ambos os bancos de dados. A entidade de segurança usada para copiar a base de dados torna-se o proprietário da base de dados na nova base de dados.

Quando você copia um banco de dados para um servidor lógico diferente, a entidade de segurança que iniciou a operação de cópia no servidor lógico de destino torna-se o proprietário do novo banco de dados.

Independentemente do servidor de destino, todos os usuários do banco de dados, permissões e identificadores de segurança (SIDs) são copiados para a cópia do banco de dados. O uso usuários de banco de dados contidos para acesso a dados garante que o banco de dados copiado tenha as mesmas credenciais de usuário, para que, após a conclusão da cópia, você possa acessá-lo imediatamente com as mesmas credenciais.

Se você usar logons no nível do servidor para acesso a dados e copiar o banco de dados para um servidor diferente, o acesso baseado em logon pode não funcionar. Isso pode acontecer porque os logins não existem no servidor lógico de destino ou porque essas senhas e identificadores de segurança (SIDs) são diferentes. Para obter mais informações sobre como gerir logins quando se copia um banco de dados para um servidor diferente, consulte Configurar e gerir a segurança do Banco de Dados SQL do Azure para restauração geográfica ou failover. Depois que a operação de cópia para um servidor lógico diferente for bem-sucedida e antes que outros usuários sejam remapeados, somente o logon associado ao proprietário do banco de dados ou o administrador do servidor poderá entrar no banco de dados copiado. Para resolver logins e estabelecer acesso a dados após a conclusão da operação de cópia, consulte Resolver logins.

Copiar um banco de dados

Você pode copiar um banco de dados usando o PowerShell, a CLI do Azure e o Transact-SQL (T-SQL).

Para copiar uma base de dados no portal do Azure, abra a página da sua base de dados e, em seguida, escolha Copiar para abrir a página Criar Base de Dados SQL - Copiar base de dados. Preencha os valores para o servidor lógico de destino para o qual você deseja copiar seu banco de dados.

Captura de tela do portal do Azure, mostrando a opção Cópia do banco de dados realçada na página de visão geral do banco de dados.

Copiar um banco de dados com Transact-SQL

Entre no banco de dados master com o login de administrador do servidor ou o login que criou o banco de dados que você deseja copiar. Para que a cópia do banco de dados seja bem-sucedida, os logons que não são administradores do servidor devem ser membros da função dbmanager. Para obter mais informações sobre logons e conexão com o servidor lógico, consulte Autorizar acesso ao banco de dados.

Comece a copiar o banco de dados de origem com a instrução CREATE DATABASE ... COMO CÓPIA DE. A instrução T-SQL continua em execução até que a operação de cópia do banco de dados seja concluída.

Esta seção fornece comandos Transact-SQL para as seguintes operações:

Observação

Encerrar a instrução T-SQL não encerra a operação de cópia do banco de dados. Para encerrar a operação, solte o banco de dados de destino.

Copiar para o mesmo servidor lógico

Entre no banco de dados master com o login de administrador do servidor ou o login que criou o banco de dados que você deseja copiar. Para que a cópia do banco de dados seja bem-sucedida, os logons que não são o administrador do servidor devem ser membros da função dbmanager .

Este comando copia Database1 para um novo banco de dados chamado Database2 no mesmo servidor lógico. Dependendo do tamanho do banco de dados, a operação de cópia pode levar algum tempo para ser concluída.

-- Execute on the master database to start copying
CREATE DATABASE Database2 AS COPY OF Database1;

Copiar para um pool elástico

Entre no banco de dados master com o login de administrador do servidor ou o login que criou o banco de dados que você deseja copiar. Para que a cópia do banco de dados seja bem-sucedida, os logons que não são o administrador do servidor devem ser membros da função dbmanager .

Este comando copia Database1 para um novo banco de dados chamado Database2 em um pool elástico chamado pool1. Dependendo do tamanho do banco de dados, a operação de cópia pode levar algum tempo para ser concluída.

Database1 pode ser um banco de dados único ou em pool. A cópia entre pools de camadas diferentes é suportada, mas algumas cópias entre camadas falham. Por exemplo, pode copiar uma base de dados standard individual ou elástica para um pool de Uso Geral, mas não pode copiar uma base de dados elástica standard para um pool Premium.

-- Execute on the master database to start copying
CREATE DATABASE Database2
AS COPY OF Database1
(SERVICE_OBJECTIVE = ELASTIC_POOL( name = pool1 ));

Copiar para um servidor lógico diferente

Conecte-se ao banco de dados master do servidor lógico de destino onde o novo banco de dados será criado. Utilize um login que tenha o mesmo nome e a mesma senha do proprietário da base de dados de origem no servidor lógico de origem. O login no servidor lógico de destino também deve ser membro da função dbmanager ou ser o login de administrador do servidor.

Este comando copia Database1 no server1 para um novo banco de dados chamado Database2 no server2. Dependendo do tamanho do banco de dados, a operação de cópia pode levar algum tempo para ser concluída.

-- Execute on the master database of the target logical server (server2) to start copying from Server1 to Server2
CREATE DATABASE Database2 AS COPY OF server1.Database1;

Importante

Ambos os firewalls de servidor lógico devem ser configurados para permitir a conexão de entrada do IP do cliente que emite o comando T-SQL CREATE DATABASE ... AS COPY OF. Para determinar o endereço IP de origem da conexão atual, execute: SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id = @@SPID;

Observação

Não há suporte para cópia de banco de dados usando T-SQL ao se conectar ao servidor lógico de destino por meio de um ponto de extremidade privado . Se um ponto de extremidade privado estiver configurado, mas o acesso à rede pública for permitido, a cópia do banco de dados é suportada quando se está ligado ao servidor lógico de destino a partir de um endereço IP público usando autenticação SQL. Quando a operação de cópia estiver concluída, o acesso público poderá ser negado.

Da mesma forma, o comando a seguir copia Database1 em server1 para um novo banco de dados chamado Database2 dentro de um pool elástico chamado pool2, em server2.

-- Execute on the master database of the target logical server (server2) to start copying from Server1 to Server2
CREATE DATABASE Database2 AS COPY OF server1.Database1 (SERVICE_OBJECTIVE = ELASTIC_POOL( name = pool2 ) );

Copiar para uma subscrição diferente

Você pode usar as etapas na seção Copiar um banco de dados SQL para um servidor lógico diferente para copiar seu banco de dados para um servidor lógico em uma assinatura diferente usando o T-SQL. Certifique-se de usar um login que tenha o mesmo nome e senha que o proprietário do banco de dados de origem. Além disso, o login deve ser membro da função dbmanager ou ser administrador de servidor nos servidores lógicos tanto de origem como de destino.

Dica

Ao copiar bancos de dados no mesmo locatário do Microsoft Entra ID, a autorização nos servidores lógicos de origem e destino é simplificada se você iniciar o comando copy usando um logon de autenticação com acesso suficiente em ambos os servidores lógicos. O nível mínimo necessário de acesso é a associação na função dbmanager no banco de dados master em ambos os servidores lógicos. Por exemplo, você pode usar um logon do Microsoft Entra ID que seja membro de um grupo designado como administrador do servidor em ambos os servidores lógicos.

Nos scripts a seguir, o nome de login a ser copiado é loginname.

Primeiro, conecte-se ao banco de dados master do servidor lógico de origem. Crie um logon e um usuário no banco de dados master do servidor lógico do Banco de Dados SQL do Azure de origem. Substitua <password> por uma senha forte.

--Step# 1
--Create login and user in the master database of the source server.

CREATE LOGIN loginname WITH PASSWORD = '<password>'
GO
CREATE USER [loginname] FOR LOGIN [loginname] WITH DEFAULT_SCHEMA=[dbo];
GO
ALTER ROLE dbmanager ADD MEMBER loginname;
GO

Conecte-se ao banco de dados de usuário de origem. Em seguida, no banco de dados de usuário de origem, crie o usuário no banco de dados de origem e adicione-o à função de banco de dados dbowner no banco de dados.

--Step# 2
--Create the user in the source database and grant dbowner permission to the database.

CREATE USER [loginname] FOR LOGIN [loginname] WITH DEFAULT_SCHEMA=[dbo];
GO
ALTER ROLE db_owner ADD MEMBER loginname;
GO

Em seguida, localize o identificador de segurança (SID) do usuário loginname do banco de dados master do servidor lógico de origem.

--Step# 3
--Capture the SID of the user "loginname" from master database

SELECT [sid] FROM sysusers WHERE [name] = 'loginname';

Execute o próximo script no banco de dados master do servidor lógico novo ou de destino. Primeiro, crie um login e um usuário no banco de dados master do servidor lógico de destino e adicione-o à função de servidor dbmanager. Substitua <password> por uma palavra-passe forte e substitua <SID of loginname login on source server> pelo SID do servidor lógico de origem.

--Step# 4
--Connect to Destination server.
--Create login and user in the master database, same as of the source server.

CREATE LOGIN loginname WITH PASSWORD = '<password>', SID = <SID of loginname login on source server>;
GO
CREATE USER [loginname] FOR LOGIN [loginname] WITH DEFAULT_SCHEMA=[dbo];
GO
ALTER ROLE dbmanager ADD MEMBER loginname;
GO

No banco de dados master do servidor lógico de destino, crie o novo banco de dados. Substitua new_database_name pelo nome desejado. Substitua source_server_name e source_database_name pelos nomes da fonte.

--Step# 5
--Execute the copy of database script from the destination logical server using the credentials created

CREATE DATABASE new_database_name
AS COPY OF source_server_name.source_database_name;

Dica

A cópia de um banco de dados de uma subscrição em um inquilino diferente do Azure só é suportada ao usar T-SQL e um login de autenticação SQL para aceder ao servidor lógico de destino. Não há suporte para a criação de uma cópia de banco de dados em um servidor lógico em um locatário diferente do Azure com autenticação do Microsoft Entra para o SQLdo Azure.

Monitorar o progresso da operação de cópia

Monitore o processo de cópia consultando as visões sys.databases, sys.dm_database_copiese sys.dm_operation_status. Enquanto a cópia estiver em andamento, a coluna state_desc da exibição sys.databases do novo banco de dados será definida como COPYING.

  • Se a cópia falhar, a coluna state_desc da visualização sys.databases do novo banco de dados será definida como SUSPECT. Execute a instrução DROP no novo banco de dados e tente novamente mais tarde.
  • Se a cópia for bem-sucedida, a coluna state_desc da exibição sys.databases do novo banco de dados será definida como ONLINE. A cópia está concluída e o novo banco de dados é um banco de dados regular que pode ser alterado independentemente do banco de dados de origem.

Observação

Se você decidir cancelar a cópia enquanto ela estiver em andamento, execute a instrução DROP DATABASE no novo banco de dados.

Importante

Se você precisar criar uma cópia com um objetivo de serviço substancialmente menor do que o de origem, o banco de dados de destino pode não ter recursos suficientes para concluir o processo de propagação e pode fazer com que a operação de cópia falhe. Nesse cenário, use uma solicitação de restauração geográfica para criar uma cópia em um servidor lógico diferente e/ou em uma região diferente. Para obter mais informações, consulte Recuperar um Banco de Dados SQL do Azure usando backups de banco de dados.

Permissões

Para criar uma cópia de base de dados, precisa de ser membro de um dos seguintes cargos:

  • Proprietário da subscrição ou
  • Função de Colaborador do SQL Server ou
  • Função personalizada no servidor lógico de origem com as seguintes permissões:
    • Microsoft.Sql/servers/databases/read
    • Microsoft.Sql/servers/databases/write e
  • Função personalizada no servidor lógico de destino com as seguintes permissões:
    • Microsoft.Sql/servers/read
    • Microsoft.Sql/servers/databases/read
    • Microsoft.Sql/servers/databases/write

Para cancelar uma cópia da base de dados, precisa de ser membro de uma das seguintes funções:

  • Proprietário da subscrição ou
  • Função de Colaborador do SQL Server ou
  • Função personalizada no banco de dados de destino com a seguinte permissão:
    • Microsoft.Sql/servers/databases/delete

Para gerenciar a cópia do banco de dados usando o portal do Azure, você também precisa das seguintes permissões:

  • Microsoft.Resources/subscriptions/resources/read
  • Microsoft.Resources/deployments/read
  • Microsoft.Resources/deployments/write
  • Microsoft.Resources/deployments/operationstatuses/read

Se você quiser ver as operações em implantações no grupo de recursos no portal, operações em vários provedores de recursos, incluindo operações SQL, você precisa destas permissões adicionais:

  • Microsoft.Resources/subscriptions/resourcegroups/deployments/operations/read
  • Microsoft.Resources/subscriptions/resourcegroups/deployments/operationstatuses/read

Resolver inícios de sessão

Depois que o novo banco de dados estiver online no servidor lógico de destino, use a instrução ALTER USER para remapear os usuários do novo banco de dados para logons no servidor lógico de destino. Para resolver usuários órfãos, consulte Solucionar problemas de usuários órfãos. Consulte também Configurar e gerenciar a segurança do Banco de Dados SQL do Azure para restauração geográfica ou failover.

Todos os usuários no novo banco de dados mantêm as permissões que tinham no banco de dados de origem. O usuário que iniciou a cópia do banco de dados torna-se o proprietário do banco de dados do novo banco de dados. Após a cópia ser bem-sucedida e antes de outros utilizadores serem remapeados, apenas o proprietário do banco de dados poderá aceder ao novo banco de dados.

Para saber mais sobre como gerenciar usuários e logons quando você copia um banco de dados para um servidor lógico diferente, consulte Configurar e gerenciar a segurança do Banco de Dados SQL do Azure para restauração geográfica ou failover.

Perímetro de segurança de rede (pré-visualização)

Um perímetro de segurança de rede (pré-visualização) controla o tráfego de rede de entrada e saída para um servidor lógico. A cópia da base de dados move dados entre servidores lógicos através da conectividade interna gerida pela plataforma, pelo que um perímetro de segurança avalia esse tráfego e pode bloquear a cópia.

Como a cópia de bases de dados utiliza o acesso à rede

A cópia da base de dados utiliza tecnologia de geo-replicação para semear a base de dados alvo e depois remove a ligação quando a cópia termina. Quando qualquer um dos servidores lógicos pertence a um perímetro, essa conectividade servidor a servidor está sujeita às regras de acesso do perímetro.

Importante

O perímetro avalia as regras de acesso uma vez, quando a solicitação de cópia começa. Não os reavalia enquanto a cópia corre ou quando a cópia termina. Uma alteração de regra ou de associação feita durante a cópia não a impede, e a cópia corre até à conclusão.

Configurações suportadas

A cópia da base de dados funciona tanto em modo de transição como em modo forçado. No modo de transição, o perímetro regista o tráfego sem o bloquear, por isso uma cópia tem sucesso mesmo que não configure nenhuma regra. Configura as regras na mesma, para que as cópias continuem a funcionar depois de mudares para o modo imposto.

No modo forçado, as regras de que precisas dependem da topologia:

Copiar topologia Regras de acesso necessárias
O destino está no mesmo servidor lógico que a origem None.
Ambos os servidores lógicos estão no mesmo perímetro None. O acesso entre recursos no mesmo perímetro é sempre permitido.
Os servidores lógicos estão em perímetros diferentes Uma regra de saída no servidor de origem e uma regra de entrada no servidor de destino.
Apenas o servidor de origem está num perímetro Uma regra de saída no servidor de origem.
Só o servidor alvo está numa rede perimetral Uma regra de entrada no servidor alvo.

A cópia da base de dados não requer uma identidade gerida pelo sistema.

Configurar regras de acesso para uma cópia de base de dados

Os passos seguintes são um exemplo. Partem do princípio de que cada servidor lógico está no seu próprio perímetro e de que altera a associação de cada servidor para o modo imposto após uma cópia de teste. Se ambos os servidores estiverem no mesmo perímetro, não precisas de regras de acesso.

  1. Associe cada servidor lógico ao seu perímetro. Um servidor recém-associado entra em modo de transição.
  2. No perfil associado ao servidor de origem, adicione uma regra de acesso de saída. Defina o tipo de destino para FQDN e use o domínio totalmente qualificado do servidor de destino, como targetserver.database.windows.net.
  3. No perfil associado ao servidor alvo, adicione uma regra de acesso de entrada. Defina o tipo de Fonte para um destes valores:
    • Assinatura, e use o ID de subscrição do servidor de origem.
    • Intervalos de endereços IP e use o intervalo de IP do servidor de origem.
    • etiquetas de serviço, e use Sql ou Sql.<region>, onde <region> é a região Azure do servidor de origem.
  4. Deixa os servidores em modo de transição e executa uma cópia da base de dados. Revise os registos de diagnóstico do perímetro de segurança da rede para confirmar que não há recusas inesperadas.
  5. Só mude a associação de cada servidor para modo imposto depois de a cópia ter sucesso e os registos estarem limpos.

Limitações e diferenças de comportamento

  • Quando um servidor lógico pertence a um perímetro, seja em modo de transição ou imposto, Transact-SQL não é uma forma suportada de copiar uma base de dados para um servidor lógico diferente. Ainda podes usar Transact-SQL para copiar uma base de dados dentro do mesmo servidor lógico. Para cópias entre servidores, utilize o portal Azure, CLI do Azure ou PowerShell.

Erros quando um perímetro de segurança bloqueia uma cópia

Código de erro Message
48001 A operação não pôde ser concluída porque o Perímetro de Segurança de Rede negou o acesso de entrada da 'fonte' ao servidor 'alvo'.
48002 A operação não pôde ser concluída porque o Perímetro de Segurança de Rede associado negava o acesso de saída do servidor 'origem' ao 'alvo'.

Os marcadores de posição nestas mensagens são substituídos por nomes lógicos de servidores. Relativamente ao 48001, reveja as regras de entrada no perfil associado ao servidor alvo. Para o 48002, reveja as regras de saída no perfil associado ao servidor de origem.

Erros de cópia do banco de dados

Os seguintes erros podem ser encontrados ao copiar um banco de dados no Banco de Dados SQL do Azure. Para obter mais informações, consulte Copiar uma cópia transacional consistente de um banco de dados no Banco de Dados SQL do Azure.

Código de erro Gravidade Descrição
40635 16 Cliente com endereço IP '%.*ls' está temporariamente desativado.
40637 16 Criar cópia de banco de dados está desabilitado no momento.
40561 16 Falha na cópia do banco de dados. O banco de dados de origem ou de destino não existe.
40562 16 Falha na cópia do banco de dados. O banco de dados de origem foi descartado.
40563 16 Falha na cópia do banco de dados. O banco de dados de destino foi descartado.
40564 16 Falha na cópia do banco de dados devido a um erro interno. Elimine o banco de dados de destino e tente novamente.
40565 16 Falha na cópia do banco de dados. Não é permitida mais do que 1 cópia simultânea do banco de dados da mesma fonte. Remova o banco de dados de destino e tente novamente mais tarde.
40566 16 Falha na cópia do banco de dados devido a um erro interno. Elimine o banco de dados de destino e tente novamente.
40567 16 Falha na cópia do banco de dados devido a um erro interno. Elimine o banco de dados de destino e tente novamente.
40568 16 Falha na cópia do banco de dados. A base de dados de origem tornou-se indisponível. Elimine o banco de dados de destino e tente novamente.
40569 16 Falha na cópia do banco de dados. O banco de dados de destino ficou indisponível. Elimine o banco de dados de destino e tente novamente.
40570 16 Falha na cópia do banco de dados devido a um erro interno. Remova o banco de dados de destino e tente novamente mais tarde.
40571 16 Falha na cópia do banco de dados devido a um erro interno. Remova o banco de dados de destino e tente novamente mais tarde.

Conteúdo relacionado

  • Última atualização a