Cache Fusion ไม่มีอะไรนอกจากการถ่ายโอนบล็อกระหว่างสองอินสแตนซ์ใน Oracle ® RealApplication Clusters (RAC) เป็นคุณสมบัติหลักและสำคัญที่สุดใน RAC
แนะนำตัว
ตาม Oracle ใน Oracle RAC Cache Fusion แต่ละ "อินสแตนซ์ [ใน] RAC คลัสเตอร์ [มี] บัฟเฟอร์แคชในเครื่องของตัวเองซึ่งทำหน้าที่แคช แต่เมื่อผู้ใช้หลายรายเชื่อมต่อกับโหนดต่างๆ [ผู้ใช้มักจะ] จำเป็นต้องเข้าถึงหรือล็อกบล็อกข้อมูลที่เป็นของ [อีก] อินสแตนซ์
“ในกรณีดังกล่าว [the] อินสแตนซ์ที่ร้องขอจะร้องขออินสแตนซ์การระงับสำหรับการบล็อกข้อมูลนั้นและเข้าถึงได้ผ่านกลไกการเชื่อมต่อระหว่างกัน [an] แนวคิดนี้เรียกว่า Cache Fusion ”
อินสแตนซ์เดียว
ก่อนสำรวจ Cache Fusion เรามาดูกันว่าฐานข้อมูลที่ไม่ใช่ RAC ทำงานอย่างไรเมื่อมีคำขอบล็อกข้อมูลเกิดขึ้น
ต่อไปนี้เป็นขั้นตอนการทำธุรกรรมสี่ขั้นตอนในอินสแตนซ์เดียว (ดึงมาจากโพสต์บล็อก Cache Fusion ของ Gopi:
- เมื่อผู้ใช้อ่านบล็อกที่แก้ไขล่าสุด อาจพบธุรกรรมที่ใช้งานอยู่ในบล็อก
- ผู้ใช้จะต้องอ่านส่วนหัวของเซ็กเมนต์เลิกทำเพื่อตัดสินใจว่าธุรกรรมได้รับการคอมมิตหรือไม่
- หากธุรกรรมไม่ได้ถูกคอมมิต กระบวนการจะสร้างเวอร์ชันอ่านที่สอดคล้องกัน (CR) ของบล็อกในบัฟเฟอร์แคชโดยใช้ข้อมูลในบล็อกและข้อมูลที่จัดเก็บไว้ในเซ็กเมนต์ที่เลิกทำ
- หากเซ็กเมนต์เลิกทำแสดงว่ามีการทำธุรกรรมแล้ว กระบวนการจะต้องทบทวนบล็อกอีกครั้งและล้างบล็อกและสร้างการทำซ้ำสำหรับการเปลี่ยนแปลง
ตอนนี้ มาดูสถานการณ์เดียวกันใน RAC กับคลัสเตอร์สองอินสแตนซ์ที่เรียกว่า Cache Fusion
แคชฟิวชั่น
Gopi กล่าวต่อ “ใน RAC มี [สอง] อินสแตนซ์ขึ้นไปที่เข้าถึงไฟล์ฐานข้อมูลเดียวกัน [ที่อยู่ในที่เก็บข้อมูลเดียวกัน (เช่น, ASM)] แต่ละอินสแตนซ์มี SGA ของตัวเอง ซึ่งเป็นกระบวนการพื้นหลัง ซึ่งหมายความว่าแต่ละอินสแตนซ์มีบัฟเฟอร์แคชของตัวเอง (ในเครื่องของแต่ละอินสแตนซ์) บัฟเฟอร์ [sic] แคชเหล่านี้ทำงานแยกกันที่ระดับอินสแตนซ์ [ที่] และหลอมรวมกันที่ระดับฐานข้อมูล [ที่] เพื่อสร้างเอนทิตีเดียว (Global Cache) [เพื่อ] แบ่งปันบล็อกข้อมูลระหว่างกัน นี่คือสิ่งที่เราเรียกว่า Cache Fusion . Cache Fusion ใช้การเชื่อมต่อระหว่าง IPC ความเร็วสูงเพื่อจัดเตรียมการถ่ายโอนบล็อกข้อมูลระหว่างแคชไปยังแคชระหว่างอินสแตนซ์ในคลัสเตอร์ การบล็อกข้อมูลนี้ช่วยขจัดดิสก์ I/O และเพิ่มประสิทธิภาพการทำงานพร้อมกันในการอ่าน/เขียน”
ความเข้าใจนี้นำเราไปสู่ Global Cache Service (GCS) ซึ่งมีหน้าที่ในการบล็อกการถ่ายโอนระหว่างอินสแตนซ์
ต่อไปนี้เป็นกระบวนการพื้นหลัง GCS ที่กล่าวถึงในโพสต์ของ Gopi:
- กระบวนการบริการแคชทั่วโลก (LMSn)
- Global Enqueue Service Daemon (LMD)
Gopi กล่าวต่อไปว่า “ก่อนเข้าสู่กระบวนการเบื้องหลังเหล่านี้ [sic] มาดูกันว่า Oracle จัดการกับบล็อกข้อมูลอย่างไรและจัดการอย่างไร
“Oracle ถือว่าบล็อคข้อมูลเป็นทรัพยากร ทรัพยากรเหล่านี้แต่ละอย่างสามารถอยู่ในโหมดที่ไม่แยแส ซึ่งเป็นกลไกสำคัญ [หนึ่ง] ในการรักษาความสมบูรณ์ของข้อมูล โหมดเหล่านี้แบ่งออกเป็น [สาม] ประเภทขึ้นอยู่กับว่าผู้ถือทรัพยากรตั้งใจที่จะแก้ไขข้อมูลหรืออ่านข้อมูล”
Gopi แสดงรายการโหมดต่างๆ ดังนี้:
- โหมด Null (N) :โหมด Null มักจะถูกเก็บไว้เป็นตัวยึดตำแหน่ง
- โหมดที่ใช้ร่วมกัน (S) :ในโหมดนี้ บล็อกข้อมูลจะไม่ถูกแก้ไขโดยเซสชันอื่น แต่จะอนุญาตการเข้าถึงที่ใช้ร่วมกันได้พร้อมกัน
- โหมดพิเศษ (X) :ระดับนี้ให้สิทธิ์การเข้าถึงกระบวนการถือครองแบบเอกสิทธิ์เฉพาะบุคคล กระบวนการอื่นไม่สามารถเขียนไปยังทรัพยากรได้ อาจมีช่วงการอ่านที่สอดคล้องกัน
Global Cache Service Daemon (LMSn)
เมื่อมีคำขอจากอินสแตนซ์ Gopi บอกเราว่า “GCS จัดระเบียบการจัดส่งบล็อกไปยังอินสแตนซ์อื่นโดยเก็บสำเนาบล็อกไว้ในหน่วยความจำ แต่ละสำเนาดังกล่าวเรียกว่าภาพในอดีต (PI) […] นอกจากนี้ยังเป็นไปได้ที่จะมี PI ของบล็อกข้อมูลมากกว่าหนึ่ง [หนึ่ง] ขึ้นอยู่กับจำนวนครั้งที่บล็อกได้รับการร้องขอใน [ขั้นตอน] สกปรก”
หมายเหตุ: Gopi กล่าวเสริมว่า “ถ้าคุณต้องการอ่านบล็อคข้อมูล บล็อกนั้นจะต้องอ่านในสถานะที่สอดคล้องกัน [a] คุณไม่ได้รับอนุญาตให้อ่านการเปลี่ยนแปลงที่ทำโดยผู้อื่น”
Global Enqueue Service Daemon (LMD)
Gopi อธิบายว่า “บริการ globalenqueue (GES) ติดตามสถานะของกลไกการเข้าคิวของ Oracle ทั้งหมด GES ดำเนินการควบคุมพร้อมกันในการล็อกแคชของพจนานุกรม การล็อกแคชของไลบรารี และธุรกรรม มันดำเนินการดำเนินการนี้สำหรับทรัพยากรที่เข้าถึงได้มากกว่าหนึ่งอินสแตนซ์ GES ควบคุมการเข้าถึงไฟล์ข้อมูลและไฟล์ควบคุม แต่ไม่ใช่สำหรับบล็อกข้อมูล
ต่อไปนี้คือทรัพยากรที่มีการจัดการของ GES ที่ Gopi แบ่งปัน:
- ล็อกธุรกรรม :จะได้รับในโหมดพิเศษเมื่อธุรกรรมเริ่มต้นการเปลี่ยนแปลง (แทรก อัปเดต ฯลฯ) การล็อกจะถูกระงับไว้จนกว่าธุรกรรมจะตกลงหรือย้อนกลับ
- ล็อกแคชไลบรารี :เมื่อมีการอ้างอิงอ็อบเจ็กต์ฐานข้อมูล (เช่น ตาราง มุมมอง แพ็คเกจ ตัวแพ็คเกจ […] และอื่นๆ) ในระหว่างการแยกวิเคราะห์หรือรวบรวมคำสั่ง SQL, DML หรือ DDL, PL/SQL หรือ Java กระบวนการแยกวิเคราะห์หรือ การคอมไพล์คำสั่งจะได้รับการล็อกแคชของห้องสมุดในโหมดที่ถูกต้อง
- ล็อคแคชพจนานุกรม :Global enqueues ถูกใช้ในโหมดฐานข้อมูลคลัสเตอร์ โครงสร้างพจนานุกรมข้อมูลจะเหมือนกันสำหรับอินสแตนซ์ Oracle ทั้งหมดในฐานข้อมูลคลัสเตอร์
- ตัวล็อคโต๊ะ :นี่คือล็อค GES ที่ปกป้องทั้งโต๊ะ ทรานแซคชันรับการล็อกตารางเมื่อมีการปรับเปลี่ยนตาราง สามารถล็อกตารางในโหมดต่างๆ ได้หลายโหมด:null (N), การแชร์แถว (RS), เฉพาะแถว (RX), การล็อกการแชร์ (S), การแชร์แถวแบบเอกสิทธิ์เฉพาะบุคคล (SRX) หรือแบบเอกสิทธิ์เฉพาะบุคคล (X)
รูปภาพที่อ่านในอดีตและสม่ำเสมอ
ก่อนเข้าสู่สถานการณ์หลัก เราต้องเข้าใจรูปภาพในอดีต (PI) และรูปภาพที่อ่านสม่ำเสมอ (CR)
ภาพในอดีต
Rohit Gupta ในบทความของเขา Oracle RAC Cache Fusion แชร์ว่า "แนวคิดของ Past Image มีความเฉพาะเจาะจงมากสำหรับการตั้งค่า RAC พิจารณาอินสแตนซ์ที่มี [an] ล็อคเฉพาะบล็อกข้อมูลสำหรับการอัปเดต หากอินสแตนซ์อื่นใน RAC ต้องการบล็อก อินสแตนซ์การถือครองสามารถส่งบล็อกไปยังอินสแตนซ์ที่ร้องขอได้ (แทนที่จะเขียนลงดิสก์) โดยเก็บ PI (ภาพในอดีต) ของบล็อกไว้ในบัฟเฟอร์แคช โดยพื้นฐานแล้ว PI คือสำเนาของบล็อกข้อมูลก่อนที่จะเขียนบล็อกลงในดิสก์”
ภาพที่อ่านสม่ำเสมอ:
Gupta กล่าวต่อว่า “จำเป็นต้องอ่านอย่างต่อเนื่องเมื่อมีการเข้าถึง/แก้ไขบล็อกเฉพาะโดยธุรกรรม[A1] และในขณะเดียวกันธุรกรรมอื่น [A2] พยายามเข้าถึง/อ่านบล็อก ถ้า[A1] ไม่ได้ถูกคอมมิต [A2] จะต้องอ่านสำเนา [(บล็อกที่ไม่ได้แก้ไข)] ที่สอดคล้องกันเพื่อดำเนินการต่อ สำเนา CR ถูกสร้างขึ้นโดยใช้ข้อมูล UNDO สำหรับบล็อกนั้น”
สถานการณ์แคชฟิวชัน
Cache Fusion มีสามสถานการณ์ที่แตกต่างกัน:
- สถานการณ์การอ่าน-อ่าน
- สถานการณ์การอ่าน-เขียน
- สถานการณ์เขียน-เขียน
สถานการณ์อ่าน-อ่าน:
นี่เป็นสถานการณ์ที่ไม่สำคัญเนื่องจากอินสแตนซ์ที่ร้องขอการบล็อกและอินสแตนซ์ที่บล็อกคำขอต่างก็ร้องขอธุรกรรมการอ่าน ที่นี่ไม่มีการล็อกพิเศษ อินสแตนซ์ B ขอบล็อกการอ่านไปยัง GCS GCS ตรวจสอบความพร้อมใช้งานของบล็อกซึ่งเป็นเจ้าของโดยอินสแตนซ์ A และรับการล็อกที่ใช้ร่วมกัน ตอนนี้ GCS ขอให้ Instance Aship บล็อกที่ร้องขอไปยังอินสแตนซ์ B.
สถานการณ์อ่าน-เขียน:
นี่เป็นสถานการณ์ที่สำคัญ
อินสแตนซ์ A กำลังอัปเดตบล็อกข้อมูล ดังนั้นจึงจำเป็นต้องได้รับการล็อกแบบเอกสิทธิ์เฉพาะบุคคล หลังจากนั้น อินสแตนซ์ B จะส่งคำขออ่านไปยัง GCS สำหรับบล็อกข้อมูลเดียวกัน
GCS ตรวจสอบและพบว่า Instance ได้รับการล็อคแบบเอกสิทธิ์เฉพาะบุคคลในบล็อกเดียวกัน ดังนั้น GCS จึงขอให้อินสแตนซ์ A ปล่อยบล็อก ตอนนี้ อินสแตนซ์ A จะสร้างอิมเมจ CR ในแคชบัฟเฟอร์ของตัวเองและแจ้ง GCS ให้ส่งไปยังอินสแตนซ์ B
GCS มีส่วนเกี่ยวข้องกับการสร้างอิมเมจ CR และจัดส่งไปยังอินสแตนซ์ที่ร้องขอคือที่ที่ Cache Fusion เข้ามามีบทบาท
สถานการณ์เขียน-เขียน
อินสแตนซ์ A และอินสแตนซ์ B ต่างก็พยายามรับการล็อกเฉพาะบนบล็อกข้อมูล
อินสแตนซ์ B ส่งคำขอบล็อกไปยัง GCS GCS ตรวจสอบความพร้อมใช้งานและพบว่า Instance Ahas ได้รับการล็อค ดังนั้น GCS จึงขอให้อินสแตนซ์ A ปล่อยบล็อกสำหรับอินสแตนซ์ B ตอนนี้อินสแตนซ์ A จะสร้าง PI ของบล็อกปัจจุบันของตัวเองในบัฟเฟอร์ สร้างรายการทำซ้ำ และแจ้ง GCS ให้จัดส่งบล็อกไปยังอินสแตนซ์ B
ขณะนี้อินสแตนซ์ B ใช้บล็อกและทำการเปลี่ยนแปลงตามปกติ
ความแตกต่างที่สำคัญระหว่าง CR และ PI
Gupta เพิ่มความคิดขั้นสุดท้ายเกี่ยวกับภาพ PI กับ CR:“[ภาพ] CR ถูกส่งเพื่อหลีกเลี่ยง [a] ประเภทความขัดแย้งประเภทอ่าน-เขียน เนื่องจากคำขออินสแตนซ์ไม่ต้องการดำเนินการเขียนจึงไม่ต้องการ ล็อคพิเศษบนบล็อก ดังนั้นสำหรับการดำเนินการอ่าน รูปภาพ CR ของบล็อกก็เพียงพอแล้ว ในขณะที่การโต้แย้งแบบเขียน-เขียน อินสแตนซ์ที่ร้องขอยังต้องได้รับการล็อกแบบเอกสิทธิ์เฉพาะบุคคลบนบล็อกข้อมูล [ในการ] รับการล็อกสำหรับการดำเนินการเขียน จะต้องมีบล็อกจริง ไม่ใช่อิมเมจ CR อินสแตนซ์การถือครองจึงส่งบล็อกจริง แต่สามารถเก็บ PI ของบล็อกไว้ได้จนกว่าจะเขียนบล็อกลงในดิสก์ ดังนั้น หากอินสแตนซ์ใดล้มเหลวหรือขัดข้อง Oracle สามารถสร้างบล็อกโดยใช้ PIfrom ข้ามอินสแตนซ์ RAC ได้ เมื่อบล็อกถูกเขียนลงดิสก์แล้ว ก็ไม่จำเป็นต้องมีการคุ้มครองในกรณีที่เกิดการขัดข้อง ดังนั้น PI ที่เกี่ยวข้องจึงสามารถละทิ้งได้”
เรียนรู้เพิ่มเติมเกี่ยวกับบริการข้อมูลของเรา
ใช้แท็บคำติชมเพื่อแสดงความคิดเห็นหรือถามคำถาม คุณสามารถเริ่มการสนทนากับเราได้
