Database SQL di Azure con Change Data Capture (CDC)

Si applica a:Database SQL di Azure

In questo articolo vengono fornite informazioni sull’implementazione nel database SQL di Azure di Change Data Capture (CDC), che registra l'attività in un database quando le tabelle e le righe sono state modificate. Per informazioni dettagliate sulla funzionalità CDC, inclusa la modalità di implementazione in SQL Server e Istanza gestita di SQL di Azure, vedere Che cos'è Change Data Capture (CDC)?

Panoramica

Nel database SQL di Azure un pianificatore di Change Data Capture sostituisce la funzione SQL Server Agent che richiama l'acquisizione e la pulizia periodiche delle tabelle di origine. Il pianificatore esegue l'acquisizione e la pulizia dei processi automaticamente all'interno del database senza alcuna dipendenza esterna per l'affidabilità o le prestazioni. Gli utenti mantengono l'opzione per avviare manualmente i processi di acquisizione e pulizia, in base alle esigenze.

Un ottimo esempio di consumer di dati a cui è rivolta questa tecnologia è un'applicazione di estrazione, trasformazione e caricamento (ETL). Un'applicazione ETL carica incrementalmente dati delle modifiche dalle tabelle di origine di SQL Server in un data warehouse oppure in un data mart. Anche se la rappresentazione delle tabelle di origine all'interno del data warehouse deve riflettere le modifiche in tali tabelle, una tecnologia end-to-end che aggiorna una replica dell'origine non è appropriata. È necessario invece un flusso affidabile di dati delle modifiche strutturato in modo che i consumer possano applicarlo a rappresentazioni di destinazione dei dati diverse. Change Data Capture di SQL Server fornisce questa tecnologia.

Per altre informazioni sull'acquisizione dei dati delle modifiche in database SQL di Azure fare riferimento a questo episodio relativo all'esposizione dei dati:

Flusso di dati

Nella figura seguente viene illustrato il flusso di dati principale per Change Data Capture con il database SQL di Azure:

Prerequisiti

Autorizzazioni

Il ruolo db_owner è necessario per abilitare Change Data Capture per database SQL di Azure.

Requisiti di calcolo di database SQL di Azure

È possibile abilitare CDC in database SQL di Azure per qualsiasi livello di servizio all'interno del modello di acquisto basato su vCore, sia per i singoli database sia per i pool elastici.

Per i database nel modello di acquisto DTU, CDC è supportato per i database nel livello S3 o versione successiva. I livelli subcore (Basic, S0, S1 e S2) non sono supportati per CDC.

Abilitare CDC per i database SQL di Azure

Prima di poter creare un'istanza di acquisizione per singole tabelle, è necessario abilitare CDC per il database SQL di Azure.

Per abilitare CDC, aprire SQL Server Management Studio (SSMS) o Azure Data Studio e connettersi al database di SQL Server. Aprire una nuova finestra di query, quindi abilitare CDC eseguendo il seguente T-SQL:

EXEC sys.sp_cdc_enable_db;
GO

Quando un database è abilitato per Change Data Capture, per il database vengono creati cdc schema, cdc user, le tabelle dei metadati e altri oggetti di sistema. cdc schema contiene le tabelle di metadati di Change Data Capture e, dopo l'abilitazione di CDC per le tabelle di origine, le singole tabelle delle modifiche fungono da repository per i dati delle modifiche. cdc schema contiene inoltre funzioni di sistema associate utilizzate per eseguire query sui dati delle modifiche.

Abilitare CDC per una tabella

Dopo aver abilitato CDC per il database SQL di Azure è possibile abilitare CDC a livello di tabella selezionando una o più tabelle per tenere traccia delle modifiche ai dati. Creare un'istanza di acquisizione per singole tabelle di origine usando la procedure sys.sp_cdc_enable_table memorizzata.

Per abilitare CDC per una tabella eseguire il seguente T-SQL:

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = NULL;
GO

Colonne nella tabella di origine da acquisire

Per impostazione predefinita, tutte le colonne della tabella di origine vengono identificate come colonne acquisite. Se è necessario rilevare solo un subset di colonne, ad esempio per motivi di privacy o di prestazioni, usare il parametro @captured_column_list per specificare il subset di colonne.

Per abilitare CDC per un elenco specifico di colonne in una tabella eseguire il codice T-SQL seguente:

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = NULL,
    @captured_column_list = N'Column1, Column2, Column3';
GO

Un ruolo per il controllo dell’accesso alla tabella delle modifiche

Lo scopo del ruolo specificato consiste nel controllare l'accesso ai dati delle modifiche. Il ruolo specificato può essere un ruolo predefinito del server esistente o un ruolo del database. Se il ruolo specificato non è già presente, verrà automaticamente creato un ruolo del database con il nome indicato. Gli utenti devono disporre dell'autorizzazione SELECT per tutte le colonne acquisite della tabella di origine. Quando viene specificato un ruolo, inoltre, gli utenti che non sono membri del ruolo sysadmin o db_owner devono essere anche membri del ruolo specificato.

Per abilitare CDC per la tabella che specifica un ruolo di controllo, eseguire il seguente T-SQL:

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = N'RoleName'
GO

Se non si vuole usare un ruolo di controllo, impostare in modo esplicito il parametro @role_name su NULL.

Una funzione per eseguire query per le modifiche di rete

Un'istanza di acquisizione include sempre una funzione con valori di tabella per la restituzione di tutte le voci della tabella delle modifiche generate in un intervallo definito. Il nome di questa funzione viene creato aggiungendo il nome dell'istanza di acquisizione a cdc.fn_cdc_get_all_changes_. Per altre informazioni vedere cdc.fn_cdc_get_all_changes.

Se il parametro @supports_net_changes è impostato su 1, viene generata anche una funzione delle modifiche delta per l'istanza di acquisizione. Questa funzione restituisce solo una modifica per ogni riga distinta modificata nell'intervallo specificato nella chiamata. Per altre informazioni vedere cdc.fn_cdc_get_net_changes.

Per supportare le query sulle modifiche delta, è necessario che la tabella di origine disponga di una chiave primaria o di un indice univoco per identificare le righe in modo univoco. Se viene usato un indice univoco, il nome dell'indice deve essere specificato con il parametro @index_name . Le colonne definite nella chiave primaria o nell'indice univoco devono essere incluse nell'elenco delle colonne di origine da acquisire.

Per abilitare CDC per una tabella con supporto per le modifiche i rete eseguire il seguente T-SQL:

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = NULL,
    @supports_net_changes = 1
GO

Se Change Data Capture è abilitato in una tabella con una chiave primaria esistente e non viene usato il parametro @index_name per identificare un indice univoco alternativo, la funzionalità Change Data Capture userà la chiave primaria. Non saranno consentite modifiche successive alla chiave primaria se prima non si disabilita Change Data Capture per la tabella. Questa regola è sempre valida, indipendentemente dal fatto che durante la configurazione di Change Data Capture sia stato o meno richiesto il supporto per le query sulle modifiche delta.

Se non è presente alcuna chiave primaria in una tabella al momento dell'abilitazione per Change Data Capture, l'aggiunta successiva di una chiave primaria viene ignorata da Change Data Capture. Poiché Change Data Capture non utilizzerà una chiave primaria creata in seguito all'abilitazione della tabella, la chiave e le colonne chiave possono essere rimosse senza restrizioni.

Per altre informazioni sugli argomenti della stored procedure sys.sp_cdc_enable_table, vedere sys.sp_cdc_enable_table.

Disabilitare CDC per database SQL di Azure

La disabilitazione di CDC per il database SQL di Azure rimuove tutti i metadati di Change Data Capture associati, inclusi cdc user, cdc schema e i processi di acquisizione e pulizia dell'utilità di pianificazione esterna. Eventuali ruoli di controllo creati da Change Data Capture, tuttavia, non verranno rimossi automaticamente e devono essere eliminati in modo esplicito.

Non è necessario disabilitare CDC per le singole tabelle prima di disabilitarlo a livello di database.

Per disabilitare CDC a livello di database eseguire il seguente T-SQL:

EXEC sys.sp_cdc_disable_db;
GO

Gestione di CDC

In Database SQL di Azure, CDC è una funzionalità fondamentale per tenere traccia e gestire le modifiche nelle tabelle di database. A differenza degli ambienti SQL Server tradizionali, il database SQL di Azure usa un'utilità di pianificazione Change Data Capture per gestire le attività CDC invece di basarsi sui processi di SQL Server Agent. Questa utilità di pianificazione avvia automaticamente processi di acquisizione e pulizia periodici per le tabelle CDC all'interno del database, garantendo affidabilità e prestazioni senza alcuna dipendenza esterna.

Acquisizione e pulizia CDC automatiche

Il processo di acquisizione CDC in database SQL di Azure viene eseguito senza soluzione di continuità ogni 20 secondi per tenere traccia delle modifiche in modo efficiente. Contemporaneamente, il processo di pulizia viene eseguito ogni ora, garantendo che le tabelle CDC rimangano ottimizzate. Gli utenti possono assicurarsi del fatto che la gestione CDC venga eseguita automaticamente senza intervento manuale.

Controllo CDC manuale

Mentre il CDC viene eseguito automaticamente, gli utenti mantengono la flessibilità necessaria per eseguire operazioni CDC manuali su richiesta. Le procedure sp_cdc_scan e sp_cdc_cleanup_change_tables consentono di attivare le attività di acquisizione e pulizia in base alle esigenze.

Monitoraggio di CDC

Il database SQL di Azure fornisce strumenti preziosi per monitorare le attività CDC. Due viste a gestione dinamica, sys.dm_cdc_log_scan_sessions e sys.dm_cdc_errors, offrono informazioni dettagliate sui processi CDC, garantendo una visibilità completa sulle modifiche dei dati.

Personalizzazione CDC

Sebbene il database SQL di Azure semplifichi la gestione CDC, esistono alcune limitazioni:

• La frequenza dei processi di acquisizione e pulizia CDC non può essere personalizzata.
• I valori pollinginterval e continuous per i processi di acquisizione e pulizia non sono applicabili al database SQL di Azure.
• La rimozione della voce del processo di acquisizione dalla tabella cdc.cdc_jobs non interrompe il processo di acquisizione in background.
• L'eliminazione della voce del processo di pulizia arresta il processo.
• La tabella cdc.cdc_jobs risiede nello schema cdc, non msdb.

Nonostante queste limitazioni è comunque possibile personalizzare le opzioni seguenti:

• Eseguire una query sulla tabella cdc.cdc_jobs per i dettagli di configurazione correnti.
• Modificare le opzioni maxtrans e maxscans usando la procedura sp_cdc_change_job memorizzata.
• Gestire i processi impiegando sp_cdc_drop_job e sp_cdc_add_job secondo necessità.

Considerazioni e raccomandazioni sulle prestazioni

L'abilitazione di Change Data Capture per il database SQL di Azure ha un effetto sulle prestazioni paragonabile all'abilitazione di CDC per SQL Server o Istanza gestita di SQL di Azure. Tuttavia, diversi fattori influenzano l'effetto delle prestazioni quando si abilita CDC, tra cui:

• Il numero di tabelle abilitate per CDC nel database SQL di Azure.

• La frequenza delle modifiche nelle tabelle rilevate o il volume di transazioni. Le transazioni attive continueranno a contenere il troncamento del log fino a quando non viene eseguito il commit della transazione e l'analisi CDC non si aggiorna oppure la transazione non termina in modo imprevisto. Poiché ciò potrebbe comportare il riempimento del log delle transazioni più del previsto, deve essere monitorato in modo che il log delle transazioni non venga compilato.

• Assicurarsi che nel database di origine sia disponibile spazio libero, perché gli artefatti CDC (ad esempio tabelle CT, cdc_jobs e così via) vengono archiviati nello stesso database,

• indipendentemente dal fatto che sia disponibile un database singolo o che faccia parte di un pool elastico.

• I database in un pool elastico condividono risorse (ad esempio lo spazio su disco), pertanto l'abilitazione di CDC in più database comporta il rischio di raggiungere le dimensioni massime del disco del pool elastico. Monitorare le risorse, tra cui CPU, memoria e produttività del log. Per altre informazioni, vedere Gestione delle risorse in pool elastici densi.

• Quando si gestiscono i database nei pool elastici, è fondamentale considerare il numero di tabelle abilitate per CDC e il numero di database cui appartengono tali tabelle. È consigliabile valutare il carico di lavoro e adottare misure necessarie, come il ridimensionamento del pool elastico. Per altre informazioni, vedere Ridimensionare le risorse dei pool elastici nel database SQL di Azure.

Quando si usa CDC con database SQL di Azure, prendere in considerazione le seguenti procedure consigliate:

• Testare accuratamente il carico di lavoro prima di abilitare CDC nei database nell'ambiente di produzione per determinare un SLO appropriato per il carico di lavoro. Per ulteriori informazioni sui livelli di calcolo per il database SQL di Azure, vedere Livelli di servizio.

• Valutare la possibilità di ridimensionare il numero di vCore o di passare a un livello di database superiore, ad esempio Hyperscale, per mantenere il livello di prestazioni precedente dopo che CDC è stato abilitato nel database SQL di Azure. Per altre informazioni, vedere Modello di acquisto vCore - Database SQL di Azure e Livello di servizio Hyperscale.

• Monitorare l'utilizzo dello spazio attentamente. Per altre informazioni, vedere Gestire lo spazio file nel database SQL di Azure.

• Monitorare il tasso di generazione dei log. Per altre informazioni, vedere Utilizzo delle risorse per carichi di lavoro utente e processi interni.

• I processi di analisi e pulizia CDC fanno parte del normale carico di lavoro del database (così come l’utilizzo delle risorse). A seconda del volume delle transazioni, la riduzione delle prestazioni può essere sostanziale a causa dei processi di analisi e pulizia che non mantengono il carico di lavoro man mano che vengono aggiunte intere righe alle tabelle delle modifiche e, per le operazioni di aggiornamento, è inclusa anche l'immagine preliminare. È consigliabile valutare il carico di lavoro e adottare le misure necessarie secondo le raccomandazioni precedenti. Per ulteriori informazioni, vedere la sezione Gestione CDC più avanti in questo articolo.

• Per evitare un aumento della latenza, verificare che il numero di database abilitati per CDC non superi il numero di vCore allocati a un pool elastico. Per altre informazioni, vedere Gestione delle risorse in pool elastici densi.

• In base al carico di lavoro e al livello di prestazioni è consigliabile modificare il periodo di conservazione CDC impostando un numero inferiore rispetto al valore predefinito di tre giorni per garantire che il processo di pulizia possa mantenere il passo con le modifiche nella tabella delle modifiche. Si consiglia di mantenere un periodo di conservazione inferiore durante il monitoraggio delle dimensioni del database.

• Non viene fornito alcun accordo sul livello di servizio (SLA) per quando le modifiche vengono popolate nelle tabelle delle modifiche. La latenza di sottosecondi non è supportata.

Problemi noti e limitazioni

Troncamento del log aggressivo

Quando si abilita Change Data Capture (CDC) nel database SQL di Azure, la funzionalità di troncamento aggressivo del log di Ripristino accelerato del database (ADR) è disabilitata. Ciò è dovuto al fatto che l'analisi di CDC accede al log delle transazioni del database. Le transazioni attive continueranno a contenere il troncamento del log delle transazioni fino a quando non viene eseguito il commit della transazione e l'analisi CDC non si aggiorna oppure la transazione non termina in modo imprevisto.

Quando si abilita CDC, è consigliabile usare l'opzione ripristinabile per l'indice quando si crea o ricompila un indice. Per la creazione o la ricompilazione di un indice ripristinabile non è necessario tenere aperta una transazione con esecuzione prolungata ed è possibile eseguire il troncamento del log durante l'operazione ottimizzando la gestione dello spazio del log. Per altre informazioni vedere Linee guida per le operazioni sugli indici online - Considerazioni sugli indici ripristinabili.

Livello di servizio del database SQL di Azure

Anche se CDC è supportato per database e pool elastici in qualsiasi livello di servizio all'interno del modello di acquisto basato su vCore, i database inferiori a S3 (ad esempio Basic, S0, S1, S2) non sono supportati nel modello di acquisto DTU.

Limiti del log del database SQL di Azure

Il ripristino accelerato del database e CDC sono compatibili. Tuttavia, il comportamento aggressivo di troncamento del log di ADR è disabilitato quando CDC è abilitato. Ciò è dovuto al fatto che l'analisi CDC accede attivamente e interagisce con il log delle transazioni del database, impedendo così il comportamento aggressivo di troncamento del log di ADR.

Quando si abilita CDC, è possibile osservare un utilizzo più elevato del log delle transazioni. Potrebbe essere necessario aumentare le prestazioni fino a un livello di servizio o a una dimensione di calcolo superiore per garantire che lo spazio del log delle transazioni sufficiente sia disponibile per le esigenze di tutti i carichi di lavoro.

Le istruzioni DDL online non sono supportate

Le istruzioni DDL online non sono supportate quando change data capture è abilitato in un database.

Personalizzazione del processo di acquisizione e pulizia

La configurazione della frequenza dell'acquisizione e dei processi di pulizia per CDC in database SQL di Azure è impossibile. L'utilità di pianificazione esegue automaticamente il processo di acquisizione e pulizia.

Failover per il database SQL di Azure

Negli scenari di failover locali o geoDR, se il database ha abilitato CDC, il processo di acquisizione e pulizia delle modifiche dei dati avviene automaticamente nel nuovo database primario dopo il failover.

Microsoft Entra ID

Se si crea un database in database SQL di Azure come utente Microsoft Entra ID e si abilita CDC, un utente di SQL (ad esempio, ruolo sysadmin) non potrà disabilitare/modificare gli artefatti CDC. Tuttavia, un altro utente Microsoft Entra potrà abilitare/disabilitare CDC nello stesso database.

Analogamente, se si crea un database SQL di Azure come utente di SQL, l'abilitazione/la disabilitazione di CDC come utente di Microsoft Entra non funzionerà.

L'abilitazione di CDC ha esito negativo se si crea un database in database SQL di Azure come utente di Microsoft Entra, non abilitare CDC, quindi provare ad abilitare CDC dopo il ripristino del database.

Per risolvere questo problema connettersi al database con l'account amministratore di Microsoft Entra ed eseguire il seguente T-SQL:

ALTER AUTHORIZATION ON DATABASE::[<restored_db_name>] TO [<azuread_admin_login_name>];

EXEC sys.sp_cdc_enable_db;

Ripristino temporizzato

Se viene abilitato CDC nel database SQL di Azure come utente SQL, il ripristino point-in-time (PITR) mantiene CDC nel database ripristinato, a meno che non venga ripristinato su un livello SLO subcore. Se ripristinato a uno SLO di un subcore, gli artefatti CDC non sono disponibili.

Se si abilita CDC nel database come utente Microsoft Entra, non è possibile eseguire il ripristino temporizzato (PITR) in un SLO subcore. Ripristinare il database nello stesso SLO o superiore dell'origine, quindi disabilitare CDC, se necessario.

Risoluzione dei problemi

La presente sezione fornisce indicazioni e procedure di risoluzione dei problemi associate a CDC in database SQL di Azure. Gli errori correlati a CDC potrebbero impedire il corretto funzionamento del processo di acquisizione e portare all'espansione del log delle transazioni del database.

Per esaminare questi errori, è possibile eseguire una query sulla vista a gestione dinamica sys.dm_cdc_errors. Se la vista sys.dm_cdc_errors a gestione dinamica restituisce errori, fare riferimento alla sezione seguente per comprendere i passaggi di mitigazione.

Le seguenti sono le diverse categorie di risoluzione dei problemi incluse nella presente sezione:

Categoria	Descrizione
Metadati modificati	Include informazioni su come attenuare i problemi relativi a CDC quando la presentazione rilevata viene modificata o eliminata.
Gestione dello spazio nel database	Include informazioni su come attenuare i problemi quando lo spazio del database si esaurisce.
Limitazione CDC	Include informazioni su come attenuare i problemi causati dalle limitazioni in CDC.

Metadati modificati

Errore 200/208: nome dell'oggetto non valido

• Causa: l'errore potrebbe verificarsi quando i metadati CDC vengono eliminati. Affinché CDC funzioni correttamente, non è consigliabile modificare manualmente metadati CDC, ad esempio CDC schema, tabelle di modifica, procedure memorizzate di sistema CDC e autorizzazioni predefinite cdc user (sys.database_principals) o rinominare cdc user.

• Raccomandazione: per risolvere questo problema è necessario disabilitare e riabilitare CDC per il database. Quando un database è abilitato per Change Data Capture, per il database vengono creati lo schema CDC, l'utente CDC, le tabelle dei metadati e altri oggetti di sistema. È necessario riabilitare manualmente CDC per le singole tabelle dopo l'abilitazione di CDC per il database.

Errore 1202: l'entità di database non esiste o l'utente non è un membro

• Causa: l'errore potrebbe verificarsi quando gli utenti CDC vengono eliminati. Affinché CDC funzioni correttamente, non è consigliabile modificare manualmente metadati CDC, come CDC schema, tabelle di modifica, procedure memorizzate di sistema CDC, autorizzazioni predefinite cdc user (sys.database_principals) o rinominare cdc user.

• Consiglio: assicurarsi che l'utente cdc esista nel database e disponga del ruolo db_owner assegnato. Per creare l'utente cdc vedere l'esempio Creare un utente CDC e assegnarvi il ruolo.

Errore 15517: non è possibile effettuare l’esecuzione come entità di database poiché l'entità di sicurezza non esiste

• Causa: questo tipo di entità non può essere rappresentato o non si dispone dell'autorizzazione necessaria. L'errore può verificarsi quando i metadati CDC sono stati eliminati o non fanno più parte del ruolo db_owner. Affinché CDC funzioni correttamente, non è consigliabile modificare manualmente metadati CDC, come CDC schema, tabelle di modifica, procedure memorizzate di sistema CDC, autorizzazioni predefinite cdc user (sys.database_principals) o rinominare cdc user.

• Consiglio: assicurarsi che l'utente cdc esista nel database e disponga del ruolo db_owner assegnato. Per creare l'utente cdc vedere l'esempio Creare un utente CDC e assegnarvi il ruolo.

Errore 18807: impossibile trovare un ID di oggetto per la tabella del sistema di replica

• Causa: questo errore si verifica quando il motore di database di SQL Server non riesce a trovare o ad accedere alla tabella del sistema di replica '%s.' La tabella potrebbe non essere raggiungibile o mancante. Affinché CDC funzioni correttamente, non modificare manualmente nessun metadato CDC, come ad esempio il CDC schema, le tabelle delle modifiche, le stored procedure di sistema CDC, le autorizzazioni predefinite cdc user (sys.database_principals) o rinominare il cdc user.

• Consiglio: verificare che la tabella di sistema esista e sia accessibile interrogandola direttamente. Eseguire una query sul catalogo di sistema sys.objects e impostare la clausola predicato con is_ms_shipped=1 e schema_name=cdc per elencare tutti gli oggetti correlati a CDC. Se la query non restituisce oggetti, è necessario disabilitare, quindi riabilitare CDC per il database. Quando un database è abilitato per Change Data Capture, per il database vengono creati cdc schema, cdc user, le tabelle dei metadati e altri oggetti di sistema. È necessario riabilitare manualmente CDC per le singole tabelle dopo l'abilitazione di CDC per il database.

Errore 21050: questa operazione può essere eseguita solo dai membri del ruolo predefinito del server sysadmin o db_owner

• Causa: l'utente cdc è stato rimosso dal ruolo db_owner del database o dal ruolo sysadmin del server.

• Consiglio: assicurarsi che all'utente cdc sia assegnato il ruolo db_owner. Per creare l'utente cdc vedere l'esempio Creare un utente CDC e assegnarvi il ruolo.

Gestione dello spazio nel database

Errore 1105: non è stato possibile allocare spazio per l'oggetto nel database perché il filegroup è pieno

• Causa: questo errore si verifica quando il filegroup primario di un database esaurisce lo spazio e database SQL non è in grado di allocare più spazio per un oggetto (ad esempio una tabella o un indice) all'interno del filegroup.

• Consiglio: per risolvere questo problema, eliminare eventuali dati non necessari all'interno del database per liberare spazio. Identificare tabelle, indici oppure altri oggetti inutilizzati nel filegroup che possono essere rimossi in modo sicuro. Monitorare attentamente l’utilizzo dello spazio. Per altre informazioni, vedere Gestire lo spazio file nel database SQL di Azure.

  Nel caso in cui l'eliminazione di dati/oggetti non necessari sia impossibile, è consigliabile passare a un livello di database superiore.

Errore 1132: il pool elastico ha raggiunto il limite di archiviazione

• Causa: questo errore si verifica quando l'utilizzo dello spazio di archiviazione nel pool elastico supera il limite allocato.

• Consiglio: per risolvere questo problema, implementare strategie di archiviazione ed eliminazione dei dati per mantenere solo i dati necessari nei database che fanno parte del pool elastico. Monitorare l'utilizzo dello spazio attentamente. Per altre informazioni, vedere Gestire lo spazio file nel database SQL di Azure.

  Nel caso in cui l’archiviazione o l'eliminazione di dati/oggetti non necessari sia impossibile, è consigliabile passare a un livello di database superiore.

Limitazione CDC

Errore 2628: i dati di tipo string o binary verrebbero troncati nella tabella

• Causa: la modifica delle dimensioni delle colonne di una tabella abilitata per CDC tramite istruzioni DDL potrebbe causare problemi con il processo di acquisizione CDC successivo. La DMV (Dynamic Management View) sys.dm_cdc_errors è utile per controllare eventuali problemi segnalati da CDC, ad esempio gli errori 2628 e 8115.

• Consiglio: prima di apportare modifiche alle dimensioni delle colonne, è necessario valutare se la modifica è compatibile con i dati esistenti nelle tabelle delle modifiche CDC. Per risolvere questo problema è necessario disabilitare e riabilitare CDC per il database. Per altre informazioni sull'abilitazione di CDC per un database o una tabella, vedere le sezioni Abilitare CDC per database SQL di Azure e Abilitare CDC per una tabella in questo articolo.

Errore 22830: la funzione predefinita 'SUSER_SNAME' nel contesto di rappresentazione non è supportata in questa versione di SQL Server

• Causa: questo errore si verifica durante l'abilitazione di CDC se nel database esiste un trigger utente con una chiamata a SUSER_SNAME() su create_table. È possibile elencare i trigger con il seguente script Transact-SQL. Questo comando fornisce i dettagli del trigger dell'oggetto e un corrispondente object_id:

  SELECT name,
      object_id
  FROM sys.triggers
  WHERE parent_class_desc = 'DATABASE'
      AND is_disabled = 0;
  

  Dopo aver ottenuto le definizioni di trigger, è possibile cercare le chiamate a SYSTEM_USER con il seguente script:

  SELECT OBJECT_DEFINITION(object_id) AS trigger_definition;
  

• Consiglio: per risolvere questo problema, seguire questa procedura per ogni trigger utente ottenuto dallo script precedente.

  • Disabilitare il trigger
  • Abilitare CDC
  • Riattivare il trigger

Per altre informazioni, vedere DISABLE TRIGGER.

Errore 913: processo di acquisizione CDC non riuscito durante l'elaborazione delle modifiche per una tabella con tipo di dati CLR di sistema

• Causa: questo errore si verifica quando si abilita CDC in una tabella con il tipo di dati CLR di sistema, si apportano modifiche DML, quindi si apportano modifiche DDL nella stessa tabella mentre il processo di acquisizione CDC elabora le modifiche correlate ad altre tabelle.

• Consiglio: la procedura consigliata consiste nel disattivare DML nella tabella, eseguire un processo di acquisizione per elaborare le modifiche, eseguire DDL per la tabella, eseguire un processo di acquisizione per elaborare le modifiche DDL, quindi riabilitare l'elaborazione DML. Per altre informazioni, vedere processo di acquisizione CDC ha esito negativo durante l'elaborazione delle modifiche per una tabella con tipo di dati CLR di sistema (geometry, geography o hierarchyid).

Creare un utente e assegnare ruoli

Se cdc user è stato rimosso, è possibile aggiungere manualmente l'utente.

Usare lo script T-SQL seguente per creare un utente (cdc) e assegnarvi il ruolo appropriato (db_owner).

IF NOT EXISTS (
    SELECT *
    FROM sys.database_principals
    WHERE NAME = 'cdc'
)
BEGIN
    CREATE USER [cdc] WITHOUT LOGIN
    WITH DEFAULT_SCHEMA = [cdc];
END

EXEC sp_addrolemember 'db_owner', 'cdc';

Controllare e aggiungere l'appartenenza ai ruoli

Per verificare se l’utente cdc appartiene al ruolo sysadmin o db_owner, eseguire la query T-SQL seguente:

EXECUTE AS USER = 'cdc';

SELECT is_srvrolemember('sysadmin'), is_member('db_owner');

Se l'utente cdc non appartiene a nessuno dei due ruoli, eseguire la query T-SQL seguente per aggiungere un ruolo db_owner all'utente cdc.

EXEC sp_addrolemember 'db_owner' , 'cdc';

Contenuto correlato

• Usare i dati delle modifiche
• Tenere traccia delle modifiche ai dati (SQL Server)
• amministrare e monitorare la cattura dati delle modifiche
• Tabelle temporali