Chính xác thì ý bạn là gì khi "đặt hàng" trong ngữ cảnh này?
Theo mặc định, mỗi nút trong cụm có một bộ nhớ cache số thứ tự riêng biệt. Vì vậy, nút 1 có thể đang phân phối các giá trị 1-100 trong khi nút 2 đang phân phối các giá trị 101-200. Các giá trị được trả về từ một nút duy nhất là tuần tự, nhưng phiên A trên nút 1 có thể nhận giá trị là 15 trong khi phiên B trên nút 2 nhận giá trị 107 nên các giá trị được trả về giữa các phiên có vẻ không theo thứ tự.
Nếu bạn chỉ định rằng trình tự phải được sắp xếp theo thứ tự, về cơ bản bạn đang đánh bại mục đích của bộ đệm trình tự vì Oracle giờ đây phải giao tiếp giữa các nút mỗi khi bạn yêu cầu một giá trị trình tự mới. Điều đó có khả năng tạo ra một lượng chi phí hiệu suất kha khá. Nếu bạn đang sử dụng trình tự như một loại dấu thời gian, chi phí đó có thể cần thiết nhưng nhìn chung không mong muốn.
Sự khác biệt về chi phí trong điều kiện thực tế sẽ phụ thuộc nhiều vào ứng dụng - nó sẽ rất nhỏ đối với một số ứng dụng và là một vấn đề đáng kể đối với những ứng dụng khác. Số lượng các nút RAC, tốc độ của kết nối và lượng lưu lượng kết nối ở đó cũng sẽ đóng góp. Và vì đây chủ yếu là vấn đề về khả năng mở rộng, nên hiệu quả thực tế sẽ hạn chế mức độ mở rộng ứng dụng của bạn vốn là phi tuyến tính. Tăng gấp đôi khối lượng giao dịch mà ứng dụng của bạn xử lý sẽ tăng hơn gấp đôi tổng chi phí.
Nếu bạn chỉ định NOCACHE, việc lựa chọn ORDER hoặc NOORDER về cơ bản là không thể thay đổi. Nếu bạn chỉ định ORDER, việc lựa chọn CACHE hoặc NOCACHE về cơ bản là không thể thay đổi. Vì vậy CACHE NOORDER cho đến nay là hiệu quả nhất, ba cái còn lại tương đối có thể thay thế cho nhau. Tất cả chúng đều sẽ liên quan đến sự phối hợp giữa các nút và lưu lượng mạng mỗi khi bạn yêu cầu một giá trị trình tự, rõ ràng đây là một nút thắt cổ chai tiềm ẩn.
Nói chung sẽ thích hơn nếu thêm cột TIMESTAMP vào bảng để lưu trữ dấu thời gian thực tế hơn là dựa vào trình tự để cung cấp thứ tự dấu thời gian.
