Các truy vấn của bạn không thực sự hoàn thành. Mặc dù truy vấn của bạn chỉ tìm nạp 1000 hàng đầu tiên, nhưng Nhà phát triển SQL chỉ tìm nạp 50 hàng đầu tiên trong số 1000 hàng đó. IDE sẽ không đóng con trỏ cho đến khi bạn cuộn đến hàng cuối cùng. Khi bạn truy xuất tất cả dữ liệu, các quá trình song song đó sẽ biến mất. Đảm bảo rằng bạn thấy "Đã tìm nạp tất cả các hàng:1000 trong X giây", thay vì "" Đã tìm nạp 50 hàng trong Y giây ". (Tôi ước Nhà phát triển SQL sẽ hiển thị rõ ràng hơn rằng có các hàng bổ sung đang chờ.) Bạn sẽ không gặp sự cố này trong SQL * Plus vì SQL * Plus luôn lấy tất cả các hàng.
Khi chỉ có N hàng đầu tiên được tìm nạp, các quá trình song song đó là "HOẠT ĐỘNG" nhưng không làm gì cả. Bạn nên có thể bỏ qua các phiên đó vì chúng không sử dụng bất kỳ tài nguyên quan trọng nào.
Nếu bạn chỉ lo lắng về số lượng phiên song song, bạn có thể muốn điều chỉnh kỳ vọng của mình. Tôi đã từng ở trong trường hợp tương tự như bạn - liên tục nói với người dùng rằng các truy vấn (chưa hoàn thành) của họ đang gây khó khăn cho tất cả các phiên song song. Cuối cùng, tôi phát hiện ra rằng đó chỉ là một vấn đề bởi vì tôi đã tạo ra một nguồn tài nguyên khan hiếm giả tạo. Các quy trình song song của Oracle thường nhẹ và cơ sở dữ liệu có thể hỗ trợ nhiều quy trình song song hơn mọi người nghĩ.
Giá trị thông số của bạn cho PARALLEL_MAX_SERVERS, PARALLEL_THREADS_PER_CPU và CPU_COUNT là gì? Xem giá trị mặc định cho PARALLEL_MAX_SERVERS
. Theo sách hướng dẫn, số mặc định là:PARALLEL_MAX_SERVERS = PARALLEL_THREADS_PER_CPU * CPU_COUNT * concurrent_parallel_users * 5 .
Hầu hết các DBA nhìn thấy số lượng tối đa các chuỗi song song trong hàng trăm, hoảng sợ, và sau đó giảm số đó. Và sau đó, chúng tôi bắt đầu la mắng các nhà phát triển vì đã sử dụng một nguồn tài nguyên không quan trọng bị giới hạn một cách giả tạo. Thay vào đó, chúng ta nên sao lưu số về mặc định và chỉ bỏ qua các phiên song song ngẫu nhiên. Nếu người dùng không vượt quá giới hạn IO hoặc CPU, thì họ sử dụng bao nhiêu luồng song song không thành vấn đề.
(Ngoại trừ khả năng ngăn chặn lớn sử dụng phiên truy vấn song song. Đưa người dùng của bạn vào một hồ sơ khác và đặt SESSIONS_PER_USER của họ thành một vài chục. KHÔNG giới hạn nó chỉ ở 1 hoặc 2. IDE cần thêm phiên cho nhiều tab, quy trình nền lấy siêu dữ liệu và phiên gỡ lỗi. Nếu bạn đặt giới hạn thành 2, các nhà phát triển của bạn sẽ không thể sử dụng IDE đúng cách.)
CHỈNH SỬA (phản hồi nhận xét)
Tôi không chắc liệu bạn có thể đọc nhiều về trạng thái của điều phối viên truy vấn . QC thực hiện một số việc, nhưng lý tưởng nhất là nó sẽ không hoạt động trong hầu hết thời gian trong khi các phiên song song xử lý hầu hết công việc.
Với mô hình nhà sản xuất / người tiêu dùng, một nửa số phiên song song có thể đang nhận dữ liệu nhưng không thực sự làm được gì - giống như chúng chỉ là cấu trúc bộ nhớ trong một số hoạt động. Các phiên song song có thể chuyển đổi giữa hoạt động và không hoạt động, vì không phải tất cả các bước đều cần nhiều phiên. Nhưng chúng tôi sẽ không muốn Oracle đóng các phiên giữa chừng, vì chúng có thể cần thiết sau này và chúng tôi sẽ không muốn lãng phí thời gian mở và đóng các phiên.
Có hàng tá yếu tố ảnh hưởng đến mức độ song song, nhưng theo tôi biết việc tăng PARALLEL_MAX_SERVERS sẽ không ảnh hưởng đến số lượng máy chủ song song được yêu cầu cho một câu lệnh. (Nhưng nếu câu lệnh đã yêu cầu nhiều máy chủ hơn mức tối đa, việc tăng tham số có thể ảnh hưởng đến số lượng phiên được phân bổ).
Có thể cảm giác như các câu lệnh SQL chỉ lấy ngẫu nhiên tất cả các phiên song song, nhưng cuối cùng các phép tính DOP hầu như luôn tuân theo các quy tắc xác định. Chỉ là các quy tắc phức tạp quá, rất khó để biết nó hoạt động như thế nào. Ví dụ:một điểm nhầm lẫn phổ biến là bất cứ khi nào truy vấn thêm tính năng sắp xếp hoặc nhóm, số phiên song song sẽ tăng gấp đôi.
