Memecahkan masalah kueri

Dokumen ini dimaksudkan untuk membantu Anda memecahkan masalah umum terkait menjalankan kueri, seperti mengidentifikasi alasan kueri lambat, atau memberikan langkah-langkah penyelesaian untuk error umum yang ditampilkan oleh kueri yang gagal.

Memecahkan masalah kueri lambat

Untuk memecahkan masalah performa kueri yang lambat, lakukan hal berikut:

  • Periksa halaman Google Cloud Service Health untuk mengetahui pemadaman layanan BigQuery yang diketahui yang mungkin memengaruhi performa kueri.

  • Tinjau linimasa tugas untuk kueri Anda di penjelajah tugas untuk melihat durasi setiap tahap kueri berjalan.

    • Jika sebagian besar waktu yang berlalu disebabkan oleh waktu pembuatan yang lama, hubungi Cloud Customer Care untuk mendapatkan bantuan.

    • Jika sebagian besar waktu yang berlalu disebabkan oleh waktu eksekusi yang lama, tinjau insight performa kueri Anda. Insight performa kueri dapat memberi tahu Anda jika kueri berjalan lebih lama dari waktu eksekusi rata-rata, dan menyarankan kemungkinan penyebabnya. Kemungkinan penyebabnya mungkin mencakup pertentangan slot kueri atau kuota shuffle yang tidak memadai. Untuk mengetahui informasi selengkapnya tentang setiap masalah performa kueri dan kemungkinan penyelesaiannya, lihat Menafsirkan insight performa kueri.

  • Tinjau kolom finalExecutionDurationMs dalam jenis objek JobStatistics untuk tugas kueri Anda. Kueri mungkin telah dicoba lagi. Kolom finalExecutionDurationMs berisi durasi dalam milidetik dari eksekusi upaya terakhir tugas ini.

  • Tinjau byte yang diproses di halaman detail tugas kueri untuk melihat apakah jumlahnya lebih tinggi dari yang diharapkan. Anda dapat melakukannya dengan membandingkan jumlah byte yang diproses oleh kueri saat ini dengan tugas kueri lain yang selesai dalam waktu yang dapat diterima. Jika ada perbedaan byte yang besar yang diproses di antara kedua kueri, mungkin kueri tersebut lambat karena volume data yang besar. Untuk mengetahui informasi tentang cara mengoptimalkan kueri Anda untuk menangani volume data yang besar, lihat Mengoptimalkan komputasi kueri.

    Anda juga dapat mengidentifikasi kueri dalam project yang memproses data dalam jumlah besar dengan menelusuri kueri yang paling mahal menggunakan tampilan INFORMATION_SCHEMA.JOBS.

  • Tinjau penggunaan pemesanan Anda dan periksa pertentangan slot. Untuk mengetahui informasi selengkapnya, lihat Analisis statistik workload.

  • Periksa eksekusi sebelumnya dan terbaru untuk hash kueri yang sama guna melihat apakah insight performa kueri baru tersedia untuk tugas yang lebih lambat, seperti perubahan skala input data. Anda dapat memfilter menurut hash kueri di penjelajah tugas administratif.

Membandingkan eksekusi lambat dan cepat dari kueri yang sama

Jika kueri yang sebelumnya berjalan cepat kini berjalan lambat, periksa output objek Job API untuk mengidentifikasi perubahan dalam eksekusinya.

Cache ditemukan

Konfirmasi apakah eksekusi tugas yang cepat merupakan cache ditemukan dengan melihat nilai cacheHit. Jika nilainya adalah true untuk eksekusi kueri yang cepat, kueri tersebut menggunakan hasil yang di-cache, bukan menjalankan kueri.

Jika Anda memperkirakan tugas yang lambat akan menggunakan hasil yang di-cache, selidiki alasan kueri tidak lagi menggunakan hasil yang di-cache. Jika Anda tidak mengharapkan kueri mengambil data dari cache, cari contoh eksekusi kueri cepat yang tidak mencapai cache untuk penyelidikan.

Penundaan kuota

Untuk menentukan apakah perlambatan disebabkan oleh penundaan kuota, periksa kolom quotaDeferments untuk kedua tugas. Bandingkan nilai untuk menentukan apakah waktu mulai kueri yang lebih lambat tertunda oleh penundaan kuota yang tidak memengaruhi tugas yang lebih cepat.

Durasi eksekusi

Untuk memahami perbedaan antara durasi eksekusi upaya terakhir kedua tugas, bandingkan nilainya untuk kolom finalExecutionDurationMs.

Jika nilai untuk finalExecutionDurationMs cukup mirip, tetapi perbedaan waktu eksekusi sebenarnya antara kedua kueri, yang dihitung sebagai startTime - endTime, jauh lebih besar, ini berarti mungkin ada percobaan ulang eksekusi kueri internal untuk tugas yang lambat karena kemungkinan masalah sementara. Jika Anda melihat pola perbedaan ini berulang kali, hubungi Cloud Customer Care untuk mendapatkan bantuan

Byte yang diproses

Tinjau byte yang diproses di halaman detail tugas kueri atau lihat totalBytesProcessed dari JobStatistics untuk mengetahui apakah nilainya lebih tinggi dari yang diharapkan. Jika ada perbedaan besar dalam byte yang diproses antara kedua kueri, kueri mungkin lambat karena perubahan volume data yang diproses. Untuk mengetahui informasi tentang cara mengoptimalkan kueri untuk menangani volume data yang besar, lihat Mengoptimalkan komputasi kueri. Alasan berikut dapat menyebabkan peningkatan jumlah byte yang diproses oleh kueri:

  • Ukuran tabel yang direferensikan oleh kueri telah meningkat.
  • Kueri kini membaca partisi tabel yang lebih besar.
  • Kueri mereferensikan tampilan yang definisinya telah berubah.

Tabel yang direferensikan

Periksa apakah kueri membaca tabel yang sama dengan menganalisis output kolom referencedTables di JobStatistics2. Perbedaan dalam tabel yang direferensikan dapat dijelaskan sebagai berikut:

  • Kueri SQL diubah untuk membaca tabel yang berbeda. Bandingkan teks kueri untuk mengonfirmasi hal ini.
  • Definisi tampilan telah berubah di antara eksekusi kueri. Periksa definisi tampilan yang dirujuk dalam kueri ini dan perbarui jika perlu.

Perbedaan dalam tabel yang direferensikan dapat menjelaskan perubahan dalam totalBytesProcessed.

Penggunaan tampilan terwujud

Jika kueri mereferensikan tampilan terwujud, perbedaan performa dapat disebabkan oleh tampilan terwujud yang dipilih atau ditolak selama eksekusi kueri. Periksa MaterializedViewStatistics untuk memahami apakah tampilan terwujud yang digunakan dalam kueri cepat ditolak dalam kueri lambat. Lihat kolom chosen dan rejectedReason di objek MaterializedView.

Statistik caching metadata

Untuk kueri yang melibatkan tabel BigLake Amazon S3 atau tabel BigLake Cloud Storage dengan caching metadata diaktifkan, bandingkan output MetadataCacheStatistics untuk memeriksa apakah ada perbedaan dalam penggunaan cache metadata antara kueri lambat dan cepat serta alasan yang sesuai. Misalnya, cache metadata mungkin berada di luar periode maxStaleness tabel.

Membandingkan statistik BigQuery BI Engine

Jika kueri menggunakan BigQuery BI Engine, analisis output BiEngineStatistics untuk menentukan apakah mode akselerasi yang sama diterapkan ke kueri lambat dan cepat. Lihat kolom BiEngineReason untuk memahami alasan umum akselerasi parsial atau tidak ada akselerasi sama sekali, seperti memori tidak cukup, tidak ada pemesanan, atau input terlalu besar.

Meninjau perbedaan dalam insight performa kueri

Bandingkan insight performa kueri untuk setiap kueri dengan melihat Execution Graph di konsol Google Cloud atau objek StagePerformanceStandaloneInsight untuk memahami kemungkinan masalah berikut:

Perhatikan insight yang diberikan untuk tugas yang lambat serta perbedaan antara insight yang dihasilkan untuk tugas yang cepat guna mengidentifikasi perubahan tahap yang memengaruhi performa.

Penetapan pemesanan

Periksa apakah ada perbedaan dalam reservasi yang ditetapkan untuk kedua tugas tersebut. Perubahan dalam pemesanan atau perpindahan dari on-demand ke pemesanan dapat memengaruhi performa. Untuk mengetahui informasi selengkapnya, lihat Model pengelolaan workload dan ukuran pemesanan.

Analisis metadata eksekusi tugas yang lebih menyeluruh memerlukan peninjauan satu tahap eksekusi kueri dengan membandingkan objek ExplainQueryStage untuk kedua tugas tersebut.

Untuk memulai, lihat metrik Wait ms dan Shuffle output bytes yang dijelaskan di bagian menafsirkan informasi tahap kueri.

Peringatan resource dari tampilan INFORMATION_SCHEMA.JOBS

Buat kueri kolom query_info.resource_warning dari tampilan INFORMATION_SCHEMA.JOBS untuk melihat apakah ada perbedaan dalam peringatan yang dianalisis oleh BigQuery sehubungan dengan resource yang digunakan.

Analisis statistik workload

Resource slot yang tersedia dan pertentangan slot dapat memengaruhi waktu eksekusi kueri. Bagian berikut membantu Anda memahami penggunaan dan ketersediaan slot untuk eksekusi kueri tertentu.

Slot rata-rata per detik

Untuk menghitung jumlah rata-rata slot yang digunakan per milidetik oleh kueri, bagi nilai slot milidetik untuk tugas, totalSlotMs dari JobStatistics2, dengan durasi dalam milidetik dari eksekusi upaya terakhir tugas ini, finalExecutionDurationMs dari JobStatistics.

Anda juga dapat menghitung jumlah rata-rata slot per milidetik yang digunakan oleh tugas dengan mengkueri tampilan INFORMATION_SCHEMA.JOBS

Tugas yang melakukan jumlah pekerjaan yang sama dengan jumlah slot rata-rata per detik yang lebih besar akan selesai lebih cepat. Penggunaan slot rata-rata per detik yang lebih rendah dapat disebabkan oleh hal berikut:

  • Tidak ada resource tambahan yang tersedia karena pertentangan resource antara berbagai tugas—reservasi telah mencapai batas maksimum.
  • Tugas tidak meminta lebih banyak slot selama sebagian besar eksekusi. Misalnya, hal ini dapat terjadi jika ada kecondongan data.

Model pengelolaan workload dan ukuran pemesanan

Jika Anda menggunakan model penagihan on-demand, jumlah slot yang dapat Anda gunakan per project akan dibatasi. Project Anda juga terkadang memiliki lebih sedikit slot yang tersedia jika ada banyak pertentangan untuk kapasitas on-demand di lokasi tertentu.

Model berbasis kapasitas lebih dapat diprediksi dan memungkinkan Anda menentukan jumlah slot dasar pengukuran yang dikonfirmasi.

Pertimbangkan perbedaan ini saat membandingkan eksekusi kueri yang dijalankan menggunakan on-demand dengan eksekusi kueri yang menggunakan pemesanan.

Menggunakan pemesanan direkomendasikan untuk memiliki performa eksekusi kueri yang stabil dan dapat diprediksi. Untuk mengetahui informasi selengkapnya tentang perbedaan antara workload on-demand dan berbasis kapasitas, lihat Pengantar pengelolaan workload.

Konkurensi tugas

Konkurensi tugas menunjukkan persaingan di antara tugas untuk mendapatkan resource slot selama eksekusi kueri. Konkurensi tugas yang lebih tinggi umumnya menyebabkan eksekusi tugas yang lebih lambat karena tugas memiliki akses ke slot yang lebih sedikit.

Anda dapat mengkueri tampilan INFORMATION_SCHEMA.JOBS untuk menemukan jumlah rata-rata tugas serentak yang berjalan bersamaan dengan kueri tertentu dalam sebuah project.

Jika ada lebih dari satu project yang ditetapkan ke pemesanan, ubah kueri untuk menggunakan JOBS_BY_ORGANIZATION, bukan JOBS_BY_PROJECT, guna mendapatkan data tingkat pemesanan yang akurat.

Konkurensi rata-rata yang lebih tinggi selama eksekusi tugas yang lambat dibandingkan dengan tugas yang cepat merupakan faktor yang berkontribusi terhadap kelambatan secara keseluruhan.

Pertimbangkan untuk mengurangi konkurensi dalam project atau pemesanan dengan menyebarkan kueri yang menggunakan banyak resource, baik dari waktu ke waktu dalam pemesanan atau project, maupun di berbagai pemesanan atau project.

Solusi lainnya adalah membeli pemesanan atau meningkatkan ukuran pemesanan yang ada. Pertimbangkan untuk mengizinkan pemesanan menggunakan slot tidak ada aktivitas.

Untuk memahami jumlah slot yang perlu ditambahkan, baca artikel tentang memperkirakan persyaratan kapasitas slot.

Tugas yang berjalan dalam pemesanan dengan lebih dari satu project yang ditetapkan dapat mengalami hasil penetapan slot yang berbeda dengan konkurensi tugas rata-rata yang sama, bergantung pada project yang menjalankannya. Baca penjadwalan yang adil untuk mempelajari lebih lanjut.

Pemakaian reservasi

Diagram resource admin dan Cloud Monitoring BigQuery dapat digunakan untuk memantau pemakaian pemesanan. Untuk mengetahui informasi selengkapnya, lihat Memantau reservasi BigQuery.

Untuk memahami apakah suatu tugas meminta slot tambahan, lihat metrik perkiraan unit yang dapat dijalankan, yaitu estimatedRunnableUnits dari respons Job API, atau period_estimated_runnable_units di tampilan INFORMATION_SCHEMA.JOBS_TIMELINE. Jika nilai untuk metrik ini lebih dari 0, tugas dapat memperoleh manfaat dari slot tambahan pada saat itu. Untuk memperkirakan persentase waktu eksekusi tugas yang akan diuntungkan dari slot tambahan, jalankan kueri berikut terhadap tampilan 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;
 Hasilnya mirip dengan berikut ini: 
+---------------------------------+
|   execution_duration_percentage |
+---------------------------------+
|                            96.7 |
+---------------------------------+

Persentase yang rendah berarti ketersediaan resource slot bukan kontributor utama lambatnya kueri dalam skenario ini.

Jika persentasenya tinggi dan pemesanan tidak digunakan sepenuhnya selama waktu ini, hubungi Cloud Customer Care untuk menyelidiki.

Jika pemesanan digunakan sepenuhnya selama eksekusi tugas yang lambat dan persentasenya tinggi, tugas tersebut dibatasi pada resource. Pertimbangkan untuk mengurangi konkurensi, meningkatkan ukuran pemesanan, mengizinkan pemesanan menggunakan slot tidak ada aktivitas, atau membeli pemesanan jika tugas dijalankan on-demand.

Metadata tugas dan temuan analisis workload tidak meyakinkan

Jika Anda masih tidak dapat menemukan alasan untuk menjelaskan performa kueri yang lebih lambat dari yang diharapkan, hubungi Cloud Customer Care untuk mendapatkan bantuan.

Memecahkan masalah kueri menggunakan Gemini Cloud Assist

Untuk menggunakan Gemini Cloud Assist dalam membantu Anda memecahkan masalah kegagalan kueri atau masalah performa, lakukan hal berikut:

  1. Di konsol Google Cloud , buka halaman BigQuery.

    Buka BigQuery

  2. Di toolbar Google Cloud , klik spark Open or close Gemini Cloud Assist chat.

  3. Di panel Cloud Assist, masukkan perintah yang menyertakan ID pekerjaan untuk menyelidiki eksekusi, metrik performa, atau alasan kegagalannya. Misalnya:

    • Mengapa JOB_ID gagal?
    • Mengapa tugas ini memerlukan waktu begitu lama? JOB_ID
    • Ringkas performa tugas saya selama 24 jam terakhir.

Memecahkan masalah kegagalan kueri menggunakan gcpdiag

gcpdiag adalah alat open source. Produk ini tidak didukung secara resmi oleh Google Cloud . Anda dapat menggunakan alat gcpdiag untuk membantu mengidentifikasi dan memperbaiki Google Cloud masalah project. Untuk mengetahui informasi selengkapnya, lihat project gcpdiag di GitHub.

Alat gcpdiag membantu Anda menganalisis kueri BigQuery yang gagal untuk memahami apakah ada penyebab utama dan mitigasi yang diketahui untuk kegagalan tertentu.

Jalankan perintah gcpdiag

Anda dapat menjalankan perintah gcpdiag dari Google Cloud CLI:

KonsolGoogle Cloud

  1. Lengkapi, lalu salin perintah berikut. 
    2. gcpdiag runbook bigquery/failed-query \
   --parameter project_id=PROJECT_ID \
   --parameter bigquery_job_region=JOB_REGION \
   --parameter bigquery_job_id=JOB_ID \
   --parameter bigquery_skip_permission_check=SKIP_PERMISSION_CHECK
  2. Buka konsol Google Cloud dan aktifkan Cloud Shell.
    3. Buka Konsol Cloud
  3. Tempel perintah yang disalin.
  4. Jalankan perintah gcpdiag, yang mendownload image docker gcpdiag, lalu melakukan pemeriksaan diagnostik. Jika ada, ikuti petunjuk output untuk memperbaiki pemeriksaan yang gagal.

Docker

Anda dapat menjalankan gcpdiag menggunakan wrapper yang memulai gcpdiag dalam container Docker. Docker atau Podman harus diinstal.

  1. Salin dan jalankan perintah berikut di workstation lokal Anda. 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Jalankan perintah gcpdiag. 
    ./gcpdiag runbook bigquery/failed-query \
   --parameter project_id=PROJECT_ID \
   --parameter bigquery_job_region=JOB_REGION \
   --parameter bigquery_job_id=JOB_ID \
   --parameter bigquery_skip_permission_check=SKIP_PERMISSION_CHECK

Lihat parameter yang tersedia untuk runbook ini.

Ganti kode berikut:

  • PROJECT_ID: ID project yang berisi resource.
  • JOB_REGION: Region tempat tugas BigQuery dijalankan.
  • JOB_ID: ID tugas dari tugas BigQuery.
  • SKIP_PERMISSION_CHECK: (Opsional) tetapkan ini ke True jika Anda ingin melewati pemeriksaan izin yang relevan dan mempercepat eksekusi runbook (nilai defaultnya adalah False).

Flag yang berguna:

Untuk mengetahui daftar dan deskripsi semua flag alat gcpdiag, lihat petunjuk penggunaan gcpdiag.

Resolusi skema Avro

String error: Cannot skip stream

Error ini dapat terjadi saat memuat beberapa file Avro dengan skema yang berbeda, yang mengakibatkan masalah resolusi skema dan menyebabkan tugas impor gagal dalam file acak.

Untuk mengatasi error ini, pastikan file alfabet terakhir dalam tugas pemuatan berisi superset (union) skema yang berbeda. Hal ini adalah persyaratan berdasarkan cara Avro menangani resolusi skema.

Kueri serentak yang bertentangan

String error: Concurrent jobs in the same session are not allowed

Error ini dapat terjadi jika beberapa kueri berjalan serentak dalam satu sesi, yang tidak didukung. Lihat batasan sesi.

Pernyataan DML yang bertentangan

String error: Could not serialize access to table due to concurrent update

Error ini terjadi saat pernyataan bahasa pengolahan data (DML) yang bermutasi serentak (UPDATE, DELETE, atau MERGE) mencoba mengubah data di partisi tabel yang sama secara bersamaan, atau saat tabel dipotong saat pernyataan DML sedang berjalan.

BigQuery memungkinkan pernyataan DML bermutasi serentak berjalan di tabel yang sama selama pernyataan tersebut mengubah partisi yang berbeda. Namun, jika dua tugas mencoba mengubah partisi yang sama, tugas pertama yang di-commit akan berhasil, dan tugas berikutnya akan gagal dengan error ini.

Untuk mengatasi error ini, coba langkah berikut:

  • Coba lagi tugas yang gagal: jika konflik disebabkan oleh tumpang-tindih sementara dengan tugas lain, coba lagi kueri setelah tugas yang bertentangan selesai.
  • Identifikasi dan koordinasikan tugas yang bertentangan: jalankan kueri diagnostik di bagian berikut untuk mengidentifikasi tugas yang bersaing, lalu koordinasikan jadwal sehingga operasi DML yang bermutasi pada partisi yang sama tidak berjalan pada saat yang sama.
  • Partisi tabel Anda: jika tugas DML serentak memperbarui segmen data yang berbeda, partisi tabel Anda berdasarkan rentang tanggal atau bilangan bulat. Pernyataan DML bermutasi serentak berhasil tanpa konflik jika mengubah partisi yang berbeda.
  • Operasi DML batch: gabungkan beberapa operasi UPDATE atau DELETE individual menjadi satu pernyataan MERGE atau tugas batch untuk mengurangi konkurensi dan overhead commit. Untuk mengetahui informasi selengkapnya, baca Praktik terbaik.

Mengidentifikasi tugas yang bertentangan

Untuk mengidentifikasi tugas mana yang secara serentak memperbarui tabel saat error terjadi, jalankan kueri terhadap tampilan 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;

Ganti kode berikut:

  • REGION: nama region tempat set data Anda berada—misalnya, us.
  • FAILED_JOB_START_TIME: stempel waktu saat tugas yang gagal dimulai—misalnya, 2026-09-01 09:55:00 UTC.
  • FAILED_JOB_END_TIME: stempel waktu saat tugas yang gagal berakhir—misalnya, 2026-09-01 10:00:00 UTC.
  • TABLE_NAME: nama tabel yang coba diperbarui oleh pernyataan DML yang gagal.
  • DATASET_NAME: nama set data yang berisi tabel.

Jika kueri tidak menampilkan tugas yang bertentangan yang dimulai oleh pengguna, konflik mungkin disebabkan oleh operasi latar belakang lain, seperti masa berlaku partisi.

Penyebab lain konflik update serentak

  • Masa berlaku partisi: tugas sistem latar belakang yang mengakhiri masa berlaku partisi dapat bertentangan dengan pernyataan DML, jika tugas tersebut mengubah partisi yang sama selama eksekusi tugas. Jika Anda menggunakan masa berlaku partisi, jadwalkan tugas DML di luar waktu masa berlaku partisi berakhir.
  • Transaksi multi-pernyataan: saat transaksi multi-pernyataan mengubah tabel, transaksi tersebut akan memblokir semua pernyataan DML serentak lainnya pada tabel tersebut hingga transaksi selesai.
  • Pernyataan DML yang memengaruhi nol baris: pernyataan UPDATE, DELETE, atau MERGE memperoleh kunci pada partisi yang ditargetkan dan dapat menyebabkan konflik serialisasi meskipun tidak ada baris yang cocok dengan kondisi filter.

Untuk mengetahui informasi selengkapnya, lihat Konflik pernyataan DML.

Subkueri berkorelasi

String error: Correlated subqueries that reference other tables are not supported unless they can be de-correlated

Error ini dapat terjadi jika kueri Anda berisi subkueri yang mereferensikan kolom dari luar subkueri tersebut, yang disebut kolom korelasi. Subkueri yang berkorelasi dievaluasi menggunakan strategi eksekusi bertingkat yang tidak efisien, di mana subkueri dievaluasi untuk setiap baris dari kueri luar yang menghasilkan kolom korelasi. Terkadang, BigQuery dapat menulis ulang kueri secara internal dengan subkueri yang berkorelasi sehingga kueri tersebut dieksekusi dengan lebih efisien. Error subkueri yang berkorelasi terjadi saat BigQuery tidak dapat mengoptimalkan kueri secara memadai.

Untuk mengatasi error ini, coba langkah berikut:

  • Hapus klausa ORDER BY, LIMIT, EXISTS, NOT EXISTS, atau IN dari subkueri Anda.
  • Gunakan kueri multi-pernyataan untuk membuat tabel sementara yang akan direferensikan dalam subkueri Anda.
  • Tulis ulang kueri Anda untuk menggunakan CROSS JOIN.

Izin kontrol akses tingkat kolom tidak memadai

String error:

  • Access denied: Requires fineGrainedGet permission on the read columns to execute the DML statements
  • `Access denied: User does not have permission to access policy tag projects/PROJECT_ID/locations/LOCATION/taxonomies/TAXONOMY_ID/policyTags/POLICY_TAG_ID on column PROJECT_ID.DATASET.TABLE.COLUMN.'

Error ini terjadi saat Anda mencoba menjalankan kueri SQL atau pernyataan DELETE, UPDATE, atau MERGE DML tanpa diberi peran Fine-Grained Reader pada kolom yang menggunakan kontrol akses tingkat kolom. Peran ini ditetapkan ke akun utama sebagai bagian dari konfigurasi tag kebijakan. Untuk mengetahui informasi selengkapnya, lihat Dampak pada penulisan dari kontrol akses tingkat kolom.

Untuk mengatasi masalah ini, ubah kueri untuk mengecualikan kolom dengan tag kebijakan, atau berikan peran Fine-Grained Reader kepada pengguna. Peran ini ditetapkan ke akun utama sebagai bagian dari konfigurasi tag kebijakan. Untuk mengetahui informasi selengkapnya, lihat Memperbarui izin pada tag kebijakan.

Memecahkan masalah kueri terjadwal

Masalah berikut mungkin muncul selama konfigurasi atau eksekusi kueri terjadwal.

Kueri terjadwal memicu operasi duplikat

Kueri terjadwal mungkin dipicu lebih dari sekali pada waktu yang dijadwalkan. Perilaku ini lebih mungkin terjadi untuk kueri yang dijadwalkan tepat pada jam tertentu (seperti pukul 09.00). Hal ini dapat menyebabkan hasil yang tidak diharapkan, seperti data duplikat jika kueri menjalankan operasi INSERT.

Untuk meminimalkan risiko duplikasi operasi, jadwalkan kueri Anda pada waktu di luar jam, seperti beberapa menit sebelum atau setelah jam (misalnya, 08.58 atau 09.03). Untuk mengetahui informasi selengkapnya, lihat Menjadwalkan kueri.

Kredensial tidak valid untuk kueri terjadwal

String error:

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

Error ini dapat terjadi jika kueri terjadwal gagal karena kredensial yang sudah tidak berlaku, terutama saat membuat kueri data Google Drive.

Untuk mengatasi error ini, ikuti langkah-langkah berikut:

Kredensial akun layanan tidak valid

String error: HttpError 403 when requesting returned: The caller does not have permission

Error ini mungkin muncul saat Anda mencoba menyiapkan kueri terjadwal dengan akun layanan. Untuk mengatasi error ini, lihat langkah-langkah pemecahan masalah di Masalah otorisasi dan izin.

Waktu snapshot tidak valid

String error: Invalid snapshot time

Error ini dapat terjadi saat mencoba membuat kueri data historis yang berada di luar periode perjalanan waktu untuk set data tersebut. Untuk mengatasi error ini, ubah kueri untuk mengakses data historis dalam periode perjalanan waktu set data.

Error ini juga dapat muncul jika salah satu tabel yang digunakan dalam kueri dihapus dan dibuat ulang setelah kueri dimulai. Periksa apakah ada kueri terjadwal atau aplikasi yang melakukan operasi ini yang berjalan bersamaan dengan kueri yang gagal. Jika ada, coba pindahkan proses yang melakukan operasi lepas dan buat ulang agar dapat berjalan pada waktu yang tidak bertentangan dengan kueri yang membaca tabel tersebut.

Tugas sudah ada

String error: Already Exists: Job <job name>

Error ini dapat terjadi untuk tugas kueri yang harus mengevaluasi array besar, sehingga perlu waktu lebih lama dari rata-rata untuk membuat tugas kueri. Misalnya, kueri dengan klausa WHERE seperti WHERE column IN (<2000+ elements array>).

Untuk mengatasi error ini, ikuti langkah-langkah berikut:

Error ini juga dapat terjadi saat Anda menetapkan ID pekerjaan secara manual, tetapi pekerjaan tidak menampilkan keberhasilan dalam periode waktu tunggu. Dalam hal ini, Anda dapat menambahkan pengendali pengecualian untuk memeriksa apakah tugas ada. Jika ya, Anda dapat menarik hasil kueri dari tugas.

Tugas tidak ditemukan

String error: Job not found

Error ini dapat terjadi sebagai respons terhadap panggilan getQueryResults, jika tidak ada nilai yang ditentukan untuk kolom location. Jika demikian, coba panggilan lagi dan berikan nilai location.

Untuk mengetahui informasi selengkapnya, lihat Menghindari beberapa evaluasi Common Table Expressions (CTE) yang sama.

Lokasi tidak ditemukan

String error: Dataset [project_id]:[dataset_id] was not found in location [region]

Error ini muncul saat Anda merujuk ke resource set data yang tidak ada, atau jika lokasi dalam permintaan tidak cocok dengan lokasi set data.

Untuk mengatasi masalah ini, tentukan lokasi set data dalam kueri atau konfirmasi bahwa set data tersedia di lokasi yang sama.

Kueri melebihi batas waktu eksekusi

String error: Query fails due to reaching the execution time limit

Jika kueri Anda mencapai batas waktu eksekusi kueri, periksa waktu eksekusi kueri sebelumnya dengan membuat kueri tampilan INFORMATION_SCHEMA.JOBS dengan kueri yang mirip dengan contoh berikut:

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";

Jika kueri yang dijalankan sebelumnya memerlukan waktu yang jauh lebih singkat, gunakan analisis performa kueri untuk menentukan dan mengatasi masalah yang mendasarinya.

Kueri melebihi batas byte maksimum yang ditagih

String error: Query exceeded limit for bytes billed: LIMIT_BYTES. REQUIRED_BYTES or higher required.

Error HTTP 400 Bad Request (reason: bytesBilledLimitExceeded) ini terjadi saat perkiraan byte pra-eksekusi yang akan ditagih untuk kueri (REQUIRED_BYTES) melebihi batas byte yang dikonfigurasi di maximumBytesBilled (LIMIT_BYTES). BigQuery menggagalkan tugas sebelum eksekusi dan tidak mengenakan biaya untuk kueri.

Karena harga sesuai permintaan menerapkan minimum 10 MB (10,485,760 byte) per tabel yang direferensikan dan estimasi pra-eksekusi untuk tabel yang dikelompokkan menghitung batas atas di semua partisi yang cocok sebelum pemangkasan cluster terjadi, REQUIRED_BYTES dapat lebih tinggi daripada byte sebenarnya yang dipindai saat kueri berjalan.

Untuk menyelesaikan masalah ini, lakukan salah satu tindakan berikut:

  • Melihat pratinjau estimasi byte dengan uji coba. Jalankan uji coba (bq query --dry_run di bq CLI atau configuration.dryRun = true di API) atau periksa validator kueri di konsol Google Cloud untuk memeriksa totalBytesProcessed sebelum menjalankan kueri.
  • Optimalkan kueri untuk memindai lebih sedikit byte. Pilih hanya kolom yang diperlukan kueri Anda, bukan menjalankan SELECT *, dan filter pada kolom yang dipartisi sehingga BigQuery dapat memangkas partisi selama estimasi pra-eksekusi. Pemfilteran pada kolom yang dikelompokkan mengurangi byte sebenarnya yang ditagih saat kueri berjalan, tetapi tidak mengurangi estimasi batas atas pra-eksekusi yang diperiksa terhadap maximumBytesBilled. Untuk mengetahui informasi selengkapnya, lihat Mengurangi pemrosesan data.
  • Tingkatkan batas maximumBytesBilled. Tetapkan batas byte maximumBytesBilled ke nilai yang sama dengan atau di atas nilai REQUIRED_BYTES yang dilaporkan dalam pesan error menggunakan Maximum bytes billed (di bagian Query settings > Advanced options) di konsol Google Cloud , flag --maximum_bytes_billed di bq CLI, atau properti konfigurasi tugas configuration.query.maximumBytesBilled di API.

Respons kueri terlalu besar

String error: responseTooLarge

Error ini terjadi jika hasil kueri Anda lebih besar dari ukuran respons maksimum, atau jika satu baris melebihi batas ukuran baris REST API.

Beberapa kueri dijalankan dalam beberapa tahapan, dan error ini terjadi saat salah satu tahap menampilkan ukuran respons yang terlalu besar, meskipun hasil akhir lebih kecil dari maksimumnya. Error ini biasanya terjadi saat kueri menggunakan klausa ORDER BY. Menghapus klausa ORDER BY atau menambahkan klausa LIMIT terkadang dapat membantu. Untuk memastikan bahwa hasil yang besar dapat ditampilkan, tentukan tabel tujuan dalam konfigurasi tugas Anda. Untuk kueri legacy SQL, Anda juga harus menetapkan properti configuration.query.allowLargeResults ke true. Untuk informasi selengkapnya, lihat Menulis hasil kueri yang besar.

Batas ukuran respons satu baris terlampaui

String error:

  • 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

Error 403 Forbidden HTTP (reason: responseTooLarge) ini terjadi saat Anda membaca hasil kueri atau baris tabel menggunakan metode REST API jobs.getQueryResults atau tabledata.list (termasuk menampilkan hasil di konsol Google Cloud atau alat command line bq), dan satu baris yang tidak bertingkat dan diserialisasi melebihi ukuran baris maksimum yang didukung oleh endpoint penomoran halaman REST (20 MB untuk jobs.getQueryResults, atau 100 MB untuk tabledata.list). Hal ini biasanya terjadi pada tabel dengan skema lebar, kolom ARRAY atau STRUCT berulang yang sangat bertingkat, atau nilai STRING atau BYTES yang besar.

Untuk membaca baris yang melebihi batas ukuran baris REST API, lakukan salah satu hal berikut:

  • Gunakan BigQuery Storage Read API. Baca tabel atau tabel tujuan kueri sementara menggunakan Storage Read API, yang melakukan streaming data dalam format Apache Arrow atau Avro biner dan mendukung pembacaan throughput tinggi dari struktur baris yang besar dan kompleks.
  • Ekspor tabel ke Cloud Storage. Ekspor tabel atau hasil kueri ke Cloud Storage menggunakan pernyataan EXPORT DATA atau tugas ekstrak (misalnya, dalam format Avro, Parquet, atau JSON) dan baca file yang diekspor dari Cloud Storage.
  • Proyeksikan atau gabungkan lebih sedikit kolom. Daripada menjalankan SELECT *, pilih hanya kolom atau subkolom tertentu yang diperlukan oleh aplikasi Anda, atau batalkan pengelompokan array berulang dalam kueri Anda sehingga setiap baris output tetap berada di bawah batas ukuran.

Parameter yang diperlukan tidak ada

String error: Required parameter is missing: PARAMETER_NAME

Error HTTP 400 Bad Request (reason: required) ini adalah error validasi API pra-eksekusi yang terjadi saat kolom wajib diisi dalam payload atau URL permintaan API tidak diberikan, atau saat properti wajib diisi pada objek konfigurasi library klien adalah null atau None.

Untuk mengatasi error ini, lakukan hal berikut:

  • Periksa referensi REST API. Periksa PARAMETER_NAME dalam pesan error, dan tinjau isi permintaan dan parameter kueri yang diperlukan untuk metode tersebut di referensi BigQuery REST API untuk memastikan kode Anda mengisi semua kolom yang diperlukan.
  • Verifikasi parameter library klien. Jika Anda menggunakan library klien BigQuery (seperti library klien Java atau Python), periksa dokumentasi library klien untuk mengetahui parameter yang diperlukan dari metode yang Anda panggil.
  • Periksa objek konfigurasi sebelum memanggil API. Gunakan debugger atau laporan log untuk memeriksa objek konfigurasi tugas atau permintaan tepat sebelum panggilan API dijalankan, dan periksa nilai None atau null yang ditetapkan ke properti yang diperlukan seperti destinationTable.

Reservasi tidak ditemukan atau tidak memiliki slot

String error: Cannot run query: project does not have the reservation in the data region or no slots are configured

Error ini terjadi jika pemesanan yang ditetapkan ke project di region kueri tidak memiliki slot yang ditetapkan. Anda dapat menambahkan slot ke pemesanan, mengizinkan pemesanan menggunakan slot tidak ada aktivitas, menggunakan pemesanan lain, atau menghapus penetapan dan menjalankan kueri sesuai permintaan.

Tabel tidak ditemukan

String error: Not found: Table [project_id]:[dataset].[table_name] was not found in location [region]

Error ini terjadi jika tabel dalam kueri Anda tidak dapat ditemukan dalam set data atau region yang Anda tentukan. Untuk mengatasi error ini, lakukan hal berikut:

  • Pastikan kueri Anda berisi nama project, set data, dan tabel yang benar.
  • Pastikan tabel ada di region tempat Anda menjalankan kueri.
  • Pastikan tabel tidak dihapus dan dibuat ulang selama eksekusi tugas. Jika tidak, penyebaran metadata yang tidak lengkap dapat menyebabkan error ini.

Terlalu banyak pernyataan DML

String error: Too many DML statements outstanding against <table-name>, limit is 20

Error ini terjadi saat Anda melebihi batas 20 pernyataan DML yang bermutasi dalam status PENDING dalam antrean untuk satu tabel. Error ini biasanya terjadi saat Anda mengirimkan tugas DML terhadap satu tabel lebih cepat daripada yang dapat diproses BigQuery.

Untuk memeriksa tugas dalam status PENDING yang mengisi antrean bersama dengan tugas RUNNING yang mungkin memblokirnya agar tidak keluar dari antrean, buat kueri tampilan 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;

Salah satu solusi yang memungkinkan adalah mengelompokkan beberapa operasi DML yang lebih kecil ke dalam tugas yang lebih besar, tetapi lebih sedikit—misalnya, dengan mengelompokkan update dan penyisipan. Saat Anda mengelompokkan tugas yang lebih kecil ke dalam tugas yang lebih besar, biaya untuk menjalankan tugas yang lebih besar akan diamortisasi dan eksekusinya akan lebih cepat. Menggabungkan pernyataan DML yang memengaruhi data yang sama umumnya meningkatkan efisiensi tugas DML, dan cenderung tidak melebihi batas kuota ukuran antrean. Untuk mengetahui informasi selengkapnya tentang cara mengoptimalkan operasi DML, lihat Menghindari pernyataan DML yang memperbarui atau menyisipkan baris tunggal.

Solusi lain untuk meningkatkan efisiensi DML Anda adalah dengan mempartisi atau mengelompokkan tabel Anda. Untuk mengetahui informasi selengkapnya, baca Praktik terbaik.

Error 403 Quota Exceeded

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

Error ini terjadi jika jumlah total tugas DML (INSERT, UPDATE, DELETE, dan MERGE) yang menulis ke satu tabel—dalam status PENDING dan RUNNING—melebihi kuota konkurensi tabel.

Meskipun error limit is 20 secara khusus membatasi antrean PENDING untuk pernyataan DML yang bermutasi (UPDATE, DELETE, dan MERGE), error 403 Quota exceeded ini berlaku untuk total gabungan semua tugas DML (INSERT plus DML yang bermutasi) yang menulis ke tabel secara bersamaan. Karena DML yang bermutasi sudah dibatasi oleh batas antrean 20 tugas, error kuota 403 ini paling sering terjadi saat Anda mengirimkan terlalu banyak kueri INSERT serentak terhadap satu tabel. Untuk mengatasi error ini, lakukan hal berikut:

  • Tingkatkan Slot Pemesanan: Tingkatkan jumlah slot dalam pemesanan Anda untuk membantu tugas selesai lebih cepat dan mengurangi konkurensi tugas. Tindakan ini akan mengurangi jumlah tugas yang tertunda dalam antrean dan membantu menghindari tercapainya batas.
  • Optimalkan Orkestrasi Alur Kerja: Batasi jumlah tugas DML serentak di alat orkestrasi Anda untuk menghindari terlampauinya batas konkurensi tingkat tabel (termasuk kueri INSERT frekuensi tinggi yang menargetkan tabel yang sama).
  • Operasi DML Batch: Gabungkan beberapa pernyataan DML yang lebih kecil menjadi lebih sedikit pernyataan yang lebih besar untuk mengurangi jumlah total tugas yang diantrekan terhadap tabel.

Transaksi dibatalkan karena update serentak

String error: Transaction is aborted due to concurrent update against table [table_name]

Error ini dapat terjadi saat dua pernyataan DML yang bermutasi berbeda mencoba memperbarui tabel yang sama secara serentak. Misalnya, Anda memulai transaksi dalam sesi yang berisi pernyataan DML yang bermutasi, diikuti dengan error. Jika tidak ada pengendali pengecualian, BigQuery akan otomatis me-roll back transaksi saat sesi berakhir, yang memerlukan waktu hingga 24 jam. Selama waktu ini, upaya lain untuk menjalankan pernyataan DML bermutasi pada tabel akan gagal.

Untuk mengatasi error ini, cantumkan sesi aktif Anda dan periksa apakah ada yang berisi tugas kueri dengan status ERROR yang menjalankan pernyataan DML yang bermutasi pada tabel. Kemudian, hentikan sesi tersebut.

Error 412: Tugas mereferensikan tabel yang termasuk dalam set data failover

String error: 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.

Artinya, tugas tidak dijalankan di edisi BigQuery Enterprise Plus, atau tugas dijalankan di region selain lokasi utama set data failover. Lihat disaster recovery terkelola untuk mengetahui detail selengkapnya.

Terjadi error saat memuat tampilan saat menggunakan hasil yang di-cache

String error: 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.

Error ini menunjukkan bahwa ID pelanggan Google Workspace Anda belum diberi akses dalam batasan kebijakan organisasi Anda. Untuk mengetahui informasi tentang cara menggunakan batasan iam.allowedPolicyMemberDomains, lihat Menggunakan batasan iam.allowedPolicyMemberDomains untuk menerapkan berbagi yang dibatasi domain.

Error legacy SQL

Error berikut dapat muncul saat menggunakan legacy SQL.

Cannot be queried with legacy SQL

String error: cannot be queried with legacy SQL. Please consider switching to standard SQL

Error ini dapat terjadi dalam salah satu dari dua skenario:

  • Kueri ditulis dalam SQL standar, tetapi opsi untuk menggunakan legacy SQL secara eksplisit telah disediakan. Pastikan untuk menjalankan kueri Anda menggunakan SQL standar dengan mengikuti dokumentasi publik , misalnya, dengan menyediakan --use_legacy_sql=false menggunakan alat command line bq.

  • Anda mencoba membuat kueri tabel dengan pemeriksaan menggunakan legacy SQL, yang tidak didukung.

Tabel dengan kolom yang diganti namanya tidak dapat dikueri dengan legacy SQL

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

Error ini terjadi jika Anda mengkueri tabel dengan kolom yang diganti namanya menggunakan legacy SQL. Gunakan SQL standar sebagai gantinya.

Pengguna tidak memiliki izin

String error:

  • 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.

Error ini dapat terjadi saat Anda menjalankan kueri tanpa izin bigquery.jobs.create pada project tempat Anda menjalankan kueri, terlepas dari izin Anda pada project yang berisi data.

Anda juga dapat menerima error ini jika akun layanan, pengguna, atau grup Anda tidak memiliki izin bigquery.tables.getData pada semua tabel dan tampilan yang dirujuk oleh kueri Anda. Untuk mengetahui informasi selengkapnya tentang izin yang diperlukan untuk menjalankan kueri, lihat Peran yang diperlukan.

Error ini juga dapat terjadi jika tabel tidak ada di region yang dikueri, seperti asia-south1. Anda dapat memverifikasi region dengan memeriksa lokasi set data.

Saat mengatasi error ini, pertimbangkan hal berikut:

  • Akun layanan: Akun layanan harus memiliki izin bigquery.jobs.create pada project tempat akun tersebut dijalankan, dan harus memiliki izin bigquery.tables.getData pada semua tabel dan tampilan yang direferensikan oleh kueri.

  • Peran khusus: Peran IAM khusus harus memiliki izin bigquery.jobs.create yang disertakan secara eksplisit dalam peran yang relevan, dan harus memiliki izin bigquery.tables.getData pada semua tabel dan tampilan yang dirujuk oleh kueri.

  • Set data bersama: Saat menggunakan set data bersama dalam project terpisah, Anda mungkin masih memerlukan izin bigquery.jobs.create dalam project untuk menjalankan kueri atau tugas dalam set data tersebut.

Untuk memberikan izin akses ke tabel atau tampilan, lihat Memberikan akses ke tabel atau tampilan.

Izin bigquery.reservations.use ditolak pada pemesanan

String error:

  • 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)

Error ini terjadi saat kueri ditetapkan untuk dijalankan dalam pemesanan tertentu menggunakan pernyataan SET @@reservation dan pengguna atau akun layanan tidak memiliki izin bigquery.reservations.use. Anda dapat memeriksa kegagalan di Cloud Logging atau halaman tugas BigQuery untuk mengidentifikasi akun utama mana yang mencoba melakukan operasi ini.

Error Access Denied lainnya

String error:

  • 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

Untuk memecahkan masalah error Access Denied umum di BigQuery, gunakan Penganalisis Kebijakan untuk menentukan akses yang dimiliki akun utama pada resource.

Di Penganalisis Kebijakan, berikan resource BigQuery yang ingin Anda akses (misalnya, //bigquery.googleapis.com/projects/YOUR_PROJECT/datasets/YOUR_DATASET/tables/YOUR_TABLE) dan email pengguna atau akun layanan yang mendapatkan error Access Denied sebagai entitas. Analisis ini menunjukkan izin akun utama pada resource, yang dapat Anda bandingkan dengan izin yang tidak ada dalam pesan error.

Enkripsi tujuan tidak didukung untuk skrip

String error: configuration.query.destinationEncryptionConfiguration cannot be set for scripts

Error ini terjadi saat mencoba menetapkan konfigurasi enkripsi tujuan untuk tugas skrip BigQuery, yang tidak didukung.

Akses ditolak oleh kebijakan organisasi

String error: IAM setPolicy failed for Dataset DATASET: Operation denied by org policy on resource.

Error ini terjadi saat kebijakan organisasi mencegah akun utama mengkueri resource BigQuery. Layanan Kebijakan Organisasi memungkinkan Anda menerapkan batasan pada resource yang didukung di seluruh hierarki organisasi Anda.

Jika akun utama seharusnya memiliki akses ke resource, Anda harus menggunakan alat pemecahan masalah VPC yang tersedia untuk mendiagnosis masalah pada kebijakan organisasi Anda.

Masalah resource terlampaui

Masalah berikut terjadi saat BigQuery tidak memiliki resource yang cukup untuk menyelesaikan kueri Anda.

Kueri melebihi resource CPU

String error: 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.

Error ini (billingTierLimitExceeded) terjadi saat kueri yang menggunakan harga on-demand melebihi batas penggunaan CPU maksimum per data yang dipindai sekitar 256 detik CPU per MiB data yang dipindai. Hal ini terjadi saat kueri on-demand menjalankan operasi yang menggunakan banyak CPU—seperti operasi CROSS JOIN tanpa batasan, kondisi join yang tidak tepat, ekspresi reguler yang kompleks, fungsi jendela analisis yang tidak dipartisi, atau UDF JavaScript yang berat secara komputasi—pada jumlah data yang dipindai yang relatif kecil.

Untuk mengatasi error ini, lakukan salah satu tindakan berikut:

  • Optimalkan kueri. Lakukan refaktorisasi SQL Anda untuk mengurangi overhead komputasi yang terkait dengan data yang dipindai, seperti dengan menghapus Cartesian product yang tidak diinginkan (operasi CROSS JOIN tanpa pemfilteran), mengganti predikat join yang tidak tepat, menyederhanakan ekspresi reguler yang kompleks, menambahkan klausa PARTITION BY ke fungsi jendela pada jendela besar yang tidak dipartisi, atau mengoptimalkan UDF JavaScript. Untuk mengetahui informasi selengkapnya, lihat Menghindari pola anti-SQL, Pengantar pengoptimalan performa kueri, dan Memecahkan masalah resource yang melebihi batas.
  • Beralih ke harga berdasarkan kapasitas. Jalankan workload menggunakan harga berbasis kapasitas (slot). Dalam harga berbasis kapasitas, kueri tidak tunduk pada batas rasio CPU terhadap byte on-demand.

Kueri melebihi resource memori

String error: Resources exceeded during query execution: The query could not be executed in the allotted memory

Untuk pernyataan SELECT, error ini terjadi saat kueri menggunakan terlalu banyak resource. Untuk mengatasi error ini, lihat Memecahkan masalah resource melebihi batas.

Ruang stack habis

String error: Out of stack space due to deeply nested query expression during query resolution.

Error ini dapat terjadi jika kueri berisi terlalu banyak panggilan fungsi bertingkat. Terkadang, bagian kueri diterjemahkan ke panggilan fungsi selama penguraian. Misalnya, ekspresi dengan operator penyambungan berulang, seperti A || B || C || ..., menjadi CONCAT(A, CONCAT(B, CONCAT(C, ...))).

Untuk mengatasi error ini, tulis ulang kueri Anda untuk mengurangi jumlah bertingkat.

Resource terlampaui selama eksekusi kueri

String error: 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.

Hal ini dapat terjadi pada kueri ORDER BY ... LIMIT ... OFFSET .... Karena detail implementasi, pengurutan mungkin terjadi pada satu unit komputasi, yang dapat kehabisan memori jika perlu memproses terlalu banyak baris sebelum LIMIT dan OFFSET diterapkan, terutama dengan OFFSET yang besar.

Untuk mengatasi error ini, hindari nilai OFFSET yang besar dalam kueri ORDER BY ... LIMIT. Atau, gunakan fungsi jendela ROW_NUMBER() yang skalabel untuk menetapkan peringkat berdasarkan urutan yang dipilih, lalu filter peringkat ini dalam klausa WHERE. Contoh:

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

Worker TensorFlow kehabisan memori

String error: Resources exceeded during query execution: TensorFlow worker out of memory.

Model yang melebihi batas memori (biasanya 250 MB), terutama saat menggunakan fungsi yang memerlukan banyak resource seperti ML.EXPLAIN_PREDICT, dapat memicu error ini.

Untuk mengatasi error ini, lakukan hal berikut:

  1. Menggunakan model jarak jauh Gemini Enterprise Agent Platform: Untuk model yang melebihi batas memori, deploy model Anda ke Agent Platform menggunakan langkah-langkah Vertex AI SDK for Python untuk men-deploy model, lalu akses menggunakan model jarak jauh. Hal ini memindahkan persyaratan memori ke infrastruktur Agent Platform khusus.

  2. Optimalkan model: Kurangi jejak RAM model dengan menggunakan penyederhanaan, kuantisasi, atau pemangkasan arsitektur.

  3. Gunakan fungsi yang tidak terlalu intensif: Jika error terjadi selama panggilan ML.EXPLAIN_PREDICT, coba jalankan tugas dengan ML.PREDICT untuk menentukan apakah model dapat dijalankan tanpa overhead tambahan dari fitur penjelasan.

  4. Menganalisis ukuran data input: Baris individual yang besar dapat menyebabkan kehabisan memori. Periksa ukuran baris terbesar Anda menggunakan: 

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

Kueri melebihi resource shuffle

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

Error ini terjadi saat kueri tidak dapat mengakses resource acak yang memadai.

Untuk mengatasi error ini, sediakan lebih banyak slot atau kurangi jumlah data yang diproses oleh kueri. Untuk mengetahui informasi selengkapnya tentang cara melakukannya, lihat Kuota acak tidak memadai.

Jika menggunakan model harga on-demand, Anda dibatasi hingga maksimum 2.000 slot. Untuk meningkatkan jumlah slot, Anda harus beralih ke model harga berbasis kapasitas.

Untuk mengetahui informasi tambahan tentang cara menyelesaikan masalah ini, lihat Memecahkan masalah resource yang melebihi batas.

Kueri terlalu rumit

String error: Resources exceeded during query execution: Not enough resources for query planning - too many subqueries or query is too complex

Error ini terjadi jika kueri terlalu kompleks. Penyebab utama kompleksitas adalah:

  • Klausul WITH yang bertingkat banyak atau digunakan berulang kali.
  • Tampilan yang bertingkat banyak atau digunakan berulang kali.
  • Penggunaan berulang operator UNION ALL.

Untuk mengatasi error ini, coba opsi berikut:

  • Pisahkan kueri menjadi beberapa kueri, lalu gunakan bahasa prosedur untuk menjalankan kueri tersebut secara berurutan dengan status bersama.
  • Gunakan tabel sementara, bukan klausa WITH.
  • Tulis ulang kueri Anda untuk mengurangi jumlah objek yang direferensikan dan perbandingan.

Anda dapat memantau kueri yang mendekati batas kompleksitas secara proaktif menggunakan kolom query_info.resource_warning dalam tampilan INFORMATION_SCHEMA.JOBS. Contoh berikut menampilkan kueri dengan penggunaan resource yang tinggi selama tiga hari terakhir:

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

Untuk mengetahui informasi tambahan tentang cara menyelesaikan masalah ini, lihat Memecahkan masalah resource yang melebihi batas.

Memecahkan masalah resource yang melebihi batas

Untuk tugas kueri:

Untuk mengoptimalkan kueri Anda, coba langkah-langkah berikut:

  • Coba hapus klausa ORDER BY.
  • Jika kueri Anda menggunakan JOIN, pastikan tabel yang lebih besar berada di sisi kiri klausa. Pastikan juga data Anda tidak berisi kunci gabungan duplikat.
  • Jika kueri Anda menggunakan FLATTEN, tentukan apakah kueri ini diperlukan untuk kasus penggunaan Anda. Untuk informasi selengkapnya, lihat data bertingkat dan berulang.
  • Jika kueri Anda menggunakan EXACT_COUNT_DISTINCT, pertimbangkan untuk menggunakan COUNT(DISTINCT).
  • Jika kueri Anda menggunakan COUNT(DISTINCT <value>, <n>) dengan nilai <n> yang besar, sebaiknya gunakan GROUP BY. Untuk mengetahui informasi selengkapnya, lihat COUNT(DISTINCT).
  • Jika kueri Anda menggunakan UNIQUE, pertimbangkan untuk menggunakan GROUP BY, atau fungsi jendela di dalam subpilihan.
  • Jika kueri Anda mewujudkan banyak baris menggunakan klausa LIMIT, pertimbangkan untuk memfilter kolom lain, misalnya ROW_NUMBER(), atau menghapus klausa LIMIT sepenuhnya untuk memungkinkan paralelisasi penulisan.
  • Jika kueri Anda menggunakan tampilan bertingkat yang dalam dan klausa WITH, hal ini dapat menyebabkan pertumbuhan eksponensial dalam kompleksitas, sehingga mencapai batasnya.
  • Gunakan tabel sementara, bukan klausa WITH. Klausa WITH mungkin harus dihitung ulang beberapa kali, yang dapat membuat kueri menjadi kompleks dan lambat. Mempertahankan hasil perantara dalam tabel sementara justru mengurangi kompleksitas.
  • Hindari penggunaan kueri UNION ALL.
  • Jika kueri Anda menggunakan MATCH_RECOGNIZE, ubah klausa PARTITION BY untuk mengurangi ukuran partisi, atau tambahkan klausa PARTITION BY jika belum ada.

Untuk informasi selengkapnya, lihat referensi berikut:

Untuk tugas pemuatan:

Jika Anda memuat file Avro atau Parquet, kurangi ukuran baris dalam file. Periksa batasan ukuran tertentu untuk format file yang sedang Anda muat:

Jika Anda mendapatkan pesan error ini saat memuat file ORC, hubungi Dukungan.

Untuk Storage API:

String error: Stream memory usage exceeded

Selama panggilan ReadRows Storage Read API, beberapa aliran data dengan penggunaan memori yang tinggi mungkin mendapatkan error RESOURCE_EXHAUSTED dengan pesan ini. Hal ini dapat terjadi saat membaca dari tabel lebar atau tabel dengan skema yang kompleks. Sebagai penyelesaian, kurangi ukuran baris hasil dengan memilih lebih sedikit kolom untuk dibaca (menggunakan parameter selected_fields), atau dengan menyederhanakan skema tabel.

Memecahkan masalah konektivitas

Bagian berikut menjelaskan cara memecahkan masalah konektivitas saat mencoba berinteraksi dengan BigQuery:

Mengizinkan DNS Google

Gunakan alat Google IP Dig untuk me-resolve endpoint DNS BigQuery bigquery.googleapis.com ke satu IP data 'A'. Pastikan IP ini tidak diblokir di setelan firewall Anda.

Secara umum, sebaiknya izinkan nama DNS Google. Rentang IP yang dibagikan dalam file https://www.gstatic.com/ipranges/goog.json dan https://www.gstatic.com/ipranges/cloud.json sering berubah; oleh karena itu, sebaiknya izinkan nama DNS Google. Berikut daftar nama DNS umum yang sebaiknya ditambahkan ke daftar yang diizinkan:

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

Mengidentifikasi proxy atau firewall yang menghapus paket

Untuk mengidentifikasi semua hop paket antara klien dan Google Front End (GFE), jalankan perintah traceroute di komputer klien Anda yang dapat menandai server yang menghapus paket yang diarahkan ke GFE. Berikut adalah contoh perintah traceroute:

traceroute -T -p 443 bigquery.googleapis.com

Anda juga dapat mengidentifikasi hop paket untuk alamat IP GFE tertentu jika masalahnya terkait dengan alamat IP tertentu:

traceroute -T -p 443 142.250.178.138

Jika ada masalah waktu tunggu di sisi Google, Anda akan melihat permintaan tersebut sampai ke GFE.

Jika Anda melihat bahwa paket tidak pernah mencapai GFE, hubungi administrator jaringan Anda untuk menyelesaikan masalah ini.

Membuat file PCAP dan menganalisis firewall atau proxy Anda

Buat file pengambilan paket (PCAP) dan analisis file tersebut untuk memastikan firewall atau proxy tidak memfilter paket ke IP Google dan mengizinkan paket mencapai GFE.

Berikut adalah contoh perintah yang dapat dijalankan dengan alat tcpdump:

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

Menyiapkan percobaan ulang untuk masalah konektivitas yang terputus-putus

Ada situasi saat load balancer GFE mungkin menghentikan koneksi dari IP klien - misalnya, jika mendeteksi pola traffic DDoS, atau jika instance load balancer sedang diperkecil skalanya, yang dapat menyebabkan IP endpoint didaur ulang. Jika load balancer GFE menghentikan koneksi, klien harus menangkap permintaan yang waktu tunggunya habis dan mencoba lagi permintaan ke endpoint DNS. Pastikan Anda tidak menggunakan alamat IP yang sama hingga permintaan akhirnya berhasil, karena alamat IP mungkin telah berubah.

Jika Anda telah mengidentifikasi masalah terkait waktu tunggu yang konsisten di sisi Google dan percobaan ulang tidak membantu, hubungi Cloud Customer Care dan pastikan untuk menyertakan file PCAP baru yang dihasilkan dengan menjalankan alat penangkapan paket seperti tcpdump.

Langkah berikutnya