Che cos'è Sincronizzazione dati SQL per Azure?

Si applica a:Database SQL di Azure

Importante

SQL sincronizzazione dati sarà ritirato il 30 settembre 2027. Considera di migrare verso soluzioni alternative di replicazione e sincronizzazione dei dati. Come parte del processo di pensionamento, non puoi creare nuovi gruppi di sincronizzazione in abbonamenti Azure che in passato non usassero SQL sincronizzazione dati. I gruppi di sincronizzazione esistenti possono continuare a operare fino alla data di pensionamento, ma dovresti migrarli a una soluzione alternativa prima di quella data.

SQL sincronizzazione dati è un servizio costruito su database SQL di Azure che puoi utilizzare per sincronizzare dati selezionati in modo bidirezionale tra più database, sia on-premises che nel cloud.

Azure SQL sincronizzazione dati non supporta Istanza gestita di SQL di Azure né Azure Synapse Analytics.

Panoramica

La sincronizzazione dati si basa sul concetto di gruppo di sincronizzazione. Un gruppo di sincronizzazione è un gruppo di database che si vuole sincronizzare.

La sincronizzazione dati usa una topologia hub-spoke per sincronizzare i dati. Uno dei database nel gruppo di sincronizzazione viene definito come database hub. Il resto dei database sono database membri. La sincronizzazione si verifica solo tra l'hub e i singoli membri.

  • Il database hub deve essere un database SQL di Azure.
  • Le banche dati membri possono essere database in database SQL di Azure o in istanze di SQL Server.
  • Il database dei metadati di sincronizzazione contiene i metadati e il log per la sincronizzazione dati. Il database dei metadati di sincronizzazione deve essere un database SQL di Azure situato nella stessa area del database hub. Il database dei metadati di sincronizzazione viene creato dal cliente ed è di sua proprietà. È possibile avere un solo database dei metadati di sincronizzazione per area e sottoscrizione. Il database dei metadati di sincronizzazione non può essere eliminato o rinominato mentre esistono gruppi o agenti di sincronizzazione. Microsoft consiglia di creare un nuovo database vuoto da usare come Database dei metadati di sincronizzazione. La sincronizzazione dati crea tabelle in questo database ed esegue un carico di lavoro frequente.

Nota

Se si usa un database locale come database membro, è necessario installare e configurare un agente di sincronizzazione locale.

Diagramma che illustra il processo di sincronizzazione dei dati tra i database.

Di seguito sono elencate le proprietà di un gruppo di sincronizzazione:

  • Lo schema di sincronizzazione descrive i dati da sincronizzare.
  • La Direzione di Sincronizzazione può essere bidirezionale, oppure può fluire in una sola direzione: da Hub a Membro, da Membro a Hub o entrambe.
  • L'intervallo di sincronizzazione descrive la frequenza con cui viene eseguita la sincronizzazione.
  • La Politica di Risoluzione dei Conflitti è una politica a livello di gruppo, che può essere Vince Hub o Vince Membro.

Quando utilizzare

La sincronizzazione dati è utile quando i dati devono essere mantenuti aggiornati in diversi database in Database SQL di Azure o SQL Server. Questi sono i principali casi d'uso per la sincronizzazione dati:

  • Sincronizzazione dei dati ibrida: con la sincronizzazione dei dati è possibile mantenere i dati sincronizzati tra i database in SQL Server e database SQL di Azure per rendere possibili applicazioni ibride. Questa funzionalità può essere interessante per i clienti che stanno valutando il passaggio al cloud e vorrebbero trasferire alcune applicazioni in Azure.
  • Applicazioni distribuite: in molti casi è vantaggioso separare carichi di lavoro diversi in database differenti. Ad esempio, se si dispone di un database di produzione di grandi dimensioni, ma è anche necessario eseguire un carico di lavoro di report o analisi su tali dati, può essere utile avere un secondo database per questo carico di lavoro aggiuntivo. Questo approccio riduce al minimo l'impatto a livello di prestazioni sul carico di lavoro di produzione. È possibile usare la sincronizzazione dati per mantenere sincronizzati i due database.
  • Applicazioni distribuite a livello globale: molte aziende sono estese a più aree, a volte anche in paesi diversi. Per ridurre al minimo la latenza di rete, è consigliabile posizionare i dati in un'area vicina. Con sincronizzazione dati è possibile mantenere facilmente sincronizzati i database in aree in tutto il mondo.

La sincronizzazione dati non è la soluzione preferita per gli scenari seguenti:

Scenario Alcune soluzioni raccomandate
Ripristino di emergenza backup automatici nel database SQL di Azure
Scala di Lettura Usa repliche di sola lettura per alleviare i carichi di lavoro delle query di sola lettura
ETL (da OLTP a OLAP) Azure Data Factory o SQL Server Integration Services
Migrazione da SQL Server al database SQL di Azure. Tuttavia, è possibile usare sincronizzazione dati SQL dopo il completamento della migrazione per assicurarsi che l'origine e la destinazione vengano mantenute sincronizzate. Servizio Migrazione del database di Azure

Funzionamento

  • Monitoraggio dei cambiamenti dei dati: sincronizzazione dati traccia le modifiche utilizzando trigger di inserimento, aggiornamento e cancellazione. Le modifiche vengono registrate in una tabella laterale nel database utente. BULK INSERT non attiva i trigger per impostazione predefinita. Se non specifichi FIRE_TRIGGERS, nessun trigger di inserimento viene eseguito. Aggiungi l'opzione FIRE_TRIGGERS così sincronizzazione dati può tracciare quegli inserti.
  • Sincronizzazione dei dati: il servizio di sincronizzazione dati è progettato in base a un modello hub-spoke. L'hub sincronizza singolarmente ogni membro. Le modifiche dall'hub vengono scaricate nel membro e quindi le modifiche dal membro vengono caricate nell'hub.
  • Risoluzione dei conflitti: La Sincronizzazione dei dati offre due opzioni per la risoluzione dei conflitti: Priorità hub o Priorità client.
    • Se selezioni Prevale l'hub, le modifiche nell'hub sovrascriveranno sempre le modifiche nel membro.
    • Se si seleziona Il membro vince, le modifiche nel membro sovrascrivono le modifiche nell'hub. In presenza di più di un membro, il valore finale dipende dal membro sincronizzato per primo.

Confronto con la replicazione transazionale

Sincronizzazione dei dati Replicazione transazionale
Vantaggi - Supporto attivo/attivo
- Bidirezionale tra on-premises e database SQL di Azure		 - Latenza inferiore
- Coerenza delle transazioni
- Riutilizzo topologia esistente dopo la migrazione
- Supporto per Istanza gestita di SQL di Azure
Svantaggi - Nessuna coerenza delle transazioni
- Maggiore impatto sulle prestazioni		 - Impossibilità di pubblicare da Database SQL di Azure
- Alti costi di manutenzione

Attenzione

La sincronizzazione dati SQL richiede l'autenticazione SQL per le connessioni ai database hub e membri. L'autenticazione Microsoft Entra ID non è supportata da SQL sincronizzazione dati.

Poiché l'autenticazione SQL si basa su password statiche, non beneficia di protezioni moderne come l'autenticazione multifattore (MFA), l'Accesso Condizionale o le identità gestite. Questa dipendenza può aumentare l'esposizione dell'intera istanza SQL al furto di credenziali, agli attacchi di bruta forza e al sovraccarico operativo per la rotazione delle password e l'applicazione delle policy.

Laddove possibile, preferisce soluzioni che supportano l'autenticazione o le identità gestite di Microsoft Entra. Poiché SQL sincronizzazione dati è previsto per il pensionamento, migra verso un'alternativa che sia in linea con gli standard di sicurezza della tua organizzazione.

Nota

Il collegamento privato sincronizzazione dati SQL è diverso dal collegamento privato di Azure.

La nuova funzionalità collegamento privato consente di scegliere un endpoint privato gestito dal servizio per stabilire una connessione sicura tra il servizio di sincronizzazione e i database membri/hub durante il processo di sincronizzazione dei dati. Un endpoint privato gestito dal servizio è un indirizzo IP privato all'interno di una rete virtuale e di una subnet specifiche. All'interno di sincronizzazione dati, l'endpoint privato gestito dal servizio viene creato da Microsoft e viene usato esclusivamente dal servizio di sincronizzazione dati per una determinata operazione di sincronizzazione.

Prima di configurare il collegamento privato, leggere i requisiti generali per la funzionalità.

Diagramma di collegamento privato per la sincronizzazione dati.

Nota

È necessario approvare manualmente l'endpoint privato gestito dal servizio, nella pagina Connessioni a endpoint privato del portale di Azure durante la distribuzione del gruppo di sincronizzazione o usando PowerShell.

Inizia

Configurare la sincronizzazione dati nel portale di Azure

Configurare la sincronizzazione dati con PowerShell

Configurare la sincronizzazione dati con l'API REST

Rivedere le procedure consigliate per la sincronizzazione dati

Qualcosa è andato storto?

Coerenza e prestazioni

Coerenza finale

Poiché sincronizzazione dati è basato su trigger, non garantisce coerenza transazionale. Microsoft garantisce che sincronizzazione dati alla fine apporti tutte le modifiche e non causi perdita di dati.

Impatto sulle prestazioni

La sincronizzazione dati usa trigger di inserimento, aggiornamento ed eliminazione per il rilevamento delle modifiche e crea tabelle laterali nel database utente per il rilevamento delle modifiche. Queste attività di rilevamento delle modifiche hanno un impatto sul carico di lavoro del database. Valutare il livello di servizio e aggiornare se necessario.

Sulle prestazioni del database possono incidere anche il provisioning e il deprovisioning eseguiti durante la creazione, l'aggiornamento e l'eliminazione dei gruppi di sincronizzazione.

Requisiti e limitazioni

Requisiti generali

  • Ogni tabella deve avere una chiave primaria. Non modificare il valore della chiave primaria in alcuna riga. Se è necessario modificare un valore della chiave primaria, eliminare la riga e ricrearla con il nuovo valore della chiave primaria.

Importante

Modificare il valore di una chiave primaria esistente comporta il seguente comportamento errato:

  • I dati tra hub e membro possono andare persi anche se la sincronizzazione non segnala alcun problema.
  • La sincronizzazione può fallire perché la tabella di tracciamento non ha una riga esistente dalla sorgente a causa del cambiamento della chiave primaria.

  • L'isolamento dello snapshot deve essere abilitato sia per i membri di sincronizzazione che per l'hub. Per altre informazioni, vedere Isolamento dello snapshot in SQL Server.

  • Per utilizzare il link privato sincronizzazione dati, sia il database membro che quello hub devono essere ospitati in Azure (in regioni identiche o diverse), nello stesso tipo di cloud (ad esempio, sia nel cloud pubblico che in entrambi nel cloud governativo). Inoltre, registra i Microsoft.Network fornitori di risorse per gli abbonamenti che ospitano l'hub e i server membri. Devi approvare manualmente il collegamento privato per sincronizzazione dati durante la configurazione di sincronizzazione, nella sezione Connessioni Private Endpoint nel portale Azure o tramite PowerShell. Per maggiori informazioni su come approvare il link privato, consulta Tutorial: Configura SQL sincronizzazione dati tra database in database SQL di Azure e SQL Server. Una volta approvato l'endpoint privato gestito dal servizio, tutta la comunicazione tra il servizio di sincronizzazione e i database membri/hub avviene tramite il collegamento privato. Puoi aggiornare i gruppi di sincronizzazione esistenti per abilitare questa funzione.

Limitazioni generali

  • Una tabella non può includere una colonna Identity che non sia la chiave primaria.
  • Una chiave primaria non può includere i tipi di dati seguenti: sql_variant, binary, varbinary, image, xml.
  • Usare i tipi di dati che seguono come chiave primaria con la massima cautela, perché supportano solo la precisione al secondo: time, datetime, datetime2, datetimeoffset.
  • I nomi degli oggetti (database, tabelle e colonne) non possono contenere i caratteri stampabili punto (.), parentesi quadra aperta ([) o parentesi quadra chiusa (]).
  • Un nome di tabella non può contenere caratteri stampabili: ! " # $ % ' ( ) * + - o spazio.
  • L'autenticazione Microsoft Entra (in precedenza Azure Active Directory) non è supportata.
  • Se ci sono tabelle con lo stesso nome ma schemi diversi (ad esempio, dbo.customers e sales.customers), puoi aggiungere solo una delle tabelle al gruppo di sincronizzazione.
  • Le colonne con tipi di dati definiti dall'utente non sono supportate.
  • Lo spostamento dei server tra sottoscrizioni diverse non è supportato.
  • Se due chiavi primarie sono diverse solo nel caso, ad esempio Foo e foo), Sincronizzazione dati non supporterà questo scenario.
  • Il troncamento delle tabelle non è un'operazione supportata da Sincronizzazione dati (le modifiche non verranno tracciate).
  • L'uso di un database Hyperscale di Azure SQL come database dell'hub o dei metadati di sincronizzazione non è supportato. Tuttavia, un database Hyperscale può essere un database membro in una topologia di sincronizzazione dati.
  • Le tabelle ottimizzate per la memoria non sono supportate.
  • Le modifiche allo schema non vengono replicate automaticamente.
  • sincronizzazione dati supporta solo le seguenti due proprietà indicizzate: Univoco, Clusterizzato/Non clusterizzato. Altre proprietà di un indice come IGNORE_DUP_KEY o il filtro WHERE e così via non sono supportate e l'indice di destinazione viene effettuato senza queste proprietà anche se l'indice di origine dispone di tali proprietà impostate.
  • Un database di processi elastici di Azure non può essere utilizzato come database dei metadati di Sincronizzazione Dati SQL e viceversa.
  • La sincronizzazione dati SQL non è supportata per i database contabili.
  • sincronizzazione dati non è uno strumento di disaster recovery o alta disponibilità, e non sincronizza le proprie informazioni sui gruppi di sincronizzazione. Non esiste un recupero automatico in caso di emergenza per sincronizzazione dati.
  • sincronizzazione dati non supporta il perimetro di sicurezza di rete per progettazione. sincronizzazione dati funziona come servizio proxy piuttosto che come risorsa Azure, quindi non ha un nome di dominio o un indirizzo IP completamente qualificato contro cui scrivere regole perimetrali. Un perimetro blocca i percorsi di rete richiesti da sincronizzazione dati sia in modalità transizione che in quella imposta, e nessuna regola di accesso lo fa funzionare. Se il tuo server logico è associato a un perimetro, migra a una soluzione di movimento dati che supporti i perimetri di sicurezza di rete.

Tipi di dati non supportati

  • FileStream
  • UDT SQL/CLR (Tipo definito dall'utente)
  • XMLSchemaCollection (supportato da XML)
  • Cursor, RowVersion, Timestamp, Hierarchyid

Tipi di colonna non supportati

La sincronizzazione dati non sincronizza le colonne di sola lettura o generate dal sistema. Ad esempio:

  • Colonne calcolate
  • Colonne generate dal sistema per le tabelle temporali

Limitazioni alle dimensioni del servizio e del database

Dimensioni Limite Soluzione alternativa
Numero massimo di gruppi di sincronizzazione a cui può appartenere qualsiasi database. 5
Numero massimo di endpoint in un singolo gruppo di sincronizzazione 30
Numero massimo di endpoint locali in un singolo gruppo di sincronizzazione. 5 Creare più gruppi di sincronizzazione
Nomi di database, tabella, schema e colonna 50 caratteri per nome
Tabelle in un gruppo di sincronizzazione 500 Creare più gruppi di sincronizzazione
Colonne in una tabella in un gruppo di sincronizzazione 1000
Dimensioni delle righe di dati in una tabella 24 MB

Nota

Potrebbero esserci fino a 30 endpoint in un singolo gruppo di sincronizzazione se ce n'è solo uno. Se ci sono più di un gruppo di sincronizzazione, il numero totale di endpoint in tutti i gruppi di sincronizzazione non può superare i 30. Se un database appartiene a più gruppi di sincronizzazione, conta come più endpoint, non come uno.

Requisiti di rete

Nota

Se usi il collegamento privato Sync, questi requisiti di rete non si applicano.

Quando viene stabilito il gruppo di sincronizzazione, il servizio sincronizzazione dati deve connettersi al database hub. Quando si stabilisce il gruppo di sincronizzazione, le impostazioni Firewalls and virtual networks del server SQL di Azure devono essere configurate nel seguente modo:

  • L'opzione Nega l'accesso alla rete pubblica è impostata su Off.
  • Consentire ai servizi e alle risorse di Azure di accedere a questo server deve essere impostato su Sì oppure è necessario creare regole IP per gli indirizzi IP usati dal servizio sincronizzazione dati.

Dopo aver creato e effettuato il provisioning del gruppo di sincronizzazione, è possibile disabilitare queste impostazioni. L'agente di sincronizzazione si connette direttamente al database hub ed è possibile usare le regole IP del firewall del server o gli endpoint privati per consentire all'agente di accedere al server di hub.

Nota

Se cambi le impostazioni dello schema del gruppo di sincronizzazione, devi permettere al servizio sincronizzazione dati di accedere nuovamente al server in modo che il database hub possa essere rifornito.

Residenza dei dati a livello di area

Se si sincronizzano i dati all'interno della stessa area, sincronizzazione dati SQL non archivia o elabora i dati dei clienti all'esterno dell'area in cui viene distribuita l'istanza del servizio. Se si sincronizzano i dati tra aree diverse, SQL sincronizzazione dati replica i dati dei clienti nelle regioni abbinate.

Domande frequenti sulla sincronizzazione dati SQL

Quanto costa il servizio di sincronizzazione dati SQL?

Non viene applicato alcun addebito per il servizio di sincronizzazione dati SQL di per sé. Tuttavia, si accumuleranno ancora gli addebiti per il trasferimento dei dati dovuti allo spostamento dei dati da e verso l'istanza di database SQL. Per altre informazioni, vedere addebiti per il trasferimento dei dati.

Quali aree supportano la sincronizzazione dati?

La sincronizzazione dati SQL è disponibile in tutte le aree geografiche.

È necessario un account del database SQL di Azure?

Sì. Per ospitare il database hub, è necessario disporre di un account del database SQL di Azure.

È possibile usare la sincronizzazione dei dati solo tra database SQL Server?

Non direttamente. Tuttavia, è possibile sincronizzare in maniera indiretta tra i database SQL Server creando un database hub in Azure e aggiungendo i database locali al gruppo di sincronizzazione.

È possibile configurare la sincronizzazione dei dati per eseguire la sincronizzazione tra database SQL di Azure che appartengono a sottoscrizioni diverse?

Sì. È possibile configurare la sincronizzazione tra database appartenenti a gruppi di risorse di proprietà di sottoscrizioni diverse, anche se le sottoscrizioni appartengono a tenant diversi.

  • Se le sottoscrizioni appartengono allo stesso tenant e sono disponibili le autorizzazioni per tutte le sottoscrizioni, è possibile configurare il gruppo di sincronizzazione nel portale di Azure.
  • In caso contrario, è necessario usare PowerShell per aggiungere i membri di sincronizzazione.
  • collegamento privato non è supportato negli scenari cross-tenant.

È possibile usare la sincronizzazione dei dati per eseguire la sincronizzazione tra database SQL appartenenti a cloud diversi (come il cloud pubblico di Azure e ad Azure operato da 21Vianet)?

sincronizzazione dati non supporta la sincronizzazione cross-cloud.

È possibile usare la sincronizzazione dati per effettuare il seeding dei dati da un database di produzione a un database vuoto e quindi sincronizzarli?

Sì. Creare manualmente lo schema nel nuovo database, scriptandolo dall'originale. Dopo aver creato lo schema, aggiungere le tabelle a un gruppo di sincronizzazione per copiare i dati e mantenerli sincronizzati.

È necessario usare la sincronizzazione dati SQL per eseguire il backup e il ripristino dei database?

Non è consigliabile usare la sincronizzazione dati SQL per creare un backup dei dati. Non è possibile eseguire il backup e il ripristino in un punto specifico nel tempo, perché le sincronizzazioni di SQL sincronizzazione dati non sono versionate. Inoltre, la sincronizzazione dati SQL non esegue il backup di altri oggetti SQL, ad esempio le stored procedure, e non esegue rapidamente l'equivalente di un'operazione di ripristino.

Per una tecnica di backup consigliata, vedere Creare una copia coerente a livello transazionale di un database SQL di Azure.

Con la sincronizzazione dei dati si possono sincronizzare tabelle e colonne crittografate?

  • Se un database usa Always Encrypted, è possibile sincronizzare solo le tabelle e colonne non crittografate. Non è possibile sincronizzare le colonne crittografate, perché la sincronizzazione dei dati non può decrittografare i dati.
  • Se una colonna utilizza Column-Level Crittografia (CLE), puoi sincronizzare la colonna, purché la dimensione della riga sia inferiore alla dimensione massima di 24 MB. La sincronizzazione dei dati considera la colonna crittografata in base alla chiave (CLE) come normali dati binari. Per decrittografare i dati in altri membri di sincronizzazione, è necessario avere lo stesso certificato.

Il supporto per le collationi è disponibile nella sincronizzazione dei dati SQL?

Sì. La sincronizzazione dati SQL supporta le regole di confronto negli scenari seguenti:

  • Se le tabelle dello schema di sincronizzazione selezionate non sono già nel database hub o membro, quando si distribuisce il gruppo di sincronizzazione, il servizio crea automaticamente le tabelle e le colonne corrispondenti con le impostazioni delle regole di confronto selezionate nei database di destinazione vuoti.
  • Se le tabelle da sincronizzare sono già presenti sia nel database hub che nel database membro, la sincronizzazione dati SQL richiede che le colonne chiavi primarie abbiano le stesse regole di confronto in entrambi i database hub e membro per una distribuzione corretta del gruppo di sincronizzazione. Per le colonne diverse dalle colonne chiavi primarie non sono previste restrizioni relative alle regole di confronto.

La federazione è supportata nella sincronizzazione dati SQL?

Puoi usare un database root di federazione con SQL sincronizzazione dati senza limitazioni. Non puoi aggiungere l'endpoint del database federato alla versione attuale di SQL sincronizzazione dati.

È possibile usare la sincronizzazione dei dati per sincronizzare i dati esportati da Dynamics 365 usando la funzionalità BYOD (Bring Your Own Database)?

La funzionalità Dynamics 365 bring your own database consente agli amministratori di esportare le entità dati dall'applicazione nel proprio database SQL di Microsoft Azure. La sincronizzazione dei dati può essere utilizzata per sincronizzare questi dati in altri database se i dati vengono esportati tramite push incrementale (il push completo non è supportato) e se l'opzione abilita trigger nel database di destinazione è impostata su sì.

Come posso creare una sincronizzazione dei dati nel gruppo di failover per supportare il ripristino di emergenza?

Sincronizzazione dati SQL non offre funzionalità di failover automatico o ripristino di emergenza. Se il database passa a un'altra regione, il gruppo di sincronizzazione smette di funzionare. Ricrea manualmente il gruppo di sincronizzazione nella regione di failover con le stesse impostazioni della regione primaria.

Contenuto correlato

Monitorare e risolvere i problemi

La sincronizzazione dati SQL ha le prestazioni previste? Per monitorare l'attività e risolvere i problemi, vedere gli articoli seguenti:

Ulteriori informazioni sul database SQL di Azure

Per maggiori informazioni su database SQL di Azure, consulta i seguenti articoli:

  • Last updated on