Creare una copia coerente a livello transazionale di un database SQL di Azure

Si applica a:Database SQL di Azure

Il database SQL di Azure offre diversi metodi per creare una copia di un database esistente nello stesso server logico del database SQL di Azure o in un server logico diverso. È possibile copiare un database tramite il portale di Azure, PowerShell, l'interfaccia della riga di comando di Azure o Transact-SQL.

Panoramica

Una copia del database è uno snapshot transazionalmente coerente del database di origine nel momento in cui viene avviata la richiesta di copia. È possibile selezionare lo stesso server logico o un server logico diverso per la copia. È inoltre possibile scegliere di mantenere la ridondanza del backup e le dimensioni di calcolo del database di origine oppure usare una ridondanza dell'archiviazione di backup diversa e/o le dimensioni di calcolo all'interno dello stesso livello di servizio. È inoltre possibile copiare un database del livello di servizio Standard nel livello Standard o per utilizzo generico e un database del livello di servizio Premium nel livello Premium o Business critical.

Al termine della copia, il nuovo database è un database completamente funzionale e indipendente nel database di origine. Accessi, utenti e autorizzazioni nel database copiato vengono gestiti in modo indipendente rispetto al database di origine. La copia viene creata usando la tecnologia di replica geografica. Al termine del seeding della replica, il collegamento di replica geografica viene terminato automaticamente. All'operazione di copia del database si applicano tutti i requisiti per l'uso della replica geografica. Per informazioni dettagliate, vedere Panoramica della replica geografica attiva.

Copia di database per database Hyperscale

Per i database nel livello di servizio Hyperscale, il database di destinazione determina se la copia è una copia veloce o una copia completa dei dati più lenta:

• Copia veloce: Quando la copia viene eseguita nella stessa area geografica dell'origine, la copia viene creata dagli snapshot dei blob; questa copia è un'operazione veloce.

• Copia basata sulla dimensione dei dati: Quando il database di destinazione si trova in una regione diversa dalla sorgente, o se la ridondanza dello storage di backup del database (Locale, Zonale, Geo) del database di destinazione differisce da quella sorgente, l'operazione di copia è un'operazione più lenta basata sulla dimensione dei dati. Il tempo di copia non è direttamente proporzionale alla dimensione perché i dati del server di pagina vengono copiati in parallelo.

Accessi nella copia del database

Quando si copia un database nello stesso server logico, è possibile usare gli stessi account di accesso in entrambi i database. L'entità di sicurezza usata per copiare il database diventa il proprietario del database nel nuovo database.

Quando si copia un database in un server logico diverso, l'entità di sicurezza che ha avviato l'operazione di copia nel server logico di destinazione diventa il proprietario del nuovo database.

A prescindere dal server di destinazione, tutti gli utenti del database, le relative autorizzazioni e i relativi ID di sicurezza (SID) vengono copiati nella copia del database. L'uso di utenti di database indipendente per l'accesso ai dati garantisce che il database copiato abbia le stesse credenziali utente, in modo che dopo il completamento della copia sia possibile accedervi immediatamente con le stesse credenziali

Se si usano accessi a livello di server per l'accesso ai dati e si copia il database in un server diverso, l'accesso potrebbe non funzionare. Ciò può verificarsi perché gli account di accesso non esistono nel server logico di destinazione o perché tali password e identificatori di sicurezza (SID) sono diversi. Per ulteriori informazioni sulla gestione dei login quando si copia un database su un server diverso, vedere Configurare e gestire la sicurezza di database SQL di Azure per il ripristino geografico o il failover. Dopo che l'operazione di copia su un server logico diverso ha avuto esito positivo, e prima che altri utenti vengano rimappati, solo il login associato al proprietario del database o l'amministratore del server può effettuare l'accesso al database copiato. Per risolvere gli accessi e ristabilire l'accesso ai dati al termine dell'operazione di copia, vedere Risolvere gli accessi.

Copiare un database

New-AzSqlDatabaseCopy -ResourceGroupName "<resourceGroup>" -ServerName $sourceserver -DatabaseName "<databaseName>" `
    -CopyResourceGroupName "myResourceGroup" -CopyServerName $targetserver -CopyDatabaseName "CopyOfMySampleDatabase"

az sql db copy --dest-name "<new database copy name>" `
--dest-resource-group "<destination resource group name>" `
--dest-server "<destination logical SQL server name>" `
--name "<source database name>" `
--resource-group "<source resource group name>" `
--server "<source logical SQL server name>"

Copiare un database con Transact-SQL

Accedere al database master con l'account di accesso dell'amministratore del server o l'account di accesso che ha creato il database da copiare. Affinché il processo di copia del database abbia esito positivo, gli account di accesso che non corrispondono all'amministratore del server devono essere membri del ruolo dbmanager. Per altre informazioni sugli account di accesso e sulla connessione al server logico, vedere Autorizzare l'accesso al database.

Iniziare a copiare il database di origine con l'istruzione CREATE DATABASE ... AS COPY OF. L'istruzione T-SQL procede con l'esecuzione fino al completamento dell'operazione di copia del database.

In questa sezione vengono forniti Transact-SQL comandi per le operazioni seguenti:

• Copiare nello stesso server logico
• Copiare in un pool elastico
• Copiare in un server logico diverso
• Copiare in una sottoscrizione diversa

Copiare nello stesso server logico

Accedere al database master con l'account di accesso dell'amministratore del server o l'account di accesso che ha creato il database da copiare. Affinché il processo di copia del database abbia esito positivo, gli account di accesso che non corrispondono all'amministratore del server devono essere membri del ruolo dbmanager.

Questo comando copia Database1 in un nuovo database denominato Database2 nello stesso server logico. A seconda delle dimensioni del database, l'operazione di copia potrebbe richiedere alcuni minuti.

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

Copia in un pool elastico

Accedere al database master con l'account di accesso dell'amministratore del server o l'account di accesso che ha creato il database da copiare. Affinché il processo di copia del database abbia esito positivo, gli account di accesso che non corrispondono all'amministratore del server devono essere membri del ruolo dbmanager.

Questo comando copia Database1 in un nuovo database denominato Database2 in un pool elastico denominato pool1. A seconda delle dimensioni del database, l'operazione di copia potrebbe richiedere alcuni minuti.

Database1 può essere un database singolo o in pool. La copia tra pool di livelli diversi è supportata, ma alcune copie tra livelli non avranno esito positivo. È ad esempio possibile copiare un database standard singolo o elastico in un pool di per utilizzo generico, ma non è possibile copiare un database elastico standard in un pool Premium.

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

Copiare in un server logico diverso

Connettersi al database master del server logico di destinazione in cui creare il nuovo database. Usare un account di accesso con lo stesso nome e la stessa password del proprietario del database di origine nel server logico di origine. Il login sul server logico di destinazione deve anche appartenere al ruolo dbmanager o essere il login amministratore del server.

Questo comando copia Database1 in server1 in un nuovo database denominato Database2 in server2. A seconda delle dimensioni del database, l'operazione di copia potrebbe richiedere alcuni minuti.

-- 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;

Analogamente, il comando seguente copia Database1 su server1 in un nuovo database chiamato Database2 all'interno di un pool elastico chiamato pool2su 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 ) );

Copia in un altro abbonamento

È possibile usare la procedura descritta nella sezione Copiare un database SQL in un server logico diverso per copiare il database in un server logico in una sottoscrizione diversa usando T-SQL. Assicurarsi di usare un account di accesso con lo stesso nome e la stessa password del proprietario del database nel server di origine. Inoltre, l'account di accesso deve essere membro del ruolo dbmanager o di un amministratore del server, sia nei server logici di origine che di destinazione.

Negli script seguenti il nome di accesso da copiare viene loginname.

Prima di tutto, connettersi al database master del server logico di origine. Creare un account di accesso e un utente nel database master del server logico di origine del database SQL di Azure. Sostituire <password> con una password complessa.

--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

Connettersi al database utente di origine. Successivamente, nel database utente di origine creare l'utente nel database di origine e aggiungerlo al ruolo del database dbowner nel database.

--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

Trovare quindi l'identificatore di sicurezza (SID) dell'utente loginname dal database master del server logico di origine.

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

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

Eseguire lo script successivo nel database master del server logico nuovo o di destinazione. Creare prima di tutto un account di accesso e un utente nel database master del server logico di destinazione e aggiungerlo al ruolo del server dbmanager. Sostituisci <password> con una password forte e sostituisci <SID of loginname login on source server> con il SID del server logico sorgente.

--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

Nel database master del server logico di destinazione creare il nuovo database. Sostituire new_database_name con il nome desiderato. Sostituire source_server_name e source_database_name con i nomi dell'origine.

--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;

Monitorare lo stato dell'operazione di copia

Monitorare il processo di copia eseguendo una query sulle viste sys.databases, sys.dm_database_copies e sys.dm_operation_status. Durante il processo di copia, la colonna state_desc della vista sys.databases per il nuovo database viene impostata su COPYING.

• Se il processo di copia non riesce, la colonna state_desc della vista sys.databases per il nuovo database viene impostata su SUSPECT. Eseguire l'istruzione DROP sul nuovo database e riprovare in un secondo momento.
• Se il processo di copia riesce, la colonna state_desc della vista sys.databases per il nuovo database viene impostata su ONLINE. La copia è stata completata e il nuovo database è un database standard, che può essere modificato indipendentemente dal database di origine.

Autorizzazioni

Per creare una copia del database, è necessario essere membri di uno dei seguenti ruoli:

• Proprietario della sottoscrizione o
• Ruolo di Collaboratore SQL Server o
• Ruolo personalizzato nel server logico di origine con le autorizzazioni seguenti:
  • Microsoft.Sql/servers/databases/read
  • Microsoft.Sql/servers/databases/write e [aggiungere il testo mancante qui]
• Ruolo personalizzato nel server logico di destinazione con le autorizzazioni seguenti:
  • Microsoft.Sql/servers/read
  • Microsoft.Sql/servers/databases/read
  • Microsoft.Sql/servers/databases/write

Per annullare una copia del database, devi essere membro di uno dei seguenti ruoli:

• Proprietario della sottoscrizione o
• Ruolo di Collaboratore SQL Server o
• Ruolo personalizzato nel database di destinazione con l'autorizzazione seguente:
  • Microsoft.Sql/servers/databases/delete

Per gestire la copia del database usando il portale di Azure sono necessarie anche le autorizzazioni seguenti:

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

Se si vogliono visualizzare nel portale le operazioni in Distribuzioni del gruppo di risorse e le operazioni tra più provider di risorse, incluse le operazioni SQL, sono necessarie le autorizzazioni aggiuntive seguenti:

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

Risolvere i problemi di accesso

Dopo che il nuovo database è online nel server logico di destinazione, usare l'istruzione ALTER USER per eseguire nuovamente il mapping degli utenti dal nuovo database ai login sul server logico di destinazione. Per risolvere gli utenti isolati, vedere Risolvere i problemi relativi agli utenti isolati (SQL Server). Consultare anche Configurare e gestire la sicurezza del database SQL di Azure per il ripristino geografico o il failover.

Tutti gli utenti nel nuovo database mantengono le autorizzazioni di cui disponevano nel database di origine. L'utente che ha avviato la copia del database diventa il proprietario del nuovo database. Dopo che la copia è stata completata e prima che altri utenti vengano rimappati, solo il proprietario del database può accedere al nuovo database.

Per informazioni sulla gestione di utenti e account di accesso quando si copia un database in un server logico diverso, vedere Configurare e gestire la sicurezza del database SQL di Azure per il ripristino geografico o il failover.

Perimetro di sicurezza di rete (anteprima)

Un perimetro di sicurezza di rete (preview) controlla il traffico di rete in entrata e in uscita per un server logico. La copia del database sposta i dati tra server logici tramite connettività interna gestita dalla piattaforma, quindi un controllo perimetrale valuta tale traffico e può bloccare la copia.

Come la copia del database utilizza l'accesso alla rete

La copia del database utilizza la tecnologia di geo-replicazione per seedare il database di destinazione, poi rimuove il collegamento una volta terminata la copia. Quando uno dei due server logici appartiene a un perimetro, quella connettività server-to-server è soggetta alle regole di accesso del perimetro.

Configurazioni supportate

La copia del database funziona sia in modalità transizione che in modalità forzata. In modalità transizione, il perimetro registra il traffico senza bloccarlo, quindi una copia ha successo anche se non configuri regole. Configura comunque le regole, così che le copie continuino a funzionare anche dopo che passi alla modalità di applicazione.

In modalità applicata, le regole necessarie dipendono dalla topologia:

La copia del database non richiede un'identità gestita.

Configura le regole di accesso per una copia del database

I seguenti passaggi sono un esempio. Prendono per scontato che ogni server logico sia nel proprio perimetro e che si modifichi l'associazione di ciascun server in modalità forzata dopo una copia di test. Se entrambi i server sono nello stesso perimetro, non servono regole di accesso.

1. Associa ogni server logico al suo perimetro. Un server appena associato si avvia in modalità transizione.
2. Nel profilo associato al server sorgente, aggiungi una regola di accesso in uscita. Imposta il tipo di destinazione su FQDN e usa il nome di dominio completamente qualificato del server target, come targetserver.database.windows.net.
3. Nel profilo associato al server target, aggiungi una regola di accesso in entrata. Imposta il tipo di sorgente a uno di questi valori:
   • Abbonamento, e usa l'ID di abbonamento del server sorgente.
   • Intervalli di indirizzi IP, e usate l'intervallo IP del server sorgente.
   • Service tag, e usare Sql o Sql.<region>, dove <region> è la regione Azure del server sorgente.
4. Lascia i server in modalità transizione ed esegui una copia del database. Esamina i log diagnostici del perimetro di sicurezza di rete per confermare che non ci siano blocchi imprevisti.
5. Passa l'associazione di ogni server in modalità forzata solo dopo che la copia ha avuto successo e i log sono puliti.

Limitazioni e differenze comportamentali

• Quando un server logico appartiene a un perimetro, sia in modalità di transizione che in modalità imposta, Transact-SQL non è un modo supportato per copiare un database in un altro server logico. Puoi ancora usare Transact-SQL per copiare un database all'interno dello stesso server logico. Per copie cross-server, usa il portale Azure, interfaccia della riga di comando di Azure o PowerShell.

Errori quando un perimetro di sicurezza blocca una copia

I segnaposto in questi messaggi vengono sostituiti con nomi logici dei server. Per 48001, rivedere le regole in entrata sul profilo associato al server target. Per 48002, rivedere le regole di uscita sul profilo associato al server sorgente.

Errori di copia del database

Durante la copia di un database nel database SQL di Azure, possono essere rilevati gli errori seguenti. Per altre informazioni, vedere Copiare una versione coerente a livello transazionale di un database in database SQL di Azure.

Contenuto correlato

• Autorizzazione dell'accesso al database per Database SQL, Istanza gestita di SQL e Azure Synapse Analytics
• Configurare e gestire la sicurezza dei database SQL di Azure per il ripristino geografico o il failover
• Esportazione in un file BACPAC - Database di Azure SQL e Istanza gestita di Azure SQL
• Riferimento della configurazione modificabile per Database SQL di Azure
• Perimetro di sicurezza di rete per database SQL di Azure (preview)