Risolvi i problemi relativi alle query

Questo documento ha lo scopo di aiutarti a risolvere i problemi comuni relativi all'esecuzione delle query, ad esempio identificare i motivi delle query lente o fornire i passaggi per la risoluzione degli errori comuni restituiti dalle query non riuscite.

Risolvi i problemi di lentezza delle query

Per risolvere i problemi relativi alle prestazioni lente delle query, segui questi passaggi:

• Controlla la pagina Cloud de Confiance by S3NS Service Health per verificare se sono presenti interruzioni del servizio BigQuery note che potrebbero influire sulle prestazioni delle query.

• Esamina la cronologia dei job per la tua query in Esplora job per vedere quanto tempo ha richiesto l'esecuzione di ogni fase della query.

  • Se la maggior parte del tempo trascorso è dovuta a tempi di creazione lunghi, contatta l'assistenza clienti Google Cloud per ricevere aiuto.

  • Se la maggior parte del tempo trascorso è dovuta a tempi di esecuzione lunghi, consulta gli insight sulle prestazioni delle query. Gli insight sulle prestazioni delle query possono informarti se la query è stata eseguita per un tempo superiore al tempo di esecuzione medio e suggerire possibili cause. Le possibili cause potrebbero includere la contesa degli slot di query o una quota di shuffling insufficiente. Per ulteriori informazioni su ogni problema di prestazioni delle query e sulle possibili soluzioni, consulta Interpreta gli insight sulle prestazioni delle query.

• Esamina il campo finalExecutionDurationMs nel tipo di oggetto JobStatistics per il job di query. La query potrebbe essere stata ripetuta. Il campo finalExecutionDurationMs contiene la durata in millisecondi dell'esecuzione del tentativo finale di questo job.

• Esamina i byte elaborati nella pagina dei dettagli del job di query per verificare se sono superiori al previsto. Puoi farlo confrontando il numero di byte elaborati dalla query corrente con un altro job di query completato in un periodo di tempo accettabile. Se esiste una grande discrepanza di byte elaborati tra le due query, è possibile che la query sia stata lenta a causa di un volume di dati elevato. Per informazioni sull'ottimizzazione delle query per la gestione di grandi volumi di dati, consulta Ottimizza il calcolo delle query.

  Puoi anche identificare le query nel tuo progetto che elaborano una grande quantità di dati cercando le query più costose utilizzando la vista INFORMATION_SCHEMA.JOBS.

• Esamina l'utilizzo delle prenotazioni e verifica la presenza di conflitti di slot. Per saperne di più, consulta Analisi delle statistiche del workload.

• Controlla le esecuzioni precedenti e recenti per lo stesso hash della query per vedere se sono disponibili nuovi insight sulle prestazioni delle query per i job più lenti, ad esempio una modifica della scala di input dei dati. Puoi filtrare in base all'hash della query in Esplora job amministrativi.

Confronta un'esecuzione lenta e una veloce della stessa query

Se una query che in precedenza veniva eseguita rapidamente ora viene eseguita lentamente, esamina l'output dell'oggetto API Job per identificare le modifiche alla sua esecuzione.

Successi della cache

Verifica se l'esecuzione rapida del job è stata un successo della cache esaminando il valore cacheHit. Se il valore è true per l'esecuzione rapida della query, la query ha utilizzato i risultati memorizzati nella cache anziché eseguire la query.

Se prevedi che il job lento utilizzi i risultati memorizzati nella cache, indaga sul motivo per cui la query non utilizza più i risultati memorizzati nella cache. Se non prevedi che la query recuperi i dati dalla cache, cerca un esempio di esecuzione rapida della query che non abbia utilizzato la cache per l'indagine.

Ritardi delle quote

Per determinare se il rallentamento è stato causato da rinvii della quota, controlla il campo quotaDeferments per entrambi i job. Confronta i valori per determinare se l'ora di inizio della query più lenta è stata ritardata da eventuali rinvii della quota che non hanno interessato il job più veloce.

Durata esecuzione

Per comprendere la differenza tra la durata dell'esecuzione dell'ultimo tentativo di entrambi i job, confronta i relativi valori per il campo finalExecutionDurationMs.

Se i valori di finalExecutionDurationMs sono abbastanza simili, ma la differenza nel tempo di esecuzione reale tra le due query, calcolata come startTime - endTime, è molto maggiore, significa che potrebbe essersi verificato un nuovo tentativo di esecuzione della query interna per il job lento a causa di un possibile problema temporaneo. Se visualizzi questo pattern di differenza ripetutamente, contatta l'assistenza clienti Google Cloud per ricevere assistenza.

Byte elaborati

Esamina i byte elaborati nella pagina dei dettagli del job di query o controlla il valore totalBytesProcessed di JobStatistics per vedere se è superiore al previsto. Se esiste una grande discrepanza di byte elaborati tra le due query, la query potrebbe essere lenta a causa di una variazione del volume di dati elaborati. Per informazioni sull'ottimizzazione delle query per la gestione di grandi volumi di dati, consulta Ottimizza il calcolo delle query. I seguenti motivi possono causare un aumento del numero di byte elaborati da una query:

• Le dimensioni delle tabelle a cui fa riferimento la query sono aumentate.
• La query ora legge una partizione più grande della tabella.
• La query fa riferimento a una vista la cui definizione è stata modificata.

Tabelle di riferimento

Controlla se le query leggono le stesse tabelle analizzando l'output del campo referencedTables in JobStatistics2. Le differenze nelle tabelle di riferimento possono essere spiegate come segue:

• La query SQL è stata modificata per leggere tabelle diverse. Confronta il testo della query per confermarlo.
• La definizione della vista è cambiata tra le esecuzioni della query. Controlla le definizioni delle viste a cui viene fatto riferimento in questa query e aggiornale, se necessario.

Le differenze nelle tabelle di riferimento potrebbero spiegare le variazioni di totalBytesProcessed.

Utilizzo delle viste materializzate

Se la query fa riferimento a viste materializzate, le differenze di prestazioni possono essere causate dalla scelta o dal rifiuto delle viste materializzate durante l'esecuzione della query. Esamina MaterializedViewStatistics per capire se le viste materializzate utilizzate nella query rapida sono state rifiutate nella query lenta. Controlla i campi chosen e rejectedReason nell'oggetto MaterializedView.

Statistiche di memorizzazione nella cache dei metadati

Per le query che coinvolgono tabelle BigLake Amazon S3 o tabelle BigLake Cloud Storage con la memorizzazione nella cache dei metadati abilitata, confronta l'output di MetadataCacheStatistics per verificare se esiste una differenza nell'utilizzo della cache dei metadati tra la query lenta e quella veloce e i motivi corrispondenti. Ad esempio, la cache dei metadati potrebbe trovarsi al di fuori della finestra maxStaleness della tabella.

Confronto delle statistiche di BigQuery BI Engine

Se la query utilizza BigQuery BI Engine, analizza l'output di BiEngineStatistics per determinare se le stesse modalità di accelerazione sono state applicate sia alla query lenta che a quella veloce. Esamina il campo BiEngineReason per comprendere il motivo generale dell'accelerazione parziale o della mancata accelerazione, ad esempio memoria insufficiente, prenotazione mancante o input troppo grande.

Esamina le differenze negli insight sulle prestazioni delle query

Confronta gli insight sulle prestazioni delle query per ciascuna query esaminando il grafico di esecuzione nella console Cloud de Confiance o l'oggetto StagePerformanceStandaloneInsight per comprendere i seguenti possibili problemi:

• Contesa slot (slotContention)
• Join con cardinalità elevata (highCardinalityJoins)
• Quota di shuffling insufficiente (insufficientShuffleQuota)
• Distorsione dei dati (partitionSkew)

Presta attenzione sia agli insight forniti per il job lento sia alle differenze tra gli insight generati per il job veloce per identificare le modifiche alle fasi che influiscono sulle prestazioni.

Assegnazione prenotazione

Controlla se esistono differenze nella prenotazione assegnata ai due job. Una modifica della prenotazione o un passaggio da on demand a una prenotazione può influire sulle prestazioni. Per saperne di più, consulta Modelli di gestione dei Workload Manager e dimensioni delle prenotazioni.

Un'analisi più approfondita dei metadati di esecuzione dei job richiede l'esame delle singole fasi di esecuzione delle query confrontando gli oggetti ExplainQueryStage per i due job.

Per iniziare, esamina le metriche Wait ms e Shuffle output bytes descritte nella sezione Interpreta le informazioni sulla fase di query.

Avvisi sulle risorse dalla visualizzazione INFORMATION_SCHEMA.JOBS

Esegui una query sul campo query_info.resource_warning della vista INFORMATION_SCHEMA.JOBS per verificare se esiste una differenza negli avvisi analizzati da BigQuery rispetto alle risorse utilizzate.

Analisi delle statistiche del workload

Le risorse slot disponibili e la contesa degli slot possono influire sul tempo di esecuzione delle query. Le sezioni seguenti ti aiutano a comprendere l'utilizzo e la disponibilità degli slot per una determinata esecuzione di una query.

Slot medi al secondo

Per calcolare il numero medio di slot utilizzati per millisecondo dalla query, dividi il valore di slot-millisecondi per il job, totalSlotMs da JobStatistics2, per la durata in millisecondi dell'esecuzione del tentativo finale di questo job, finalExecutionDurationMs da JobStatistics.

Puoi anche calcolare il numero medio di slot per millisecondo utilizzati da un job eseguendo una query sulla vista INFORMATION_SCHEMA.JOBS

Un job che esegue una quantità di lavoro simile con un numero medio di slot al secondo maggiore viene completato più velocemente. Un utilizzo slot medio al secondo inferiore può essere causato da quanto segue:

• Non erano disponibili risorse aggiuntive a causa di una contesa delle risorse tra job diversi: la prenotazione era al massimo.
• Il job non ha richiesto altri slot durante gran parte dell'esecuzione. Ad esempio, questo può accadere quando si verifica una distorsione dei dati.

Modelli di gestione dei workload e dimensioni della prenotazione

Se utilizzi il modello di fatturazione on demand, il numero di slot che puoi utilizzare per progetto è limitato. Inoltre, occasionalmente il tuo progetto potrebbe avere meno slot disponibili se esiste un livello elevato di conflitto per la capacità on demand in una località specifica.

Il modello basato sulla capacità è più prevedibile e ti consente di specificare un numero confermato di slot di riferimento.

Tieni conto di queste differenze quando confronti un'esecuzione di query on demand con un'esecuzione di query che utilizza una prenotazione.

L'utilizzo di una prenotazione è consigliato per ottenere prestazioni di esecuzione delle query stabili e prevedibili. Per saperne di più sulle differenze tra i workload on demand e quelli basati sulla capacità, consulta Introduzione alla gestione dei workload.

Concorrenza job

La contemporaneità dei job rappresenta la concorrenza tra i job per le risorse degli slot durante l'esecuzione delle query. Una maggiore concorrenza dei job in genere causa un'esecuzione più lenta dei job perché il job ha accesso a meno slot.

Puoi eseguire una query sulla vista INFORMATION_SCHEMA.JOBS per trovare il numero medio di job simultanei in esecuzione contemporaneamente a una determinata query all'interno di un progetto.

Se a una prenotazione è assegnato più di un progetto, modifica la query in modo da utilizzare JOBS_BY_ORGANIZATION anziché JOBS_BY_PROJECT per ottenere dati accurati a livello di prenotazione.

Una concorrenza media più elevata durante l'esecuzione del job lento rispetto al job veloce è un fattore che contribuisce alla lentezza complessiva.

Valuta la possibilità di ridurre la concorrenza all'interno del progetto o della prenotazione distribuendo le query ad alta intensità di risorse nel tempo all'interno di una prenotazione o di un progetto o tra prenotazioni o progetti diversi.

Un'altra soluzione è acquistare una prenotazione o aumentare le dimensioni di una prenotazione esistente. Valuta la possibilità di consentire alla prenotazione di utilizzare gli slot inattivi.

Per capire quanti slot aggiungere, leggi Stima dei requisiti di capacità degli slot.

I job in esecuzione in prenotazioni con più di un progetto assegnato possono avere risultati di assegnazione degli slot diversi con la stessa concorrenza media dei job, a seconda del progetto che li esegue. Per saperne di più, leggi informazioni sulla pianificazione equa.

Utilizzo della prenotazione

I grafici delle risorse di amministrazione e Cloud Monitoring di BigQuery possono essere utilizzati per monitorare l'utilizzo delle prenotazioni. Per saperne di più, consulta Monitora le prenotazioni BigQuery.

Per capire se un job ha richiesto slot aggiuntivi, osserva la metrica delle unità eseguibili stimate, ovvero estimatedRunnableUnits dalla risposta dell'API Job o period_estimated_runnable_units nella vista INFORMATION_SCHEMA.JOBS_TIMELINE. Se il valore di questa metrica è maggiore di 0, il job avrebbe potuto trarre vantaggio da slot aggiuntivi in quel momento. Per stimare la percentuale del tempo di esecuzione del job in cui il job avrebbe beneficiato di slot aggiuntivi, esegui la seguente query sulla vista INFORMATION_SCHEMA.JOBS_TIMELINE:

SELECT
  ROUND(COUNTIF(period_estimated_runnable_units > 0) / COUNT(*) * 100, 1) AS execution_duration_percentage
FROM `myproject`.`region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
WHERE job_id = 'my_job_id'
GROUP BY job_id;

+---------------------------------+
|   execution_duration_percentage |
+---------------------------------+
|                            96.7 |
+---------------------------------+

Una percentuale bassa indica che la disponibilità delle risorse degli slot non è un fattore principale della lentezza delle query in questo scenario.

Se la percentuale è elevata e la prenotazione non è stata utilizzata completamente durante questo periodo, contatta l'assistenza clienti Google Cloud per indagare.

Se la prenotazione è stata utilizzata completamente durante l'esecuzione lenta del job e la percentuale è elevata, il job era limitato dalle risorse. Valuta la possibilità di ridurre la contemporaneità, aumentare le dimensioni della prenotazione, consentire alla prenotazione di utilizzare gli slot inattivi o acquistare una prenotazione se il job è stato eseguito on demand.

Risultati dell'analisi dei metadati del job e del workload non conclusivi

Se non riesci ancora a trovare il motivo per spiegare le prestazioni delle query più lente del previsto, contatta l'assistenza clienti Google Cloud per ricevere aiuto.

Risolvi i problemi delle query utilizzando Gemini Cloud Assist

Per utilizzare Gemini Cloud Assist per aiutarti a risolvere i problemi relativi a un errore di query o a un problema di prestazioni, segui questi passaggi:

1. Nella console Cloud de Confiance , vai alla pagina BigQuery.

   Vai a BigQuery

2. Nella barra degli strumenti Cloud de Confiance , fai clic suspark Apri o chiudi la chat di Gemini Cloud Assist.

3. Nel riquadro Cloud Assist, inserisci un prompt che includa l'ID job per esaminarne l'esecuzione, le metriche sul rendimento o i motivi dell'errore. Ad esempio:

   • Perché JOB_ID non è andato a buon fine?
   • Perché questo job richiede così tanto tempo? JOB_ID
   • Riassumi il mio rendimento lavorativo delle ultime 24 ore.

Risolvi i problemi relativi alle query non riuscite utilizzando gcpdiag

gcpdiag è uno strumento open source. Non è un prodotto Cloud de Confiance by S3NS ufficialmente supportato. Puoi utilizzare lo strumento gcpdiag per identificare e risolvere Cloud de Confiance by S3NS i problemi del progetto. Per saperne di più, consulta il progetto gcpdiag su GitHub.

Risoluzione dello schema Avro

Stringa di errore: Cannot skip stream

Questo errore può verificarsi durante il caricamento di più file Avro con schemi diversi, causando un problema di risoluzione dello schema e l'errore del job di importazione in un file casuale.

Per risolvere questo errore, assicurati che l'ultimo file in ordine alfabetico nel job di caricamento contenga il superset (unione) degli schemi diversi. Questo è un requisito basato su come Avro gestisce la risoluzione dello schema.

Query simultanee in conflitto

Stringa di errore: Concurrent jobs in the same session are not allowed

Questo errore può verificarsi quando più query vengono eseguite contemporaneamente in una sessione, il che non è supportato. Consulta le limitazioni delle sessioni.

Istruzioni DML in conflitto

Stringa di errore: Could not serialize access to table due to concurrent update

Questo errore si verifica quando istruzioni di data manipulation language (DML) di mutazione simultanee (UPDATE, DELETE o MERGE) tentano di modificare i dati nella stessa partizione della tabella contemporaneamente o quando la tabella viene troncata mentre è in esecuzione un'istruzione DML.

BigQuery consente l'esecuzione di istruzioni DML di mutazione simultanee sulla stessa tabella, a condizione che modifichino partizioni diverse. Tuttavia, se due job tentano di modificare la stessa partizione, il primo job di cui viene eseguito il commit ha esito positivo e i job successivi non vanno a buon fine con questo errore.

Per risolvere questo errore, prova i seguenti passaggi:

• Riprova il job non riuscito: se il conflitto è stato causato da una sovrapposizione temporanea con un altro job, riprova a eseguire la query dopo il completamento del job in conflitto.
• Identifica e coordina i job in conflitto: esegui la query di diagnostica nella sezione seguente per identificare il job in conflitto, quindi coordina le pianificazioni in modo che le operazioni DML di mutazione sulla stessa partizione non vengano eseguite contemporaneamente.
• Partiziona le tabelle: se i job DML simultanei aggiornano segmenti di dati diversi, partiziona la tabella per data o intervallo di numeri interi. Le istruzioni DML di mutazione simultanee vengono eseguite correttamente senza conflitti se modificano partizioni diverse.
• Operazioni DML batch: combina più operazioni UPDATE o DELETE singole in un'unica istruzione MERGE o un job batch per ridurre l'overhead di concorrenza e commit. Per saperne di più, consulta le best practice.

Identifica il job in conflitto

Per identificare il job che stava aggiornando contemporaneamente la tabella quando si è verificato l'errore, esegui una query sulla vista INFORMATION_SCHEMA.JOBS:

SELECT
  job_id,
  query,
  start_time,
  end_time
FROM
  `region-REGION`.INFORMATION_SCHEMA.JOBS
WHERE
  creation_time BETWEEN
    TIMESTAMP_SUB(TIMESTAMP 'FAILED_JOB_START_TIME', INTERVAL 1 DAY)
    AND TIMESTAMP 'FAILED_JOB_END_TIME'
  AND destination_table.table_id = 'TABLE_NAME'
  AND destination_table.dataset_id = 'DATASET_NAME'
  AND statement_type IN ('UPDATE', 'DELETE', 'MERGE')
  AND start_time <= 'FAILED_JOB_END_TIME'
  AND (end_time >= 'FAILED_JOB_START_TIME' OR end_time IS NULL)
ORDER BY
  start_time;

Sostituisci quanto segue:

• REGION: il nome della regione in cui si trova il set di dati, ad esempio us.
• FAILED_JOB_START_TIME: il timestamp dell'inizio del job non riuscito, ad esempio 2026-09-01 09:55:00 UTC.
• FAILED_JOB_END_TIME: il timestamp di fine del job non riuscito, ad esempio 2026-09-01 10:00:00 UTC.
• TABLE_NAME: il nome della tabella che l'istruzione DML non riuscita ha tentato di aggiornare.
• DATASET_NAME: il nome del set di dati che contiene la tabella.

Se la query non restituisce job in conflitto avviati dall'utente, il conflitto potrebbe essere stato causato da un'altra operazione in background, ad esempio la scadenza della partizione.

Altre cause di conflitti di aggiornamento simultaneo

• Scadenza della partizione: le attività di sistema in background che fanno scadere le partizioni possono entrare in conflitto con un'istruzione DML se modificano la stessa partizione durante l'esecuzione del job. Se utilizzi la scadenza delle partizioni, pianifica i job DML al di fuori degli orari di scadenza delle partizioni.
• Transazioni con più istruzioni: quando una transazione con più istruzioni modifica una tabella, blocca tutte le altre istruzioni DML simultanee su quella tabella fino al completamento della transazione.
• Istruzioni DML che interessano zero righe: un'istruzione UPDATE, DELETE o MERGE acquisisce i blocchi sulle partizioni target e può causare conflitti di serializzazione anche se nessuna riga corrisponde alle condizioni di filtro.

Per saperne di più, consulta Conflitti di istruzioni DML.

Subquery correlate

Stringa di errore: Correlated subqueries that reference other tables are not supported unless they can be de-correlated

Questo errore può verificarsi quando la query contiene una sottoquery che fa riferimento a una colonna esterna alla sottoquery, chiamata colonna di correlazione. La subquery correlata viene valutata utilizzando una strategia di esecuzione nidificata inefficiente, in cui la subquery viene valutata per ogni riga della query esterna che produce le colonne di correlazione. A volte, BigQuery può riscrivere internamente le query con sottoquery correlate in modo che vengano eseguite in modo più efficiente. L'errore delle sottoquery correlate si verifica quando BigQuery non riesce a ottimizzare sufficientemente la query.

Per risolvere questo errore, prova i seguenti passaggi:

• Rimuovi eventuali clausole ORDER BY, LIMIT, EXISTS, NOT EXISTS o IN dalla subquery.
• Utilizza una query con più istruzioni per creare una tabella temporanea a cui fare riferimento nella sottoquery.
• Riscrivi la query per utilizzare un CROSS JOIN.

Autorizzazioni di controllo dell'accesso a livello di colonna insufficienti

Stringhe di errore:

• Access denied: Requires fineGrainedGet permission on the read columns to execute the DML statements
• "Accesso negato: l'utente non dispone dell'autorizzazione per accedere al tag di criteri projects/PROJECT_ID/locations/LOCATION/taxonomies/TAXONOMY_ID/policyTags/POLICY_TAG_ID nella colonna PROJECT_ID.DATASET.TABLE.COLUMN."

Questi errori si verificano quando tenti di eseguire una query SQL o un'istruzione DML DELETE, UPDATE o MERGE senza che ti sia stato concesso il ruolo Fine-Grained Reader sulle colonne che utilizzano il controllo dell'accesso a livello di colonna. Questo ruolo viene assegnato alle entità nell'ambito della configurazione di un tag di criteri. Per saperne di più, consulta Impatto sulle scritture dal controllo dell'accesso a livello di colonna.

Per risolvere il problema, modifica la query in modo da escludere le colonne con tag di policy o concedi all'utente il ruolo Lettore granulare. Questo ruolo viene assegnato alle entità nell'ambito della configurazione di un tag di criteri. Per saperne di più, consulta Aggiorna le autorizzazioni sui tag di policy.

Risolvi i problemi relativi alle query pianificate

Durante la configurazione o l'esecuzione delle query pianificate potrebbero verificarsi i seguenti problemi.

La query pianificata attiva esecuzioni duplicate

Una query pianificata potrebbe essere attivata più di una volta all'ora pianificata. Questo comportamento è più probabile per le query pianificate esattamente all'ora (ad esempio alle 09:00). Ciò può portare a risultati imprevisti, come dati duplicati se la query esegue operazioni INSERT.

Per ridurre al minimo il rischio di esecuzioni duplicate, pianifica le query in un orario non preciso, ad esempio qualche minuto prima o dopo l'ora (ad esempio, 08:58 o 09:03). Per saperne di più, consulta Pianificazione delle query.

Credenziali non valide per le query pianificate

Stringhe di errore:

• Error code: INVALID_USERID
• Error code 5: Authentication failure: User Id not found
• PERMISSION_DENIED: BigQuery: Permission denied while getting Drive credentials

Questo errore può verificarsi quando una query pianificata non va a buon fine a causa di credenziali obsolete, soprattutto quando si eseguono query sui dati di Google Drive.

Per risolvere questo errore:

• Assicurati di aver attivato BigQuery Data Transfer Service, che è un prerequisito per l'utilizzo delle query pianificate.
• Aggiorna le credenziali delle query pianificate.

Credenziali dell'account di servizio non valide

Stringa di errore: HttpError 403 when requesting returned: The caller does not have permission

Questo errore potrebbe essere visualizzato quando tenti di configurare una query pianificata con un account di servizio. Per risolvere questo errore, consulta i passaggi per la risoluzione dei problemi descritti in Problemi di autorizzazione e autorizzazioni.

Data/ora snapshot non valida

Stringa di errore: Invalid snapshot time

Questo errore può verificarsi quando si tenta di eseguire query su dati storici che non rientrano nella finestra di viaggio nel tempo per il set di dati. Per risolvere questo errore, modifica la query in modo da accedere ai dati storici all'interno della finestra di viaggio nel tempo del set di dati.

Questo errore può essere visualizzato anche se una delle tabelle utilizzate nella query viene eliminata e ricreata dopo l'avvio della query. Controlla se esiste una query o un'applicazione pianificata che esegue questa operazione e che è stata eseguita contemporaneamente alla query non riuscita. In questo caso, prova a spostare il processo che esegue l'operazione di eliminazione e ricreazione in modo che venga eseguito in un momento che non entri in conflitto con le query che leggono la tabella.

Il job esiste già

Stringa di errore: Already Exists: Job <job name>

Questo errore può verificarsi per i job di query che devono valutare array di grandi dimensioni, in modo che la creazione di un job di query richieda più tempo della media. Ad esempio, una query con una clausola WHERE come WHERE column IN (<2000+ elements array>).

Per risolvere questo errore:

• Consenti a BigQuery di generare un valore jobId casuale anziché specificarne uno.
• Utilizza una query con parametri per caricare l'array.

Questo errore può verificarsi anche quando imposti manualmente un ID job, ma il job non restituisce un esito positivo entro un periodo di timeout. In questo caso, puoi aggiungere un gestore delle eccezioni per verificare se il job esiste. In questo caso, puoi estrarre i risultati della query dal job.

Job non trovato

Stringa di errore: Job not found

Questo errore può verificarsi in risposta a una chiamata getQueryResults, in cui non è specificato alcun valore per il campo location. In questo caso, riprova la chiamata e fornisci un valore location.

Per saperne di più, consulta Evita più valutazioni delle stesse espressioni di tabella comuni (CTE).

Posizione non trovata

Stringa di errore: Dataset [project_id]:[dataset_id] was not found in location [region]

Questo errore viene restituito quando fai riferimento a una risorsa del set di dati che non esiste o quando la località nella richiesta non corrisponde a quella del set di dati.

Per risolvere il problema, specifica la località del set di dati nella query o verifica che il set di dati sia disponibile nella stessa località.

La query supera il limite di tempo di esecuzione

Stringa di errore: Query fails due to reaching the execution time limit

Se la query raggiunge il limite di tempo di esecuzione della query, controlla il tempo di esecuzione delle esecuzioni precedenti della query eseguendo una query sulla vista INFORMATION_SCHEMA.JOBS con una query simile al seguente esempio:

SELECT TIMESTAMP_DIFF(end_time, start_time, SECOND) AS runtime_in_seconds
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE statement_type = 'QUERY'
AND query = "my query string";

Se le esecuzioni precedenti della query hanno richiesto molto meno tempo, utilizza gli insight sulle prestazioni delle query per determinare e risolvere il problema di fondo.

La query supera il limite massimo di byte fatturati

Stringa di errore: Query exceeded limit for bytes billed: LIMIT_BYTES. REQUIRED_BYTES or higher required.

Questo errore HTTP 400 Bad Request (reason: bytesBilledLimitExceeded) si verifica quando la stima pre-esecuzione dei byte da fatturare per una query (REQUIRED_BYTES) supera il limite di byte configurato in maximumBytesBilled (LIMIT_BYTES). BigQuery non esegue il job prima dell'esecuzione e non addebita alcun costo per la query.

Poiché i prezzi on demand impongono un minimo di 10 MB (10,485,760 byte) per tabella di riferimento e la stima pre-esecuzione per le tabelle in cluster calcola un limite superiore per tutte le partizioni corrispondenti prima che venga eseguita la riduzione del cluster, REQUIRED_BYTES può essere superiore ai byte effettivi analizzati durante l'esecuzione della query.

Per risolvere questo problema, procedi in uno dei seguenti modi:

• Visualizza l'anteprima dei byte stimati con un dry run. Esegui un dry run (bq query --dry_run nell'interfaccia a riga di comando bq o configuration.dryRun = true nell'API) o controlla lo strumento di convalida query nella console Cloud de Confiance per ispezionare totalBytesProcessed prima di eseguire la query.
• Ottimizza la query per analizzare meno byte. Seleziona solo le colonne necessarie per la query anziché eseguire SELECT * e applica un filtro alle colonne partizionate in modo che BigQuery possa eliminare le partizioni durante la stima pre-esecuzione. Il filtro sulle colonne raggruppate riduce i byte effettivi fatturati quando viene eseguita la query, ma non riduce la stima del limite superiore pre-esecuzione rispetto a maximumBytesBilled. Per saperne di più, consulta Riduci il trattamento dei dati.
• Aumenta il limite di maximumBytesBilled. Imposta il limite di byte maximumBytesBilled su un valore pari o superiore al valore REQUIRED_BYTES riportato nel messaggio di errore utilizzando Byte massimi fatturati (in Impostazioni query > Opzioni avanzate) nella console Cloud de Confiance , il flag --maximum_bytes_billed nell'interfaccia a riga di comando bq o la proprietà di configurazione del job configuration.query.maximumBytesBilled nell'API.

La risposta alla query è troppo grande

Stringa di errore: responseTooLarge

Questo errore si verifica quando i risultati della query sono superiori alle dimensioni massime della risposta o quando una singola riga supera il limite di dimensioni della riga dell'API REST.

Alcune query vengono eseguite in più fasi e questo errore si verifica quando una fase restituisce una dimensione della risposta troppo grande, anche se il risultato finale è inferiore al valore massimo. Questo errore si verifica comunemente quando le query utilizzano una clausola ORDER BY. A volte può essere utile rimuovere la clausola ORDER BY o aggiungere una clausola LIMIT. Per assicurarti che possano essere restituiti risultati di grandi dimensioni, specifica una tabella di destinazione nella configurazione del job. Per le query SQL precedente, devi anche impostare la proprietà configuration.query.allowLargeResults su true. Per saperne di più, consulta Scrittura di risultati di query di grandi dimensioni.

Limite di dimensioni della risposta per una singola riga superato

Stringhe di errore:

• Response too large to return. Message before conversion exceeds max row limit, limit: LIMIT actual: ACTUAL
• Response too large to return. single row too big to return due to byte limit, actual: ACTUAL limit: LIMIT

Questo errore HTTP 403 Forbidden (reason: responseTooLarge) si verifica quando leggi i risultati delle query o le righe della tabella utilizzando i metodi dell'API REST jobs.getQueryResults o tabledata.list (inclusa la visualizzazione dei risultati nella console Cloud de Confiance o nello strumento a riga di comando bq) e una singola riga serializzata non nidificata supera la dimensione massima della riga supportata dall'endpoint di paginazione REST (20 MB per jobs.getQueryResults o 100 MB per tabledata.list). Questo accade comunemente nelle tabelle con schemi ampi, campi ARRAY o STRUCT ripetuti nidificati in profondità o valori STRING o BYTES di grandi dimensioni.

Per leggere righe che superano i limiti di dimensione delle righe dell'API REST, esegui una delle seguenti operazioni:

• Utilizza l'API BigQuery Storage Read. Leggi la tabella o la tabella di destinazione della query temporanea utilizzando l'API Storage Read, che trasmette i dati in formato binario Apache Arrow o Avro e supporta letture con throughput elevato di strutture di righe grandi e complesse.
• Esporta la tabella in Cloud Storage. Esporta la tabella o i risultati della query in Cloud Storage utilizzando un'istruzione EXPORT DATA o un job di estrazione (ad esempio in formato Avro, Parquet o JSON) e leggi i file esportati da Cloud Storage.
• Proietta o aggrega meno colonne. Anziché eseguire SELECT *, seleziona solo le colonne o i campi secondari specifici richiesti dalla tua applicazione oppure annulla l'nidificazione degli array ripetuti nella query in modo che le singole righe di output rimangano al di sotto del limite di dimensioni.

Parametro obbligatorio mancante

Stringa di errore: Required parameter is missing: PARAMETER_NAME

Questo errore HTTP 400 Bad Request (reason: required) è un errore di convalida dell'API pre-esecuzione che si verifica quando un campo obbligatorio in un payload o un URL di richiesta API non viene fornito o quando una proprietà obbligatoria in un oggetto di configurazione della libreria client è null o None.

Per risolvere questo errore, segui questi passaggi:

• Consulta il riferimento API REST. Esamina PARAMETER_NAME nel messaggio di errore e controlla il corpo della richiesta e i parametri di query obbligatori per il metodo nel Riferimento API REST BigQuery per assicurarti che il codice compili tutti i campi obbligatori.
• Verifica i parametri della libreria client. Se utilizzi una libreria client di BigQuery (ad esempio la libreria client Java o Python), consulta la documentazione della libreria client per i parametri obbligatori del metodo che stai chiamando.
• Ispeziona l'oggetto di configurazione prima di chiamare l'API. Utilizza un debugger o un'istruzione di log per ispezionare l'oggetto di configurazione del job o della richiesta immediatamente prima dell'esecuzione della chiamata API e verifica la presenza di valori None o null assegnati alle proprietà obbligatorie, ad esempio destinationTable.

Prenotazione non trovata o slot mancanti

Stringa di errore: Cannot run query: project does not have the reservation in the data region or no slots are configured

Questo errore si verifica quando alla prenotazione assegnata al progetto nella regione della query non sono assegnati slot. Puoi aggiungere slot alla prenotazione, consentire alla prenotazione di utilizzare slot inattivi, utilizzare una prenotazione diversa o rimuovere l'assegnazione ed eseguire la query on demand.

Tabella non trovata

Stringa di errore: Not found: Table [project_id]:[dataset].[table_name] was not found in location [region]

Questo errore si verifica quando una tabella della query non viene trovata nel set di dati o nella regione che hai specificato. Per risolvere questo errore:

• Verifica che la query contenga il nome corretto del progetto, del set di dati e della tabella.
• Verifica che la tabella esista nella regione in cui hai eseguito la query.
• Assicurati che la tabella non sia stata eliminata e ricreata durante l'esecuzione del job. In caso contrario, la propagazione incompleta dei metadati può causare questo errore.

Troppe istruzioni DML

Stringa di errore: Too many DML statements outstanding against <table-name>, limit is 20

Questo errore si verifica quando superi il limite di 20 istruzioni DML di mutazione con stato PENDING in una coda per una singola tabella. Questo errore si verifica in genere quando invii job DML su una singola tabella più velocemente di quanto BigQuery possa elaborarli.

Per controllare i job in stato PENDING che riempiono la coda insieme ai job RUNNING che potrebbero impedire la rimozione dalla coda, esegui una query sulla vista INFORMATION_SCHEMA.JOBS:

SELECT
  project_id,
  job_id,
  creation_time,
  user_email,
  statement_type,
  state
FROM
  `region-us`.INFORMATION_SCHEMA.JOBS
WHERE
  statement_type IN ('UPDATE', 'DELETE', 'MERGE')
  AND state IN ('RUNNING', 'PENDING')
ORDER BY
  creation_time DESC;

Una possibile soluzione è raggruppare più operazioni DML di piccole dimensioni in job più grandi, ma in numero inferiore, ad esempio raggruppando aggiornamenti batch e inserimenti. Quando raggruppi job più piccoli in job più grandi, il costo di esecuzione di questi ultimi viene ammortizzato e l'esecuzione è più rapida. Il consolidamento delle istruzioni DML che interessano gli stessi dati generalmente migliora l'efficienza dei job DML e ha meno probabilità di superare il limite di quota per le dimensioni della coda. Per saperne di più sull'ottimizzazione delle operazioni DML, consulta Evita istruzioni DML che aggiornano o inseriscono singole righe.

Altre soluzioni per migliorare l'efficienza del DML potrebbero essere il partizionamento o il clustering delle tabelle. Per saperne di più, consulta le best practice.

Errore 403: quota superata

Stringa di errore: 403 Quota exceeded: Your table exceeded quota for total number of DML jobs writing to a table, pending + running.

Questo errore si verifica quando il numero totale di job DML (INSERT, UPDATE, DELETE e MERGE) che scrivono in una singola tabella, sia in stato PENDING che RUNNING, supera la quota di contemporaneità della tabella.

Mentre l'errore limit is 20 limita specificamente la coda PENDING per le istruzioni DML di mutazione (UPDATE, DELETE e MERGE), questo errore 403 Quota exceeded si applica al totale combinato di tutti i job DML (INSERT più DML di mutazione) che scrivono contemporaneamente in una tabella. Poiché il DML di mutazione è già limitato dal limite di coda di 20 job, questo errore di quota 403 si verifica più comunemente quando invii troppe query INSERT contemporanee su una singola tabella. Per risolvere questo errore, segui questi passaggi:

• Aumenta gli slot di prenotazione: aumenta il numero di slot nella prenotazione per consentire ai job di essere completati più velocemente e ridurre la concorrenza dei job. In questo modo, il numero di job in attesa nella coda si riduce e si evita di raggiungere il limite.
• Ottimizza l'orchestrazione del workflow: limita il numero di attività DML simultanee nel tuo strumento di orchestrazione per evitare di superare i limiti di contemporaneità a livello di tabella (incluse le query INSERT ad alta frequenza che hanno come target la stessa tabella).
• Raggruppa le operazioni DML: combina più istruzioni DML di dimensioni ridotte in un numero inferiore di istruzioni di dimensioni maggiori per ridurre il numero totale di job in coda per la tabella.

Transazione interrotta a causa di un aggiornamento simultaneo

Stringa di errore: Transaction is aborted due to concurrent update against table [table_name]

Questo errore può verificarsi quando due diverse istruzioni DML di mutazione tentano di aggiornare contemporaneamente la stessa tabella. Ad esempio, supponiamo che tu avvii una transazione in una sessione che contiene un'istruzione DML di mutazione seguita da un errore. Se non è presente un gestore delle eccezioni, BigQuery esegue automaticamente il rollback della transazione al termine della sessione, il che richiede fino a 24 ore. Durante questo periodo, altri tentativi di eseguire un'istruzione DML di mutazione sulla tabella non andranno a buon fine.

Per risolvere questo errore, elenca le sessioni attive e controlla se una di queste contiene un job di query con stato ERROR che ha eseguito un'istruzione DML di mutazione sulla tabella. Quindi, termina la sessione.

Errore 412: il job fa riferimento a una tabella che appartiene a un set di dati di failover

Stringa di errore: Error 412: The job references a table that belongs to a failover dataset in the ... region (PROJECT_ID:DATASET_ID). However, only jobs that run on a reservation with the "ENTERPRISE_PLUS" edition can modify or write to failover datasets. Please also make sure that the job that is writing to the failover dataset is running in the current primary location.

Ciò significa che il job non è stato eseguito in una versione BigQuery Enterprise Plus o che è stato eseguito in una regione diversa dalla località principale del set di dati di failover. Per ulteriori dettagli, consulta disaster recovery gestito.

Errore durante il caricamento della visualizzazione quando si utilizzano i risultati memorizzati nella cache

Stringa di errore: BigQuery data export: There was an error loading this view. IAM setPolicy failed for Dataset <PROJECT_ID>. One or more users named in the policy do not belong to a permitted customer.

Questo errore indica che ai tuoi ID cliente Google Workspace non è stato concesso l'accesso nel vincolo della policy dell'organizzazione. Per informazioni sull'utilizzo del vincolo iam.allowedPolicyMemberDomains, consulta Utilizza il vincolo iam.allowedPolicyMemberDomains per implementare la condivisione limitata per i domini.

Errori SQL legacy

Quando utilizzi SQL precedente, possono verificarsi i seguenti errori.

Cannot be queried with legacy SQL

Stringa di errore: cannot be queried with legacy SQL. Please consider switching to standard SQL

Questo errore può verificarsi in uno dei due scenari seguenti:

• La query è stata scritta in SQL standard, ma è stata fornita l'opzione per utilizzare esplicitamente SQL legacy. Assicurati di eseguire la query utilizzando SQL standard seguendo la documentazione pubblica, ad esempio fornendo --use_legacy_sql=false utilizzando lo strumento a riga di comando bq.

• Stai tentando di eseguire una query su una tabella con regole di confronto utilizzando SQL precedente, che non è supportato.

Non è possibile eseguire query sulle tabelle con colonne rinominate con SQL precedente

Stringa di errore: Table project:dataset.table with renamed columns cannot be queried with legacy SQL. Please consider switching to standard SQL or dropping column my_column

Questo errore si verifica se esegui una query su una tabella con una colonna rinominata utilizzando SQL precedente. Utilizza invece SQL standard.

L'utente non dispone dell'autorizzazione

Stringhe di errore:

• Access Denied: Project [project_id]: User does not have bigquery.jobs.create permission in project [project_id].
• User does not have permission to query table project-id:dataset.table.
• Access Denied: User does not have permission to query table or perhaps it does not exist.

Questi errori possono verificarsi quando esegui una query senza l'autorizzazione bigquery.jobs.create sul progetto da cui esegui la query, indipendentemente dalle tue autorizzazioni sul progetto che contiene i dati.

Potresti ricevere questi errori anche se il tuo account di servizio, utente o gruppo non dispone dell'autorizzazione bigquery.tables.getData su tutte le tabelle e le viste a cui fa riferimento la query. Per ulteriori informazioni sulle autorizzazioni richieste per l'esecuzione di una query, consulta Ruoli richiesti.

Questi errori possono verificarsi anche se la tabella non esiste nella regione su cui è stata eseguita la query, ad esempio asia-south1. Puoi verificare la regione esaminando la località del set di dati.

Quando correggi questi errori, tieni presente quanto segue:

• Service account: i service account devono disporre dell'autorizzazione bigquery.jobs.create sul progetto da cui vengono eseguiti e dell'autorizzazione bigquery.tables.getData su tutte le tabelle e le viste a cui fa riferimento la query.

• Ruoli personalizzati: i ruoli IAM personalizzati devono avere l'autorizzazione bigquery.jobs.create inclusa esplicitamente nel ruolo pertinente e devono avere l'autorizzazione bigquery.tables.getData su tutte le tabelle e le viste a cui fa riferimento la query.

• Set di dati condivisi: quando lavori con set di dati condivisi in un progetto separato, potresti comunque aver bisogno dell'autorizzazione bigquery.jobs.create nel progetto per eseguire query o job in quel set di dati.

Per concedere l'autorizzazione ad accedere a una tabella o a una vista, consulta Concedi l'accesso a una tabella o a una vista.

Autorizzazione bigquery.reservations.use negata per la prenotazione

Stringa di errore:

• Access Denied: Reservation projects/project/locations/region/reservations/reservation_name: Permission bigquery.reservations.use denied on reservation projects/project/locations/region/reservations/reservation_name (or it may not exist)

Questo errore si verifica quando una query viene assegnata per l'esecuzione in una prenotazione specifica utilizzando l'istruzione SET @@reservation e l'account utente o di servizio non dispone dell'autorizzazione bigquery.reservations.use. Puoi esaminare l'errore in Cloud Logging o nella pagina dei job BigQuery per identificare l'entità che ha tentato di eseguire questa operazione.

Altri errori Access Denied

Stringhe di errore:

• Access Denied: Dataset project_id:dataset_id: Permission bigquery.datasets.get denied on dataset project_id:dataset_id (or it may not exist).
• Access Denied: Dataset project_id:dataset_id: Permission bigquery.datasets.update denied on dataset project_id:dataset_id (or it may not exist).
• Access Denied: BigQuery BigQuery: User does not have permission to access data protected by policy tag

Per risolvere gli errori generali di Access Denied in BigQuery, utilizza Policy Analyzer per determinare l'accesso di un'entità a una risorsa.

In Policy Analyzer, fornisci la risorsa BigQuery a cui stai tentando di accedere (ad esempio //bigquery.googleapis.com/projects/YOUR_PROJECT/datasets/YOUR_DATASET/tables/YOUR_TABLE) e l'indirizzo email dell'utente o del account di servizio che riceve l'errore Access Denied come entità. L'analisi mostra le autorizzazioni dell'entità sulla risorsa, che puoi confrontare con le autorizzazioni mancanti nel messaggio di errore.

Crittografia della destinazione non supportata per gli script

Stringa di errore: configuration.query.destinationEncryptionConfiguration cannot be set for scripts

Questo errore si verifica quando si tenta di impostare la configurazione della crittografia di destinazione per un job di script BigQuery, che non è supportata.

Accesso negato dalla policy dell'organizzazione

Stringa di errore: IAM setPolicy failed for Dataset DATASET: Operation denied by org policy on resource.

Questo errore si verifica quando una policy dell'organizzazione impedisce all'entità di eseguire query su una risorsa BigQuery. Il servizio policy dell'organizzazione ti consente di applicare vincoli alle risorse supportate nella gerarchia della tua organizzazione.

Se l'entità deve avere accesso alla risorsa, dovrai utilizzare gli strumenti di risoluzione dei problemi VPC disponibili per diagnosticare il problema con la policy dell'organizzazione.

Problemi relativi al superamento delle risorse

I seguenti problemi si verificano quando BigQuery non dispone di risorse sufficienti per completare la query.

La query supera le risorse della CPU

Stringa di errore: Query exceeded resource limits. This query used CPU_SECONDS_USED CPU seconds but would charge only ANALYSIS_MEGABYTES_BILLEDM Analysis bytes. This exceeds the ratio supported by the on-demand pricing model. Please consider moving this workload to a capacity-based pricing model, which does not have this limit. CPU_SECONDS_USED CPU seconds were used, and this query must use less than CPU_SECONDS_LIMIT CPU seconds.

Questo errore (billingTierLimitExceeded) si verifica quando una query che utilizza i prezzi on demand supera il limite di utilizzo massimo della CPU per dati scansionati di circa 256 secondi di CPU per MiB di dati scansionati. Ciò si verifica quando una query on demand esegue operazioni ad alta intensità di CPU, come operazioni CROSS JOIN non vincolate, condizioni di join imprecise, espressioni regolari complesse, funzioni di finestra analitica non partizionate o funzioni definite dall'utente JavaScript con un carico di calcolo elevato, su una quantità relativamente ridotta di dati scansionati.

Per risolvere questo errore, esegui una delle seguenti operazioni:

• Ottimizza la query. Rifattorizza l'SQL per ridurre l'overhead di calcolo relativo ai dati scansionati, ad esempio rimuovendo i prodotti cartesiani non intenzionali (operazioni CROSS JOIN senza filtri), sostituendo i predicati di join imprecisi, semplificando le espressioni regolari complesse, aggiungendo clausole PARTITION BY alle funzioni finestra su finestre non partizionate di grandi dimensioni o ottimizzando le UDF JavaScript. Per saperne di più, consulta Evita gli anti-pattern SQL, Introduzione all'ottimizzazione delle prestazioni delle query e Risolvi i problemi relativi alle risorse esaurite.
• Passa ai prezzi basati sulla capacità. Esegui il workload utilizzando i prezzi basati sulla capacità (slot). Con i prezzi basati sulla capacità, le query non sono soggette al limite del rapporto CPU-byte on demand.

La query supera le risorse di memoria

Stringa di errore: Resources exceeded during query execution: The query could not be executed in the allotted memory

Per le istruzioni SELECT, questo errore si verifica quando la query utilizza troppe risorse. Per risolvere questo errore, consulta Risolvi i problemi relativi al superamento delle risorse.

Spazio dello stack esaurito

Stringa di errore: Out of stack space due to deeply nested query expression during query resolution.

Questo errore può verificarsi quando una query contiene troppe chiamate di funzione nidificate. A volte, parti di una query vengono tradotte in chiamate di funzione durante l'analisi. Ad esempio, un'espressione con operatori di concatenazione ripetuti, come A || B || C || ..., diventa CONCAT(A, CONCAT(B, CONCAT(C, ...))).

Per risolvere questo errore, riscrivi la query per ridurre la quantità di nidificazione.

Risorse superate durante l'esecuzione della query

Stringa di errore: Resources exceeded during query execution: The query could not be executed in the allotted memory. Peak usage: [percentage]% of limit. Top memory consumer(s): ORDER BY operations.

Questo può accadere con le query ORDER BY ... LIMIT ... OFFSET .... A causa dei dettagli di implementazione, l'ordinamento potrebbe avvenire su una singola unità di calcolo, che potrebbe esaurire la memoria se deve elaborare troppe righe prima dell'applicazione di LIMIT e OFFSET, in particolare con un OFFSET di grandi dimensioni.

Per risolvere questo errore, evita valori OFFSET elevati nelle query ORDER BY … LIMIT. In alternativa, utilizza la funzione finestra scalabile ROW_NUMBER() per assegnare i ranking in base all'ordine scelto, quindi filtra questi ranking in una clausola WHERE. Ad esempio:

SELECT ...
FROM (
  SELECT ROW_NUMBER() OVER (ORDER BY ...) AS rn
  FROM ...
)
WHERE rn > @start_index AND rn <= @page_size + @start_index  -- note that row_number() starts with 1

Memoria del worker TensorFlow esaurita

Stringa di errore: Resources exceeded during query execution: TensorFlow worker out of memory.

I modelli che superano il limite di memoria (in genere 250 MB), in particolare quando utilizzano funzioni che richiedono un uso intensivo delle risorse come ML.EXPLAIN_PREDICT, possono attivare questo errore.

Per risolvere questo errore:

1. Utilizza i modelli remoti della piattaforma agentica Gemini Enterprise: per i modelli che superano i limiti di memoria, esegui il deployment del modello sulla piattaforma agentica seguendo i passaggi dell'SDK Vertex AI Python per eseguire il deployment di un modello, quindi accedi utilizzando i modelli remoti. In questo modo, i requisiti di memoria vengono trasferiti all'infrastruttura dedicata di Agent Platform.

2. Ottimizza il modello: riduci l'impatto della RAM del modello utilizzando la semplificazione, la quantizzazione o la potatura dell'architettura.

3. Utilizza funzioni meno intensive: se l'errore si verifica durante una chiamata ML.EXPLAIN_PREDICT, prova a eseguire il job con ML.PREDICT per determinare se il modello può essere eseguito senza l'overhead aggiuntivo delle funzionalità di spiegabilità.

4. Analizza le dimensioni dei dati di input: singole righe di grandi dimensioni possono contribuire all'esaurimento della memoria. Controlla le dimensioni delle righe più grandi utilizzando:

   SELECT BYTE_LENGTH(TO_JSON_STRING(t)) AS row_size
   FROM your_table AS t
   ORDER BY row_size DESC
   LIMIT 10

La query supera le risorse di shuffle

Stringa di errore: Resources exceeded during query execution: Your project or organization exceeded the maximum disk and memory limit available for shuffle operations

Questo errore si verifica quando una query non può accedere a risorse di shuffle sufficienti.

Per risolvere questo errore, esegui il provisioning di più slot o riduci la quantità di dati elaborati dalla query. Per saperne di più su come farlo, consulta Quota di shuffling insufficiente.

Se utilizzi il modello di prezzo on demand, hai un limite massimo di 2000 slot. Per aumentare il numero di slot, devi passare a un modello di prezzi basato sulla capacità.

Per ulteriori informazioni su come risolvere questi problemi, consulta Risolvi i problemi relativi al superamento delle risorse.

La query è troppo complessa

Stringa di errore: Resources exceeded during query execution: Not enough resources for query planning - too many subqueries or query is too complex

Questo errore si verifica quando una query è troppo complessa. Le cause principali della complessità sono:

• WITH clausole con nidificazione profonda o utilizzate ripetutamente.
• Viste con un livello di nidificazione elevato o utilizzate ripetutamente.
• Utilizzo ripetuto dell'operatore UNION ALL.

Per risolvere questo errore, prova le seguenti opzioni:

• Suddividi la query in più query, quindi utilizza il linguaggio procedurale per eseguire le query in una sequenza con stato condiviso.
• Utilizza tabelle temporanee anziché clausole WITH.
• Riscrivi la query per ridurre il numero di oggetti e confronti di riferimento.

Puoi monitorare in modo proattivo le query che si avvicinano al limite di complessità utilizzando il campo query_info.resource_warning nella vista INFORMATION_SCHEMA.JOBS. L'esempio seguente restituisce le query con un utilizzo elevato delle risorse negli ultimi tre giorni:

SELECT
  ANY_VALUE(query) AS query,
  MAX(query_info.resource_warning) AS resource_warning
FROM
  <your_project_id>.`region-us`.INFORMATION_SCHEMA.JOBS
WHERE
  creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 3 DAY)
  AND query_info.resource_warning IS NOT NULL
GROUP BY
  query_info.query_hashes.normalized_literals
LIMIT
  1000

Per ulteriori informazioni su come risolvere questi problemi, consulta Risolvi i problemi relativi al superamento delle risorse.

Risolvi i problemi relativi al superamento delle risorse

Per i job di query:

Per ottimizzare le query, prova a seguire questi passaggi:

• Prova a rimuovere una clausola ORDER BY.
• Se la query utilizza JOIN, assicurati che la tabella più grande si trovi sul lato sinistro della clausola. Assicurati inoltre che i dati non contengano chiavi di join duplicate.
• Se la query utilizza FLATTEN, determina se è necessaria per il tuo caso d'uso. Per saperne di più, consulta Dati nidificati e ripetuti.
• Se la query utilizza EXACT_COUNT_DISTINCT, valuta la possibilità di utilizzare COUNT(DISTINCT).
• Se la query utilizza COUNT(DISTINCT <value>, <n>) con un valore <n> elevato, valuta la possibilità di utilizzare GROUP BY. Per saperne di più, consulta COUNT(DISTINCT).
• Se la query utilizza UNIQUE, valuta la possibilità di utilizzare GROUP BY o una funzione finestra all'interno di una selezione secondaria.
• Se la query materializza molte righe utilizzando una clausola LIMIT, valuta la possibilità di filtrare in base a un'altra colonna, ad esempio ROW_NUMBER(), o di rimuovere completamente la clausola LIMIT per consentire la parallelizzazione della scrittura.
• Se la query utilizzava viste con nidificazione profonda e una clausola WITH, ciò può causare una crescita esponenziale della complessità, raggiungendo così i limiti.
• Utilizza tabelle temporanee anziché clausole WITH. Una clausola WITH potrebbe dover essere ricalcolata più volte, il che può rendere la query complessa e quindi lenta. La persistenza dei risultati intermedi in tabelle temporanee riduce invece la complessità.
• Evita di utilizzare query UNION ALL.
• Se la query utilizza MATCH_RECOGNIZE, modifica la clausola PARTITION BY per ridurre le dimensioni delle partizioni o aggiungi una clausola PARTITION BY se non esiste.

Per maggiori informazioni, consulta le seguenti risorse:

• Ottimizza il calcolo delle query.
• Monitora l'integrità, l'utilizzo delle risorse e i job

Per i job di caricamento:

Se carichi file Avro o Parquet, riduci le dimensioni delle righe nei file. Verifica le limitazioni di dimensioni specifiche per il formato file che stai caricando:

• Requisiti dei file di input Avro
• Requisiti dei file di input Parquet

Se ricevi questo errore durante il caricamento dei file ORC, contatta l'assistenza.

Per l'API Storage:

Stringa di errore: Stream memory usage exceeded

Durante una chiamata ReadRows all'API Storage Read, alcuni stream con un utilizzo elevato della memoria utilizzata potrebbero ricevere un errore RESOURCE_EXHAUSTED con questo messaggio. Questo può accadere durante la lettura di tabelle ampie o con uno schema complesso. Per risolvere il problema, riduci le dimensioni delle righe dei risultati selezionando meno colonne da leggere (utilizzando il parametro selected_fields) o semplificando lo schema della tabella.

Risolvi i problemi di connettività

Le sezioni seguenti descrivono come risolvere i problemi di connettività quando si tenta di interagire con BigQuery:

Inserisci i DNS di Google nella lista consentita

Utilizza lo strumento Google IP Dig per risolvere l'endpoint DNS BigQuery bigquery.googleapis.com in un singolo IP del record "A". Assicurati che questo IP non sia bloccato nelle impostazioni del firewall.

In generale, consigliamo di inserire nella lista consentita i nomi DNS di Google. Gli intervalli IP condivisi nei file https://documentation.s3ns.fr/ipranges/goog.json e https://documentation.s3ns.fr/ipranges/cloud.json cambiano spesso, pertanto ti consigliamo di inserire nella lista consentita i nomi DNS di Google. Ecco un elenco di nomi DNS comuni che ti consigliamo di aggiungere alla lista consentita:

• *.1e100.net
• *.google.com
• *.gstatic.com
• *.googleapis.com
• *.googleusercontent.com
• *.appspot.com
• *.gvt1.com

Identifica il proxy o il firewall che sta eliminando i pacchetti

Per identificare tutti gli hop dei pacchetti tra il client e Google Front End (GFE), esegui un comando traceroute sulla macchina client che potrebbe evidenziare il server che sta eliminando i pacchetti indirizzati al GFE. Ecco un comando traceroute di esempio:

traceroute -T -p 443 bigquery.googleapis.com

È anche possibile identificare gli hop dei pacchetti per indirizzi IP GFE specifici se il problema è correlato a un indirizzo IP particolare:

traceroute -T -p 443 142.250.178.138

Se si verifica un problema di timeout lato Google, vedrai che la richiesta arriva fino al GFE.

Se noti che i pacchetti non raggiungono mai il GFE, contatta l'amministratore di rete per risolvere il problema.

Genera un file PCAP e analizza il firewall o il proxy

Genera un file di acquisizione dei pacchetti (PCAP) e analizzalo per assicurarti che il firewall o il proxy non filtri i pacchetti verso gli IP di Google e consenta ai pacchetti di raggiungere il GFE.

Ecco un comando di esempio che può essere eseguito con lo strumento tcpdump:

tcpdump -s 0 -w debug.pcap -K -n host bigquery.googleapis.com

Configura i nuovi tentativi per i problemi di connettività intermittente

In alcune situazioni, i bilanciatori del carico GFE potrebbero interrompere le connessioni da un IP client, ad esempio se rilevano pattern di traffico DDoS o se l'istanza del bilanciatore del carico viene ridotta, il che potrebbe comportare il riciclo dell'IP dell'endpoint. Se i bilanciatori del carico GFE interrompono la connessione, il client deve intercettare la richiesta scaduta e riprovare a inviarla all'endpoint DNS. Assicurati di non utilizzare lo stesso indirizzo IP finché la richiesta non va a buon fine, perché l'indirizzo IP potrebbe essere cambiato.

Se hai identificato un problema con timeout costanti lato Google in cui i nuovi tentativi non sono utili, contatta l'assistenza clienti Google Cloud e assicurati di includere un nuovo file PCAP generato eseguendo uno strumento di acquisizione di pacchetti come tcpdump.

Passaggi successivi

• Ottieni insight sulle prestazioni delle query.
• Scopri di più sull'ottimizzazione delle query per le prestazioni.
• Esamina quote e limiti per le query.
• Scopri di più su altri messaggi di errore di BigQuery.