Procedure consigliate per la sincronizzazione dati SQL di Azure
Si applica a: Database SQL di Azure
Importante
Sincronizzazione dati SQL verrà ritirato il 30 settembre 2027. Valutare la possibilità di eseguire la migrazione a soluzioni alternative per la replica/sincronizzazione dei dati.
Questo articolo descrive le procedure consigliate per la sincronizzazione dati SQL di Azure.
Per una panoramica di Sincronizzazione dati SQL, vedere Che cos’è Sincronizzazione dati SQL per Azure?
Sicurezza e affidabilità
Agente client
- Installare l'agente client usando un account utente con privilegi minimi e con accesso ai servizi di rete.
- Installare l'agente client in un server diverso da quello in cui è installato SQL Server.
- Non registrare un database locale con più di un agente.
- Evitare questa operazione anche se si intende sincronizzare tabelle diverse relative a diversi gruppi di sincronizzazione.
- La registrazione di un database locale con più agenti client può causare problemi quando si elimina uno dei gruppi di sincronizzazione.
Account di database con privilegi minimi
Per la configurazione della sincronizzazione:
- Autorizzazioni SQL Server: CREATE/ALTER TABLE, ALTER DATABASE, CREATE PROCEDURE, SELECT/ALTER SCHEMA, CREATE TYPE. Queste autorizzazioni sono incluse (insieme ad altre autorizzazioni) nel ruolo
ddl_admin
predefinito del database . - A livello di gruppo di risorse, è necessaria l'appartenenza al ruolo Collaboratore database SQL. Per ulteriori informazioni, vedi Assegnare ruoli di Azure usando il portale di Azure. Anche l'appartenenza a ruoli più ampi, ad esempio collaboratore o proprietario, se già assegnata.
- Le autorizzazioni a livello di sottoscrizione non devono essere necessarie, ma potrebbero fornire un modo semplificato (anche se non meno necessario) per fornire le autorizzazioni necessarie per più implementazioni di Azure sincronizzazione dati in una sottoscrizione. Un'API originale deprecata richiede queste autorizzazioni di Controllo degli accessi in base al ruolo di Azure, ma non deve più essere in uso.
- "Microsoft.Sql/locations/syncMemberOperationResults/read"
- "Microsoft.Sql/locations/syncAgentOperationResults/read"
- "Microsoft.Sql/locations/syncGroupOperationResults/read"
- Autorizzazioni SQL Server: CREATE/ALTER TABLE, ALTER DATABASE, CREATE PROCEDURE, SELECT/ALTER SCHEMA, CREATE TYPE. Queste autorizzazioni sono incluse (insieme ad altre autorizzazioni) nel ruolo
Per la sincronizzazione continua.
- Autorizzazioni di SQL Server: SELECT, INSERT, UPDATE e DELETE sulle tabelle dell’utente selezionate per la sincronizzazione. Autorizzazione EXECUTE per i tipi di tabella definiti dall'utente.
- Autorizzazioni di SQL Server: autorizzazione SELECT, INSERT, UPDATE, and DELETE per i metadati di sincronizzazione e le tabelle di rilevamento create dal sistema. Autorizzazione EXECUTE per le stored procedure create dal servizio.
- Lo schema
DataSync
viene usato per gli oggetti creati dal sistema nei database hub e membri. - Gli schemi
dss
eTaskHosting
vengono usati per gli oggetti creati dal sistema nel database dei metadati di sincronizzazione.
- Lo schema
Per il deprovisioning.
- Autorizzazioni SQL server: ALTER su tabelle che fanno parte della sincronizzazione; SELECT/DELETE su tabelle di metadati di sincronizzazione; CONTROL su tabelle di rilevamento della sincronizzazione, stored procedure e tipi di tabelle definiti dall'utente.
- Per la pulizia, rimuovere gli oggetti creati dal sistema negli schemi
DataSync
,dss
eTaskHosting
.
Il database SQL di Azure supporta un solo set di credenziali. Per eseguire queste operazioni nei limiti di questo vincolo, considerare le opzioni seguenti:
- Modificare le credenziali per le diverse fasi, ad esempio credentials1 per la configurazione e credentials2 per la sincronizzazione continua.
- Modificare l'autorizzazione delle credenziali, ovvero, modificare l'autorizzazione dopo aver configurato la sincronizzazione.
Eseguire i controlli
È consigliabile abilitare il controllo a livello dei database nei gruppi di sincronizzazione. Informazioni su come abilitare il controllo nel database SQL di Azure o abilitare il controllo nel database di SQL Server.
Attrezzaggio
Vincoli e considerazioni sui database
Dimensione database
Quando si crea un nuovo database, impostare la dimensione massima in modo che sia sempre maggiore rispetto al database da distribuire. Se la dimensione massima impostata non è maggiore rispetto al database distribuito, la sincronizzazione avrà esito negativo. Anche se la sincronizzazione dati SQL non offre funzioni di aumento automatico, è possibile eseguire il comando ALTER DATABASE
per aumentare le dimensioni del database dopo che è stato creato. Verificare di rientrare nei limiti delle dimensioni del database.
Importante
Sincronizzazione dati SQL archivia altri metadati con ogni database. Tenere conto di questi metadati quando si calcola lo spazio necessario. La maggiore quantità di overhead è correlata alla larghezza delle tabelle (ad esempio, le tabelle strette richiedono più overhead) e alla quantità di traffico.
Vincoli e considerazioni sulle tabelle
Selezione delle tabelle
Non è necessario includere in un gruppo di sincronizzazione tutte le tabelle presenti in un database. Le tabelle che si includono in un gruppo di sincronizzazione incidono sui costi e sull'efficienza. Includere pertanto in un gruppo di sincronizzazione solo le tabelle necessarie all'azienda e quelle da cui le prime dipendono.
Chiavi primarie
Ogni tabella inclusa in un gruppo di sincronizzazione deve avere una chiave primaria. La sincronizzazione dati SQL non può sincronizzare una tabella che non dispone di una chiave primaria.
Prima di usare la sincronizzazione dati SQL in fase di produzione, testare le prestazioni della sincronizzazione iniziale e di quella continua.
Le tabelle vuote offrono le migliori prestazioni
Le tabelle vuote offrono le migliori prestazioni al momento dell'inizializzazione. Se la tabella di destinazione è vuota, la sincronizzazione dati usa l'inserimento in blocco per caricare i dati. In caso contrario, la sincronizzazione dei dati esegue un confronto e l'inserimento riga per riga per verificare la presenza di conflitti. Se le prestazioni non sono un problema, tuttavia, è possibile impostare la sincronizzazione tra le tabelle che contengono già i dati.
Provisioning dei database di destinazione
La sincronizzazione dati SQL consente il provisioning automatico di base dei database.
Questa sezione descrive le limitazioni del provisioning nel servizio di sincronizzazione dati SQL.
Limitazioni del provisioning automatico
Per quanto riguarda il provisioning automatico, la sincronizzazione dati SQL presenta le limitazioni seguenti:
- Nella tabella di destinazione vengono create solo le colonne selezionate. Nelle tabelle di destinazione non viene eseguito il provisioning delle colonne che non fanno parte del gruppo di sincronizzazione.
- Gli indici vengono creati solo per le colonne selezionate. Se gli indici della tabella di origine includono colonne che non fanno parte del gruppo di sincronizzazione, non verrà eseguito il provisioning di questi indici nelle tabelle di destinazione.
- Non viene eseguito il provisioning degli indici nelle colonne di tipo XML.
- Sincronizzazione dati supporta solo le due proprietà di indice seguenti: Univoco, Clustered/Non Clustered. Altre proprietà dell'indice come IGNORE_DUP_KEY, Where filter predicate 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.
- Non viene eseguito il provisioning dei vincoli CHECK.
- Non viene eseguito il provisioning dei trigger esistenti nelle tabelle di origine.
- Non vengono create viste e stored procedure nel database di destinazione.
- Le azioni ON UPDATE CASCADE e ON DELETE CASCADE su vincoli di chiave esterna non vengono ricreate nelle tabelle di destinazione.
- Se si hanno colonne decimali o numeriche con una precisione superiore a 28, la sincronizzazione dati SQL può riscontrare un problema di overflow di conversione durante la sincronizzazione. Si consiglia di limitare la precisione delle colonne del decimale o numerica su 28 o su un valore inferiore.
Consigli
- Usare la funzionalità di provisioning automatico della sincronizzazione dati SQL solo per testare il servizio.
- Per la fase di produzione eseguire il provisioning dello schema del database.
Ubicazione del database hub
Scenario da azienda a cloud
Per ridurre al minimo la latenza, mantenere il database hub in prossimità della maggiore concentrazione del traffico del database del gruppo di sincronizzazione.
Scenario da cloud a cloud
- Quando tutti i database di un gruppo di sincronizzazione sono ubicati in un unico data center, l'hub deve trovarsi nello stesso data center. Questa configurazione riduce la latenza e il costo del trasferimento dei dati tra data center.
- Quando i database di un gruppo di sincronizzazione sono ubicati in più data center, l'hub deve trovarsi nello stesso data center in cui si trova la maggior parte dei database e in cui è presente il maggior volume di traffico.
Scenari misti
Applicare le linee guida precedenti a configurazioni più complesse di gruppi di sincronizzazione, ad esempio a scenari misti da azienda a cloud e da cloud a cloud.
Sincronizza
Evitare una sincronizzazione iniziale lenta e dispendiosa
Questa sezione prende in esame la sincronizzazione iniziale di un gruppo di sincronizzazione e spiega come evitare che per tale sincronizzazione iniziale siano richiesti tempi più lunghi e costi più elevati del necessario.
Funzionamento della sincronizzazione iniziale
Quando si crea un gruppo di sincronizzazione, iniziare con dati in un solo database. Se sono presenti dati in più database, la sincronizzazione dati SQL considera ogni riga come un conflitto da risolvere. La risoluzione dei conflitti causa un rallentamento della sincronizzazione iniziale, che può richiedere giorni o addirittura mesi a seconda delle dimensioni del database.
Se i database si trovano in data center diversi, ogni riga deve spostarsi da un data center a un altro, con il conseguente aumento dei costi della sincronizzazione iniziale.
Elemento consigliato
Se possibile, iniziare con i dati in un unico database del gruppo di sincronizzazione.
Progettazione che evita i cicli di sincronizzazione
Si verifica un ciclo di sincronizzazione quando all'interno di un gruppo di sincronizzazione sono presenti riferimenti circolari. In uno scenario di questo tipo ogni modifica in un database viene replicata in modo circolare e all'infinito nei database del gruppo di sincronizzazione.
È consigliabile evitare i cicli di sincronizzazione in quanto possono provocare una riduzione delle prestazioni e un aumento significativo dei costi.
Modifiche che non vengono propagate
Cause della mancata propagazione delle modifiche
È possibile che le modifiche apportate non vengano propagate per uno dei motivi seguenti:
- Incompatibilità dello schema o del tipo di dati.
- Inserimento di valori null in colonne che non ammettono valori null.
- Violazione di vincoli di chiavi esterne.
Cosa accade se le modifiche non vengono propagate?
- Il gruppo di sincronizzazione indica che si trova in uno stato di Warning (Avviso).
- I dettagli sono elencati nel visualizzatore log dell'interfaccia utente del portale.
- Se il problema non viene risolto per 45 giorni, il database risulterà "Non aggiornato".
Nota
Queste modifiche non verranno mai propagate. L'unico modo per risolvere il problema è ricreare il gruppo di sincronizzazione.
Elemento consigliato
Monitorare regolarmente l'integrità del database e del gruppo di sincronizzazione attraverso l'interfaccia del portale e del log.
Gestione
Evitare database e gruppi di sincronizzazione non aggiornati
È possibile che un gruppo di sincronizzazione o un database all'interno di un gruppo di sincronizzazione non sia più aggiornato. Quando lo stato di un gruppo di sincronizzazione è Out-of-date (Non aggiornato), il gruppo smette di funzionare. Quando lo stato di un database è Out-of-date (Non aggiornato), può verificarsi una perdita di dati. È consigliabile evitare questo scenario anziché provare a risolvere il problema.
Evitare database e gruppi di sincronizzazione non aggiornati
Lo stato di un database viene impostato su Out-of-date (Non aggiornato) quando il database è offline da almeno 45 giorni. Per evitare che lo stato di un database venga impostato su Out-of-date (Non aggiornato), verificare che nessun database rimanga offline per 45 giorni o più.
Evitare i gruppi di sincronizzazione non aggiornati
Lo stato di un gruppo di sincronizzazione viene impostato su Out-of-date (Non aggiornato) quando le modifiche nel gruppo non vengono propagate al resto del gruppo di sincronizzazione per 45 giorni o più. Per evitare che lo stato di un gruppo di sincronizzazione venga impostato su Out-of-date (Non aggiornato), controllare regolarmente il log della cronologia del gruppo di sincronizzazione. Verificare che tutti i conflitti siano risolti e che le modifiche vengano propagate a tutti i database del gruppo di sincronizzazione.
È possibile che un gruppo di sincronizzazione non riesca ad applicare una modifica per uno dei motivi seguenti:
- Incompatibilità dello schema tra tabelle.
- Incompatibilità dei dati tra tabelle.
- Inserimento di una riga con valore null in una colonna che non ammette valori null.
- Aggiornamento di una riga con un valore che viola un vincolo di chiave esterna.
Per evitare che i gruppi di sincronizzazione non vengano aggiornati:
- Aggiornare lo schema per includere i valori contenuti nelle righe con esito negativo.
- Aggiornare i valori delle chiavi esterne per includere i valori contenuti nelle righe con esito negativo.
- Aggiornare i valori dei dati nella riga con esito negativo in modo che siano compatibili con lo schema o con le chiavi esterne nel database di destinazione.
Evitare problemi di deprovisioning
In alcuni casi, l'annullamento della registrazione di un database con un agente client può causare un errore di sincronizzazione.
Scenario
- Il gruppo di sincronizzazione A è stato creato con un'istanza di database SQL e un database di SQL Server, associato all'agente locale 1.
- Lo stesso database locale è registrato con l'agente locale 2, che non è associato ad alcun gruppo di sincronizzazione.
- Se si annulla la registrazione del database locale dall'agente locale 2, vengono rimosse le tabelle di rilevamento e metadati del gruppo di sincronizzazione A per il database locale.
- Le operazioni del gruppo di sincronizzazione A non riescono e viene visualizzato il messaggio di errore seguente: "The current operation could not be completed because the database is not provisioned for sync or you do not have permissions to the sync configuration tables" (Non è stato possibile completare l'operazione corrente perché non è stato eseguito il provisioning del database per la sincronizzazione o non si dispone delle autorizzazioni per accedere alle tabelle di configurazione della sincronizzazione).
Soluzione
Per evitare questo scenario, non registrare un database con più agenti.
Per risolvere il problema:
- Rimuovere il database da ogni gruppo di sincronizzazione a cui appartiene.
- Riaggiungere il database a ogni gruppo di sincronizzazione da cui è stato rimosso.
- Distribuire ogni gruppo di sincronizzazione interessato (questa operazione esegue il provisioning del database).
Modificare un gruppo di sincronizzazione
Non provare a rimuovere un database da un gruppo di sincronizzazione e quindi a modificare il gruppo senza aver prima distribuito una delle modifiche.
Rimuovere prima un database da un gruppo di sincronizzazione. Distribuire quindi la modifica e attendere che venga completato il deprovisioning. Al termine di questa operazione, è possibile modificare il gruppo di sincronizzazione e distribuire le modifiche.
Se si prova a rimuovere un database e quindi a modificare un gruppo di sincronizzazione senza aver prima distribuito una delle modifiche, una delle due operazioni avrà esito negativo. L'interfaccia del portale può essere visualizzata in modo incoerente. In questo caso, aggiornare la pagina per ripristinare lo stato corretto.
Evitare il timeout dell'aggiornamento dello schema
Se si dispone di uno schema complesso da sincronizzare, è possibile che si verifichi un "timeout dell'operazione" durante un aggiornamento dello schema se il database dei metadati di sincronizzazione ha uno SKU inferiore (ad esempio: basic).
Soluzione
Per prevenire questo problema, valutare la possibilità di aumentare le risorse del database dei metadati di sincronizzazione.
Contenuto correlato
Per altre informazioni sulla sincronizzazione dati SQL, vedere:
- Panoramica: Sincronizzare i dati tra più database cloud e locali con la sincronizzazione dati SQL di Azure
- Configurare la sincronizzazione dati SQL
- Agente di sincronizzazione dei dati: Agente di sincronizzazione dei dati per la sincronizzazione dati SQL di Azure
- Monitoraggio: Monitorare la sincronizzazione dati SQL con i log di Monitoraggio di Azure
- Risoluzione dei problemi: Risolvere i problemi della sincronizzazione dati SQL di Azure
- Aggiornare lo schema di sincronizzazione
Per altre informazioni sul database SQL, vedere: