Điều quan trọng nhất cần hiểu về tính song song của Oracle là nó phức tạp. Tối ưu hóa tính song song đòi hỏi nhiều kiến thức về Oracle, đọc hướng dẫn sử dụng, kiểm tra nhiều tham số, kiểm tra các truy vấn chạy dài và rất nhiều hoài nghi.
Đặt câu hỏi phù hợp
Các vấn đề song song thực sự liên quan đến ba câu hỏi khác nhau:
- Có bao nhiêu máy chủ song song được yêu cầu?
- Có bao nhiêu máy chủ song song được cấp phát?
- Có bao nhiêu máy chủ song song đã được sử dụng một cách có ý nghĩa?
Sử dụng các công cụ tốt nhất
Đi thẳng đến công cụ tốt nhất - Giám sát SQL với các báo cáo đang hoạt động. Tìm SQL_ID của bạn và tạo báo cáo HTML:select dbms_sqltune.report_sql_monitor(sql_id => 'your_sql_id', type => 'active') from dual; . Đây là cách duy nhất để biết đã dành bao nhiêu thời gian cho mỗi bước trong kế hoạch thực hiện. Và nó sẽ cho bạn biết mức độ song song đã được sử dụng một cách hiệu quả và ở đâu. Ví dụ:
Một tùy chọn tốt khác là type => 'text' . Nó không có nhiều thông tin nhưng xem nhanh hơn và dễ chia sẻ hơn.
Giám sát SQL cũng bao gồm DOP được yêu cầu và DOP được phân bổ:
select 100 dòng song song có thể chạy đẹp, nhưng sau đó mọi thứ tạm dừng ở một bước duy nhất vì một trình tự chưa được xóa. Bạn có thể nhìn chằm chằm vào một kế hoạch giải thích, một dấu vết hoặc một báo cáo AWR trong nhiều giờ mà không thấy vấn đề. Báo cáo hoạt động làm cho các bước chậm gần như không thể tìm thấy. Đừng lãng phí thời gian để đoán xem vấn đề nằm ở đâu.
Tuy nhiên, các công cụ khác vẫn được yêu cầu. Một kế hoạch giải thích được tạo bằng explain plan for ... và select * from table(dbms_xplan.display); sẽ cung cấp một vài thông tin chính. Cụ thể là Notes phần có thể bao gồm nhiều lý do tại sao truy vấn không yêu cầu song song.
Nhưng TẠI SAO tôi lại nhận được số lượng máy chủ song song đó?
Thông tin liên quan được lan truyền trên nhiều sách hướng dẫn khác nhau, rất hữu ích nhưng đôi khi không chính xác hoặc gây hiểu lầm. Có rất nhiều huyền thoại và nhiều lời khuyên xấu về sự song song. Và công nghệ thay đổi đáng kể theo từng bản phát hành.
Khi bạn tổng hợp tất cả các nguồn có uy tín, danh sách các yếu tố ảnh hưởng đến số lượng máy chủ song song là lớn một cách đáng kinh ngạc. Danh sách dưới đây được sắp xếp theo thứ tự mà tôi nghĩ là các yếu tố quan trọng nhất:
- Tính song song giữa các hoạt động Bất kỳ truy vấn nào sử dụng sắp xếp hoặc nhóm sẽ phân bổ gấp đôi số máy chủ song song so với DOP. Điều này có lẽ là nguyên nhân dẫn đến câu chuyện hoang đường "Oracle phân bổ càng nhiều máy chủ song song càng tốt!".
- Gợi ý truy vấn Tốt hơn là gợi ý cấp câu lệnh như
/*+ parallel */hoặc có thể là gợi ý cấp đối tượng như/*+ noparallel(table1) */. Nếu một bước cụ thể của kế hoạch đang chạy nối tiếp, thì đó thường là do các gợi ý cấp đối tượng chỉ trên một phần của truy vấn. - SQL đệ quy Một số hoạt động có thể chạy song song nhưng có thể được tuần tự hóa một cách hiệu quả bằng SQL đệ quy. Ví dụ, một trình tự chưa được lưu trên một phụ trang lớn. SQL đệ quy được tạo ra để phân tích cú pháp câu lệnh cũng sẽ được nối tiếp; ví dụ:truy vấn lấy mẫu động.
- Phiên thay thế
alter session [force|enable] parallel [query|dml|ddl];Lưu ý rằng DML song song bị tắt theo mặc định. - Bảng độ
- Mức độ chỉ mục
- Chỉ mục rẻ hơn Các gợi ý song song chỉ cho trình tối ưu hóa xem xét việc quét toàn bộ bảng với một DOP nhất định. Họ không thực sự ép buộc song song. Trình tối ưu hóa vẫn miễn phí sử dụng truy cập chỉ mục nối tiếp nếu nó cho rằng nó rẻ hơn. (
FULLgợi ý có thể giúp giải quyết vấn đề này.) - Quản lý kế hoạch Cơ sở Kế hoạch SQL, phác thảo, hồ sơ, viết lại nâng cao và Trình dịch SQL đều có thể thay đổi mức độ song song sau lưng bạn. Kiểm tra phần Ghi chú của kế hoạch.
- Ấn bản Chỉ các Phiên bản Doanh nghiệp và Cá nhân mới cho phép hoạt động song song. Ngoại trừ gói DBMS_PARALLEL_EXECUTE.
- PARALLEL_ADAPTIVE_MULTI_USER
- PARALLEL_AUTOMATIC_TUNING
- PARALLEL_DEGREE_LIMIT
- PARALLEL_DEGREE_POLICY
- PARALLEL_FORCE_LOCAL
- PARALLEL_INSTANCE_GROUP
- PARALLEL_IO_CAP_ENABLED
- PARALLEL_MAX_SERVERS Đây là giới hạn trên cho toàn bộ hệ thống. Có một sự đánh đổi ở đây. Chạy quá nhiều máy chủ song song cùng một lúc có hại cho hệ thống. Tuy nhiên, hạ cấp một truy vấn thành nối tiếp có thể là thảm họa đối với một số truy vấn.
- PARALLEL_MIN_PERCENT
- PARALLEL_MIN_SERVERS
- PARALLEL_MIN_TIME_THRESHOLD
- PARALLEL_SERVERS_TARGET
- PARALLEL_THREADS_PER_CPU
- Số lượng nút RAC Một hệ số khác cho DOP mặc định.
- CPU_COUNT Nếu DOP mặc định được sử dụng.
- RECOVERY_PARALLELISM
- FAST_START_PARALLEL_ROLLBACK
- Hồ sơ
SESSIONS_PER_USERcũng giới hạn các máy chủ song song. - Người quản lý tài nguyên
- Tải hệ thống Nếu song song_adaptive_multi_user là true. Có lẽ không thể đoán được khi nào Oracle sẽ bắt đầu điều chỉnh.
- CÁC QUY TRÌNH
- Các hạn chế DML song song DML song song sẽ không hoạt động nếu bất kỳ trường hợp nào sau đây:
- TƯƠNG THÍCH <9.2 cho phân vùng nội bộ
- CHÈN GIÁ TRỊ, bảng có trình kích hoạt
- sao chép
- tính toàn vẹn tự tham chiếu hoặc xóa các ràng buộc toàn vẹn theo dòng hoặc hoãn lại
- truy cập một cột đối tượng
- bảng không phân vùng với LOB
- song song trong phân vùng với LOB
- giao dịch phân tán
- bảng nhóm
- bảng tạm thời
- Truy vấn con vô hướng không chạy song song? Cái này có trong sách hướng dẫn và tôi ước cái này là nhưng các bài kiểm tra của tôi chỉ ra rằng tính năng song song hoạt động ở đây sau 11g.
- ENQUEUE_RESOURCES Tham số ẩn trong 10g, điều này có liên quan nữa không?
- Bảng được tổ chức theo chỉ mục Không thể chèn đường dẫn trực tiếp vào IOT song song? (Điều này có còn đúng không?)
- Yêu cầu đối với chức năng pipelined song song Phải sử dụng
CURSOR(?). VIỆC LÀM. - Các hàm phải là PARALLEL_ENABLE
- Loại tuyên bố Các phiên bản cũ hơn đã hạn chế tính song song trên DML tùy thuộc vào việc phân vùng. Một số sách hướng dẫn hiện tại vẫn ghi điều này nhưng chắc chắn nó không còn đúng nữa.
- Số lượng phân vùng Chỉ dành cho các tham gia phân vùng khôn ngoan trên các phiên bản cũ hơn. (?)
- Lỗi Cụ thể là tôi đã thấy rất nhiều lỗi với phân tích cú pháp. Oracle sẽ phân bổ đúng số lượng máy chủ song song nhưng sẽ không có gì xảy ra vì tất cả chúng đều đợi các sự kiện như
cursor: pin s wait on x.
Danh sách này chắc chắn không đầy đủ và không bao gồm các tính năng 12c. Và nó không giải quyết các vấn đề về hệ điều hành và phần cứng. Và nó không trả lời câu hỏi khó khủng khiếp, "mức độ song song tốt nhất là gì?" (Câu trả lời ngắn gọn:nhiều hơn thường tốt hơn, nhưng phải trả giá bằng các quy trình khác.) Hy vọng rằng nó ít nhất cũng cho bạn biết những vấn đề này có thể khó khăn như thế nào và là một nơi tốt để bắt đầu tìm kiếm.
