เซสชัน Oracle ขาดผ่าน VPN ใช่ไหม? ตรวจสอบชั้น keepalive

ยี่สิบห้านาทีของงานฐานข้อมูลที่ใช้ประโยชน์ได้แทบไม่สร้างผลลัพธ์ใด ๆ และจากทุกอุปกรณ์บนเส้นทาง กระแสดังกล่าวดูเหมือนไม่มีการใช้งาน สถานะที่ไม่มีการใช้งานคือสิ่งที่ถูกเก็บคืน รายงานภายหลังมีรูปร่างเดิมเสมอ: คำสั่งคิวรีกำลังทำงาน จากนั้นเซสชันก็หายไป และผลลัพธ์ไม่เคยมาถึง

การตรวจสอบสี่ข้อตัดสินว่าเซสชันที่เงียบจะอยู่รอดหรือไม่ และมันไล่จากซ็อกเก็ตออกไปข้างนอก ทำตามลำดับ เพราะแต่ละข้อถือว่าชั้นก่อนหน้าทำหน้าที่ของตน

กระแสไหนที่เงียบลง

การเชื่อมต่อที่สำคัญคือตัวที่บรรทุกทราฟฟิกฐานข้อมูล ระบุได้จากที่อยู่และพอร์ตของมันเอง ไม่มีอย่างอื่นรีเฟรชการเชื่อมต่อนี้ การปิงไปยังเกตเวย์ การเชื่อมต่อ SQL ครั้งที่สองจากโฮสต์เดียวกัน และการเต้นของหัวใจของอุโมงค์เองเป็นกระแสแยกกัน โดยมีสถานะแยกกันในทุกอุปกรณ์ที่ติดตามมัน

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

รายการซ็อกเก็ตแสดงตัวจับเวลาและสถานะคิวของการเชื่อมต่อที่ยังมีชีวิต ซึ่งให้ข้อมูลมากกว่าการทดสอบการเข้าถึง ค่า sysctl เป็นค่าเริ่มต้นของเคอร์เนลสำหรับพฤติกรรม keepalive และหัวข้อถัดไปอธิบายว่าทำไมมันอาจไม่ถูกนำมาใช้กับเซสชันของคุณเลย ค่าเริ่มต้นที่ไม่เคยทำงานนั้นแยกไม่ออกจากกรณีที่ไม่มีค่าเริ่มต้นเลย

จดที่อยู่ พอร์ต และอินเทอร์เฟซที่การเชื่อมต่อใช้ เมื่อเซสชันตาย รายละเอียดเหล่านี้คือสิ่งที่ทำให้คุณถามอุปกรณ์ที่ถูกต้องว่าได้ทำอะไรไป แทนที่จะถามว่าเครือข่ายทำงานอยู่หรือไม่

นโยบายไม่ใช้งานหมดอายุหรือจำกัด

นโยบายสองแบบให้อาการเดียวกันและต้องตอบสนองตรงกันข้าม การหมดเวลาเมื่อไม่ใช้งานจะลบสถานะที่ทราฟฟิกที่เข้าเกณฑ์อาจรีเฟรชได้ และ keepalive สามารถป้องกันได้ ขีดจำกัดเซสชันแบบสัมบูรณ์จะลบกระแสหลังจากระยะเวลาคงที่โดยไม่สนใจกิจกรรม และไม่มี keepalive ใดเปลี่ยนสิ่งนั้น

ถามเจ้าของตัวกลางแต่ละตัวว่าใช้นโยบายไหน ไฟร์วอลล์ อุปกรณ์ NAT ตัวกระจายโหลด และเกตเวย์คลาวด์ล้วนเก็บสถานะได้ และไม่จำเป็นต้องเห็นตรงกัน ตัวที่แคบที่สุดเป็นตัวกำหนดเส้นตายที่คุณต้องเอาชนะ

ความแตกต่างนี้ยังบอกด้วยว่าเมื่อใดควรหยุดปรับแต่ง หากนโยบายเป็นขีดจำกัดสัมบูรณ์ วิธีแก้ที่ถูกต้องคือหน่วยงานที่สั้นลง งานที่ทำต่อได้ หรือข้อยกเว้นที่ได้รับอนุมัติ และการตรวจสอบด้านล่างจะยืนยันเพียงว่า keepalive ไม่ได้เปลี่ยนอะไร

สวิตช์ซ็อกเก็ตเบื้องหลังค่าเริ่มต้นของ Linux

keepalive เป็นทางเลือกต่อซ็อกเก็ต ค่าเริ่มต้นของเคอร์เนลอธิบายว่าการหยั่งเชิงทำงานอย่างไรหลังจากซ็อกเก็ตเปิดกลไกแล้ว และมันไม่ได้เปิดกลไกให้กับการเชื่อมต่อที่มีอยู่ แอปพลิเคชันที่ไม่เคยขอจะไม่ได้รับการหยั่งเชิง ไม่ว่า sysctl จะว่าอย่างไร

ดังนั้นการเพิ่มตัวเลขเพียงอย่างเดียวไม่เปลี่ยนอะไรสำหรับไคลเอนต์ฐานข้อมูล ไลบรารีไคลเอนต์หรือแอปพลิเคชันต้องเปิดกลไก และในที่ที่สแตกมีตัวควบคุมต่อการเชื่อมต่อ การตั้งค่าแบบจำกัดก็เหนือกว่าการเปลี่ยนทั้งโฮสต์ซึ่งกระทบบริการที่ไม่เกี่ยวข้อง

ช่วงจนถึงการหยั่งเชิงครั้งแรกก็ไม่ใช่เวลาหมดอายุของคำสั่ง การเชื่อมต่อที่แข็งแรงจะเงียบระหว่างการหยั่งเชิง และคู่ที่ตายแล้วจะถูกรู้จักตามช่วงและจำนวนการหยั่งเชิง การอ่านค่าทั้งสามนี้เป็นเวลาหมดอายุเดียวคือทางที่ทำให้ได้การตั้งค่าซึ่งตรวจจับความล้มเหลวช้าเกินไปหรือเร็วเกินไป สิ่งเหล่านี้ควบคุมการตรวจจับ ไม่ใช่ความอดทนของแอปพลิเคชัน

EXPIRE_TIME เป็นการตั้งค่าฐานข้อมูล ไม่ใช่การซ่อมเครือข่าย

Oracle Net มีกลไกการมีชีวิตของตัวเอง กำหนดค่าในโปรไฟล์ที่มีผลสำหรับโปรเซส ไม่ใช่ในไฟล์ใด ๆ ที่บังเอิญมีชื่อคล้ายกัน ค่าแสดงเป็นนาที

SQLNET.EXPIRE_TIME = 5

จุดประสงค์หลักคือการตรวจจับการเชื่อมต่อที่ตายแล้วฝั่งเซิร์ฟเวอร์ และบนแพลตฟอร์มที่รองรับโมเดลขั้นสูงยังปรับพฤติกรรม TCP keepalive สำหรับการเชื่อมต่อเหล่านั้นด้วย นี่เป็นคุณสมบัติที่มีประโยชน์: ชั้นฐานข้อมูลสามารถจัดการการหยั่งเชิงได้โดยไม่ต้องขอให้แอปพลิเคชันไคลเอนต์เปลี่ยน

ค่าตัวอย่างข้างต้นเป็นการเลือกที่ประสานกับเส้นตายที่สมมติขึ้น ไม่ใช่คำแนะนำ แนวทางทั่วไปที่บันทึกไว้คือช่วงที่ยาวขึ้น และตัวเลขที่ถูกต้องขึ้นกับการใช้งานที่ติดตั้ง ต้นทุนการหยั่งเชิงที่คุณยอมรับ และกฎการรีเฟรชจริงบนเส้นทาง วางการตั้งค่าไว้ในโปรไฟล์ที่โปรเซสที่เกี่ยวข้องอ่าน และยืนยันว่าโปรเซสรับมันไปแล้ว Oracle บันทึกตำแหน่งโปรไฟล์และพฤติกรรมการตรวจจับไว้ในเอกสารอ้างอิงพารามิเตอร์

ทดสอบช่วงที่เงียบ แล้ววางแผนการกู้คืน

ปล่อยให้การเชื่อมต่อใหม่ที่ได้รับอนุญาตผ่านช่วงเงียบที่ยาวกว่าเส้นตายที่คุณพยายามเอาชนะ และเฝ้าดูทราฟฟิกการมีชีวิตกับผลลัพธ์ของแอปพลิเคชัน อย่าจับเนื้อหาเพย์โหลดที่คุณไม่ต้องการ ตัวจับเวลาและสถานะการเชื่อมต่อตอบคำถามนั้น

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

หากเซสชันยังหายไปอีก เส้นตายนั้นเป็นของอุปกรณ์ที่คุณยังไม่ได้ถาม หรือนโยบายเป็นขีดจำกัดสัมบูรณ์ หากมันอยู่รอด ให้บันทึกว่าชั้นใดเปลี่ยน เพื่อให้การดำเนินการเงียบครั้งถัดไปไม่ต้องตรวจสอบซ้ำ

สุดท้าย ตัดสินใจว่าเกิดอะไรขึ้นเมื่อการเชื่อมต่อล้มจริง เพราะการตรวจสอบการมีชีวิตช่วยลดความถี่และไม่เคยขจัดความเป็นไปได้ ยืนยันผลลัพธ์ที่บันทึกไว้ของการดำเนินการฐานข้อมูลก่อนส่งซ้ำ: การสูญเสียคำตอบไม่ได้พิสูจน์อะไรว่ามันยืนยันงานแล้วหรือไม่ สำหรับทุกสิ่งที่ไม่ควรหายเมื่อปิดแล็ปท็อปหรือรีสตาร์ตอุโมงค์ งานที่เป็นของเซิร์ฟเวอร์และมีผลลัพธ์ที่คงทนคือการออกแบบที่แข็งแรงกว่า และ keepalive ไม่ใช่ตัวจัดตาราง