Mengapa saya sepertinya tidak bisa memaksa Oracle 11g untuk mengkonsumsi lebih banyak CPU untuk satu kueri SQL?

Hal terpenting untuk dipahami tentang paralelisme Oracle adalah rumit. Mengoptimalkan paralelisme membutuhkan banyak pengetahuan Oracle, membaca manual, memeriksa banyak parameter, menguji kueri yang berjalan lama, dan banyak skeptisisme.

Ajukan Pertanyaan yang Tepat

Masalah paralel benar-benar melibatkan tiga pertanyaan berbeda:

1. Berapa banyak server paralel yang diminta?
2. Berapa banyak server paralel yang dialokasikan?
3. Berapa banyak server paralel yang digunakan secara bermakna?

Gunakan Alat Terbaik

Langsung ke alat terbaik - Pemantauan SQL dengan laporan aktif. Temukan SQL_ID Anda dan buat laporan HTML:select dbms_sqltune.report_sql_monitor(sql_id => 'your_sql_id', type => 'active') from dual; . Ini adalah satu-satunya cara untuk mengetahui berapa banyak waktu yang dihabiskan untuk setiap langkah dalam rencana eksekusi. Dan itu akan memberi tahu Anda berapa banyak paralelisme yang digunakan secara efektif, dan di mana. Sebagai contoh:

Pilihan bagus lainnya adalah type => 'text' . Tidak memiliki banyak informasi tetapi lebih cepat dilihat dan lebih mudah dibagikan.

SQL Monitoring juga mencakup DOP yang diminta dan DOP yang dialokasikan:

select parallel paralel 100 baris dapat berjalan dengan indah, tetapi kemudian semuanya berhenti pada satu langkah karena urutan yang tidak di-cache. Anda dapat menatap rencana penjelasan, jejak, atau laporan AWR selama berjam-jam dan tidak melihat masalahnya. Laporan aktif membuat langkah-langkah lambat hampir sepele untuk ditemukan. Jangan buang waktu untuk menebak di mana masalahnya.

Namun, alat lain masih diperlukan. Rencana penjelasan yang dibuat dengan explain plan for ... dan select * from table(dbms_xplan.display); akan memberikan beberapa informasi penting. Khususnya Notes bagian dapat menyertakan banyak alasan mengapa kueri tidak meminta paralelisme.

Tetapi MENGAPA saya mendapatkan server paralel sebanyak itu?

Informasi yang relevan tersebar di beberapa manual yang berbeda, yang sangat berguna tetapi terkadang tidak akurat atau menyesatkan. Ada banyak mitos dan banyak nasihat buruk tentang paralelisme. Dan teknologi berubah secara signifikan dengan setiap rilis.

Ketika Anda mengumpulkan semua sumber yang memiliki reputasi baik, daftar faktor yang mempengaruhi jumlah server paralel sangat banyak. Daftar di bawah ini diurutkan secara kasar berdasarkan apa yang menurut saya merupakan faktor terpenting:

1. Paralelisme antar-operasi Permintaan apa pun yang menggunakan pengurutan atau pengelompokan akan mengalokasikan dua kali lebih banyak server paralel daripada DOP. Ini mungkin bertanggung jawab atas mitos "Oracle mengalokasikan server paralel sebanyak mungkin!".
2. Petunjuk kueri Sebaiknya petunjuk tingkat pernyataan seperti /*+ parallel */ , atau mungkin petunjuk tingkat objek seperti /*+ noparallel(table1) */ . Jika langkah tertentu dari suatu rencana berjalan secara serial, biasanya karena petunjuk tingkat objek hanya pada sebagian kueri.
3. SQL Rekursif Beberapa operasi dapat berjalan secara paralel tetapi dapat secara efektif diserialisasi oleh SQL rekursif. Misalnya, urutan yang tidak di-cache pada sisipan besar. SQL rekursif yang dihasilkan untuk mengurai pernyataan juga akan serial; misalnya kueri pengambilan sampel dinamis.
4. Ubah sesi alter session [force|enable] parallel [query|dml|ddl]; Perhatikan bahwa DML paralel dinonaktifkan secara default.
5. Derajat tabel
6. Derajat indeks
7. Indeks lebih murah Petunjuk paralel hanya memberi tahu pengoptimal untuk mempertimbangkan pemindaian tabel lengkap dengan DOP tertentu. Mereka tidak benar-benar memaksakan paralelisme. Pengoptimal masih bebas menggunakan akses indeks serial jika dianggap lebih murah. (FULL petunjuk dapat membantu memecahkan masalah ini.)
8. Pengelolaan rencana SQL Plan Baselines, outlines, profiles, advanced rewrite, dan SQL Translators semuanya dapat mengubah tingkat paralelisme di belakang Anda. Periksa bagian Catatan rencana.
9. Edisi Hanya Enterprise dan Personal Editions yang memungkinkan operasi paralel. Kecuali paket DBMS_PARALLEL_EXECUTE.
10. PARALLEL_ADAPTIVE_MULTI_USER
11. PARALLEL_AUTOMATIC_TUNING
12. PARALLEL_DEGREE_LIMIT
13. PARALLEL_DEGREE_POLICY
14. PARALLEL_FORCE_LOCAL
15. PARALLEL_INSTANCE_GROUP
16. PARALLEL_IO_CAP_ENABLED
17. PARALLEL_MAX_SERVERS Ini adalah batas atas untuk keseluruhan sistem. Ada trade-off di sini. Menjalankan terlalu banyak server paralel sekaligus berdampak buruk bagi sistem. Tetapi menurunkan kueri ke serial dapat menjadi bencana untuk beberapa kueri.
18. PARALLEL_MIN_PERCENT
19. PARALLEL_MIN_SERVERS
20. PARALLEL_MIN_TIME_THRESHOLD
21. PARALLEL_SERVERS_TARGET
22. PARALLEL_THREADS_PER_CPU
23. Jumlah node RAC Pengganda lain untuk DOP default.
24. CPU_COUNT Jika DOP default digunakan.
25. PEMULIHAN_PARALLELISME
26. FAST_START_PARALLEL_ROLLBACK
27. Profil SESSIONS_PER_USER juga membatasi server paralel.
28. Manajer Sumber Daya
29. Pemuatan sistem Jika parallel_adaptive_multi_user benar. Mungkin mustahil untuk menebak kapan Oracle akan mulai membatasi.
30. PROSES
31. Pembatasan DML paralel DML paralel tidak akan berfungsi jika salah satu dari kasus berikut:
    1. COMPATIBLE <9.2 untuk intra-partisi
    2. MASUKKAN NILAI, tabel dengan pemicu
    3. replikasi
    4. integritas referensi mandiri atau hapus kaskade atau batasan integritas yang ditangguhkan
    5. mengakses kolom objek
    6. tabel yang tidak dipartisi dengan LOB
    7. paralelisme intra-partisi dengan LOB
    8. transaksi terdistribusi
    9. tabel berkerumun
    10. tabel sementara
32. Subkueri skalar tidak berjalan secara paralel? Ini ada di manual, dan saya berharap ini ada benar, tetapi pengujian saya menunjukkan bahwa paralelisme berfungsi di sini dalam 11g.
33. ENQUEUE_RESOURCES Parameter tersembunyi dalam 10g, apakah ini relevan lagi?
34. Tabel yang disusun berdasarkan indeks Tidak dapat memasukkan jalur langsung ke IOT secara paralel? (Apakah ini masih benar?)
35. Persyaratan fungsi saluran paralel Harus menggunakan CURSOR (?). LAKUKAN.
36. Fungsi harus PARALLEL_ENABLE
37. Jenis pernyataan Versi lama membatasi paralelisme pada DML tergantung pada partisi. Beberapa manual saat ini masih menyertakan hal ini, tetapi sudah pasti tidak benar lagi.
38. Jumlah partisi Hanya untuk penggabungan partisi pada versi yang lebih lama.(?)
39. Bug Secara khusus saya telah melihat banyak bug dengan parsing. Oracle akan mengalokasikan jumlah yang tepat dari server paralel tetapi tidak ada yang akan terjadi karena mereka semua menunggu peristiwa seperti cursor: pin s wait on x .

Daftar ini tentu tidak lengkap, dan tidak menyertakan fitur 12c. Dan itu tidak membahas masalah sistem operasi dan perangkat keras. Dan itu tidak menjawab pertanyaan yang sangat sulit, "berapa derajat paralelisme terbaik?" (Jawaban singkat:lebih banyak biasanya lebih baik, tetapi dengan mengorbankan proses lain.) Semoga setidaknya ini memberi Anda gambaran betapa sulitnya masalah ini, dan tempat yang baik untuk mulai mencari.