Sesi Oracle tercicir melalui VPN? Semak lapisan keepalive

Dua puluh lima minit kerja pangkalan data yang berguna hampir tidak menghasilkan output, dan dari setiap peranti di laluan itu aliran tersebut kelihatan tidak aktif. Keadaan tidak aktif itulah yang dikumpulkan. Laporan selepas itu sentiasa berbentuk sama: pertanyaan sedang berjalan, kemudian sesi hilang, dan hasilnya tidak pernah tiba.

Empat semakan menentukan sama ada sesi senyap bertahan, dan semuanya bergerak dari soket ke luar. Lakukan mengikut urutan, kerana setiap satu menganggap lapisan sebelumnya menjalankan tugasnya.

Aliran mana yang menjadi senyap

Sambungan yang penting ialah yang membawa trafik pangkalan data, dikenal pasti melalui alamat dan portnya sendiri. Tiada apa-apa lagi memperbaharuinya. Ping ke gateway, sambungan SQL kedua dari hos yang sama dan denyut nadi terowong itu sendiri ialah aliran berasingan dengan keadaan berasingan pada setiap peranti yang menjejakinya.

ss -tio dst 10.60.4.20
sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes

Senarai soket menunjukkan pemasa dan keadaan baris gilir untuk sambungan hidup, yang lebih bermaklumat daripada ujian kebolehcapaian. Nilai sysctl ialah nilai lalai kernel untuk tingkah laku keepalive, dan bahagian seterusnya menjelaskan mengapa ia mungkin tidak pernah terpakai pada sesi anda. Nilai lalai yang tidak pernah tercetus tidak dapat dibezakan daripada tiada nilai lalai langsung.

Catat alamat, port dan antara muka yang digunakan oleh sambungan. Apabila sesi mati, butiran itulah yang membolehkan anda bertanya kepada peranti yang betul apa yang dilakukannya, bukan bertanya sama ada rangkaian sedang hidup.

Sama ada dasar diam luput atau mengehadkan

Dua dasar menghasilkan simptom yang sama dan memerlukan tindak balas bertentangan. Tamat masa diam membuang keadaan yang boleh diperbaharui oleh trafik yang layak, dan keepalive boleh menghalangnya. Had sesi mutlak membuang aliran selepas tempoh tetap tanpa mengira aktiviti, dan tiada keepalive mengubahnya.

Tanya pemilik setiap perantara mana satu daripadanya yang dilaksanakan. Firewall, peranti NAT, pengimbang beban dan gateway awan semuanya boleh menyimpan keadaan, dan mereka tidak perlu bersetuju. Yang paling sempit menetapkan tarikh akhir yang perlu anda kalahkan.

Perbezaan itu juga memberitahu anda bila perlu berhenti menala. Jika dasarnya had mutlak, penyelesaian yang betul ialah unit kerja yang lebih pendek, kerja yang boleh disambung semula atau pengecualian yang diluluskan, dan semakan di bawah hanya akan mengesahkan bahawa keepalive tidak mengubah apa-apa.

Suis soket di sebalik nilai lalai Linux

Keepalive adalah pilihan bagi setiap soket. Nilai lalai kernel menerangkan bagaimana probe berkelakuan selepas soket mengaktifkan mekanismenya, dan ia tidak mengaktifkannya untuk sambungan sedia ada. Aplikasi yang tidak pernah memintanya tidak mendapat probe, apa pun kata nilai sysctl.

Sebab itu menaikkan nombor sahaja tidak mengubah apa-apa bagi klien pangkalan data. Pustaka klien atau aplikasi mesti mengaktifkan mekanismenya, dan di tempat tindanan menyediakan kawalan setiap sambungan, tetapan terhad mengatasi perubahan untuk seluruh hos yang menjejaskan perkhidmatan tidak berkaitan.

Selang sehingga probe pertama juga bukan tamat masa pertanyaan. Sambungan sihat kekal senyap antara probe, dan rakan mati dikenali mengikut selang dan bilangan probe. Membaca ketiga-tiga nilai itu sebagai satu tamat masa membawa orang kepada tetapan yang mengesan kegagalan sama ada terlalu lewat atau terlalu ghairah. Ia mengawal pengesanan, bukan kesabaran aplikasi.

EXPIRE_TIME ialah tetapan pangkalan data, bukan pembaikan rangkaian

Oracle Net menawarkan mekanisme kehidupannya sendiri, dikonfigurasikan dalam profil berkesan untuk proses itu dan bukan dalam fail sewenang-wenangnya yang kebetulan mempunyai nama serupa. Nilainya dinyatakan dalam minit.

SQLNET.EXPIRE_TIME = 5

Tujuan utamanya ialah pengesanan sambungan mati di sebelah pelayan, dan pada platform yang menyokong model dipertingkatkan ia juga menala tingkah laku keepalive TCP untuk sambungan tersebut. Itu sifat yang berguna: lapisan pangkalan data boleh mengatur probe tanpa meminta aplikasi klien berubah.

Nilai ilustratif di atas ialah pilihan terkoordinasi terhadap tarikh akhir yang diandaikan, bukan cadangan. Panduan umum yang didokumenkan ialah selang yang lebih panjang, dan nombor yang betul bergantung pada pelaksanaan yang dipasang, kos probe yang anda terima dan peraturan pembaharuan sebenar di laluan. Letakkan tetapan itu dalam profil yang dibaca oleh proses berkenaan, dan sahkan bahawa proses itu telah mengambilnya. Oracle mendokumenkan lokasi profil dan tingkah laku pengesanan dalam rujukan parameternya.

Uji selang senyap, kemudian rancang pemulihan

Lalukan sambungan baharu yang dibenarkan melalui tempoh senyap yang lebih panjang daripada tarikh akhir yang anda cuba kalahkan, dan perhatikan trafik kehidupan serta hasil aplikasi. Jangan tangkap kandungan muatan yang tidak anda perlukan; pemasa dan keadaan sambungan menjawab persoalannya.

ss -tio dst 10.60.4.20
# after the quiet interval, same command
ls -l "$ORACLE_HOME/network/admin/sqlnet.ora"

Jika sesi masih hilang, tarikh akhir itu milik peranti yang belum anda tanyai, atau dasarnya had mutlak. Jika ia bertahan, catat lapisan mana yang berubah supaya operasi senyap seterusnya tidak mengulangi siasatan.

Akhir sekali, tentukan apa yang berlaku apabila sambungan benar-benar terputus, kerana semakan kehidupan mengurangkan kekerapan dan tidak pernah menghapuskan kemungkinannya. Tetapkan hasil yang direkodkan bagi operasi pangkalan data sebelum menghantarnya semula: hilangnya balasan tidak membuktikan apa-apa tentang sama ada kerja itu telah disahkan. Bagi apa-apa yang mesti bertahan apabila komputer riba ditutup atau terowong dimulakan semula, kerja milik pelayan dengan hasil yang tahan lama ialah reka bentuk yang lebih kukuh, dan keepalive bukan penjadual.