Saya mendapat telepon dari seseorang bahwa mereka mendapatkan kesalahan TNS-12519 dalam aplikasi mereka. Benar saja, pesan-pesan itu juga ada di file listener.log.
TNS-12519: TNS:no appropriate service handler found
Bagi mereka yang tidak terbiasa dengan kesalahan ini, biasanya berarti salah satu dari dua hal. Nama layanan tidak terdaftar dengan pemroses atau database telah mencapai jumlah proses maksimum. Untuk yang terakhir, apa yang terjadi adalah bahwa Pendengar tahu bahwa database tidak dapat menerima proses baru apa pun sehingga membutuhkan nama layanan di luar layanan untuk berbicara. "Status lsnrctl" cepat menunjukkan kepada saya bahwa nama layanan terdaftar dengan benar. Jadi harus yang terakhir. Saya kemudian mengeluarkan pertanyaan berikut dan mengkonfirmasi kecurigaan saya.
SQL> select resource_name,current_utilization,max_utilization 2 from v$resource_limit where resource_name='processes';
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION --------------- ------------------- --------------- processes 299 300
Tentu saja. Saya telah mencapai proses maksimal, yang didefinisikan dalam SPFILE saya menjadi 300. Saya meningkatkan parameter menjadi 600 dan memantulkan instance. Kami menekan kesalahan lagi dengan menggandakan jumlah proses. Saya jelas perlu menggali ini lebih jauh.
Untuk beberapa latar belakang, dan untuk sesuatu yang akan menjadi penting di kemudian hari, penting untuk diketahui bahwa database ini mendukung upaya pengujian otomatis kami. Kami memiliki harness uji yang melatih aplikasi produksi utama kami. Test suite ini meluncurkan aplikasi, menghubungkan ke database, menekan beberapa tombol dan memilih beberapa item menu lalu memutuskan sambungan.
Saya memeriksa file listener.log untuk melihat dari mana permintaan koneksi berasal. Permintaan ini berasal dari server aplikasi jahat, bukan rangkaian pengujian kami. Saya tahu ada sesuatu yang salah karena kami belum memulai rangkaian pengujian dan kami mendapatkan kesalahan. Kami memperbaiki server aplikasi dan saya tidak melihat kesalahan kembali. Kami kemudian menjalankan test suite dan beberapa waktu kemudian, kesalahan TNS-12519 kembali. Hmmm… Saya pikir saya menemukan pelakunya. Tapi mari kita periksa pemanfaatan proses kita.
SQL> select resource_name,current_utilization,max_utilization 2 from v$resource_limit where resource_name='processes';
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION --------------- ------------------- --------------- processes 89 157
Jadi saat ini saya melihat 89 proses dengan pemanfaatan maksimum 157. Saya tidak mendekati batas baru saya yaitu 600. Jadi apa penyebabnya? Butuh beberapa saat bagi saya untuk mencari tahu apa masalahnya. Nama layanan terdaftar dengan benar dan saya tidak mendekati batas saya. MOS NOTE 552765.1 berbicara tentang bagaimana Pendengar tiba di kesalahan TNS-12519. Sebelumnya, saya melihat penyebab paling umum. PROSES Maks telah tercapai. Tapi tidak kali ini Jadi apa yang memberi?
Setelah penyelidikan, saya menemukan jawaban saya di log pendengar. Tapi itu tidak jelas seperti beberapa pesan kesalahan besar. Kesalahan TNS-12519 pertama kali terjadi pada pukul 09:38. Saya mencari "service_update" di log pendengar dan melihat entri ini.
25-JUN-2015 09:17:08 * service_update * orcl * 0 25-JUN-2015 09:17:26 * service_update * orcl * 0 25-JUN-2015 09:17:29 * service_update * orcl * 0 25-JUN-2015 09:17:44 * service_update * orcl * 0 25-JUN-2015 09:17:50 * service_update * orcl * 0 25-JUN-2015 09:17:53 * service_update * orcl * 0 25-JUN-2015 09:18:56 * service_update * orcl * 0 25-JUN-2015 09:18:59 * service_update * orcl * 0 25-JUN-2015 09:19:50 * service_update * orcl * 0 25-JUN-2015 09:20:11 * service_update * orcl * 0 25-JUN-2015 09:21:27 * service_update * orcl * 0 25-JUN-2015 09:22:09 * service_update * orcl * 0 25-JUN-2015 09:24:05 * service_update * orcl * 0 25-JUN-2015 09:27:53 * service_update * orcl * 0 25-JUN-2015 09:29:32 * service_update * orcl * 0 25-JUN-2015 09:34:07 * service_update * orcl * 0 25-JUN-2015 09:41:45 * service_update * orcl * 0
Perhatikan bahwa pembaruan layanan ini terjadi secara teratur pada 9:17 dan 9:18, tetapi waktu antara pembaruan layanan semakin lama. Perhatikan bahwa ada 8 menit 38 detik antara pembaruan layanan di akhir (9:34 hingga 9:41). Mengapa ini penting?
Ini adalah database Oracle 11.2.0.4. Untuk 11.2 dan sebelumnya, PMON bertanggung jawab untuk membersihkan setelah proses dan untuk meneruskan informasi ke Listener. Pada startup basis data, PMON mencoba mendaftarkan layanan dengan Pendengar. Satu hal lain yang dilakukan PMON adalah memberi tahu Pendengar berapa banyak proses maksimal yang dapat dilayani. Dalam hal ini, PMON memberi tahu pendengar bahwa ia dapat memiliki hingga 600 proses. PMON melakukan lebih banyak, tetapi untuk tujuan diskusi ini, itu sudah cukup.
Satu bagian penting yang perlu diketahui adalah bahwa Listener tidak pernah tahu berapa banyak proses yang saat ini terhubung. Itu hanya tahu berapa banyak permintaan koneksi yang telah membantu broker. Pendengar tidak pernah tahu jika proses terputus dari database. Service_update di atas adalah tempat PMON memberi tahu Listener berapa banyak proses yang sebenarnya sedang digunakan. Jadi pada 9:34:07, pembaruan layanan PMON memberi tahu Pendengar bahwa ada 145 proses yang digunakan. Pendengar sekarang up-to-date. Saat permintaan koneksi baru masuk, Listener menambahkan ini ke 146 proses. Di antara pembaruan layanan, Pendengar sama sekali tidak menyadari bahwa 1 atau lebih proses mungkin telah dihentikan, secara normal atau tidak normal. Itu terus menambah jumlah prosesnya hingga pembaruan layanan berikutnya ketika Pendengar mendapatkan akun yang akurat tentang berapa banyak proses yang muncul.
Jadi kami memiliki jeda 8,5 menit antara pembaruan layanan. Mengapa PMON butuh waktu lama untuk kembali ke Pendengar? Nah petunjuk untuk itu ada di listener.log juga. Saya menghapus semuanya dari log sebelum 9:34 service_update dan setelah 9:41 service update. Dari sana, mudah untuk mengambil “(CONNECT_DATA="” di bagian yang tersisa dan menyalurkan ke “wc -l” untuk mendapatkan jumlah baris.
Selama interval 8,5 menit ini, saya mendapatkan lebih dari 450 permintaan koneksi baru! Namun sebagian besar koneksi baru tersebut dihentikan sebagaimana dibuktikan oleh V$RESOURCE_LIMIT yang menunjukkan kepada saya bahwa saya memiliki maksimal 150. PMON sangat sibuk membersihkan aplikasi yang keluar dari koneksi databasenya sehingga memiliki jeda yang besar sebelum memperbarui Listener. Bagi Pendengar, 150 koneksi saat ini ditambah 450 koneksi baru berarti telah mencapai batas 600.
PMON dapat memakan waktu hingga 10 menit untuk kembali ke Pendengar dengan pembaruan layanan berikutnya. Membersihkan setelah sesi keluar dari instance memiliki prioritas lebih tinggi daripada pembaruan layanan ke Listener. Pada tanda 10 menit, PMON menjadikan pembaruan layanan sebagai prioritas utama jika pembaruan layanan belum pernah dilakukan sebelumnya dalam interval waktu tersebut.
Ingatlah bahwa ini adalah database untuk mendukung pengujian otomatis. Kami harus hidup dengan banyak operasi sambungkan/putuskan ini karena kami memiliki robot otomatis yang menguji aplikasi kami dengan cara cepat. Kami tidak ingin mengubah cara kerja aplikasi karena bekerja dengan sangat baik saat dijalankan oleh satu pengguna. Rangkaian pengujian otomatis kami menjalankan aplikasi secara berbeda dari yang dirancang untuk dilakukan. Tetapi kami ingin menjalankan aplikasi seperti yang tertulis untuk berpotensi mengekspos bug sebelum perubahan kode mencapai produksi.
Untuk saat ini, saya telah meningkatkan parameter PROCESSES ke nilai yang tidak akan pernah kita capai. Semua ini agar Pendengar tidak dapat mencapai batas di penghitung internalnya. Semakin banyak PROSES, semakin banyak memori yang dibutuhkan di SGA untuk mendukung angka yang lebih tinggi itu. Tapi database ini bisa mengatasinya.
Jika ada yang tahu cara agar pembaruan layanan terjadi dalam jendela 5 menit, beri tahu saya. Tidak ada parameter terdokumentasi untuk mengontrol perilaku ini dan saya juga tidak dapat menemukan parameter yang tidak terdokumentasi.
Terakhir, masalah ini ada di salah satu database 11.2.0.4 saya. Oracle 12c mengubah arsitekturnya sedikit. Proses latar belakang Listener Registration (LREG) baru menangani pekerjaan yang biasa dilakukan PMON. Saya belum memiliki sistem untuk diuji, tetapi saya yakin LREG tidak akan memiliki masalah yang sama di 12c yang dipamerkan PMON di sini dalam 11g karena LREG tidak harus menangani tugas pembersihan seperti yang dilakukan PMON. Catatan MOS 1592184.1 menunjukkan bahwa LREG akan melakukan pembaruan layanan.
Pembaruan:Sejak saya menulis artikel ini, saya memiliki kesempatan untuk memutakhirkan database ke 12c dengan proses LREG yang baru. Dengan LREG yang menangani pembaruan layanan Pendengar, kami melihat masalah tersebut hilang. Bahkan selama masa aktivitas sesi yang berat, khususnya menghubungkan dan memutuskan sambungan, LREG membuat pembaruan layanan rutin yang tidak dapat dilakukan oleh PMON sesering itu.
