Amazon Redshift tidak akan lagi mendukung pembuatan Python UDFs baru mulai Patch 198. Python yang ada UDFs akan terus berfungsi hingga 30 Juni 2026. Untuk informasi lebih lanjut, lihat [posting blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Penyetelan kinerja kueri Amazon Redshift menggunakan kueri berdasarkan bahasa kueri terstruktur (SQL) untuk berinteraksi dengan data dan objek dalam sistem. Bahasa manipulasi data (DHTML) adalah bagian dari SQL yang Anda gunakan untuk melihat, menambah, mengubah, dan menghapus data. Data definition language (DDL) adalah bagian dari SQL yang Anda gunakan untuk menambah, mengubah, dan menghapus objek database seperti tabel dan tampilan. Setelah sistem Anda diatur, Anda biasanya bekerja dengan DHTML paling banyak, terutama [SELECT](r_SELECT_synopsis.md) perintah untuk mengambil dan melihat data. Untuk menulis kueri pengambilan data yang efektif di Amazon Redshift, kenali SELECT dan terapkan tip yang diuraikan [Praktik terbaik Amazon Redshift untuk mendesain tabel](c_designing-tables-best-practices.md) untuk memaksimalkan efisiensi kueri. Untuk memahami cara Amazon Redshift memproses kueri, gunakan bagian dan. [Pemrosesan kueri](c-query-processing.md) [Analisis dan peningkatan kueri](c-query-tuning.md) Kemudian Anda dapat menerapkan informasi ini dalam kombinasi dengan alat diagnostik untuk mengidentifikasi dan menghapus masalah dalam kinerja kueri. Untuk mengidentifikasi dan mengatasi beberapa masalah paling umum dan paling serius yang mungkin Anda temui dengan kueri Amazon Redshift, gunakan bagian ini. [Pemecahan masalah kueri](queries-troubleshooting.md) **Topics** + [Pemrosesan kueri](c-query-processing.md) + [Analisis dan peningkatan kueri](c-query-tuning.md) + [Pemecahan masalah kueri](queries-troubleshooting.md) # Pemrosesan kueri Amazon Redshift merutekan kueri SQL yang dikirimkan melalui parser dan pengoptimal untuk mengembangkan rencana kueri. Mesin eksekusi kemudian menerjemahkan rencana kueri ke dalam kode dan mengirimkan kode itu ke node komputasi untuk dieksekusi. **Topics** + [Perencanaan kueri dan alur kerja eksekusi](c-query-planning.md) + [Membuat dan menafsirkan rencana kueri](c-the-query-plan.md) + [Meninjau langkah-langkah rencana kueri](reviewing-query-plan-steps.md) + [Faktor-faktor yang mempengaruhi kinerja kueri](c-query-performance.md) # Perencanaan kueri dan alur kerja eksekusi Ilustrasi berikut memberikan tampilan tingkat tinggi dari alur kerja perencanaan dan eksekusi kueri. ![\[Alur kerja perencanaan dan eksekusi kueri untuk node pemimpin.\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/images/07-QueryPlanning.png) Alur kerja perencanaan dan eksekusi kueri mengikuti langkah-langkah berikut: 1. Node pemimpin menerima kueri dan mem-parsing SQL. 1. Parser menghasilkan pohon query awal yang merupakan representasi logis dari query asli. Amazon Redshift kemudian memasukkan pohon kueri ini ke pengoptimal kueri. 1. Pengoptimal mengevaluasi dan jika perlu menulis ulang kueri untuk memaksimalkan efisiensinya. Proses ini terkadang menghasilkan beberapa kueri terkait untuk menggantikan satu kueri. 1. Pengoptimal menghasilkan rencana kueri (atau beberapa, jika langkah sebelumnya menghasilkan beberapa kueri) untuk eksekusi dengan kinerja terbaik. Paket kueri menentukan opsi eksekusi seperti tipe gabungan, urutan gabungan, opsi agregasi, dan persyaratan distribusi data. Anda dapat menggunakan [EXPLAIN](r_EXPLAIN.md) perintah untuk melihat rencana kueri. Rencana kueri adalah alat mendasar untuk menganalisis dan menyetel kueri yang kompleks. Untuk informasi selengkapnya, lihat [Membuat dan menafsirkan rencana kueri](c-the-query-plan.md). 1. Mesin eksekusi menerjemahkan rencana kueri menjadi *langkah*, *segmen*, dan *aliran*: **Langkah** Setiap langkah adalah operasi individual yang diperlukan selama eksekusi kueri. Langkah-langkah dapat digabungkan untuk memungkinkan node komputasi melakukan kueri, bergabung, atau operasi database lainnya. **Segment** Kombinasi dari beberapa langkah yang dapat dilakukan oleh satu proses, juga unit kompilasi terkecil yang dapat dieksekusi oleh irisan node komputasi. *Slice* adalah unit pemrosesan paralel di Amazon Redshift. Segmen dalam aliran berjalan secara paralel. **Streaming** Kumpulan segmen yang akan dibagi di atas irisan node komputasi yang tersedia. Mesin eksekusi menghasilkan kode yang dikompilasi berdasarkan langkah, segmen, dan aliran. Kode yang dikompilasi berjalan lebih cepat daripada kode yang ditafsirkan dan menggunakan kapasitas komputasi yang lebih sedikit. Kode yang dikompilasi ini kemudian disiarkan ke node komputasi. **catatan** Saat membandingkan kueri Anda, Anda harus selalu membandingkan waktu untuk eksekusi kedua kueri, karena waktu eksekusi pertama mencakup overhead kompilasi kode. Untuk informasi selengkapnya, lihat [Faktor-faktor yang mempengaruhi kinerja kueri](c-query-performance.md). 1. Irisan node komputasi menjalankan segmen kueri secara paralel. Sebagai bagian dari proses ini, Amazon Redshift memanfaatkan komunikasi jaringan, memori, dan manajemen disk yang dioptimalkan untuk meneruskan hasil perantara dari satu langkah rencana kueri ke langkah berikutnya. Ini juga membantu mempercepat eksekusi kueri. Langkah 5 dan 6 terjadi sekali untuk setiap aliran. Mesin membuat segmen yang dapat dieksekusi untuk satu aliran dan mengirimkannya ke node komputasi. Ketika segmen aliran itu selesai, mesin menghasilkan segmen untuk aliran berikutnya. Dengan cara ini, mesin dapat menganalisis apa yang terjadi di aliran sebelumnya (misalnya, apakah operasi berbasis disk) untuk mempengaruhi generasi segmen di aliran berikutnya. Ketika node komputasi selesai, mereka mengembalikan hasil kueri ke node pemimpin untuk pemrosesan akhir. Node pemimpin menggabungkan data menjadi satu set hasil dan menangani penyortiran atau agregasi yang diperlukan. Node pemimpin kemudian mengembalikan hasilnya ke klien. **catatan** Node komputasi mungkin mengembalikan beberapa data ke node pemimpin selama eksekusi kueri jika perlu. Misalnya, jika Anda memiliki subquery dengan klausa LIMIT, limit diterapkan pada node pemimpin sebelum data didistribusikan kembali di seluruh cluster untuk diproses lebih lanjut. # Membuat dan menafsirkan rencana kueri Anda dapat menggunakan paket kueri untuk mendapatkan informasi tentang operasi individual yang diperlukan untuk menjalankan kueri. Sebelum Anda bekerja dengan paket kueri, sebaiknya Anda terlebih dahulu memahami cara Amazon Redshift menangani kueri pemrosesan dan membuat paket kueri. Untuk informasi selengkapnya, lihat [Perencanaan kueri dan alur kerja eksekusi](c-query-planning.md). Untuk membuat rencana kueri, jalankan [EXPLAIN](r_EXPLAIN.md) perintah diikuti oleh teks kueri yang sebenarnya. Paket kueri memberi Anda informasi berikut: + Operasi apa yang dilakukan mesin eksekusi, membaca hasil dari bawah ke atas. + Jenis langkah apa yang dilakukan setiap operasi. + Tabel dan kolom mana yang digunakan dalam setiap operasi. + Berapa banyak data yang diproses dalam setiap operasi, dalam hal jumlah baris dan lebar data dalam byte. + Biaya relatif operasi. *Biaya* adalah ukuran yang membandingkan waktu eksekusi relatif dari langkah-langkah dalam suatu rencana. Biaya tidak memberikan informasi yang tepat tentang waktu eksekusi aktual atau konsumsi memori, juga tidak memberikan perbandingan yang berarti antara rencana eksekusi. Itu memberi Anda indikasi operasi mana dalam kueri yang menghabiskan sumber daya paling banyak. Perintah EXPLOW tidak benar-benar menjalankan kueri. Ini hanya menunjukkan paket yang dijalankan Amazon Redshift jika kueri dijalankan dalam kondisi operasi saat ini. Jika Anda mengubah skema atau data untuk tabel dan menjalankannya [MENGANALISA](r_ANALYZE.md) lagi untuk memperbarui metadata statistik, rencana kueri mungkin berbeda. Output rencana kueri oleh EXPLOW adalah tampilan eksekusi kueri tingkat tinggi yang disederhanakan. Itu tidak menggambarkan detail pemrosesan query paralel. Untuk melihat informasi terperinci, jalankan kueri itu sendiri, lalu dapatkan informasi ringkasan kueri dari tampilan SVL\$1QUERY\$1SUMMARY atau SVL\$1QUERY\$1REPORT. Untuk informasi selengkapnya tentang menggunakan tampilan ini, lihat[Menganalisis ringkasan kueri](c-analyzing-the-query-summary.md). Contoh berikut menunjukkan output EXPLOW untuk query GROUP BY sederhana pada tabel EVENT: ``` explain select eventname, count(*) from event group by eventname; QUERY PLAN ------------------------------------------------------------------- XN HashAggregate (cost=131.97..133.41 rows=576 width=17) -> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=17) ``` EXPLORE mengembalikan metrik berikut untuk setiap operasi: **Biaya** Nilai relatif yang berguna untuk membandingkan operasi dalam rencana. Biaya terdiri dari dua nilai desimal yang dipisahkan oleh dua periode, misalnya. `cost=131.97..133.41` Nilai pertama, dalam hal ini 131,97, memberikan biaya relatif untuk mengembalikan baris pertama untuk operasi ini. Nilai kedua, dalam hal ini 133,41, memberikan biaya relatif untuk menyelesaikan operasi. Biaya dalam paket kueri bersifat kumulatif saat Anda membaca rencana, sehingga HashAggregate biaya dalam contoh ini (131,97.. 133,41) termasuk biaya Pemindaian Seq di bawahnya (0,00.87.98). **Baris** Perkiraan jumlah baris untuk kembali. Dalam contoh ini, pemindaian diharapkan mengembalikan 8798 baris. HashAggregate Operator sendiri diharapkan mengembalikan 576 baris (setelah nama peristiwa duplikat dibuang dari set hasil). Perkiraan baris didasarkan pada statistik yang tersedia yang dihasilkan oleh perintah ANALYZE. Jika ANALYSIS belum dijalankan baru-baru ini, estimasi kurang dapat diandalkan. **Lebar** Perkiraan lebar baris rata-rata, dalam byte. Dalam contoh ini, baris rata-rata diharapkan menjadi 17 byte lebar. ## JELASKAN operator Bagian ini menjelaskan secara singkat operator yang paling sering Anda lihat di output EXPLOW. Untuk daftar lengkap operator, lihat [EXPLAIN](r_EXPLAIN.md) di bagian Perintah SQL. ### Operator pemindaian berurutan Operator pemindaian sekuensial (Seq Scan) menunjukkan pemindaian tabel. Seq Scan memindai setiap kolom dalam tabel secara berurutan dari awal hingga akhir dan mengevaluasi kendala kueri (dalam klausa WHERE) untuk setiap baris. ### Bergabunglah dengan operator Amazon Redshift memilih operator gabungan berdasarkan desain fisik tabel yang digabungkan, lokasi data yang diperlukan untuk bergabung, dan persyaratan spesifik kueri itu sendiri. + **Loop Bersarang** Gabungan yang paling tidak optimal, loop bersarang digunakan terutama untuk cross-join (produk Cartesian) dan beberapa kesenjangan bergabung. + **Hash Bergabung dan Hash** Biasanya lebih cepat daripada gabungan loop bersarang, gabungan hash dan hash digunakan untuk gabungan dalam dan gabungan luar kiri dan kanan. Operator ini digunakan saat menggabungkan tabel di mana kolom gabungan bukan kunci distribusi *dan* kunci pengurutan. Operator hash membuat tabel hash untuk tabel bagian dalam di join; operator bergabung hash membaca tabel luar, hash kolom bergabung, dan menemukan kecocokan di tabel hash bagian dalam. + **Gabung Bergabung** Biasanya gabungan tercepat, gabungan gabungan digunakan untuk sambungan dalam dan gabungan luar. Gabungan gabungan tidak digunakan untuk bergabung penuh. Operator ini digunakan saat menggabungkan tabel di mana kolom gabungan adalah kunci distribusi *dan* kunci pengurutan, dan ketika kurang dari 20 persen tabel penggabungan tidak disortir. Ia membaca dua tabel yang diurutkan secara berurutan dan menemukan baris yang cocok. Untuk melihat persentase baris yang tidak disortir, kueri tabel [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md) sistem. + **Bergabung Spasial** Biasanya gabungan cepat berdasarkan kedekatan data spasial, digunakan untuk `GEOMETRY` dan tipe `GEOGRAPHY` data. ### Operator agregat Paket kueri menggunakan operator berikut dalam kueri yang melibatkan fungsi agregat dan operasi GROUP BY. + **Agregat** Operator untuk fungsi agregat skalar seperti AVG dan SUM. + **HashAggregate** Operator untuk fungsi agregat dikelompokkan yang tidak disortir. + **GroupAggregate** Operator untuk fungsi agregat dikelompokkan yang diurutkan. ### Mengurutkan operator Paket kueri menggunakan operator berikut ketika kueri harus mengurutkan atau menggabungkan kumpulan hasil. + **Urutkan** Mengevaluasi klausa ORDER BY dan operasi pengurutan lainnya, seperti jenis yang diperlukan oleh kueri dan gabungan UNION, kueri SELECT DISTINCT, dan fungsi jendela. + **Gabungkan** Menghasilkan hasil akhir yang diurutkan menurut hasil diurutkan antara yang berasal dari operasi paralel. ### UNION, INTERSECT, dan KECUALI operator Paket kueri menggunakan operator berikut untuk kueri yang melibatkan operasi set dengan UNION, INTERSECT, dan EXCEPT. + **Subkueri** Digunakan untuk menjalankan query UNION. + **Hash Intersect Berbeda** Digunakan untuk menjalankan query INTERSECT. + **SetOp Kecuali** Digunakan untuk menjalankan kueri KECUALI (atau MINUS). ### Operator lainnya Operator berikut juga sering muncul dalam output EXPLOW untuk kueri rutin. + **Unik** Menghapus duplikat untuk kueri SELECT DISTINCT dan kueri UNION. + **Batasi** Memproses klausa LIMIT. + **Jendela** Menjalankan fungsi jendela. + **Hasil** Menjalankan fungsi skalar yang tidak melibatkan akses tabel apa pun. + **Subrencana** Digunakan untuk subquery tertentu. + **Jaringan** Mengirim hasil antara ke node pemimpin untuk diproses lebih lanjut. + **Terwujud** Menyimpan baris untuk input ke gabungan loop bersarang dan beberapa gabungan gabungan. ## Bergabung dalam EXPLOW Pengoptimal kueri menggunakan jenis gabungan yang berbeda untuk mengambil data tabel, tergantung pada struktur kueri dan tabel yang mendasarinya. Output EXPLORE mereferensikan tipe gabungan, tabel yang digunakan, dan cara data tabel didistribusikan di seluruh cluster untuk menjelaskan bagaimana kueri diproses. ### Contoh tipe gabungan Contoh berikut menunjukkan berbagai jenis gabungan yang dapat digunakan oleh pengoptimal kueri. Jenis gabungan yang digunakan dalam rencana kueri tergantung pada desain fisik tabel yang terlibat. #### Contoh: Hash bergabung dengan dua tabel Kueri berikut bergabung dengan EVENT dan CATEGORY pada kolom CATID. CATID adalah kunci distribusi dan sortir untuk CATEGORY tetapi tidak untuk EVENT. Gabungan hash dilakukan dengan EVENT sebagai tabel luar dan CATEGORY sebagai tabel bagian dalam. Karena CATEGORY adalah tabel yang lebih kecil, perencana menyiarkan salinannya ke node komputasi selama pemrosesan kueri dengan menggunakan DS\$1BCAST\$1INNER. Biaya bergabung dalam contoh ini menyumbang sebagian besar biaya kumulatif paket. ``` explain select * from category, event where category.catid=event.catid; QUERY PLAN ------------------------------------------------------------------------- XN Hash Join DS_BCAST_INNER (cost=0.14..6600286.07 rows=8798 width=84) Hash Cond: ("outer".catid = "inner".catid) -> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=35) -> XN Hash (cost=0.11..0.11 rows=11 width=49) -> XN Seq Scan on category (cost=0.00..0.11 rows=11 width=49) ``` **catatan** Indentasi selaras untuk operator dalam output EXPLOW terkadang menunjukkan bahwa operasi tersebut tidak bergantung satu sama lain dan dapat dimulai secara paralel. Dalam contoh sebelumnya, meskipun pemindaian pada tabel EVENT dan operasi hash selaras, pemindaian EVENT harus menunggu sampai operasi hash selesai sepenuhnya. #### Contoh: Gabung bergabung dengan dua tabel Kueri berikut juga menggunakan SELECT \$1, tetapi bergabung dengan SALES dan LISTING pada kolom LISTID, di mana LISTID telah ditetapkan sebagai distribusi dan kunci pengurutan untuk kedua tabel. Gabungan gabungan dipilih, dan tidak diperlukan redistribusi data untuk join (DS\$1DIST\$1NONE). ``` explain select * from sales, listing where sales.listid = listing.listid; QUERY PLAN ----------------------------------------------------------------------------- XN Merge Join DS_DIST_NONE (cost=0.00..6285.93 rows=172456 width=97) Merge Cond: ("outer".listid = "inner".listid) -> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=44) -> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=53) ``` Contoh berikut menunjukkan berbagai jenis gabungan dalam query yang sama. Seperti pada contoh sebelumnya, SALES dan LISTING digabungkan, tetapi tabel ketiga, EVENT, harus hash bergabung dengan hasil gabungan gabungan. Sekali lagi, bergabung hash menimbulkan biaya siaran. ``` explain select * from sales, listing, event where sales.listid = listing.listid and sales.eventid = event.eventid; QUERY PLAN ---------------------------------------------------------------------------- XN Hash Join DS_BCAST_INNER (cost=109.98..3871130276.17 rows=172456 width=132) Hash Cond: ("outer".eventid = "inner".eventid) -> XN Merge Join DS_DIST_NONE (cost=0.00..6285.93 rows=172456 width=97) Merge Cond: ("outer".listid = "inner".listid) -> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=44) -> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=53) -> XN Hash (cost=87.98..87.98 rows=8798 width=35) -> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=35) ``` #### Contoh: Gabung, agregat, dan urutkan Kueri berikut menjalankan gabungan hash dari tabel SALES dan EVENT, diikuti oleh agregasi dan operasi pengurutan untuk memperhitungkan fungsi SUM yang dikelompokkan dan klausa ORDER BY. Operator pengurutan awal berjalan secara paralel pada node komputasi. Kemudian operator Jaringan mengirimkan hasilnya ke node pemimpin, di mana operator Merge menghasilkan hasil akhir yang diurutkan. ``` explain select eventname, sum(pricepaid) from sales, event where sales.eventid=event.eventid group by eventname order by 2 desc; QUERY PLAN --------------------------------------------------------------------------------- XN Merge (cost=1002815366604.92..1002815366606.36 rows=576 width=27) Merge Key: sum(sales.pricepaid) -> XN Network (cost=1002815366604.92..1002815366606.36 rows=576 width=27) Send to leader -> XN Sort (cost=1002815366604.92..1002815366606.36 rows=576 width=27) Sort Key: sum(sales.pricepaid) -> XN HashAggregate (cost=2815366577.07..2815366578.51 rows=576 width=27) -> XN Hash Join DS_BCAST_INNER (cost=109.98..2815365714.80 rows=172456 width=27) Hash Cond: ("outer".eventid = "inner".eventid) -> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=14) -> XN Hash (cost=87.98..87.98 rows=8798 width=21) -> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=21) ``` ### Redistribusi data Output EXPLOW untuk gabungan juga menentukan metode untuk bagaimana data dipindahkan di sekitar cluster untuk memfasilitasi penggabungan. Pergerakan data ini dapat berupa siaran atau redistribusi. Dalam siaran, nilai data dari satu sisi gabungan disalin dari setiap node komputasi ke setiap node komputasi lainnya, sehingga setiap node komputasi berakhir dengan salinan data yang lengkap. Dalam redistribusi, nilai data yang berpartisipasi dikirim dari irisan mereka saat ini ke irisan baru (mungkin pada node yang berbeda). Data biasanya didistribusikan ulang agar sesuai dengan kunci distribusi dari tabel lain yang berpartisipasi dalam gabungan jika kunci distribusi itu adalah salah satu kolom yang bergabung. Jika tidak satu pun dari tabel memiliki kunci distribusi pada salah satu kolom yang bergabung, baik kedua tabel didistribusikan atau tabel bagian dalam disiarkan ke setiap node. Output EXPLORE juga mereferensikan tabel dalam dan luar. Tabel bagian dalam dipindai terlebih dahulu, dan muncul lebih dekat di bagian bawah rencana kueri. Meja bagian dalam adalah meja yang diperiksa untuk korek api. Biasanya disimpan dalam memori, biasanya tabel sumber untuk hashing, dan jika mungkin, adalah tabel yang lebih kecil dari keduanya yang bergabung. Tabel luar adalah sumber baris untuk dicocokkan dengan meja bagian dalam. Biasanya dibaca dari disk. Pengoptimal kueri memilih tabel bagian dalam dan luar berdasarkan statistik database dari proses terbaru dari perintah ANALYZE. Urutan tabel dalam klausa FROM dari kueri tidak menentukan tabel mana yang dalam dan mana yang luar. Gunakan atribut berikut dalam rencana kueri untuk mengidentifikasi bagaimana data dipindahkan untuk memfasilitasi kueri: + **DS\$1BCAST\$1INNER** Salinan seluruh tabel bagian dalam disiarkan ke semua node komputasi. + **DS\$1DIST\$1ALL\$1NONE** Tidak diperlukan redistribusi, karena tabel bagian dalam telah didistribusikan ke setiap node menggunakan DISTYLE ALL. + **DS\$1DIST\$1TIDAK ADA** Tidak ada tabel yang didistribusikan kembali. Gabungan kolokasi dimungkinkan karena irisan yang sesuai digabungkan tanpa memindahkan data antar node. + **DS\$1DIST\$1INNER** Meja bagian dalam didistribusikan kembali. + **DS\$1DIST\$1OUTER** Tabel luar didistribusikan kembali. + **DS\$1DIST\$1ALL\$1INNER** Seluruh tabel bagian dalam didistribusikan kembali ke satu irisan karena tabel luar menggunakan DISTSTYLE ALL. + **DS\$1DIST\$1KEDUANYA** Kedua tabel didistribusikan kembali. # Meninjau langkah-langkah rencana kueri Anda dapat melihat langkah-langkah dalam rencana kueri dengan menjalankan perintah EXPLOW. Contoh berikut menunjukkan query SQL dan menjelaskan output. Membaca rencana query dari bawah ke atas, Anda dapat melihat setiap operasi logis yang digunakan untuk melakukan query. Untuk informasi selengkapnya, lihat [Membuat dan menafsirkan rencana kueri](c-the-query-plan.md). ``` explain select eventname, sum(pricepaid) from sales, event where sales.eventid = event.eventid group by eventname order by 2 desc; ``` ``` XN Merge (cost=1002815366604.92..1002815366606.36 rows=576 width=27) Merge Key: sum(sales.pricepaid) -> XN Network (cost=1002815366604.92..1002815366606.36 rows=576 width=27) Send to leader -> XN Sort (cost=1002815366604.92..1002815366606.36 rows=576 width=27) Sort Key: sum(sales.pricepaid) -> XN HashAggregate (cost=2815366577.07..2815366578.51 rows=576 width=27) -> XN Hash Join DS_BCAST_INNER (cost=109.98..2815365714.80 rows=172456 width=27) Hash Cond: ("outer".eventid = "inner".eventid) -> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=14) -> XN Hash (cost=87.98..87.98 rows=8798 width=21) -> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=21) ``` Sebagai bagian dari pembuatan rencana kueri, pengoptimal kueri memecah paket menjadi aliran, segmen, dan langkah. Pengoptimal kueri memecah rencana untuk mempersiapkan pendistribusian data dan beban kerja kueri ke node komputasi. Untuk informasi selengkapnya tentang aliran, segmen, dan langkah, lihat[Perencanaan kueri dan alur kerja eksekusi](c-query-planning.md). Ilustrasi berikut menunjukkan kueri sebelumnya dan rencana kueri terkait. Ini menampilkan bagaimana operasi kueri melibatkan peta ke langkah-langkah yang digunakan Amazon Redshift untuk menghasilkan kode yang dikompilasi untuk irisan node komputasi. Setiap operasi rencana kueri memetakan ke beberapa langkah dalam segmen, dan terkadang ke beberapa segmen dalam aliran. ![\[Kueri dan rencana kueri terkait dipetakan ke tiga aliran.\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/images/map-plan-to-streams.png) Dalam ilustrasi ini, pengoptimal kueri menjalankan rencana kueri sebagai berikut: 1. Di`Stream 0`, kueri berjalan `Segment 0` dengan operasi pemindaian sekuensial untuk memindai `events` tabel. Query berlanjut `Segment 1` dengan operasi hash untuk membuat tabel hash untuk tabel bagian dalam di join. 1. Di`Stream 1`, kueri berjalan `Segment 2` dengan operasi pemindaian sekuensial untuk memindai `sales` tabel. Ini berlanjut `Segment 2` dengan bergabung dengan hash untuk bergabung dengan tabel di mana kolom gabungan bukan kunci distribusi dan kunci pengurutan. Sekali lagi berlanjut `Segment 2` dengan agregat hash untuk mengumpulkan hasil. Kemudian kueri berjalan `Segment 3` dengan operasi agregat hash untuk melakukan fungsi agregat dikelompokkan yang tidak disortir, dan operasi pengurutan untuk mengevaluasi klausa ORDER BY dan operasi pengurutan lainnya. 1. Dalam`Stream 2`, kueri menjalankan operasi jaringan di `Segment 4` dan `Segment 5` untuk mengirim hasil antara ke node pemimpin untuk diproses lebih lanjut. Segmen terakhir dari query mengembalikan data. Jika set pengembalian dikumpulkan atau diurutkan, node komputasi masing-masing mengirim bagian hasil perantara mereka ke node pemimpin. Node pemimpin kemudian menggabungkan data sehingga hasil akhir dapat dikirim kembali ke klien yang meminta. Untuk informasi selengkapnya tentang operator EXPLORE, lihat[EXPLAIN](r_EXPLAIN.md). # Faktor-faktor yang mempengaruhi kinerja kueri Sejumlah faktor dapat mempengaruhi kinerja kueri. Aspek berikut dari operasi data, cluster, dan database Anda semuanya berperan dalam seberapa cepat proses kueri Anda. + **Jumlah node, prosesor, atau irisan** — Node komputasi dipartisi menjadi irisan. Lebih banyak node berarti lebih banyak prosesor dan lebih banyak irisan, yang memungkinkan kueri Anda memproses lebih cepat dengan menjalankan bagian kueri secara bersamaan di seluruh irisan. Namun, lebih banyak node juga berarti biaya yang lebih besar, jadi Anda perlu menemukan keseimbangan biaya dan kinerja yang sesuai untuk sistem Anda. Untuk informasi selengkapnya tentang arsitektur klaster Amazon Redshift, lihat. [Arsitektur sistem gudang data](c_high_level_system_architecture.md) + **Tipe node** — Cluster Amazon Redshift dapat menggunakan salah satu dari beberapa jenis node. Setiap jenis node menawarkan ukuran dan batasan yang berbeda untuk membantu Anda menskalakan klaster dengan tepat. Ukuran node menentukan kapasitas penyimpanan, memori, CPU, dan harga setiap node dalam cluster. Untuk informasi selengkapnya tentang jenis node, lihat [Ringkasan klaster Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#working-with-clusters-overview) di Panduan Manajemen Pergeseran Merah *Amazon*. + **Distribusi data** — Amazon Redshift menyimpan data tabel pada node komputasi sesuai dengan gaya distribusi tabel. Saat Anda menjalankan kueri, pengoptimal kueri mendistribusikan ulang data ke node komputasi sesuai kebutuhan untuk melakukan gabungan dan agregasi apa pun. Memilih gaya distribusi yang tepat untuk tabel membantu meminimalkan dampak langkah redistribusi dengan menemukan data di tempat yang diperlukan sebelum penggabungan dilakukan. Untuk informasi selengkapnya, lihat [Distribusi data untuk optimasi kueri](t_Distributing_data.md). + **Urutan pengurutan data** - Amazon Redshift menyimpan data tabel pada disk dalam urutan yang diurutkan sesuai dengan kunci pengurutan tabel. Pengoptimal kueri dan prosesor kueri menggunakan informasi tentang lokasi data untuk mengurangi jumlah blok yang perlu dipindai dan dengan demikian meningkatkan kecepatan kueri. Untuk informasi selengkapnya, lihat [Sortir kunci](t_Sorting_data.md). + **Ukuran set data** — Volume data yang lebih tinggi di cluster dapat memperlambat kinerja kueri untuk kueri, karena lebih banyak baris perlu dipindai dan didistribusikan kembali. Anda dapat mengurangi efek ini dengan menyedot debu dan pengarsipan data secara teratur, dan dengan menggunakan predikat untuk membatasi kumpulan data kueri. + **Operasi bersamaan** — Menjalankan beberapa operasi sekaligus dapat memengaruhi kinerja kueri. Setiap operasi mengambil satu atau lebih slot dalam antrian kueri yang tersedia dan menggunakan memori yang terkait dengan slot tersebut. Jika operasi lain berjalan, slot antrian kueri yang cukup mungkin tidak tersedia. Dalam hal ini, kueri harus menunggu slot terbuka sebelum dapat mulai diproses. Untuk informasi selengkapnya tentang membuat dan mengonfigurasi antrian kueri, lihat. [Manajemen beban kerja](cm-c-implementing-workload-management.md) + **Struktur kueri** — Bagaimana kueri Anda ditulis mempengaruhi kinerjanya. Sebisa mungkin, tulis kueri untuk memproses dan mengembalikan data sesedikit mungkin yang memenuhi kebutuhan Anda. Untuk informasi selengkapnya, lihat [Praktik terbaik Amazon Redshift untuk mendesain kueri](c_designing-queries-best-practices.md). + **Kompilasi kode** — Amazon Redshift menghasilkan dan mengkompilasi kode yang dioptimalkan untuk setiap rencana eksekusi kueri. Kode yang dikompilasi berjalan lebih cepat karena menghilangkan overhead menggunakan interpreter. Untuk meminimalkan latensi kueri baru sambil mempertahankan manfaat kinerja kode yang dikompilasi, Amazon Redshift menggunakan teknik yang disebut komposisi. Komposisi menghasilkan pengaturan ringan logika yang sudah ada sebelumnya untuk memproses kueri baru dengan segera, sambil secara bersamaan mengkompilasi kode khusus kueri yang sangat dioptimalkan di latar belakang. Ini menghapus kompilasi dari jalur kritis eksekusi kueri, sehingga kueri baru dimulai lebih cepat dan memberikan kinerja yang konsisten dengan proses berikutnya. Amazon Redshift juga menggunakan layanan kompilasi tanpa server untuk menskalakan kompilasi kueri di luar sumber daya komputasi klaster Amazon Redshift. Segmen kode yang dikompilasi di-cache baik secara lokal di cluster maupun dalam cache jarak jauh yang hampir tidak terbatas yang bertahan setelah reboot cluster. Eksekusi selanjutnya dari kueri yang sama berjalan lebih cepat karena mereka dapat melewati fase kompilasi. Dengan menggunakan layanan kompilasi yang dapat diskalakan, Amazon Redshift mengkompilasi kode secara paralel untuk memberikan kinerja yang cepat secara konsisten. # Analisis dan peningkatan kueri Mengambil informasi dari gudang data Amazon Redshift melibatkan menjalankan kueri kompleks pada data dalam jumlah yang sangat besar, yang dapat memakan waktu lama untuk diproses. Untuk memastikan bahwa kueri diproses secepat mungkin, ada sejumlah alat yang dapat Anda gunakan untuk mengidentifikasi potensi masalah kinerja. **Topics** + [Alur kerja analisis kueri](c-query-analysis-process.md) + [Meninjau peringatan kueri](c-reviewing-query-alerts.md) + [Menganalisis rencana kueri](c-analyzing-the-query-plan.md) + [Menganalisis ringkasan kueri](c-analyzing-the-query-summary.md) + [Peningkatan kinerja kueri](query-performance-improvement-opportunities.md) + [Kueri diagnostik untuk penyetelan kueri](diagnostic-queries-for-query-tuning.md) # Alur kerja analisis kueri Jika kueri membutuhkan waktu lebih lama dari yang diharapkan, gunakan langkah-langkah berikut untuk mengidentifikasi dan memperbaiki masalah yang mungkin berdampak negatif pada kinerja kueri. Jika Anda tidak yakin kueri apa di sistem Anda yang mungkin mendapat manfaat dari penyetelan kinerja, mulailah dengan menjalankan kueri diagnostik. [Mengidentifikasi kueri yang merupakan kandidat teratas untuk penyetelan](identify-queries-that-are-top-candidates-for-tuning.md) 1. Pastikan tabel Anda dirancang sesuai dengan praktik terbaik. Untuk informasi selengkapnya, lihat [Praktik terbaik Amazon Redshift untuk mendesain tabel](c_designing-tables-best-practices.md). 1. Lihat apakah Anda dapat menghapus atau mengarsipkan data yang tidak dibutuhkan di tabel Anda. Misalnya, kueri Anda selalu menargetkan data senilai 6 bulan terakhir tetapi Anda memiliki nilai 18 bulan terakhir di tabel Anda. Dalam hal ini, Anda dapat menghapus atau mengarsipkan data lama untuk mengurangi jumlah catatan yang harus dipindai dan didistribusikan. 1. Jalankan [VAKUM](r_VACUUM_command.md) perintah pada tabel dalam kueri untuk merebut kembali ruang dan mengurutkan ulang baris. Menjalankan VACUUM membantu jika wilayah yang tidak disortir besar dan kueri menggunakan kunci pengurutan dalam gabungan atau predikat. 1. Jalankan [MENGANALISA](r_ANALYZE.md) perintah pada tabel dalam kueri untuk memastikan bahwa statistik mutakhir. Menjalankan ANALYZE membantu jika salah satu tabel dalam kueri baru-baru ini banyak berubah ukurannya. Jika menjalankan perintah ANALYZE penuh akan memakan waktu terlalu lama, jalankan ANALYZE pada satu kolom untuk mengurangi waktu pemrosesan. Pendekatan ini masih memperbarui statistik ukuran tabel; ukuran tabel merupakan faktor penting dalam perencanaan kueri. 1. Pastikan bahwa kueri Anda telah dijalankan sekali untuk setiap jenis klien (berdasarkan jenis protokol koneksi apa yang digunakan klien) sehingga kueri dikompilasi dan di-cache. Pendekatan ini mempercepat proses kueri berikutnya. Untuk informasi selengkapnya, lihat [Faktor-faktor yang mempengaruhi kinerja kueri](c-query-performance.md). 1. Periksa [STL\$1ALERT\$1EVENT\$1LOG](r_STL_ALERT_EVENT_LOG.md) tabel untuk mengidentifikasi dan memperbaiki kemungkinan masalah dengan kueri Anda. Untuk informasi selengkapnya, lihat [Meninjau peringatan kueri](c-reviewing-query-alerts.md). 1. Jalankan [EXPLAIN](r_EXPLAIN.md) perintah untuk mendapatkan paket kueri dan gunakan untuk mengoptimalkan kueri. Untuk informasi selengkapnya, lihat [Menganalisis rencana kueri](c-analyzing-the-query-plan.md). 1. Gunakan [SVL\$1QUERY\$1SUMMARY](r_SVL_QUERY_SUMMARY.md) dan [SVL\$1QUERY\$1REPORT](r_SVL_QUERY_REPORT.md) tampilan untuk mendapatkan informasi ringkasan dan menggunakannya untuk mengoptimalkan kueri. Untuk informasi selengkapnya, lihat [Menganalisis ringkasan kueri](c-analyzing-the-query-summary.md). Terkadang kueri yang harus berjalan cepat dipaksa untuk menunggu hingga kueri lain yang berjalan lebih lama selesai. Dalam hal ini, Anda mungkin tidak memiliki apa pun untuk ditingkatkan dalam kueri itu sendiri, tetapi Anda dapat meningkatkan kinerja sistem secara keseluruhan dengan membuat dan menggunakan antrian kueri untuk berbagai jenis kueri. Untuk mendapatkan gambaran tentang waktu tunggu antrian untuk kueri Anda, lihat. [Meninjau waktu tunggu antrian untuk kueri](review-queue-wait-times-for-queries.md) Untuk informasi selengkapnya tentang mengonfigurasi antrian kueri, lihat. [Manajemen beban kerja](cm-c-implementing-workload-management.md) # Meninjau peringatan kueri Untuk menggunakan tabel [STL\$1ALERT\$1EVENT\$1LOG](r_STL_ALERT_EVENT_LOG.md) sistem untuk mengidentifikasi dan memperbaiki potensi masalah kinerja dengan kueri Anda, ikuti langkah-langkah berikut: 1. Jalankan berikut ini untuk menentukan ID kueri Anda: ``` select query, elapsed, substring from svl_qlog order by query desc limit 5; ``` Periksa teks kueri terpotong di `substring` bidang untuk menentukan `query` nilai mana yang akan dipilih. Jika Anda telah menjalankan kueri lebih dari sekali, gunakan `query` nilai dari baris dengan `elapsed` nilai yang lebih rendah. Itu adalah baris untuk versi yang dikompilasi. Jika Anda telah menjalankan banyak kueri, Anda dapat meningkatkan nilai yang digunakan oleh klausa LIMIT yang digunakan untuk memastikan bahwa kueri Anda disertakan. 1. Pilih baris dari STL\$1ALERT\$1EVENT\$1LOG untuk kueri Anda: ``` Select * from stl_alert_event_log where query = MyQueryID; ``` ![\[Contoh hasil kueri dari STL_ALERT_EVENT_LOG.\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/images/stl_alert_event_log_results.png) 1. Evaluasi hasil untuk kueri Anda. Gunakan tabel berikut untuk menemukan solusi potensial untuk masalah apa pun yang telah Anda identifikasi. **catatan** Tidak semua kueri memiliki baris di STL\$1ALERT\$1EVENT\$1LOG, hanya yang memiliki masalah yang diidentifikasi. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/c-reviewing-query-alerts.html) # Menganalisis rencana kueri Jalankan [EXPLAIN](r_EXPLAIN.md) perintah untuk mendapatkan rencana kueri. Sebelum menganalisis rencana kueri, Anda harus terbiasa dengan cara membacanya. Jika Anda tidak terbiasa membaca rencana kueri, kami sarankan Anda membaca [Membuat dan menafsirkan rencana kueri](c-the-query-plan.md) sebelum melanjutkan. Untuk menganalisis data yang disediakan oleh rencana kueri, ikuti langkah-langkah berikut: 1. Identifikasi langkah-langkah dengan biaya tertinggi. Berkonsentrasilah untuk mengoptimalkannya saat melanjutkan langkah-langkah yang tersisa. 1. Lihatlah jenis gabungannya: + **Nested Loop**: Gabungan seperti itu biasanya terjadi karena kondisi gabungan dihilangkan. Untuk solusi yang direkomendasikan, lihat[Loop Bersarang](query-performance-improvement-opportunities.md#nested-loop). + **Hash dan Hash Join: Gabungan** hash digunakan saat menggabungkan tabel di mana kolom gabungan bukan kunci distribusi dan juga bukan kunci pengurutan. Untuk solusi yang direkomendasikan, lihat[Hash bergabung](query-performance-improvement-opportunities.md#hash-join). + **Gabung Gabung**: Tidak diperlukan perubahan. 1. Perhatikan tabel mana yang digunakan untuk penggabungan bagian dalam, dan yang mana untuk gabungan luar. Mesin kueri umumnya memilih tabel yang lebih kecil untuk sambungan bagian dalam, dan tabel yang lebih besar untuk gabungan luar. Jika pilihan seperti itu tidak terjadi, statistik Anda kemungkinan sudah ketinggalan zaman. Untuk solusi yang direkomendasikan, lihat[Statistik tabel hilang atau kedaluwarsa](query-performance-improvement-opportunities.md#table-statistics-missing-or-out-of-date). 1. Lihat apakah ada operasi pengurutan berbiaya tinggi. Jika ada, lihat [Baris yang tidak disortir atau disortir](query-performance-improvement-opportunities.md#unsorted-or-mis-sorted-rows) solusi yang direkomendasikan. 1. Cari operator siaran berikut di mana ada operasi berbiaya tinggi: + **DS\$1BCAST\$1INNER**: Menunjukkan bahwa tabel disiarkan ke semua node komputasi. Ini bagus untuk meja kecil, tetapi tidak ideal untuk meja yang lebih besar. + **DS\$1DIST\$1ALL\$1INNER**: Menunjukkan bahwa semua beban kerja berada pada satu irisan. + **DS\$1DIST\$1BOTH: Menunjukkan redistribusi** berat. Untuk solusi yang direkomendasikan untuk situasi ini, lihat[Distribusi data suboptimal](query-performance-improvement-opportunities.md#suboptimal-data-distribution). # Menganalisis ringkasan kueri Untuk mendapatkan langkah-langkah eksekusi dan statistik secara lebih rinci daripada dalam rencana kueri yang [EXPLAIN](r_EXPLAIN.md) menghasilkan, gunakan tampilan [SVL\$1QUERY\$1SUMMARY](r_SVL_QUERY_SUMMARY.md) dan [SVL\$1QUERY\$1REPORT](r_SVL_QUERY_REPORT.md) sistem. SVL\$1QUERY\$1SUMMARY menyediakan statistik kueri berdasarkan aliran. Anda dapat menggunakan informasi yang diberikannya untuk mengidentifikasi masalah dengan langkah-langkah mahal, langkah-langkah yang berjalan lama, dan langkah-langkah yang menulis ke disk. Tampilan sistem SVL\$1QUERY\$1REPORT memungkinkan Anda melihat informasi yang mirip dengan itu untuk SVL\$1QUERY\$1SUMMARY, hanya dengan menghitung irisan simpul daripada berdasarkan aliran. Anda dapat menggunakan informasi tingkat irisan untuk mendeteksi distribusi data yang tidak merata di seluruh cluster (juga dikenal sebagai kemiringan distribusi data), yang memaksa beberapa node untuk melakukan lebih banyak pekerjaan daripada yang lain dan merusak kinerja kueri. **Topics** + [Menggunakan tampilan SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md) + [Menggunakan tampilan SVL\$1QUERY\$1REPORT](using-SVL-Query-Report.md) + [Memetakan rencana kueri ke ringkasan kueri](query-plan-summary-map.md) # Menggunakan tampilan SVL\$1QUERY\$1SUMMARY Untuk menganalisis informasi ringkasan kueri dengan streaming menggunakan[SVL\$1QUERY\$1SUMMARY](r_SVL_QUERY_SUMMARY.md), lakukan hal berikut: 1. Jalankan kueri berikut untuk menentukan ID kueri Anda: ``` select query, elapsed, substring from svl_qlog order by query desc limit 5; ``` Periksa teks kueri terpotong di `substring` bidang untuk menentukan `query` nilai mana yang mewakili kueri Anda. Jika Anda telah menjalankan kueri lebih dari sekali, gunakan `query` nilai dari baris dengan `elapsed` nilai yang lebih rendah. Itu adalah baris untuk versi yang dikompilasi. Jika Anda telah menjalankan banyak kueri, Anda dapat meningkatkan nilai yang digunakan oleh klausa LIMIT yang digunakan untuk memastikan bahwa kueri Anda disertakan. 1. Pilih baris dari SVL\$1QUERY\$1SUMMARY untuk kueri Anda. Urutkan hasil berdasarkan aliran, segmen, dan langkah: ``` select * from svl_query_summary where query = MyQueryID order by stm, seg, step; ``` Berikut ini adalah contoh hasil. ![\[Hasil sampel untuk baris di SVL_QUERY_SUMMARY yang cocok dengan kueri yang diberikan.\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/images/svl_query_summary_results.png) 1. Petakan langkah-langkah untuk operasi dalam rencana kueri menggunakan informasi di[Memetakan rencana kueri ke ringkasan kueri](query-plan-summary-map.md). Mereka harus memiliki nilai yang kira-kira sama untuk baris dan byte (baris \$1 lebar dari rencana kueri). Jika tidak, lihat solusi [Statistik tabel hilang atau kedaluwarsa](query-performance-improvement-opportunities.md#table-statistics-missing-or-out-of-date) yang direkomendasikan. 1. Lihat apakah `is_diskbased` bidang memiliki nilai `t` (true) untuk setiap langkah. Hash, agregat, dan sortir adalah operator yang cenderung menulis data ke disk jika sistem tidak memiliki cukup memori yang dialokasikan untuk pemrosesan kueri. Jika `is_diskbased` benar, lihat [Memori tidak cukup dialokasikan untuk kueri](query-performance-improvement-opportunities.md#insufficient-memory-allocated-to-the-query) solusi yang direkomendasikan. 1. Tinjau nilai `label` bidang dan lihat apakah ada AGG-DIST-AGG urutan di mana saja dalam langkah-langkahnya. Kehadirannya menunjukkan agregasi dua langkah, yang mahal. Untuk memperbaikinya, ubah klausa GROUP BY untuk menggunakan kunci distribusi (kunci pertama, jika ada beberapa kunci). 1. Tinjau `maxtime` nilai untuk setiap segmen (sama di semua langkah di segmen). Identifikasi segmen dengan `maxtime` nilai tertinggi dan tinjau langkah-langkah di segmen ini untuk operator berikut. **catatan** `maxtime`Nilai tinggi tidak selalu menunjukkan masalah dengan segmen. Meskipun nilainya tinggi, segmen ini mungkin tidak membutuhkan waktu lama untuk diproses. Semua segmen dalam aliran mulai diatur waktunya secara serempak. Namun, beberapa segmen hilir mungkin tidak dapat berjalan sampai mereka mendapatkan data dari segmen hulu. Efek ini mungkin membuat mereka tampak memakan waktu lama karena `maxtime` nilainya mencakup waktu tunggu dan waktu pemrosesan mereka. + **BCAST atau DIST**: Dalam kasus ini, `maxtime` nilai tinggi mungkin merupakan hasil dari mendistribusikan kembali sejumlah besar baris. Untuk solusi yang direkomendasikan, lihat[Distribusi data suboptimal](query-performance-improvement-opportunities.md#suboptimal-data-distribution). + **HJOIN (hash join)**: Jika langkah yang dimaksud memiliki nilai yang sangat tinggi di `rows` bidang dibandingkan dengan `rows` nilai pada langkah RETURN terakhir dalam kueri, lihat solusi yang [Hash bergabung](query-performance-improvement-opportunities.md#hash-join) direkomendasikan. + **SCAN/SORT**: Cari urutan langkah SCAN, SORT, SCAN, MERGE tepat sebelum langkah bergabung. Pola ini menunjukkan bahwa data yang tidak disortir sedang dipindai, diurutkan, dan kemudian digabungkan dengan area tabel yang diurutkan. Lihat apakah nilai baris untuk langkah SCAN memiliki nilai yang sangat tinggi dibandingkan dengan nilai baris pada langkah RETURN terakhir dalam kueri. Pola ini menunjukkan bahwa mesin eksekusi memindai baris yang kemudian dibuang, yang tidak efisien. Untuk solusi yang direkomendasikan, lihat[Predikat yang tidak cukup membatasi](query-performance-improvement-opportunities.md#insufficiently-restrictive-predicate). Jika `maxtime` nilai untuk langkah SCAN tinggi, lihat solusi yang [Klausa WHERE suboptimal](query-performance-improvement-opportunities.md#suboptimal-WHERE-clause) direkomendasikan. Jika `rows` nilai untuk langkah SORT bukan nol, lihat solusi yang [Baris yang tidak disortir atau disortir](query-performance-improvement-opportunities.md#unsorted-or-mis-sorted-rows) direkomendasikan. 1. Tinjau `rows` dan `bytes` nilai untuk 5-10 langkah yang mendahului langkah RETURN akhir untuk mendapatkan gambaran tentang jumlah data yang dikembalikan ke klien. Proses ini bisa menjadi sedikit seni. Misalnya, dalam ringkasan kueri contoh berikut, langkah PROJECT ketiga memberikan `rows` nilai, tetapi bukan `bytes` nilai. Dengan melihat melalui langkah-langkah sebelumnya untuk satu dengan `rows` nilai yang sama, Anda menemukan langkah SCAN yang menyediakan informasi baris dan byte. Berikut ini adalah hasil sampel. ![\[Baris dalam hasil ringkasan kueri yang merupakan langkah SCAN dengan informasi baris dan byte.\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/images/rows_and_bytes.png) Jika Anda mengembalikan volume data yang luar biasa besar, lihat solusi yang [Set hasil yang sangat besar](query-performance-improvement-opportunities.md#very-large-result-set) direkomendasikan. 1. Lihat apakah `bytes` nilainya relatif tinggi terhadap `rows` nilai untuk langkah apa pun, dibandingkan dengan langkah lain. Pola ini dapat menunjukkan bahwa Anda memilih banyak kolom. Untuk solusi yang direkomendasikan, lihat[Daftar SELECT besar](query-performance-improvement-opportunities.md#large-SELECT-list). # Menggunakan tampilan SVL\$1QUERY\$1REPORT Untuk menganalisis informasi ringkasan kueri dengan menggunakan slice[SVL\$1QUERY\$1REPORT](r_SVL_QUERY_REPORT.md), lakukan hal berikut: 1. Jalankan berikut ini untuk menentukan ID kueri Anda: ``` select query, elapsed, substring from svl_qlog order by query desc limit 5; ``` Periksa teks kueri terpotong di `substring` bidang untuk menentukan `query` nilai mana yang mewakili kueri Anda. Jika Anda telah menjalankan kueri lebih dari sekali, gunakan `query` nilai dari baris dengan `elapsed` nilai yang lebih rendah. Itu adalah baris untuk versi yang dikompilasi. Jika Anda telah menjalankan banyak kueri, Anda dapat meningkatkan nilai yang digunakan oleh klausa LIMIT yang digunakan untuk memastikan bahwa kueri Anda disertakan. 1. Pilih baris dari SVL\$1QUERY\$1REPORT untuk kueri Anda. Urutkan hasil berdasarkan segmen, langkah, elapsed\$1time, dan baris: ``` select * from svl_query_report where query = MyQueryID order by segment, step, elapsed_time, rows; ``` 1. Untuk setiap langkah, periksa untuk melihat bahwa semua irisan memproses kira-kira jumlah baris yang sama: ![\[Sebuah daftar irisan data yang digunakan untuk menjalankan query. Setiap irisan memproses kira-kira jumlah baris yang sama.\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/images/SVL_QUERY_REPORT_rows.png) Periksa juga untuk melihat bahwa semua irisan membutuhkan waktu yang kira-kira sama: ![\[Sebuah daftar irisan data yang digunakan untuk menjalankan query. Setiap irisan membutuhkan waktu yang kira-kira sama..\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/images/SVL_QUERY_REPORT_elapsed_time.png) Perbedaan besar dalam nilai-nilai ini dapat menunjukkan kemiringan distribusi data karena gaya distribusi suboptimal untuk kueri khusus ini. Untuk solusi yang direkomendasikan, lihat[Distribusi data suboptimal](query-performance-improvement-opportunities.md#suboptimal-data-distribution). # Memetakan rencana kueri ke ringkasan kueri Saat menganalisis ringkasan kueri, Anda bisa mendapatkan detail lebih lanjut dengan memetakan operasi dari rencana kueri ke langkah-langkah (diidentifikasi oleh nilai bidang label) dalam ringkasan kueri. Tabel berikut memetakan operasi rencana kueri ke langkah-langkah ringkasan kueri. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/query-plan-summary-map.html) # Peningkatan kinerja kueri Berikut ini adalah beberapa masalah umum yang memengaruhi kinerja kueri Amazon Redshift, dengan petunjuk tentang cara mendiagnosis dan menyelesaikannya. **Topics** + [Statistik tabel hilang atau kedaluwarsa](#table-statistics-missing-or-out-of-date) + [Loop Bersarang](#nested-loop) + [Hash bergabung](#hash-join) + [Baris hantu atau baris yang tidak terikat](#ghost-rows-or-uncommitted-rows) + [Baris yang tidak disortir atau disortir](#unsorted-or-mis-sorted-rows) + [Distribusi data suboptimal](#suboptimal-data-distribution) + [Memori tidak cukup dialokasikan untuk kueri](#insufficient-memory-allocated-to-the-query) + [Klausa WHERE suboptimal](#suboptimal-WHERE-clause) + [Predikat yang tidak cukup membatasi](#insufficiently-restrictive-predicate) + [Set hasil yang sangat besar](#very-large-result-set) + [Daftar SELECT besar](#large-SELECT-list) ## Statistik tabel hilang atau kedaluwarsa Jika statistik tabel hilang atau kedaluwarsa, Anda mungkin melihat yang berikut: + Pesan peringatan dalam hasil perintah EXPLORE. + Peristiwa peringatan statistik yang hilang di STL\$1ALERT\$1EVENT\$1LOG. Untuk informasi selengkapnya, lihat [Meninjau peringatan kueri](c-reviewing-query-alerts.md). Untuk memperbaiki masalah ini, jalankan[MENGANALISA](r_ANALYZE.md). ## Loop Bersarang Jika loop bersarang hadir, Anda mungkin melihat peristiwa peringatan loop bersarang di STL\$1ALERT\$1EVENT\$1LOG. Anda juga dapat mengidentifikasi jenis acara ini dengan menjalankan kueri di[Mengidentifikasi kueri dengan loop bersarang](identify-queries-with-nested-loops.md). Untuk informasi selengkapnya, lihat [Meninjau peringatan kueri](c-reviewing-query-alerts.md). Untuk memperbaikinya, tinjau kueri Anda untuk cross-join dan hapus jika memungkinkan. Cross-join adalah gabungan tanpa kondisi gabungan yang menghasilkan produk Cartesian dari dua tabel. Mereka biasanya dijalankan sebagai gabungan loop bersarang, yang merupakan jenis gabungan yang paling lambat. ## Hash bergabung Jika bergabung dengan hash hadir, Anda mungkin melihat yang berikut ini: + Hash dan hash bergabung dengan operasi dalam rencana kueri. Untuk informasi selengkapnya, lihat [Menganalisis rencana kueri](c-analyzing-the-query-plan.md). + Langkah HJOIN di segmen dengan nilai maxtime tertinggi di SVL\$1QUERY\$1SUMMARY. Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md). Untuk memperbaiki masalah ini, Anda dapat mengambil beberapa pendekatan: + Tulis ulang kueri untuk menggunakan gabungan gabungan jika memungkinkan. Anda dapat melakukan ini dengan menentukan kolom gabungan yang merupakan kunci distribusi dan kunci sortir. + Jika langkah HJOIN di SVL\$1QUERY\$1SUMMARY memiliki nilai yang sangat tinggi di bidang baris dibandingkan dengan nilai baris pada langkah RETURN terakhir dalam kueri, periksa apakah Anda dapat menulis ulang kueri untuk bergabung pada kolom unik. Ketika kueri tidak bergabung pada kolom unik, seperti kunci utama, itu meningkatkan jumlah baris yang terlibat dalam gabungan. ## Baris hantu atau baris yang tidak terikat Jika ada baris hantu atau baris yang tidak terikat, Anda mungkin melihat peristiwa peringatan di STL\$1ALERT\$1EVENT\$1LOG yang menunjukkan baris hantu yang berlebihan. Untuk informasi selengkapnya, lihat [Meninjau peringatan kueri](c-reviewing-query-alerts.md). Untuk memperbaiki masalah ini, Anda dapat mengambil beberapa pendekatan: + **Periksa tab Memuat konsol Amazon Redshift Anda untuk operasi pemuatan aktif di salah satu tabel kueri.** Jika Anda melihat operasi beban aktif, tunggu sampai selesai sebelum mengambil tindakan. + Jika tidak ada operasi pemuatan aktif, jalankan [VAKUM](r_VACUUM_command.md) pada tabel kueri untuk menghapus baris yang dihapus. ## Baris yang tidak disortir atau disortir Jika ada baris yang tidak disortir atau disortir, Anda mungkin melihat peristiwa peringatan filter yang sangat selektif di STL\$1ALERT\$1EVENT\$1LOG. Untuk informasi selengkapnya, lihat [Meninjau peringatan kueri](c-reviewing-query-alerts.md). Anda juga dapat memeriksa untuk melihat apakah ada tabel dalam kueri Anda memiliki area besar yang tidak disortir dengan menjalankan kueri di. [Mengidentifikasi tabel dengan data miring atau baris yang tidak disortir](identify-tables-with-data-skew-or-unsorted-rows.md) Untuk memperbaiki masalah ini, Anda dapat mengambil beberapa pendekatan: + Jalankan [VAKUM](r_VACUUM_command.md) pada tabel kueri untuk mengurutkan ulang baris. + Tinjau kunci pengurutan pada tabel kueri untuk melihat apakah ada perbaikan yang dapat dilakukan. Ingatlah untuk mempertimbangkan kinerja kueri ini terhadap kinerja kueri penting lainnya dan sistem secara keseluruhan sebelum membuat perubahan apa pun. Untuk informasi selengkapnya, lihat [Sortir kunci](t_Sorting_data.md). ## Distribusi data suboptimal Jika distribusi data kurang optimal, Anda mungkin melihat yang berikut: + Eksekusi serial, siaran besar, atau peristiwa peringatan distribusi besar muncul di STL\$1ALERT\$1EVENT\$1LOG. Untuk informasi selengkapnya, lihat [Meninjau peringatan kueri](c-reviewing-query-alerts.md). + Irisan tidak memproses kira-kira jumlah baris yang sama untuk langkah tertentu. Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\$1QUERY\$1REPORT](using-SVL-Query-Report.md). + Irisan tidak mengambil kira-kira jumlah waktu yang sama untuk langkah tertentu. Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\$1QUERY\$1REPORT](using-SVL-Query-Report.md). Jika tidak ada yang sebelumnya benar, Anda juga dapat melihat apakah salah satu tabel dalam kueri Anda memiliki kemiringan data dengan menjalankan kueri di. [Mengidentifikasi tabel dengan data miring atau baris yang tidak disortir](identify-tables-with-data-skew-or-unsorted-rows.md) Untuk memperbaiki masalah ini, tinjau gaya distribusi untuk tabel dalam kueri dan lihat apakah ada perbaikan yang dapat dilakukan. Ingatlah untuk mempertimbangkan kinerja kueri ini terhadap kinerja kueri penting lainnya dan sistem secara keseluruhan sebelum membuat perubahan apa pun. Untuk informasi selengkapnya, lihat [Distribusi data untuk optimasi kueri](t_Distributing_data.md). ## Memori tidak cukup dialokasikan untuk kueri Jika memori tidak cukup dialokasikan untuk kueri Anda, Anda mungkin melihat langkah di SVL\$1QUERY\$1SUMMARY yang memiliki nilai true. `is_diskbased` Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md). Untuk memperbaiki masalah ini, alokasikan lebih banyak memori ke kueri dengan meningkatkan sementara jumlah slot kueri yang digunakannya. Manajemen Beban Kerja (WLM) menyimpan slot dalam antrian kueri yang setara dengan tingkat konkurensi yang ditetapkan untuk antrian. Misalnya, antrian dengan level konkurensi 5 memiliki 5 slot. Memori yang ditugaskan ke antrian dialokasikan secara merata ke setiap slot. Menetapkan beberapa slot ke satu kueri memberikan akses kueri ke memori untuk semua slot tersebut. Untuk informasi lebih lanjut tentang cara meningkatkan slot sementara untuk kueri, lihat[wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md). ## Klausa WHERE suboptimal Jika klausa WHERE menyebabkan pemindaian tabel yang berlebihan, Anda mungkin melihat langkah SCAN di segmen dengan `maxtime` nilai tertinggi di SVL\$1QUERY\$1SUMMARY. Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md). Untuk memperbaiki masalah ini, tambahkan klausa WHERE ke kueri berdasarkan kolom pengurutan utama tabel terbesar. Pendekatan ini membantu meminimalkan waktu pemindaian. Untuk informasi selengkapnya, lihat [Praktik terbaik Amazon Redshift untuk mendesain tabel](c_designing-tables-best-practices.md). ## Predikat yang tidak cukup membatasi Jika kueri Anda memiliki predikat restriktif yang tidak memadai, Anda mungkin melihat langkah SCAN di segmen dengan `maxtime` nilai tertinggi di SVL\$1QUERY\$1SUMMARY yang memiliki nilai sangat tinggi dibandingkan dengan `rows` nilai pada langkah RETURN terakhir dalam `rows` kueri. Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md). Untuk memperbaiki masalah ini, coba tambahkan predikat ke kueri atau buat predikat yang ada lebih ketat untuk mempersempit output. ## Set hasil yang sangat besar Jika kueri Anda mengembalikan kumpulan hasil yang sangat besar, pertimbangkan untuk menulis ulang kueri yang akan digunakan [MEMBONGKAR](r_UNLOAD.md) untuk menulis hasil ke Amazon S3. Pendekatan ini meningkatkan kinerja langkah RETURN dengan memanfaatkan pemrosesan paralel. Untuk informasi lebih lanjut tentang memeriksa set hasil yang sangat besar, lihat[Menggunakan tampilan SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md). ## Daftar SELECT besar Jika kueri Anda memiliki daftar SELECT yang luar biasa besar, Anda mungkin melihat `bytes` nilai yang relatif tinggi terhadap nilai untuk langkah apa pun (dibandingkan dengan `rows` langkah lain) di SVL\$1QUERY\$1SUMMARY. `bytes`Nilai tinggi ini bisa menjadi indikator bahwa Anda memilih banyak kolom. Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md). Untuk memperbaiki masalah ini, tinjau kolom yang Anda pilih dan lihat apakah ada yang dapat dihapus. # Kueri diagnostik untuk penyetelan kueri Gunakan kueri berikut untuk mengidentifikasi masalah dengan kueri atau tabel dasar yang dapat memengaruhi kinerja kueri. Sebaiknya gunakan kueri ini dengan proses penyetelan kueri yang dibahas di. [Analisis dan peningkatan kueri](c-query-tuning.md) **catatan** Kueri ini untuk kluster yang disediakan Amazon Redshift. Kueri ini tidak untuk digunakan dengan grup kerja Redshift Serverless. **Topics** + [Mengidentifikasi kueri yang merupakan kandidat teratas untuk penyetelan](identify-queries-that-are-top-candidates-for-tuning.md) + [Mengidentifikasi tabel dengan data miring atau baris yang tidak disortir](identify-tables-with-data-skew-or-unsorted-rows.md) + [Mengidentifikasi kueri dengan loop bersarang](identify-queries-with-nested-loops.md) + [Meninjau waktu tunggu antrian untuk kueri](review-queue-wait-times-for-queries.md) + [Meninjau peringatan kueri berdasarkan tabel](review-query-alerts-by-table.md) + [Mengidentifikasi tabel dengan statistik yang hilang](identify-tables-with-missing-statistics.md) # Mengidentifikasi kueri yang merupakan kandidat teratas untuk penyetelan Kueri berikut mengidentifikasi 50 pernyataan paling memakan waktu teratas yang telah dijalankan dalam 7 hari terakhir. Anda dapat menggunakan hasilnya untuk mengidentifikasi kueri yang membutuhkan waktu yang sangat lama. Anda juga dapat mengidentifikasi kueri yang sering dijalankan (kueri yang muncul lebih dari sekali dalam kumpulan hasil). Kueri ini seringkali merupakan kandidat yang baik untuk penyetelan guna meningkatkan kinerja sistem. Kueri ini juga menyediakan hitungan peristiwa peringatan yang terkait dengan setiap kueri yang diidentifikasi. Peringatan ini memberikan detail yang dapat Anda gunakan untuk meningkatkan kinerja kueri. Untuk informasi selengkapnya, lihat [Meninjau peringatan kueri](c-reviewing-query-alerts.md). ``` select trim(database) as db, count(query) as n_qry, max(substring (qrytext,1,80)) as qrytext, min(run_minutes) as "min" , max(run_minutes) as "max", avg(run_minutes) as "avg", sum(run_minutes) as total, max(query) as max_query_id, max(starttime)::date as last_run, sum(alerts) as alerts, aborted from (select userid, label, stl_query.query, trim(database) as database, trim(querytxt) as qrytext, md5(trim(querytxt)) as qry_md5, starttime, endtime, (datediff(seconds, starttime,endtime)::numeric(12,2))/60 as run_minutes, alrt.num_events as alerts, aborted from stl_query left outer join (select query, 1 as num_events from stl_alert_event_log group by query ) as alrt on alrt.query = stl_query.query where userid <> 1 and starttime >= dateadd(day, -7, current_date)) group by database, label, qry_md5, aborted order by total desc limit 50; ``` # Mengidentifikasi tabel dengan data miring atau baris yang tidak disortir Kueri berikut mengidentifikasi tabel yang memiliki distribusi data yang tidak merata (data miring) atau persentase tinggi baris yang tidak disortir. `skew`Nilai rendah menunjukkan bahwa data tabel didistribusikan dengan benar. Jika tabel memiliki `skew` nilai 4,00 atau lebih tinggi, pertimbangkan untuk memodifikasi gaya distribusi datanya. Untuk informasi selengkapnya, lihat [Distribusi data suboptimal](query-performance-improvement-opportunities.md#suboptimal-data-distribution). Jika tabel memiliki `pct_unsorted` nilai lebih besar dari 20 persen, pertimbangkan untuk menjalankan [VAKUM](r_VACUUM_command.md) perintah. Untuk informasi selengkapnya, lihat [Baris yang tidak disortir atau disortir](query-performance-improvement-opportunities.md#unsorted-or-mis-sorted-rows). Juga tinjau `mbytes` dan `pct_of_total` nilai untuk setiap tabel. Kolom ini mengidentifikasi ukuran tabel dan berapa persentase ruang disk mentah yang dikonsumsi tabel. Ruang disk mentah mencakup ruang yang dicadangkan oleh Amazon Redshift untuk penggunaan internal, sehingga lebih besar dari kapasitas disk nominal, yang merupakan jumlah ruang disk yang tersedia untuk pengguna. Gunakan informasi ini untuk memverifikasi bahwa Anda memiliki ruang disk kosong sama dengan setidaknya 2,5 kali ukuran tabel terbesar Anda. Memiliki ruang ini memungkinkan sistem untuk menulis hasil perantara ke disk saat memproses kueri kompleks. ``` select trim(pgn.nspname) as schema, trim(a.name) as table, id as tableid, decode(pgc.reldiststyle,0, 'even',1,det.distkey ,8,'all') as distkey, dist_ratio.ratio::decimal(10,4) as skew, det.head_sort as "sortkey", det.n_sortkeys as "#sks", b.mbytes, decode(b.mbytes,0,0,((b.mbytes/part.total::decimal)*100)::decimal(5,2)) as pct_of_total, decode(det.max_enc,0,'n','y') as enc, a.rows, decode( det.n_sortkeys, 0, null, a.unsorted_rows ) as unsorted_rows , decode( det.n_sortkeys, 0, null, decode( a.rows,0,0, (a.unsorted_rows::decimal(32)/a.rows)*100) )::decimal(5,2) as pct_unsorted from (select db_id, id, name, sum(rows) as rows, sum(rows)-sum(sorted_rows) as unsorted_rows from stv_tbl_perm a group by db_id, id, name) as a join pg_class as pgc on pgc.oid = a.id join pg_namespace as pgn on pgn.oid = pgc.relnamespace left outer join (select tbl, count(*) as mbytes from stv_blocklist group by tbl) b on a.id=b.tbl inner join (select attrelid, min(case attisdistkey when 't' then attname else null end) as "distkey", min(case attsortkeyord when 1 then attname else null end ) as head_sort , max(attsortkeyord) as n_sortkeys, max(attencodingtype) as max_enc from pg_attribute group by 1) as det on det.attrelid = a.id inner join ( select tbl, max(mbytes)::decimal(32)/min(mbytes) as ratio from (select tbl, trim(name) as name, slice, count(*) as mbytes from svv_diskusage group by tbl, name, slice ) group by tbl, name ) as dist_ratio on a.id = dist_ratio.tbl join ( select sum(capacity) as total from stv_partitions where part_begin=0 ) as part on 1=1 where mbytes is not null order by mbytes desc; ``` # Mengidentifikasi kueri dengan loop bersarang Kueri berikut mengidentifikasi kueri yang memiliki peristiwa peringatan dicatat untuk loop bersarang. Untuk informasi tentang cara memperbaiki kondisi loop bersarang, lihat[Loop Bersarang](query-performance-improvement-opportunities.md#nested-loop). ``` select query, trim(querytxt) as SQL, starttime from stl_query where query in ( select distinct query from stl_alert_event_log where event like 'Nested Loop Join in the query plan%') order by starttime desc; ``` # Meninjau waktu tunggu antrian untuk kueri Kueri berikut menunjukkan berapa lama kueri terbaru menunggu slot terbuka dalam antrian kueri sebelum dijalankan. Jika Anda melihat tren waktu tunggu yang tinggi, Anda mungkin ingin mengubah konfigurasi antrian kueri Anda untuk throughput yang lebih baik. Untuk informasi selengkapnya, lihat [Menerapkan manual WLM](cm-c-defining-query-queues.md). ``` select trim(database) as DB , w.query, substring(q.querytxt, 1, 100) as querytxt, w.queue_start_time, w.service_class as class, w.slot_count as slots, w.total_queue_time/1000000 as queue_seconds, w.total_exec_time/1000000 exec_seconds, (w.total_queue_time+w.total_Exec_time)/1000000 as total_seconds from stl_wlm_query w left join stl_query q on q.query = w.query and q.userid = w.userid where w.queue_start_Time >= dateadd(day, -7, current_Date) and w.total_queue_Time > 0 and w.userid >1 and q.starttime >= dateadd(day, -7, current_Date) order by w.total_queue_time desc, w.queue_start_time desc limit 35; ``` # Meninjau peringatan kueri berdasarkan tabel Kueri berikut mengidentifikasi tabel yang memiliki peristiwa peringatan yang dicatat untuk mereka, dan juga mengidentifikasi jenis peringatan apa yang paling sering muncul. Jika `minutes` nilai untuk baris dengan tabel yang diidentifikasi tinggi, periksa tabel tersebut untuk melihat apakah perlu pemeliharaan rutin, seperti memiliki [MENGANALISA](r_ANALYZE.md) atau [VAKUM](r_VACUUM_command.md) menjalankannya. Jika `count` nilainya tinggi untuk sebuah baris tetapi `table` nilainya nol, jalankan kueri terhadap STL\$1ALERT\$1EVENT\$1LOG untuk `event` nilai terkait guna menyelidiki mengapa peringatan itu sering muncul. ``` select trim(s.perm_table_name) as table, (sum(abs(datediff(seconds, s.starttime, s.endtime)))/60)::numeric(24,0) as minutes, trim(split_part(l.event,':',1)) as event, trim(l.solution) as solution, max(l.query) as sample_query, count(*) from stl_alert_event_log as l left join stl_scan as s on s.query = l.query and s.slice = l.slice and s.segment = l.segment and s.step = l.step where l.event_time >= dateadd(day, -7, current_Date) group by 1,3,4 order by 2 desc,6 desc; ``` # Mengidentifikasi tabel dengan statistik yang hilang Kueri berikut memberikan hitungan kueri yang Anda jalankan terhadap tabel yang tidak memiliki statistik. Jika query ini mengembalikan baris apapun, melihat `plannode` nilai untuk menentukan tabel terpengaruh, dan kemudian berjalan [MENGANALISA](r_ANALYZE.md) di atasnya. ``` select substring(trim(plannode),1,100) as plannode, count(*) from stl_explain where plannode like '%missing statistics%' group by plannode order by 2 desc; ``` # Pemecahan masalah kueri Bagian ini memberikan referensi cepat untuk mengidentifikasi dan mengatasi beberapa masalah paling umum dan paling serius yang mungkin Anda temui dengan kueri Amazon Redshift. **Topics** + [Koneksi gagal](queries-troubleshooting-connection-fails.md) + [Kueri hang](queries-troubleshooting-query-hangs.md) + [Query membutuhkan waktu terlalu lama](queries-troubleshooting-query-takes-too-long.md) + [Beban gagal](queries-troubleshooting-load-fails.md) + [Beban memakan waktu terlalu lama](queries-troubleshooting-load-takes-too-long.md) + [Memuat data tidak benar](queries-troubleshooting-load-data-incorrect.md) + [Mengatur parameter ukuran pengambilan JDBC](set-the-JDBC-fetch-size-parameter.md) Saran ini memberi Anda titik awal untuk pemecahan masalah. Anda juga dapat merujuk ke sumber daya berikut untuk informasi lebih rinci. Untuk informasi tentang perubahan perilaku dalam fungsionalitas Amazon Redshift yang dapat memengaruhi aplikasi Anda, lihat Perubahan [Perilaku](https://docs.aws.amazon.com/redshift/latest/mgmt/behavior-changes.html). + [Mengakses cluster dan database Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/using-rs-tools.html) + [Optimalisasi tabel otomatis](t_Creating_tables.md) + [Memuat data di Amazon Redshift](t_Loading_data.md) + [Tutorial: Memuat data dari Amazon S3](tutorial-loading-data.md) # Koneksi gagal Koneksi kueri Anda dapat gagal karena alasan berikut. Kami menyarankan pendekatan pemecahan masalah berikut. **Klien tidak dapat terhubung ke server** Jika Anda menggunakan sertifikat SSL atau server, pertama-tama hapus kompleksitas ini saat Anda memecahkan masalah koneksi. Kemudian tambahkan sertifikat SSL atau server kembali ketika Anda telah menemukan solusi. Untuk informasi selengkapnya, buka [Konfigurasi Opsi Keamanan untuk Koneksi](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html) di *Panduan Manajemen Amazon Redshift*. **Koneksi ditolak** Umumnya, ketika Anda menerima pesan kesalahan yang menunjukkan bahwa ada kegagalan untuk membuat koneksi, itu berarti bahwa ada masalah dengan izin untuk mengakses cluster. Untuk informasi lebih lanjut, buka [Koneksi ditolak atau gagal](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-refusal-failure-issues.html) di Panduan *Manajemen Pergeseran Merah Amazon*. # Kueri hang Kueri Anda dapat menggantung, atau berhenti merespons, karena alasan berikut. Kami menyarankan pendekatan pemecahan masalah berikut. **Koneksi ke database terputus** Kurangi ukuran unit transmisi maksimum (MTU). Ukuran MTU menentukan ukuran maksimum, dalam byte, dari paket yang dapat ditransfer dalam satu bingkai Ethernet melalui koneksi jaringan Anda. Untuk informasi selengkapnya, buka [Koneksi ke database dijatuhkan](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-drop-issues.html) di Panduan *Manajemen Pergeseran Merah Amazon*. **Waktu koneksi ke database habis** Koneksi klien Anda ke database tampaknya hang atau time out saat menjalankan kueri panjang, seperti perintah COPY. Dalam kasus ini, Anda mungkin mengamati bahwa konsol Amazon Redshift menampilkan bahwa kueri telah selesai, tetapi alat klien itu sendiri tampaknya masih menjalankan kueri. Hasil kueri mungkin hilang atau tidak lengkap tergantung kapan koneksi berhenti. Efek ini terjadi ketika koneksi idle diakhiri oleh komponen jaringan perantara. Untuk informasi selengkapnya, buka [Masalah Timeout Firewall](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-firewall-guidance.html) di Panduan *Manajemen Amazon Redshift*. **out-of-memoryKesalahan sisi klien terjadi dengan ODBC** Jika aplikasi klien Anda menggunakan koneksi ODBC dan kueri Anda membuat kumpulan hasil yang terlalu besar untuk dimasukkan ke dalam memori, Anda dapat mengalirkan hasil yang disetel ke aplikasi klien Anda dengan menggunakan kursor. Untuk informasi selengkapnya, lihat [MENYATAKAN](declare.md) dan [Pertimbangan kinerja saat menggunakan kursor](declare.md#declare-performance). **out-of-memoryKesalahan sisi klien terjadi dengan JDBC** Saat Anda mencoba mengambil set hasil besar melalui koneksi JDBC, Anda mungkin mengalami kesalahan sisi klien. out-of-memory Untuk informasi selengkapnya, lihat [Mengatur parameter ukuran pengambilan JDBC](set-the-JDBC-fetch-size-parameter.md). **Ada potensi kebuntuan** Jika ada potensi kebuntuan, coba yang berikut ini: + Lihat tabel [STV\$1LOCKS](r_STV_LOCKS.md) dan [STL\$1TR\$1CONFLICT](r_STL_TR_CONFLICT.md) sistem untuk menemukan konflik yang melibatkan pembaruan ke lebih dari satu tabel. + Gunakan [PG\$1CANCEL\$1BACKEND](PG_CANCEL_BACKEND.md) fungsi untuk membatalkan satu atau beberapa kueri yang saling bertentangan. + Gunakan [PG\$1TERMINATE\$1BACKEND](PG_TERMINATE_BACKEND.md) fungsi untuk mengakhiri sesi, yang memaksa setiap transaksi yang sedang berjalan di sesi yang dihentikan untuk melepaskan semua kunci dan memutar kembali transaksi. + Jadwalkan operasi tulis bersamaan dengan hati-hati. Untuk informasi selengkapnya, lihat [Mengelola operasi tulis bersamaan](c_Concurrent_writes.md). # Query membutuhkan waktu terlalu lama Permintaan Anda bisa memakan waktu terlalu lama karena alasan berikut. Kami menyarankan pendekatan pemecahan masalah berikut. **Tabel tidak dioptimalkan** Atur kunci sortir, gaya distribusi, dan pengkodean kompresi tabel untuk memanfaatkan sepenuhnya pemrosesan paralel. Untuk informasi selengkapnya, lihat [Optimalisasi tabel otomatis](t_Creating_tables.md) **Query menulis ke disk** Kueri Anda mungkin menulis ke disk untuk setidaknya sebagian dari eksekusi kueri. Untuk informasi selengkapnya, lihat [Peningkatan kinerja kueri](query-performance-improvement-opportunities.md). **Kueri harus menunggu kueri lain selesai** Anda mungkin dapat meningkatkan kinerja sistem secara keseluruhan dengan membuat antrian kueri dan menetapkan berbagai jenis kueri ke antrian yang sesuai. Untuk informasi selengkapnya, lihat [Manajemen beban kerja](cm-c-implementing-workload-management.md). **Kueri tidak dioptimalkan** Analisis rencana penjelasan untuk menemukan peluang untuk menulis ulang kueri atau mengoptimalkan database. Untuk informasi selengkapnya, lihat [Membuat dan menafsirkan rencana kueri](c-the-query-plan.md). **Kueri membutuhkan lebih banyak memori untuk dijalankan** Jika kueri tertentu membutuhkan lebih banyak memori, Anda dapat meningkatkan memori yang tersedia dengan meningkatkan[wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md). **Database membutuhkan perintah VACUUM untuk dijalankan** Jalankan perintah VACUUM setiap kali Anda menambahkan, menghapus, atau memodifikasi sejumlah besar baris, kecuali jika Anda memuat data Anda dalam urutan kunci sortir. Perintah VACUUM mengatur ulang data Anda untuk mempertahankan urutan pengurutan dan memulihkan kinerja. Untuk informasi selengkapnya, lihat [Tabel penyedot debu](t_Reclaiming_storage_space202.md). ## Sumber daya tambahan untuk memecahkan masalah kueri yang berjalan lama Berikut ini adalah topik tampilan sistem dan bagian dokumentasi lainnya yang berguna untuk penyetelan kueri: + Tampilan [STV\$1DALAM PENERBANGAN](r_STV_INFLIGHT.md) sistem menunjukkan kueri mana yang berjalan di cluster. Akan sangat membantu untuk menggunakannya bersama [STV\$1TERBARU](r_STV_RECENTS.md) untuk menentukan kueri mana yang sedang berjalan atau baru saja selesai. + [SYS\$1QUERY\$1HISTORY](SYS_QUERY_HISTORY.md)berguna untuk pemecahan masalah. Ini menunjukkan kueri DDL dan DMLdengan properti yang relevan seperti statusnya saat ini, seperti `running` atau`failed`, waktu yang dibutuhkan masing-masing untuk dijalankan, dan apakah kueri dijalankan pada cluster penskalaan konkurensi. + [STL\$1QUERYTEXT](r_STL_QUERYTEXT.md)menangkap teks kueri untuk perintah SQL. Selain itu[SVV\$1QUERY\$1DALAM PENERBANGAN](r_SVV_QUERY_INFLIGHT.md), yang menggabungkan STL\$1QUERYTEXT ke STV\$1INFLIGHT, menampilkan lebih banyak metadata kueri. + Konflik kunci transaksi dapat menjadi kemungkinan sumber masalah kinerja kueri. Untuk informasi tentang transaksi yang saat ini menyimpan kunci pada tabel, lihat[SVV\$1TRANSAKSI-TRANSAKSI](r_SVV_TRANSACTIONS.md). + [Mengidentifikasi kueri yang merupakan kandidat teratas untuk penyetelan](https://docs.aws.amazon.com/redshift/latest/dg/diagnostic-queries-for-query-tuning.html#identify-queries-that-are-top-candidates-for-tuning) memberikan kueri pemecahan masalah yang membantu Anda menentukan kueri mana yang baru-baru ini dijalankan paling memakan waktu. Ini dapat membantu Anda memfokuskan upaya Anda pada pertanyaan yang perlu diperbaiki. + Jika Anda ingin menjelajahi manajemen kueri lebih lanjut dan memahami cara mengelola antrian kueri, [Manajemen beban kerja](cm-c-implementing-workload-management.md) tunjukkan cara melakukannya. Manajemen beban kerja adalah fitur canggih dan kami merekomendasikan manajemen beban kerja otomatis dalam banyak kasus. # Beban gagal Beban data Anda dapat gagal karena alasan berikut. Kami menyarankan pendekatan pemecahan masalah berikut. **Sumber Data berada di AWS Wilayah yang berbeda** Secara default, bucket Amazon S3 atau tabel Amazon DynamoDB yang ditentukan dalam perintah COPY harus berada di Wilayah yang sama dengan cluster. AWS Jika data dan klaster Anda berada di Wilayah yang berbeda, Anda menerima kesalahan yang mirip dengan berikut ini: ``` The bucket you are attempting to access must be addressed using the specified endpoint. ``` Jika memungkinkan, pastikan klaster dan sumber data Anda berada di Wilayah yang sama. Anda dapat menentukan Wilayah yang berbeda dengan menggunakan [REGION](copy-parameters-data-source-s3.md#copy-region) opsi dengan perintah COPY. **catatan** Jika cluster dan sumber data Anda berada di AWS Wilayah yang berbeda, Anda akan dikenakan biaya transfer data. Anda juga memiliki latensi yang lebih tinggi. **Perintah COPY gagal** Kueri STL\$1LOAD\$1ERRORS untuk menemukan kesalahan yang terjadi selama pemuatan tertentu. Untuk informasi selengkapnya, lihat [STL\$1LOAD\$1ERRORS](r_STL_LOAD_ERRORS.md). # Beban memakan waktu terlalu lama Operasi beban Anda bisa memakan waktu terlalu lama karena alasan berikut. Kami menyarankan pendekatan pemecahan masalah berikut. **COPY memuat data dari satu file** Pisahkan data pemuatan Anda menjadi beberapa file. Saat Anda memuat semua data dari satu file besar, Amazon Redshift dipaksa untuk melakukan pemuatan serial, yang jauh lebih lambat. Jumlah file harus kelipatan dari jumlah irisan di cluster Anda, dan file harus berukuran sama, antara 1 MB dan 1 GB setelah kompresi. Untuk informasi selengkapnya, lihat [Praktik terbaik Amazon Redshift untuk mendesain kueri](c_designing-queries-best-practices.md). **Operasi beban menggunakan beberapa perintah COPY** Jika Anda menggunakan beberapa perintah COPY bersamaan untuk memuat satu tabel dari beberapa file, Amazon Redshift dipaksa untuk melakukan pemuatan serial, yang jauh lebih lambat. Dalam hal ini, gunakan satu perintah COPY. # Memuat data tidak benar Operasi COPY Anda dapat memuat data yang salah dengan cara berikut. Kami menyarankan pendekatan pemecahan masalah berikut. **File yang salah dimuat** Menggunakan awalan objek untuk menentukan file data dapat menyebabkan file yang tidak diinginkan dibaca. Sebagai gantinya, gunakan file manifes untuk menentukan dengan tepat file mana yang akan dimuat. Untuk informasi selengkapnya, lihat [copy_from_s3_manifest_file](copy-parameters-data-source-s3.md#copy-manifest-file) opsi untuk perintah COPY dan [Example: COPY from Amazon S3 using a manifest](r_COPY_command_examples.md#copy-command-examples-manifest) dalam contoh COPY. # Mengatur parameter ukuran pengambilan JDBC Secara default, driver Redshift JDBC menggunakan buffer ring untuk mengelola memori secara efisien dan mencegah kesalahan. out-of-memory Parameter ukuran pengambilan hanya berlaku ketika buffer cincin dinonaktifkan secara eksplisit. Untuk informasi lebih lanjut, tinjau [tautannya](https://docs.aws.amazon.com/redshift/latest/mgmt/jdbc20-configuration-options.html#jdbc20-enablefetchringbuffer-option). Dalam konfigurasi ini, Anda harus mengatur ukuran pengambilan untuk mengontrol berapa banyak baris yang diambil di setiap batch. Gunakan parameter ukuran ambil saat: + Anda membutuhkan kontrol halus atas batching berbasis baris + Bekerja dengan aplikasi lama yang memerlukan perilaku ukuran pengambilan tradisional Ketika buffer dering dinonaktifkan, driver JDBC mengumpulkan semua hasil untuk kueri pada satu waktu secara default. Kueri yang mengembalikan set hasil besar dapat menghabiskan memori yang berlebihan. Untuk mengambil set hasil dalam batch, bukan sekaligus, atur parameter ukuran pengambilan JDBC di aplikasi Anda. **catatan** Ukuran pengambilan tidak didukung untuk ODBC. Untuk kinerja terbaik, atur ukuran pengambilan ke nilai tertinggi yang tidak menyebabkan kesalahan memori. Nilai ukuran pengambilan yang lebih rendah menghasilkan lebih banyak perjalanan server, yang memperpanjang waktu eksekusi. Server menyimpan sumber daya, termasuk slot kueri WLM dan memori terkait, hingga klien mengambil seluruh kumpulan hasil atau kueri dibatalkan. Saat Anda menyetel ukuran pengambilan dengan tepat, sumber daya tersebut dirilis lebih cepat, membuatnya tersedia untuk kueri lain. **catatan** Jika Anda perlu mengekstrak kumpulan data besar, sebaiknya gunakan pernyataan [UNLOAD](https://docs.aws.amazon.com/redshift/latest/dg/r_UNLOAD.html) untuk mentransfer data ke Amazon S3. Saat Anda menggunakan UNLOAD, node komputasi bekerja secara paralel untuk mempercepat transfer data. Untuk informasi selengkapnya tentang pengaturan parameter ukuran pengambilan JDBC, buka [Mendapatkan hasil berdasarkan kursor dalam dokumentasi PostgreSQL](https://jdbc.postgresql.org/documentation/query/#getting-results-based-on-a-cursor).