Cache Fusion, về cơ bản là việc truyền các block giữa hai instance trong Oracle® Real Application Clusters (RAC), là tính năng chính và quan trọng nhất trong RAC.
Giới thiệu
Theo Oracle trong Oracle RAC Cache Fusion, mỗi "instance [trong] cụm RAC [có] buffer cache cục bộ riêng nơi nó thực hiện chức năng cache. Nhưng khi nhiều người dùng kết nối với các node khác nhau, [người dùng thường] cần truy cập hoặc khóa một data block do [instance] khác sở hữu.
"Trong những trường hợp này, [instance] yêu cầu yêu cầu instance giữ block dữ liệu đó và truy cập nó thông qua [một] cơ chế interconnect. Khái niệm này được gọi là Cache Fusion."
Single Instance (Instance đơn)
Trước khi khám phá Cache Fusion, hãy xem database non-RAC xử lý yêu cầu data block như thế nào.
Dưới đây là quy trình giao dịch 4 bước trong instance đơn (lấy từ bài blog Cache Fusion của Gopi):
- Khi người dùng đọc một block vừa được sửa đổi, có thể tìm thấy một giao dịch đang hoạt động trong block.
- Người dùng sẽ cần đọc undo segment header để quyết định giao dịch đã commit hay chưa.
- Nếu giao dịch chưa commit, tiến trình tạo một phiên bản consistent read (CR) của block trong buffer cache sử dụng dữ liệu trong block và dữ liệu lưu trong undo segment.
- Nếu undo segment cho thấy giao dịch đã commit, tiến trình phải quay lại block và dọn dẹp block cũng như tạo redo cho các thay đổi.
Bây giờ, hãy xem cùng một kịch bản trong RAC với cụm 2 instance, gọi là Cache Fusion.
Cache Fusion
Gopi tiếp tục, "Trong RAC, có [hai] hoặc nhiều instance truy cập cùng các file database [đang ở cùng storage (ví dụ, ASM)]. Mỗi instance có SGA riêng, background processes, nghĩa là mỗi instance có buffer cache riêng (cục bộ cho mỗi instance). Các buffer cache này hoạt động riêng lẻ ở cấp độ instance và hòa hợp ở cấp độ database để hình thành một thực thể duy nhất (Global Cache) [để] chia sẻ data block giữa chúng. Đây chính là điều chúng ta gọi là Cache Fusion. Cache Fusion sử dụng IPC interconnect tốc độ cao để cung cấp chuyển đổi data block cache-to-cache giữa các instance trong cụm. Việc chuyển block dữ liệu này loại bỏ disk I/O và tối ưu hóa độ đồng thời đọc/ghi."
Sự hiểu này dẫn chúng ta đến Global Cache Service (GCS), chịu trách nhiệm chuyển block giữa các instance.
Dưới đây là các background process GCS được nhắc đến trong bài của Gopi:
- Global Cache Service Processes (LMSn)
- Global Enqueue Service Daemon (LMD)
Gopi nói thêm, "Trước khi đi sâu vào các background process này, [sic] hãy xem Oracle xử lý data block như thế nào và quản lý chúng thế nào.
"Oracle coi data block như tài nguyên. Mỗi tài nguyên này có thể được giữ ở các mode khác nhau, đây là [một] cơ chế quan trọng để duy trì tính toàn vẹn dữ liệu. Các mode này được phân loại thành [ba] loại tùy thuộc vào việc holder của tài nguyên có ý định sửa đổi dữ liệu hay chỉ đọc dữ liệu."
Gopi liệt kê các mode như sau:
- Null (N) mode: Null mode thường được giữ làm placeholder.
- Shared (S) mode: Ở mode này, data block không được sửa đổi bởi session khác nhưng cho phép truy cập shared đồng thời.
- Exclusive (X) mode: Cấp độ này trao quyền truy cập độc quyền cho tiến trình giữ. Các tiến trình khác không thể ghi vào tài nguyên. Có thể có các block consistent read.
Global Cache Service Daemon (LMSn)
Khi có yêu cầu từ một instance, Gopi cho biết, "GCS tổ chức việc chuyển block đến các instance khác bằng cách giữ bản sao block trong bộ nhớ. Mỗi bản sao như vậy được gọi là past image (PI). [...] Cũng có thể có nhiều hơn [một] PI của data block tùy thuộc vào số lần block được yêu cầu ở [giai đoạn] dirty."
Lưu ý: Gopi thêm, "Nếu bạn muốn đọc một data block, nó phải được đọc ở [một] trạng thái consistent. Bạn không được phép đọc các thay đổi do người khác thực hiện."
Global Enqueue Service Daemon (LMD)
Gopi giải thích, "Global enqueue service (GES) theo dõi trạng thái của tất cả cơ chế enqueuing của Oracle. GES thực hiện kiểm soát độ đồng thời trên dictionary cache locks, library cache locks, và transactions. Nó thực hiện thao tác này cho các tài nguyên được truy cập bởi nhiều hơn một instance. GES kiểm soát truy cập vào data files và control files nhưng không phải cho data blocks."
Dưới đây là các tài nguyên được GES quản lý mà Gopi chia sẻ:
- Transaction locks: Được lấy ở exclusive mode khi một transaction bắt đầu thay đổi (insert, update, v.v.) Lock được giữ cho đến khi transaction commit hoặc rollback.
- Library Cache locks: Khi một database object (như table, view, package, package body, [...] v.v.) được tham chiếu trong quá trình parsing hoặc compiling SQL, DML hoặc DDL, PL/SQL, hoặc Java statement, tiến trình parsing hoặc compiling statement lấy library cache lock ở mode thích hợp.
- Dictionary Cache Locks: Global enqueues được sử dụng ở chế độ cluster database. Cấu trúc data dictionary giống nhau cho tất cả Oracle instance trong cluster database.
- Table locks: Đây là GES locks bảo vệ toàn bộ table(s). Một transaction lấy table lock khi một table bị sửa đổi. Table lock có thể được giữ ở một số mode: null (N), row share (RS), row exclusive (RX), share lock (S), share row exclusive (SRX), hoặc exclusive (X).
Past Image và Consistent Read Image
Trước khi đi vào kịch bản chính, chúng ta cần hiểu past images (PI) và consistent read (CR) images.
Past Image
Rohit Gupta, trong bài viết Oracle RAC Cache Fusion, chia sẻ, "Khái niệm Past Image rất đặc thù cho thiết lập RAC. Xem xét một instance giữ [một] exclusive lock trên data block để cập nhật. Nếu instance khác trong RAC cần block đó, instance giữ có thể gửi block đến instance yêu cầu (thay vì ghi ra disk) bằng cách giữ một PI (Past Image) của block trong buffer cache của nó. Về cơ bản, PI là bản sao của data block trước khi block được ghi ra disk."
Consistent Read Image:
Gupta tiếp tục, "Consistent read được cần khi một block cụ thể đang được truy cập/sửa đổi bởi transaction [A1], và cùng lúc transaction khác [A2] cố gắng truy cập/đọc block. Nếu [A1] chưa commit, [A2] cần một bản sao consistent read [(block không sửa đổi)] của block để tiến hành. Bản sao CR được tạo sử dụng dữ liệu UNDO cho block đó."
Các kịch bản Cache Fusion
Cache Fusion có ba kịch bản khác nhau:
- Read-Read scenario
- Read-Write scenario
- Write-Write scenario
Read-Read Scenario:
Đây là kịch bản không critical vì instance yêu cầu block và instance chặn yêu cầu đều yêu cầu transaction đọc. Ở đây, không có exclusive lock xảy ra. Instance B yêu cầu read block đến GCS. GCS kiểm tra tính khả dụng của block, do instance A sở hữu, và lấy shared lock. Giờ GCS yêu cầu Instance A gửi block được yêu cầu đến Instance B.
Read-Write Scenario:
Đây là kịch bản critical.
Instance A đang cập nhật data block, nên nó cần lấy exclusive lock. Sau một thời gian, Instance B gửi read request đến GCS cho cùng data block.
GCS kiểm tra và thấy Instance A đã lấy exclusive lock trên cùng block. Vậy GCS yêu cầu Instance A giải phóng block. Bây giờ, Instance A tạo CR Image trong buffer cache của chính nó và thông báo cho GCS để gửi nó đến Instance B.
GCS tham gia vào việc tạo CR image và gửi nó đến instance được yêu cầu là nơi Cache Fusion phát huy tác dụng.
Write-Write Scenario
Instance A và Instance B đều cố gắng lấy exclusive lock trên một data block.
Instance B gửi block request đến GCS. GCS kiểm tra và thấy Instance A đã lấy lock. Do đó, GCS yêu cầu Instance A giải phóng block cho Instance B. Bây giờ, Instance A tạo PI của block hiện tại của nó trong buffer, tạo các redo entry, và thông báo GCS gửi block đến Instance B.
Instance B giờ sử dụng block và thực hiện thay đổi như bình thường.
Sự khác biệt chính giữa CR và PI
Gupta thêm suy nghĩ cuối cùng về PI so với CR images: "[Bản] CR image được gửi để tránh [kiểu] contention Read-Write vì instance yêu cầu không muốn thực hiện write operation và do đó không cần exclusive lock trên block. Vì vậy cho read operation, CR image của block là đủ. Trong khi đối với contention Write-Write, instance yêu cầu cũng cần lấy exclusive lock trên data block. [Để] lấy lock cho write operations, nó cần block thực tế chứ không phải CR image. Instance giữ do đó gửi block thực tế nhưng có trách nhiệm giữ PI của block cho đến khi block đã được ghi ra disk. Vì vậy, nếu có bất kỳ instance failure hoặc crash nào, Oracle có thể xây dựng lại block sử dụng PI từ các instance RAC. Khi block được ghi ra disk, nó sẽ không cần recovery trong trường hợp crash, và các PI liên quan có thể bị loại bỏ."
Tìm hiểu thêm về dịch vụ Data của chúng tôi.
Sử dụng tab Feedback để đưa ra nhận xét hoặc đặt câu hỏi. Bạn cũng có thể bắt đầu cuộc trò chuyện với chúng tôi.