Giới hạn mức độ song song (DOP) có sẵn cho bất kỳ truy vấn nào

Trên Oracle Exadata (11gR2), chúng tôi có một cơ sở dữ liệu tương đối mạnh mẽ.

• cpu_count là 24
• allel_server_instances là 2
• allel_threads_per_cpu là 2

Chúng tôi lưu ý, thông qua quan sát trong Trình quản lý doanh nghiệp Oracle (OEM), hiệu suất đó rất tệ do các truy vấn được thực hiện một cách an toàn. Để giải quyết điều này, tất cả các bảng, các khung nhìn và chỉ mục cụ thể hóa đã được thay đổi để tận dụng lợi thế của sự song song. ví dụ:

ALTER TABLE SOME_TABLE PARALLEL (DEGREE DEFAULT INSTANCES DEFAULT);

Hệ thống đã được thay đổi để bật song song:

ALTER SYSTEM SET PARALLEL_DEGREE_POLICY = 'AUTO';

Điều này dẫn đến hiệu suất tốt hơn nhưng đôi khi chúng tôi quan sát thấy trong OEM rằng một truy vấn duy nhất sẽ buộc DOP là 96 (tất cả các tài nguyên có sẵn). Điều này dẫn đến các truy vấn tiếp theo bị hạ cấp xuống DOP 1 (không song song). Kết quả là hiệu suất kém cho đến khi hoàn thành truy vấn hogging.

Để giải quyết vấn đề này, chúng tôi đã cố gắng giới hạn DOP có sẵn cho bất kỳ truy vấn nào với:

ALTER SYSTEM SET PARALLEL_DEGREE_LIMIT = 24;

Điều này không có tác dụng. Chúng tôi thường xuyên quan sát các truy vấn sẽ sử dụng nhiều hơn giới hạn (thường là 48 hoặc 96, nhưng không có mẫu thực).

Làm thế nào để chúng tôi ngăn chặn bất kỳ truy vấn duy nhất nào ăn cắp tất cả các tài nguyên có sẵn?

Bộ máy chủ song song: PARALLEL_DEGREE_LIMIT giới hạn mức độ song song, nhưng nếu truy vấn của bạn sắp xếp hoặc nhóm số lượng quy trình song song có thể gấp đôi (hai bộ máy chủ để cho phép xử lý song song giữa các quá trình). Điều đó giải thích tại sao bạn sẽ thấy 48 quy trình song song ngay cả với giới hạn 24. Điều này cũng xảy ra nếu bạn sử dụng trình quản lý tài nguyên để giới hạn DOP.

Gợi ý song song: PARALLEL_DEGREE_LIMIT chỉ áp dụng cho các câu lệnh sử dụng mức độ song song tự động. Bất kỳ câu lệnh nào sử dụng mức độ mã hóa cứng, hoặc thậm chí bất kỳ loại gợi ý song song cấp đối tượng nào, sẽ bỏ qua giới hạn. Nếu bạn có những gợi ý đó, điều đó có thể giải thích tại sao bạn thấy 96 lần.

Hiệu chỉnh IO: Có thể DOP tự động không được sử dụng, và do đó giới hạn không được tuân theo, vì IO không được hiệu chỉnh . Truy vấn này sẽ cho bạn biết nếu IO đã được hiệu chỉnh:

select * from V$IO_CALIBRATION_STATUS;

Tôi đã thấy điều này gây ra vấn đề trước đây, nhưng hệ thống hiện tại của tôi không được hiệu chỉnh và DOP tự động dường như hoạt động tốt. Bạn có thể biết liệu đây có thực sự là vấn đề hay không bằng cách xem phần Ghi chú của kế hoạch giải thích. Nếu bạn thấy một cái gì đó như - automatic DOP: Computed Degree of Parallelism is 2bạn ổn, nhưng bạn không muốn thấy automatic DOP: skipped because of IO calibrate statistics are missing.

Tăng PARALLEL_MAX_SERVERS: Thay vì lo lắng về việc hết máy chủ song song, tôi khuyên bạn nên tăng đáng kể PARALLEL_MAX_SERVERS. Ít nhất bạn nên cố gắng quay trở lại giá trị mặc định , PARALLEL_THREADS_PER_CPU x CPU_COUNT x concallel_abul_users x 5, trong khoảng 240 đến 960 tùy thuộc vào cài đặt bộ nhớ của bạn.

Những con số cao này nghe có vẻ vô lý với nhiều DBA, nhưng chúng thực sự có ý nghĩa rất lớn vì những lý do sau:

• Các máy chủ song song của Oracle có trọng lượng nhẹ hơn hầu hết mọi người nghĩ. (Và hầu như không ai từng kiểm tra nó, họ chỉ tìm thấy một tình huống trong đó một DOP lớn gây ra vấn đề và cho rằng DOP cao luôn xấu.)
• Việc chạy truy vấn adhoc trong công cụ GUI chỉ truy xuất 50 hàng đầu tiên, nhưng vẫn sử dụng hàng chục máy chủ song song. Các truy vấn này KHÔNG tiêu thụ bất kỳ tài nguyên quan trọng nào, trừ khi PARALLEL_MAX_SERVERS quá thấp. Sau đó mọi người bị mắng vì chạy các truy vấn hoàn toàn hợp lý, điều này có thể dẫn đến một số tình huống xấu.
• Một DOP rất lớn cho một truy vấn không phải lúc nào cũng xấu. Mọi người đều cho rằng nếu bạn tiếp tục tăng DOP, thì chi phí sẽ tăng quá cao và hiệu suất sẽ giảm đáng kể. Nhưng trên nhiều hệ thống, tôi thấy rằng ngay cả một DOP cao một cách lố bịch sẽ dẫn đến hiệu suất tốt hơn, mặc dù có lợi nhuận giảm dần, và nó có thể rất không công bằng cho các phiên khác. Nhưng đừng chỉ đoán, kiểm tra nó; lấy một truy vấn và chạy nó với tất cả các loại DOP, lên tới 1000. Bạn có thể ngạc nhiên.
• Vâng, quá nhiều song song có thể là xấu. Nhưng điều gì tồi tệ hơn cho hệ thống, có nhiều hơn một chút so với số phiên tối ưu hoặc buộc một truy vấn nối tiếp và về cơ bản giết chết một công việc quan trọng? Bạn nên theo dõi hệ thống trước khi đưa ra các giới hạn tùy ý.