Diagnostica dei problemi

Quando uno stream rileva un errore di runtime in Datastream, puoi visualizzare i dettagli nella pagina Stream o Dettagli stream nella console Google Cloud . Puoi anche recuperare le informazioni di diagnostica utilizzando l'API Datastream. Alcuni problemi, come una password non valida, sono recuperabili e la replica riprende automaticamente dopo averli risolti. Altri errori interessano un singolo oggetto, ad esempio un tipo di dati non supportato, o interrompono lo stream quando Datastream non riesce a connettersi all'origine.

Per risolvere un problema, controlla il messaggio di errore e segui i passaggi per gli errori di configurazione, connettività, origine o destinazione BigQuery.

Errori di configurazione e connettività

Errore	Passaggi per la risoluzione dei problemi
Errore di connessione al database di origine (generico).	Ciò può accadere per vari motivi. Per risolvere questo errore: Assicurati che il database di origine sia attivo e raggiungibile. Vai al profilo di connessione di origine dalle pagine Stream o Profili di connessione. Verifica che le informazioni di connettività del profilo di connessione siano corrette. Verifica che il nome utente e la password corrispondano. Verifica che il nome utente esista nel database e disponga dei privilegi richiesti. Salva le modifiche apportate nella pagina Profili di connessione. Lo stream riprende automaticamente.
Connessione al database di origine non riuscita (inserimento degli IP nella lista consentita).	Questo può accadere se il metodo di connettività scelto è Lista consentita IP, ma uno o più indirizzi IP in uscita di Datastream non vengono aggiunti correttamente nel database di origine. Assicurati che gli indirizzi IP in uscita visualizzati nel profilo di connessione di Datastream siano configurati sul firewall di rete in modo che il server di database di origine possa accettare connessioni da questi indirizzi IP. Una volta risolto il problema, lo stream riprende automaticamente.
Connessione al database di origine non riuscita (tunnel SSH di forwarding).	Questo può accadere se si verifica un problema con il tunnel SSH di forwarding. Controlla lo stato del tunnel. Se il tunnel è stato arrestato, deve essere avviato. Una volta risolto il problema, lo stream riprende automaticamente.
Datastream non può connettersi a un bastion host tramite un tunnel SSH di forwarding.	Verifica che la configurazione del tunnel SSH di forwarding sia configurata correttamente nel profilo di connessione di origine e che la porta sul server del tunnel SSH sia aperta.
Connessione al database di origine non riuscita a causa di certificati non validi.	Questo può accadere se si verifica un problema con i certificati forniti durante la definizione del profilo di connessione di origine. Vai alla pagina Profili di connessione e seleziona il profilo di connessione specificato. Verifica che i certificati siano configurati correttamente. Dopo aver apportato le modifiche, salva il profilo di connessione e il flusso riprenderà automaticamente.
Errore durante l'utilizzo della connettività privata per connettersi al database di origine.	Questo errore riguarda il metodo di connettività privata del peering VPC. Assicurati di aver completato tutti i prerequisiti del peering VPC. Dopo aver creato la configurazione di connettività privata, verifica che la route che contiene l'indirizzo IP interno del database venga visualizzata nella scheda Route esportate della pagina Peering di rete VPC. Per farlo, vai alla pagina Peering di rete VPC, quindi cerca il peering aggiunto (il nome è peering-[UUID]). La route si trova nella scheda Route esportate. Se questa route non esiste, aggiungila manualmente. Datastream non verifica la presenza di sovrapposizioni con le route di peering dinamico. La specifica di una subnet che si sovrappone a una route dinamica potrebbe causare problemi di connettività. Pertanto, sconsigliamo di utilizzare una subnet che fa parte di una route dinamica. Assicurati che le route personalizzate per gli intervalli di indirizzi IP di Datastream siano annunciate correttamente. Se le route personalizzate non sono presenti, consulta Route annunciate personalizzate. Se i problemi di connessione al database di origine persistono, consulta Configura un reverse proxy.
Impossibile utilizzare l'interfaccia Private Service Connect per connettersi al database di origine.	Assicurati di aver completato tutti i prerequisiti. Assicurati che le regole firewall consentano alla subnet del collegamento di rete fornito di connettersi al database di origine. Assicurati che le route personalizzate per gli intervalli di indirizzi IP di Datastream siano annunciate correttamente. Se le route personalizzate non sono presenti, consulta Route annunciate personalizzate.
Il tipo di connettività STATIC_SERVICE_IP_CONNECTIVITY non è consentito se il vincolo delle policy dell'organizzazione/datastream.disablePublicConnectivity è attivo.	Hai selezionato i metodi di connettività di rete Lista consentita di IP pubblici o Tunnel SSH di forwarding per il profilo di connessione che stai creando. Tuttavia, la policy dell'organizzazione Blocca i metodi di connettività pubblica per Datastream è abilitata. Pertanto, non puoi selezionare metodi di connettività pubblica per il tuo profilo di connessione. Per risolvere il problema, seleziona il metodo di connettività di rete peering VPC privato o interfacce Private Service Connect oppure disabilita la policy dell'organizzazione. Per disattivare la policy dell'organizzazione: Vai alla pagina Policy dell'organizzazione nella console Google Cloud . Seleziona la policy dell'organizzazione Datastream - Metodi di blocco della connettività pubblica. Fai clic su MODIFICA. Se il pulsante MODIFICA è disattivato, non disponi delle autorizzazioni orgpolicy.policy.get e orgpolicy.policy.set per modificare questa policy dell'organizzazione. Per saperne di più su come ottenere queste autorizzazioni, consulta Riferimento alle autorizzazioni IAM . Nella sezione Applicabile a della pagina, seleziona Personalizza. Nella sezione Applicazione, seleziona Off. Se selezioni l'opzione Off, disattivi l'applicazione del vincolo associato a questa policy dell'organizzazione. Puoi utilizzare metodi di connettività pubblica per il tuo profilo di connessione. Fai clic su SALVA. Torna al profilo di connessione Oracle che stai creando, quindi fai clic su CREA. Potrebbero essere necessari alcuni minuti prima che le modifiche apportate alla policy dell'organizzazione vengano applicate. Inoltre, per saperne di più sulle policy dell'organizzazione, consulta Introduzione al servizio Policy dell'organizzazione.
Durante la configurazione del database di origine per il mio stream, non riesco a trovare le tabelle e gli schemi che voglio trasferire nell'elenco degli oggetti da includere.	Questo può accadere se il database contiene migliaia di tabelle e schemi. Alcuni di questi potrebbero non essere inclusi nell'elenco degli oggetti da estrarre durante la configurazione dell'origine per lo stream nella console Google Cloud . Anziché selezionare Schemi e tabelle specifici nella sezione Seleziona gli oggetti da includere, seleziona Personalizzato. Nel campo Criteri di corrispondenza degli oggetti, inserisci gli schemi e le tabelle che vuoi che Datastream estragga.
Ho aggiunto più tabelle al mio stream utilizzando il menu Oggetti da includere. Tuttavia, quando guardo la scheda Oggetti in Dettagli stream, vedo che mancano alcune tabelle.	Assicurati che sia presente almeno un aggiornamento CDC per ciascuna di queste tabelle, in modo che Datastream possa riconoscere le modifiche e includere automaticamente le tabelle nel flusso.
Errore durante il caricamento dell'elenco di oggetti quando utilizzi il menu Oggetti da includere nella console Google Cloud .	Questo può accadere se il tuo database contiene più di 5000 schemi e tabelle. Utilizza un altro metodo per specificare gli oggetti da includere o utilizza l'API Datastream. Per saperne di più, consulta Configura i database di origine.
Eventi eliminati durante lo streaming e non replicati nella destinazione.	Datastream potrebbe ignorare gli eventi non supportati durante lo streaming. Per risolvere il problema, puoi eseguire le seguenti azioni: Attiva manualmente un backfill dell'intera tabella. Questo funziona se gli eventi ignorati sono solo eventi UPSERT. Se gli eventi eliminati includono eventi DELETE, devi troncare la tabella in BigQuery prima di eseguire il backfill. Per informazioni su come eseguire un backfill, consulta Avvia il backfill. Contatta l'Assistenza Google e chiedi di eseguire un backfill parziale. Questo è possibile solo se puoi identificare gli eventi eliminati con una clausola SQL WHERE e se nessuno degli eventi è un evento DELETE. Ignora il problema se il numero di eventi ignorati è basso o se gli eventi ignorati non sono significativi.
Timeout durante il tentativo di connessione all'origine dati. Assicurati che la configurazione del nome host e della porta sia corretta e che l'origine dati sia accessibile.	Poiché non è possibile eseguire il peering della rete Datastream direttamente con una rete di servizi privati (ad esempio un'istanza Cloud SQL) quando utilizzi il peering VPC, devi utilizzare una VM di Network Address Translation (NAT) per stabilire la connettività tra Datastream e la tua risorsa. Per saperne di più su come configurare una VM NAT, consulta Configura il peering VPC.
Lo schema dell'oggetto OBJECT_NAME è troppo grande per essere elaborato da Datastream.	Datastream non supporta la replica di eventi con schemi di origine corrispondenti di dimensioni superiori a 2.621.440 caratteri Unicode. Questi eventi vengono ignorati con il seguente codice motivo: UNSUPPORTED_LARGE_SCHEMA. Potresti voler escludere alcune colonne o rinominarle. In alternativa, puoi escludere l'oggetto con lo schema di grandi dimensioni.
Lo stato dello stream è cambiato.	Sebbene possano esserci più motivi per cui si verifica questo errore, un problema comune è la configurazione non valida dell'origine. Se lo stream non si avvia con questo messaggio di errore, controlla la configurazione dell'origine per verificare la presenza di chiavi o nomi di tabelle duplicati, incoerenze dei dati o conflitti di schema. Molti dei problemi possono essere risolti modificando le impostazioni dello stream non riuscito direttamente nella console Google Cloud e modificando le voci per gli oggetti inclusi ed esclusi. Per saperne di più, consulta Modifica le informazioni di configurazione del database di origine.

Errori Oracle

Errore	Passaggi per la risoluzione dei problemi
Il logging supplementare non è configurato correttamente nel database di origine.	Se la configurazione del logging supplementare non è corretta nel database di origine, può verificarsi un errore durante il recupero dei dati di Change Data Capture (CDC) in corso. Verifica che il logging supplementare sia configurato correttamente. In particolare, verifica che il logging supplementare sia attivato per le tabelle del database di cui viene eseguito lo streaming dall'origine alla destinazione. Lo stream riprende automaticamente.
Impossibile riprendere la replica perché la posizione del log è andata persa.	Questo errore può verificarsi quando il processo di replica viene messo in pausa per un lungo periodo di tempo, il che causa la perdita della posizione del log. Gli stream non devono essere messi in pausa per periodi di tempo che si avvicinano al periodo di conservazione dei log. Ricrea lo stream.
I file di log sono mancanti, parzialmente o completamente.	I file di log potrebbero essere stati eliminati. Oracle elimina i file di log non appena possibile, a meno che non specifichi un periodo di rotazione minimo per conservarli. Nel server Oracle, imposta per quanto tempo devono essere conservati i file di log. Ad esempio, utilizza CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS; per conservare i file di log per almeno 4 giorni. Per un deployment RDS, utilizza exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',96);
L'elenco di esclusione ha la precedenza sull'elenco di inclusione.	L'elenco di inclusione è completamente contenuto nell'elenco di esclusione, pertanto l'elenco di oggetti che Datastream estrae dall'origine è vuoto. Modifica la selezione degli oggetti e riprova.
La modalità di logging per il database Oracle non è impostata su ARCHIVELOG.	Modifica la modalità di logging e riprova.
Datastream restituisce un messaggio di errore ORA-00942: table or view does not exist, ma tutto è configurato correttamente.	Ciò può essere dovuto alla memorizzazione nella cache sul server Oracle. La ricreazione dell'utente del database dovrebbe risolvere il problema di memorizzazione nella cache.
Le modifiche a un'origine Oracle non vengono applicate alla destinazione quando lo stream è già in esecuzione.	Se utilizzi LogMiner come metodo CDC, Datastream legge dai file di redo log archiviati. In questo caso, le modifiche apportate all'origine non vengono applicate alla destinazione finché il log non viene archiviato. Per visualizzare le modifiche nella destinazione, cambia il metodo CDC in lettore di log binario, modifica la policy di archiviazione dei log o forza manualmente un cambio di log. Per saperne di più, consulta Utilizza i file di redo log del database Oracle.
Convalida della configurazione di Oracle CDC non riuscita.	Hai selezionato un metodo CDC per il quale il database di origine non è stato configurato. Seleziona un altro metodo o completa la configurazione del metodo CDC. Per maggiori dettagli, consulta Configura un database Oracle di origine.
Si è verificato un errore interno imprevisto.	Per maggiori dettagli, contatta l'Assistenza Google.

Errori MySQL

Errore	Passaggi per la risoluzione dei problemi
Binlog non è configurato correttamente nel database di origine.	Questo può accadere per i flussi MySQL continui se la configurazione del binlog non è corretta nel database di origine. Per risolvere questo errore, esegui queste azioni: Verifica che il binlog sia configurato correttamente. Verifica che il formato del log binario del database MySQL sia impostato su ROW. Riavvia lo stream.
Impossibile riprendere la replica perché la posizione del binlog è andata persa.	Questo errore può verificarsi quando il processo di replica viene messo in pausa per un lungo periodo di tempo, il che causa la perdita della posizione del binlog. Gli stream non devono essere messi in pausa per periodi di tempo che si avvicinano al periodo di conservazione del binlog. Ricrea lo stream.
Esecuzione dello stream non riuscita a causa di versioni del database di origine e di destinazione incompatibili.	Questo può accadere quando il database di origine non rispetta la matrice di supporto delle versioni. Per risolvere questo errore, esegui queste azioni: Assicurati che il database di origine rispetti la matrice. Ricrea il flusso con il database di origine aggiornato.
I binlog di origine MySQL AWS RDS sono mancanti, parzialmente o completamente.	I binlog potrebbero essere stati eliminati. AWS RDS elimina i binlog non appena possibile, a meno che non specifichi un periodo di rotazione minimo per conservarli. Nell'istanza MySQL AWS RDS di origine, imposta per quanto tempo, in ore, devono essere conservati i binlog. Ad esempio, utilizza mysql.rds_set_configuration('binlog retention hours', 168); per conservare i binlog per almeno 7 giorni.
L'elenco di esclusione comprende l'elenco di inclusione.	L'elenco di inclusione è completamente contenuto nell'elenco di esclusione, pertanto l'elenco di oggetti che Datastream estrae dall'origine è vuoto. Modifica la selezione degli oggetti e riprova.
Datastream non può replicare un database MySQL.	Assicurati che Datastream disponga delle autorizzazioni per replicare il database.
Quando crei un profilo di connessione per un'origine MySQL, non sono accettati più certificati SSL con codifica PEM nel menu Tipo di crittografia.	Datastream non supporta le catene di certificati SSL nei profili di connessione MySQL. Sono supportati solo singoli certificati x509 con codifica PEM.
Latenza elevata durante lo streaming da un'origine MySQL.	Aumenta la capacità di Datastream di leggere dal database di origine: Riduci le dimensioni massime del file di log binario (binlog) per il database di origine. La riduzione delle dimensioni aumenta il numero di file binlog. Se sono presenti più file binlog, imposta di conseguenza il numero di attività CDC simultanee massime per lo stream. La presenza di più file binlog consente a Datastream di leggere contemporaneamente gli eventi del database di origine, fino al numero impostato nel campo maxConcurrentCdcTasks.
Convalida della configurazione CDC di MySQL non riuscita.	Il database di origine non è stato configurato per il metodo CDC selezionato. Seleziona un altro metodo o completa la configurazione del metodo CDC. Per maggiori dettagli, consulta Configura un database MySQL di origine.
Si è verificato un errore interno imprevisto.	Per maggiori dettagli, contatta l'Assistenza Google.

Errori PostgreSQL

Errore	Passaggi per la risoluzione dei problemi
La decodifica logica non è configurata correttamente nel database di origine.	Verifica che la decodifica logica sia configurata correttamente. Consulta Configura un database PostgreSQL di origine.
Lo slot di replica non esiste.	Se lo slot di replica non esiste nel database, può verificarsi un errore durante il recupero dei dati Change Data Capture (CDC) in corso. Verifica che lo slot di replica sia configurato correttamente. Consulta Configura un database PostgreSQL di origine.
Lo slot di replica è configurato con un plug-in errato.	Questo errore può verificarsi se lo slot di replica è configurato con un plug-in diverso da pgoutput. Verifica che lo slot di replica sia configurato correttamente. Per saperne di più, consulta Database PostgreSQL di origine.
Lo slot di replica è attivo in un processo diverso.	Questo errore può verificarsi quando lo slot di replica viene utilizzato da un altro processo. Gli slot di replica possono essere utilizzati da un solo processo alla volta. Assicurati di non utilizzare lo stesso slot di replica in nessun altro processo, ad eccezione di Datastream.
La pubblicazione non è configurata correttamente.	Questo errore può verificarsi quando la pubblicazione non è configurata per esporre le tabelle incluse nella configurazione dello stream. Verifica che la pubblicazione sia configurata correttamente. Consulta Configura le informazioni sul database di origine per lo stream.
La pubblicazione non esiste.	Questo errore può verificarsi se la pubblicazione non esiste nel database. Verifica che la pubblicazione sia configurata correttamente. Consulta Configura un database PostgreSQL di origine.
Impossibile riprendere la replica perché i file WAL sono andati persi.	Questo errore può verificarsi quando il processo di replica viene messo in pausa per un lungo periodo di tempo, il che causa la perdita dei file WAL. Gli stream non devono essere messi in pausa per periodi di tempo che si avvicinano al periodo di conservazione dei file WAL. Ricrea lo stream.
L'elenco di esclusione ha la precedenza sull'elenco di inclusione.	L'elenco di inclusione è completamente contenuto nell'elenco di esclusione, pertanto l'elenco di oggetti che Datastream estrae dall'origine è vuoto. Modifica la selezione degli oggetti e riprova.
Datastream non può replicare uno schema PostgreSQL.	Assicurati che Datastream disponga delle autorizzazioni per replicare lo schema.
Le transazioni di grandi dimensioni nel database di origine causano problemi con la replica e la sincronizzazione dei dati.	Se inserisci, aggiorni o elimini un numero significativo di record nel database di origine, lo slot di replica potrebbe essere sovraccaricato dagli eventi corrispondenti. Datastream ha bisogno di tempo per leggere ed elaborare questi eventi. Poiché gli slot di replica PostgreSQL sono single-thread, l'elaborazione di altre modifiche nello slot di replica, incluse le modifiche ai dati in altre tabelle, viene ritardata finché Datastream non recupera tutte le modifiche nello slot di replica.
Transazioni di grandi dimensioni nel database di origine causano una bassa velocità effettiva di CDC.	Datastream non supporta il CDC multi-thread in PostgreSQL. Per superare questa limitazione e aumentare la velocità effettiva di CDC, puoi suddividere l'origine in più stream, ciascuno con la propria pubblicazione e il proprio slot di replica. Ad esempio, potresti voler creare uno stream per la tabella più grande del tuo database e un altro per tutte le altre tabelle oppure uno stream per le tabelle con priorità più alta e un altro per le restanti. I casi d'uso potrebbero variare, quindi devi considerare ciò che ha più senso nel tuo scenario CDC specifico. Per informazioni sulla creazione di una pubblicazione, consulta Configura un database PostgreSQL di origine.
Eventi non supportati eliminati con codice motivo: BIGQUERY_TOO_MANY_PRIMARY_KEYS.	Quando l'identità della replica PostgreSQL per una tabella è impostata su FULL, Datastream tratta tutte le colonne di questa tabella come chiavi primarie. Se nella tabella sono presenti più di 16 colonne, viene violata la limitazione di BigQuery CDC e viene generato l'errore. Per risolvere il problema, completa i seguenti passaggi: Cambia l'identità della replica in DEFAULT: ALTER TABLE TABLE_NAME REPLICA IDENTITY DEFAULT Sostituisci TABLE_NAME con il nome della tabella per cui vuoi modificare l'identità della replica. Rimuovi la tabella dall'elenco di oggetti da includere nel flusso. Per saperne di più, consulta Modifica le informazioni di configurazione del database di origine. Elimina la tabella da BigQuery. Per saperne di più, consulta Elimina tabelle. In Datastream, aggiungi nuovamente la tabella allo stream modificando la configurazione dell'origine.
Si è verificato un errore interno imprevisto.	Per maggiori dettagli, contatta l'Assistenza Google.

Errori di SQL Server

Errore	Passaggi per la risoluzione dei problemi
La tecnologia CDC è disabilitata per il database DATABASE_NAME.	La tecnologia Change Data Capture (CDC) deve essere abilitata per il database. Datastream richiede l'accesso in lettura diretto ai log delle transazioni per replicare le modifiche in tempo reale nel database di origine e per ottenere informazioni complete sui log. Abilita CDC per il database e riprova. Per informazioni sull'abilitazione di CDC per un database, consulta Configura un database SQL Server di origine.
Tabelle con CDC disabilitata.	Change Data Capture (CDC) deve essere abilitato per tutte le tabelle incluse nello stream. Datastream deve avere accesso in lettura diretto ai log delle transazioni per replicare le modifiche in tempo reale alle tabelle di origine e per ottenere informazioni complete sui log. Abilita CDC per le tabelle incluse nello stream e riprova. Per informazioni sull'attivazione di CDC per le tabelle di origine, consulta Configura un database SQL Server di origine.
Autorizzazioni mancanti.	Datastream non dispone delle autorizzazioni necessarie per leggere dall'origine. Concedi i privilegi appropriati all'account utente utilizzato per la connessione al tuo database e riprova.
La versione SQL Server EDITION_NAME non è supportata.	Datastream non supporta questa versione di SQL Server. Per saperne di più sulle versioni supportate di SQL Server, consulta Panoramica di SQL Server come origine.
La versione SQL Server VERSION_NAME dell'edizione Standard non è supportata.	Datastream non supporta questa versione di SQL Server Standard Edition. Per saperne di più sulle versioni supportate di SQL Server, consulta Panoramica di SQL Server come origine.
Il flusso non è in grado di leggere l'evento nell'LSN "YOUR_LSN" perché il log delle transazioni sembra essere troncato.	Questo problema può verificarsi quando i log delle transazioni non esistono più nel database di origine. Quando replichi i dati da un'origine SQL Server utilizzando il metodo CDC dei log delle transazioni, i log potrebbero essere troncati prima che Datastream li legga. In questo caso, Datastream non può replicare in modo affidabile il database di origine nella destinazione. Per risolvere il problema, recupera lo stream o valuta la possibilità di utilizzare il metodo CDC delle tabelle delle modifiche. Per saperne di più sulle differenze tra i due metodi, consulta Panoramica di SQL Server come origine.
Configurazione CDC di SQL Server: non riuscita.	Il metodo CDC selezionato non è conforme alla configurazione del database. Modifica il metodo CDC e riprova.

Errori di Salesforce

Errore	Passaggi per la risoluzione dei problemi
Autorizzazioni insufficienti.	L'utente dell'app connessa o dell'app client esterna che hai configurato per autenticare la connessione tra la tua organizzazione Salesforce e Datastream non dispone di autorizzazioni sufficienti per accedere ai dati che vuoi replicare. Assicurati di aver configurato correttamente l'origine Salesforce. Per saperne di più, consulta Configura un'origine Salesforce.
API Bulk 2.0 disabilitata.	L'API Bulk 2.0 è abilitata per impostazione predefinita per le versioni Performance, Unlimited, Enterprise e Developer. Questo messaggio di errore indica che l'API è disattivata nella tua versione o che le credenziali che utilizzi non dispongono di autorizzazioni sufficienti. Assicurati che al profilo utente che utilizzi sia stata concessa l'autorizzazione API Enabled.
Limite superato.	Hai superato il limite di query dell'API Salesforce. Questo messaggio viene visualizzato quando raggiungi il 90% della quota limite dell'API. In questo caso, Datastream riprova a eseguire l'operazione in un secondo momento. Ti consigliamo di aumentare la quota dell'API Salesforce.
Limite di eliminazioni superato.	Quando esegui query per i record eliminati, Salesforce limita la risposta a 600.000 identificatori di record. La granularità di query più bassa in Salesforce è di un minuto e, se elimini più di 600.000 record in un minuto, Salesforce restituisce questo errore.
Errore di autenticazione.	Datastream non può eseguire l'autenticazione con Salesforce. Probabilmente hai utilizzato credenziali o un nome di dominio errati.

Errori di MongoDB

Errore	Passaggi per la risoluzione dei problemi
Autenticazione non riuscita.	Controlla se il valore di authSource per l'utente Datastream è admin. L'utente Datastream deve essere creato nel database admin. Questo database è un database con privilegi che consente agli utenti di eseguire determinati comandi amministrativi.
Accesso al database non riuscito.	Controlla il nome utente e la password e riprova. Inoltre, assicurati che il tuo account utente sia stato creato nel database admin. Se il problema persiste, è possibile che il tuo account utente sia stato eliminato o creato in modo errato.
L'elenco di oggetti esclusi non è valido: {exclude_list}.	Specifica gli oggetti esclusi nel seguente formato: DATABASE_NAME.COLLECTION_NAME.FIELD_NAME.NESTED_FIELD_NAME con caratteri jolly facoltativi. Esempi validi: db.*, database.collection.*, database.*.field.*.
Non abbiamo le autorizzazioni necessarie per leggere dall'origine.	Assegna il ruolo readAnyDatabase al tuo utente e riprova.
La versione VERSION_NAME di MongoDB non è supportata.	Utilizza la versione 5.0 o successiva.
Datastream non è riuscito a eseguire il comando buildinfo per determinare la versione di MongoDB.	Assicurati che l'utente disponga delle autorizzazioni necessarie per eseguire il comando buildinfo e riprova. Per ulteriori informazioni sulle autorizzazioni richieste, consulta Configura un database MongoDB.
La connessione al cluster MongoDB è scaduta.	Assicurati di aver fornito il nome host e le credenziali corretti, quindi riprova.
Impossibile leggere i dati necessari a causa di autorizzazioni insufficienti.	Assegna il ruolo readAnyDatabase all'account utilizzato per connetterti al tuo cluster MongoDB, quindi riprova.
L'account utente utilizzato per connettersi al cluster MongoDB non esiste.	Crea l'account utente e riprova.
Impossibile connettersi utilizzando le informazioni fornite.	Verifica che venga utilizzato il formato di connessione corretto (SRV o Standard) e che siano incluse tutte le informazioni necessarie, ad esempio i nomi dei set di repliche per la stringa di connessione del set di repliche. Per saperne di più, consulta Crea un profilo di connessione per un database MongoDB.
Si è verificata un'eccezione MongoDB. Messaggio di errore di origine: {source_error}.	Se il messaggio di errore di origine non è chiaro, contatta l'Assistenza Google.

Errori di Spanner

Errore	Passaggi per la risoluzione dei problemi
Errore di lettura di Spanner.	Se il tuo database Spanner si trova in un progetto diverso da quello in cui è in esecuzione Datastream, assicurati di aver fornito le autorizzazioni necessarie. Inoltre, assicurati che il database Spanner disponga di risorse CPU sufficienti e non limiti le richieste.
Modifiche in tempo reale al di fuori della conservazione.	Non puoi recuperare uno stream che ha riscontrato questo errore. L'errore indica che Datastream è rimasto indietro rispetto alla finestra di conservazione delle modifiche in tempo reale di Spanner e ha perso dati. Se la finestra di conservazione era breve, ad esempio se è durata secondi o minuti, puoi provare ad aumentarla e creare un nuovo stream.

Errori BigQuery

Errore	Passaggi per la risoluzione dei problemi
BIGQUERY_UNSUPPORTED_PRIMARY_KEY_CHANGE, details: Failed to write to BigQuery due to an unsupported primary key change: adding primary keys to existing tables is not supported.	Se la chiave primaria cambia nell'origine, devi eliminare la tabella in BigQuery e avviare nuovamente il backfill. Si tratta di una limitazione di BigQuery, perché non esiste un modo per garantire l'unione corretta dei nuovi eventi con le righe esistenti se la chiave primaria è diversa. Per saperne di più, consulta Configura una destinazione BigQuery.
La tabella BigQuery di destinazione contiene un numero di record significativamente maggiore rispetto alla tabella di origine.	Questo può accadere quando la tabella di origine non ha una chiave primaria. In questo caso, Datastream elabora la tabella in modalità di scrittura di sola aggiunta e ogni evento per una determinata riga viene visualizzato come riga separata in BigQuery.
I dati vengono duplicati quando si esegue il backfill in modalità di scrittura Solo aggiunta.	Quando selezioni la modalità di scrittura Solo aggiunta per il tuo stream, i dati vengono aggiunti in BigQuery come stream di eventi INSERT, UPDATE-INSERT, UPDATE-DELETE e DELETE, senza alcun consolidamento. Ciò potrebbe causare la scrittura di righe duplicate in BigQuery quando esegui il backfill o quando si verifica un problema e il writer di BigQuery riprova le operazioni di scrittura. Per risolvere il problema, ti consigliamo di eseguire regolarmente una query di deduplicazione simile alla seguente: SELECT * FROM (SELECT *, row_number() OVER (PARTITION BY datastream_metadata.uuid) AS num FROM TABLE_NAME) WHERE num=1
Datastream è configurato per la modalità di scrittura di unione, ma le modifiche non vengono unite in BigQuery.	Verifica che nella tabella di origine sia presente una chiave primaria. BigQuery ne ha bisogno per unire le modifiche nella tabella di destinazione. Un vincolo UNIQUE non soddisfa il requisito PRIMARY KEY per l'unione degli eventi. Se non esiste una chiave primaria, valuta la possibilità di aggiungerne una nella tabella di origine o di destinazione. Per aggiungere una chiave primaria nella tabella BigQuery di destinazione, segui questi passaggi: Mettere in pausa lo stream. Tronca la tabella in BigQuery. Aggiungi la chiave primaria alla definizione della tabella. Riprendi lo stream. Attiva il backfill per la tabella.
Impossibile aggiungere una chiave primaria, rimuovere una chiave primaria o modificare la definizione della chiave primaria per una tabella già replicata in BigQuery.	Per impostazione predefinita, Datastream non supporta l'aggiunta di una chiave primaria a una tabella già replicata in BigQuery senza una chiave primaria o la rimozione di una chiave primaria da una tabella replicata in BigQuery con una chiave primaria. Tuttavia, puoi modificare la definizione della chiave primaria di una tabella di origine replicata in BigQuery che ha già una chiave primaria: Controlla la metrica della latenza totale per lo stream e attendi almeno il tempo della latenza corrente per assicurarti che tutti gli eventi in corso vengano scritti nella destinazione. In questo modo, tutti gli eventi con la chiave primaria originale possono essere trasmessi in streaming correttamente. Metti in pausa lo stream. Copia il comando DDL (Data Definition Language) CREATE TABLE per la tabella in BigQuery: SELECT ddl FROM PROJECT_ID.DATASET.INFORMATION_SCHEMA.TABLES WHERE table_name='TABLE_NAME'; Sostituisci quanto segue: PROJECT_ID: l'identificatore del tuo progetto Google Cloud . DATASET_ID: l'identificatore del set di dati in BigQuery. TABLE_NAME: il nome della tabella per cui vuoi copiare il comando DDL. Elimina la tabella in BigQuery. Modifica il comando DDL CREATE TABLE con le nuove chiavi primarie. Includi le chiavi di partizione e cluster e max_staleness OPTION: CREATE TABLE `[PROJECT_ID].[DATASET_ID].[TABLE_NAME]` ( product_id INT64 NOT NULL, product_name STRING, datastream_metadata STRUCT, PRIMARY KEY (product_id) NOT ENFORCED ) CLUSTER BY dept_no OPTIONS( max_staleness=INTERVAL '0-0 0 0:MINS:0' YEAR TO SECOND ); ; Sostituisci quanto segue: PROJECT_ID: l'identificatore del tuo progetto Google Cloud . DATASET_ID: l'identificatore del set di dati in BigQuery. TABLE_NAME: il nome della tabella per cui hai copiato il comando DDL. MINS: il numero di minuti che vuoi impostare per l'opzione max_staleness, ad esempio 15. Esegui la query modificata per ricreare la tabella in BigQuery. Riprendi lo stream. Avvia il backfill per la tabella.

Passaggi successivi

• Per scoprire come individuare potenziali problemi con lo stream, consulta Risolvi i problemi di uno stream.
• Per scoprire come configurare il database di origine, consulta Origini.
• Per scoprire come configurare la destinazione BigQuery o Cloud Storage, consulta Destinazioni.