Yêu cầu của DBA không có ý nghĩa.
Điều mà DBA gần như chắc chắn đang nghĩ là anh ta muốn giảm thiểu số lần dịch chuyển ngữ cảnh công cụ SQL sang PL / SQL diễn ra khi bạn đang tìm nạp dữ liệu từ con trỏ. Nhưng giải pháp đang được đề xuất không được nhắm mục tiêu vào vấn đề cụ thể này và gây ra các vấn đề hiệu suất nghiêm trọng hơn nhiều trong hầu hết các hệ thống.
Trong Oracle, một sự thay đổi ngữ cảnh SQL sang PL / SQL xảy ra khi PL / SQL VM yêu cầu SQL VM cung cấp thêm dữ liệu, SQL VM phản hồi bằng cách thực thi thêm câu lệnh để lấy dữ liệu mà sau đó nó đóng gói và giao lại cho PL / Máy ảo SQL. Nếu công cụ PL / SQL đang yêu cầu từng hàng một và bạn đang tìm nạp rất nhiều hàng, có thể những thay đổi ngữ cảnh này có thể chiếm một phần đáng kể trong thời gian chạy tổng thể của bạn. Để giải quyết vấn đề đó, Oracle đã đưa ra khái niệm hoạt động hàng loạt ít nhất là trong 8i ngày tới. Điều này cho phép PL / SQL VM yêu cầu nhiều hàng cùng một lúc từ SQL VM. Nếu PL / SQL VM yêu cầu 100 hàng cùng một lúc, bạn đã loại bỏ 99% sự thay đổi ngữ cảnh và mã của bạn có khả năng chạy nhanh hơn nhiều.
Sau khi các hoạt động hàng loạt được giới thiệu, có rất nhiều mã có thể được cấu trúc lại để hiệu quả hơn bằng cách sử dụng rõ ràng BULK COLLECT thay vì tìm nạp từng hàng một rồi sử dụng FORALL vòng lặp để xử lý dữ liệu trong các bộ sưu tập đó. Tuy nhiên, vào ngày 10.2, Oracle đã tích hợp các hoạt động hàng loạt vào FOR ngầm định lặp lại để một FOR ngầm hiểu vòng lặp hiện tự động thu thập hàng loạt theo lô 100 thay vì tìm nạp từng hàng một.
Tuy nhiên, trong trường hợp của bạn, vì bạn đang trả lại dữ liệu cho một ứng dụng khách, việc sử dụng các thao tác hàng loạt ít đáng kể hơn nhiều. Bất kỳ API phía máy khách phù hợp nào cũng sẽ có chức năng cho phép máy khách chỉ định số hàng cần được tìm nạp từ con trỏ trong mỗi vòng quay của mạng và các yêu cầu tìm nạp đó sẽ chuyển trực tiếp đến máy ảo SQL, không phải thông qua PL / SQL VM, vì vậy không có sự thay đổi ngữ cảnh SQL sang PL / SQL nào phải lo lắng. Ứng dụng của bạn phải lo lắng về việc tìm nạp số lượng hàng thích hợp trong mỗi chuyến khứ hồi - đủ để ứng dụng không trở nên quá ồn ào và tắc nghẽn trên mạng nhưng không quá nhiều khiến bạn phải đợi quá lâu để có kết quả. trả lại hoặc để lưu trữ quá nhiều dữ liệu trong bộ nhớ.
Việc trả lại các bộ sưu tập PL / SQL thay vì một REF CURSOR cho ứng dụng khách sẽ không làm giảm số lần thay đổi ngữ cảnh diễn ra. Nhưng nó sẽ có một loạt các nhược điểm khác, không ít nhất là việc sử dụng bộ nhớ. Bộ sưu tập PL / SQL phải được lưu trữ hoàn toàn trong khu vực toàn cầu của quy trình (PGA) (giả sử các kết nối máy chủ chuyên dụng) trên máy chủ cơ sở dữ liệu. Đây là một phần bộ nhớ phải được cấp phát từ RAM của máy chủ. Điều đó có nghĩa là máy chủ sẽ phải cấp phát bộ nhớ để lấy mọi hàng cuối cùng mà mọi máy khách yêu cầu. Đến lượt nó, điều đó sẽ hạn chế đáng kể khả năng mở rộng của ứng dụng của bạn và tùy thuộc vào cấu hình cơ sở dữ liệu, có thể ăn cắp RAM từ các phần khác của cơ sở dữ liệu Oracle vốn rất hữu ích trong việc cải thiện hiệu suất ứng dụng. Và nếu bạn hết dung lượng PGA, các phiên của bạn sẽ bắt đầu gặp lỗi liên quan đến bộ nhớ. Ngay cả trong các ứng dụng hoàn toàn dựa trên PL / SQL, bạn sẽ không bao giờ muốn tìm nạp tất cả dữ liệu vào các bộ sưu tập, bạn luôn muốn tìm nạp nó trong các lô nhỏ hơn, để giảm thiểu lượng PGA bạn đang sử dụng.
Ngoài ra, việc tìm nạp tất cả dữ liệu vào bộ nhớ sẽ khiến ứng dụng hoạt động chậm hơn nhiều. Hầu hết mọi khung công tác sẽ cho phép bạn tìm nạp dữ liệu khi bạn cần, ví dụ:nếu bạn có một báo cáo mà bạn đang hiển thị trong các trang gồm 25 hàng mỗi trang, ứng dụng của bạn sẽ chỉ cần tìm nạp 25 hàng đầu tiên trước khi vẽ màn hình đầu tiên. Và nó sẽ không bao giờ phải tìm nạp 25 hàng tiếp theo trừ khi người dùng tình cờ yêu cầu trang kết quả tiếp theo. Tuy nhiên, nếu bạn đang tìm nạp dữ liệu vào các mảng như DBA của bạn đề xuất, bạn sẽ phải tìm nạp tất cả các hàng trước khi ứng dụng của bạn có thể bắt đầu hiển thị hàng đầu tiên ngay cả khi người dùng không bao giờ muốn xem nhiều hơn một số hàng. Điều đó có nghĩa là sẽ có nhiều I / O hơn trên máy chủ cơ sở dữ liệu để tìm nạp tất cả các hàng, nhiều PGA hơn trên máy chủ, nhiều RAM hơn trên máy chủ ứng dụng để đệm kết quả và thời gian chờ mạng lâu hơn.
