Căn cứ vào nhu cầu về sử dụng một tập tin cụ thể, tài nguyên được duy trì trên các trường hợp được sử dụng nhiều nhất. Ví dụ, nếu SSKY1 được truy cập vào một đối tượng A1 và đối tượng đã được xử lý khoảng 1.500 yêu cầu dữ liệu từ người sử dụng, tất cả các trường hợp kết nối SSKY1, và trường hợp SSKY2 truy cập cũng cần thiết đến các đối tượng A1 cho 100 người sử dụng, rõ ràng là SSKY1 sẽ có nhiều người dùng truy cập vào đối tượng A1 này. Do đó, trường hợp SSKY1 sẽ được phân bổ như chủ tài nguyên cho đối tượng này, và GRD (Global Resource Directory) cho đối tượng này sẽ được duy trì trên SSKY1. Khi SKY2 yêu cầu thông tin từ đối tượng này, nó sẽ phải phối hợp với GCS (Global Cache Services) và GRD trên SSKY1 để lấy / chuyển dữ liệu qua kết nối cluster.
Nếu mô hình sử dụng thay đổi, ví dụ, số lượng người dùng trên SSKY2 tăng đến 2.000 và trên SSKY1 giảm xuống đến 500, tiến trình GCS và GES (Global Enqueue Service), sẽ kết hợp và đánh giá mô hình sử dụng hiện tại và chuyển giao quản lý tài nguyên thông qua các kết nối đến SSKY2. Toàn bộ quá trình quản lý lại các nguồn tài nguyên này được gọi là mối quan hệ tài nguyên. Nói cách khác, mối quan hệ tài nguyên là việc sử dụng các nguồn tài nguyên động quản lý lại để di chuyển vị trí của quản lý tài nguyên cho một tập tin cơ sở dữ liệu với các trường hợp hoạt động khối thường xuyên xảy ra nhất.
Mối quan hệ tối ưu hóa hệ thống nguồn tài nguyên trong các tình huống giao dịch cập nhật được thực hiện trên một trong những trường hợp. Nếu hoạt động không được khoanh vùng,
quyền sở hữu tài nguyên được phân phối đến các trường một cách công bằng.
Hình 2.5, minh họa phân phối tài nguyên trong một nhóm
bốn nút. Đó là các các trường hợp SSKY1, SSKY2, SSKY3, SSKY4 và nguồn tài nguyên tương ứng R1, R2, R3, R4, R5, R6, R7.
Hình 2.5. Quản lý nguồn tài nguyên
Quản lý tài nguyên trên các trường hợp mà tại đó các hoạt động của người dùng là cao nhất cho phép tối ưu hóa trên cluster và giúp đạt được khối lượng phân phối công việc và thời gian khởi động nhanh hơn. Trên một hệ thống bận rộn, hiệu năng hệ thống có thể bị ảnh hưởng nếu khối lượng công việc thay đổi liên tục trên hệ thống đó, dẫn đến sử dụng nguồn lực để thay đổi và, đến lượt nó làm cho nguồn tài nguyên này hoạt động liên tục. Quá trình này cũng xảy ra khi có một nút tham ra hoặc rời khỏi nhóm. Tuy nhiên, thay vì quản lý tất cả các khóa/các nguồn tài nguyên trên tất cả các nút, Oracle sử dụng một thuật toán gọi là “lazy remastering”. Theo thuật toán này, thay vì các nguồn cân bằng tải bằng cách loại bỏ tất cả các nguồn tài nguyên và quản lý tài nguyên như nhau trên các instances, Oracle chỉ quản lý các nguồn tài nguyên thuộc quyền
Hình 2.6: Minh họa việc quản lý lại các nguồn lực từ trường
hợp SSKY4 đến trường hợp SSKY2, và SSKY3 tương ứng.
Hình 2.6. Quản lý lại nguồn tài nguyên
Nếu trường hợp SSKY4 xảy ra lỗi, SSKY1 và SSKY2 sẽ tiếp tục làm chủ các nguồn tài nguyên của chúng, cụ thể là R1 R2, R3, R4. Là một phần của quá trình phục hồi, quản lý các nguồn tài nguyên trong trường hợp xảy ra lỗi, lúc đó các nguồn tài nguyên này sẽ được làm chủ bởi một trong các instance còn lại. Oracle sử dụng khái niệm quản lý lại và tự động đặt các nguồn tài nguyên lên một trong các instance còn lại. Do đó, trong hình trên, R6 được thừa hưởng bởi SSKY2 và R7 được kế thừa SSKY3, SSKY1 không bị ảnh hưởng.
Sau một khoảng thời gian, khi khối lượng công việc người sử dụng đã ổn định (tức là phục hồi được hoàn thành), GCS và GES sẽ đánh giá lại tình hình và thực hiện một hoạt động quản lý lại trên các trường hợp nơi mà nhu cầu cao. Một hoạt động tương tự sẽ xảy ra khi một instance tham gia vào nhóm. Về cơ bản, một tài nguyên được lấy ra từ mỗi instance có sẵn và chuyển đến các instance tham gia vào nhóm.
Quản lý lại cũng sẽ xảy ra khi một instance không hoạt động. Oracle yêu cầu nguồn lực bổ sung để quản lý tổng thể tài nguyên khác. Trong hoàn cảnh này, Oracle sẽ quản lý di chuyển nguồn tài nguyên mà không được truy cập đến một instance ít hoạt động hơn.