Cache Fusion คือการถ่ายโอนบล็อกข้อมูลระหว่างสอง instance ใน Oracle® Real Application Clusters (RAC) ซึ่งเป็นฟีเจอร์หลักและสำคัญที่สุดของ RAC
บทนำ
ตาม Oracle ในเอกสาร Oracle RAC Cache Fusion "แต่ละ instance ใน RAC cluster มี local buffer cache ของตัวเองที่ทำหน้าที่ cache functionality แต่เมื่อผู้ใช้หลายคนเชื่อมต่อกับโหนดที่ต่างกัน ผู้ใช้มักต้องการเข้าถึงหรือล็อกบล็อกข้อมูลที่เป็นของอีก instance หนึ่ง
ในกรณีเช่นนี้ instance ที่ร้องขอจะขอ instance ที่ถือครองบล็อกข้อมูลนั้น และเข้าถึงผ่านกลไก interconnect แนวคิดนี้เรียกว่า Cache Fusion"
Single Instance (Instance เดียว)
ก่อนจะสำรวจ Cache Fusion มาเดูว่า non-RAC databases พฤติกรรมอย่างไรเมื่อมีคำขอบล็อกข้อมูล
กระบวนการทำธุรกรรม 4 ขั้นตอนใน single instance (มาจากบล็อกของ Gopi เกี่ยวกับ Cache Fusion):
- เมื่อผู้ใช้อ่านบล็อกที่ถูกแก้ไขล่าสุด อาจพบ active transaction ในบล็อกนั้น
- ผู้ใช้จะต้องอ่าน undo segment header เพื่อตัดสินใจว่า transaction ถูก commit หรือยัง
- ถ้า transaction ยังไม่ commit กระบวนการจะสร้าง consistent read (CR) version ของบล็อกใน buffer cache โดยใช้ข้อมูลในบล็อกและข้อมูลที่เก็บใน undo segment
- ถ้า undo segment แสดงว่า transaction committed แล้ว กระบวนการต้องกลับไปที่บล็อกอีกครั้ง และ clean out บล็อก และสร้าง redo สำหรับการเปลี่ยนแปลง
ตอนนี้มาเดูสถานการณ์เดียวกันใน RAC ด้วย two-instance cluster ซึ่งเรียกว่า Cache Fusion
Cache Fusion
Gopi อธิบายต่อว่า "ใน RAC มี instance สองตัวหรือมากกว่าที่เข้าถึง database files เดียวกัน (อยู่ใน storage เดียวกัน เช่น ASM) แต่ละ instance มี SGA, background processes ของตัวเอง หมายความว่าแต่ละ instance มี buffer cache ของตัวเอง (local ต่อแต่ละ instance) Buffer cache เหล่านี้ทำงานแยกกันที่ระดับ instance และรวมกันที่ระดับ database เพื่อสร้าง entity เดียว (Global Cache) เพื่อแชร์บล็อกข้อมูลระหว่างกัน นี่คือสิ่งที่เราเรียกว่า Cache Fusion Cache Fusion ใช้ high-speed IPC interconnect เพื่อให้เกิด cache-to-cache transfers ของบล็อกข้อมูลระหว่าง instances ใน cluster การส่งบล็อกข้อมูลนี้กำจัด disk I/O และเพิ่มประสิทธิภาพ read/write concurrency"
ความเข้าใจนี้นำเราไปสู่ Global Cache Service (GCS) ซึ่งรับผิดชอบการถ่ายโอนบล็อกระหว่าง instances
GCS background processes ที่กล่าวถึงในบทความของ Gopi:
- Global Cache Service Processes (LMSn)
- Global Enqueue Service Daemon (LMD)
Gopi กล่าวต่อว่า "ก่อนจะไปที่ background processes เหล่านี้ มาเดูว่า Oracle จัดการกับบล็อกข้อมูลอย่างไร และจัดการมันอย่างไร
Oracle จัดการบล็อกข้อมูลเป็น resources แต่ละ resource สามารถถือครองได้ในโหมดที่ต่างกัน ซึ่งเป็นกลไกสำคัญในการรักษาความสมบูรณ์ของข้อมูล โหมดเหล่านี้แบ่งเป็น 3 ประเภท ขึ้นอยู่กับว่า resource holder ต้องการแก้ไขข้อมูลหรืออ่านข้อมูล"
Gopi แสดงโหมดดังนี้:
- Null (N) mode: Null mode ปกติถือครองเป็น placeholder
- Shared (S) mode: ในโหมดนี้ บล็อกข้อมูลไม่ถูกแก้ไขโดย session อื่น แต่จะอนุญาตให้เข้าถึงแบบ shared พร้อมกันได้
- Exclusive (X) mode: ระดับนี้ให้การเข้าถึงเฉพาะตัวแก่กระบวนการที่ถือครอง กระบวนการอื่นไม่สามารถเขียนทรัพยากรได้ อาจมี consistent read blocks
Global Cache Service Daemon (LMSn)
เมื่อมีคำขอจาก instance Gopi บอกว่า "GCS จัดการการส่งบล็อกไปยัง instances อื่นๆ โดยเก็บ copies ของบล็อกไว้ในหน่วยความจำ แต่ละ copy เรียกว่า past image (PI) [...] ยังเป็นไปได้ที่จะมี PI ของบล็อกข้อมูลมากกว่าหนึ่ง ขึ้นอยู่กับว่าบล็อกถูกขอใน dirty stage กี่ครั้ง"
หมายเหตุ: Gopi เพิ่มว่า "ถ้าคุณต้องการอ่านบล็อกข้อมูล มันต้องอ่านใน consistent state คุณไม่ได้รับอนุญาตให้อ่านการเปลี่ยนแปลงที่ทำโดยผู้อื่น"
Global Enqueue Service Daemon (LMD)
Gopi อธิบายว่า "Global enqueue service (GES) ติดตามสถานะของ Oracle enqueuing mechanisms ทั้งหมด GES ทำ concurrency control บน dictionary cache locks, library cache locks และ transactions มันดำเนินการนี้สำหรับ resources ที่ถูกเข้าถึงโดยมากกว่าหนึ่ง instance GES ควบคุมการเข้าถึง data files และ control files แต่ไม่ใช่สำหรับ data blocks"
GES managed resources ที่ Gopi แชร์:
- Transaction locks: ได้รับใน exclusive mode เมื่อ transaction เริ่มเปลี่ยนแปลง (insert, update, etc.) Lock ถูกถือครองจนกว่า transaction จะ commit หรือ rollback
- Library Cache locks: เมื่อ database object (เช่น table, view, package, package body, [...] ฯลฯ) ถูกอ้างอิงระหว่าง parsing หรือ compiling ของ SQL, DML หรือ DDL, PL/SQL หรือ Java statement กระบวนการที่ parse หรือ compile statement จะได้ library cache lock ในโหมดที่ถูกต้อง
- Dictionary Cache Locks: Global enqueues ถูกใช้ใน cluster database mode โครงสร้าง data dictionary เหมือนกันสำหรับ Oracle instances ทั้งหมดใน cluster database
- Table locks: นี่คือ GES locks ที่ปกป้อง table(s) ทั้งหมด Transaction ได้รับ table lock เมื่อ table ถูกแก้ไข Table lock สามารถถือครองได้ในหลายโหมด: null (N), row share (RS), row exclusive (RX), share lock (S), share row exclusive (SRX), หรือ exclusive (X)
Past และ Consistent Read Images
ก่อนจะไปสู่สถานการณ์หลัก เราต้องเข้าใจ past images (PI) และ consistent read (CR) images
Past Image
Rohit Gupta ในบทความ Oracle RAC Cache Fusion แชร์ว่า "แนวคิดของ Past Image เฉพาะเจาะจงสำหรับ RAC setup พิจารณา instance ที่ถือ exclusive lock บนบล็อกข้อมูลสำหรับ updates หาก instance อื่นใน RAC ต้องการบล็อกนั้น instance ที่ถือครองสามารถส่งบล็อกไปยัง instance ที่ร้องขอ (แทนที่จะเขียนลงดิสก์) โดยเก็บ PI (Past Image) ของบล็อกไว้ใน buffer cache ของมัน โดยพื้นฐาน PI คือ copy ของบล็อกข้อมูลก่อนที่บล็อกจะถูกเขียนลงดิสก์"
Consistent Read Image
Gupta กล่าวต่อว่า "Consistent read จำเป็นเมื่อบล็อกเฉพาะถูกเข้าถึง/แก้ไขโดย transaction [A1] และในเวลาเดียวกัน transaction อื่น [A2] พยายามเข้าถึง/อ่านบล็อก ถ้า [A1] ยังไม่ commit [A2] ต้องการ consistent read (non-modified block) copy ของบล็อกเพื่อดำเนินต่อไป CR copy ถูกสร้างโดยใช้ UNDO data สำหรับบล็อกนั้น"
Cache Fusion Scenarios
Cache Fusion มี 3 สถานการณ์ที่แตกต่างกัน:
- Read-Read scenario
- Read-Write scenario
- Write-Write scenario
Read-Read Scenario
นี่คือสถานการณ์ที่ไม่สำคัญ เพราะ instance ที่ร้องขอบล็อก และ instance ที่บล็อกคำขอ ทั้งคู่ร้องขอ read transactions ที่นี่ไม่มี exclusive lock เกิดขึ้น Instance B ร้องขอ read block ให้ GCS GCS ตรวจสอบความพร้อมของบล็อกซึ่งเป็นของ instance A และได้ shared lock ตอนนี้ GCS ขอให้ Instance A ส่งบล็อกที่ร้องขอไปยัง Instance B
Read-Write Scenario
นี่คือสถานการณ์สำคัญ
Instance A กำลังอัปเดตบล็อกข้อมูล ดังนั้นต้องได้ exclusive lock หลังจากผ่านไปสักพัก Instance B ส่ง read request ให้ GCS สำหรับบล็อกข้อมูลเดียวกัน
GCS ตรวจสอบและพบว่า Instance ได้ exclusive lock บนบล็อกเดียวกัน ดังนั้น GCS ขอให้ Instance A ปล่อยบล็อก ตอนนี้ Instance A สร้าง CR Image ใน buffer cache ของตัวเอง และแจ้ง GCS ตามนั้นเพื่อส่งไปยัง Instance B
GCS เกี่ยวข้องกับการสร้าง CR image และการส่งไปยัง instance ที่ร้องขอ นี่คือที่ที่ Cache Fusion เข้ามามีบทบาท
Write-Write Scenario
Instance A และ Instance B พยายามได้ exclusive lock บนบล็อกข้อมูล
Instance B ส่ง block request ให้ GCS GCS ตรวจสอบความพร้อมและพบว่า Instance A ได้ lock ไว้ ดังนั้น GCS ขอให้ Instance A ปล่อยบล็อกให้ Instance B ตอนนี้ Instance A สร้าง PI ของ current block ของตัวเองใน buffer สร้าง redo entries และแจ้ง GCS ส่งบล็อกไปยัง Instance B
Instance B ตอนนี้ใช้บล็อกและทำการเปลี่ยนแปลงตามปกติ
ความแตกต่างหลักระหว่าง CR และ PI
Gupta เพิ่มความคิดเห็นสุดท้ายเกี่ยวกับ PI เทียบกับ CR images: "CR image ถูกส่งเพื่อหลีกเลี่ยง Read-Write type of contention เพราะ requesting instance ไม่ต้องการทำ write operation และจึงไม่ต้องการ exclusive lock บนบล็อก ดังนั้นสำหรับ read operation CR image ของบล็อกก็เพียงพอแล้ว ในขณะที่สำหรับ Write-Write contention requesting instance ก็ต้องได้ exclusive lock บนบล็อกข้อมูล เพื่อได้ lock สำหรับ write operations มันต้องการ actual block ไม่ใช่ CR image Instance ที่ถือครองจึงส่ง actual block แต่ต้องรับผิดชอบเก็บ PI ของบล็อกจนกว่าบล็อกจะถูกเขียนลงดิสก์ ดังนั้นถ้ามี instance failure หรือ crash Oracle สามารถสร้างบล็อกใหม่ได้โดยใช้ PI จาก RAC instances ทั้งหมด เมื่อบล็อกถูกเขียนลงดิสก์แล้ว มันจะไม่ต้องการ recovery ในกรณี crash และ PI ที่เกี่ยวข้องสามารถทิ้งได้"
เรียนรู้เพิ่มเติมเกี่ยวกับบริการข้อมูลของเรา
ใช้แท็บ Feedback เพื่อแสดงความคิดเห็นหรือถามคำถาม คุณยังสามารถเริ่มการสนทนากับเราได้
