DBMS_XPLAN.DISPLAY_CURSOR vs Giải thích kế hoạch nếu không sử dụng gather_plan_statistics gợi ý

Question

Chỉ cần yêu cầu một số giải thích về sự khác biệt giữa 2. Từ những gì tôi hiểu, giải thích kế hoạch cung cấp cho bạn những lý thuyết kế hoạch thực hiện trong khi DBMS_XPLAN.DISPLAY_CURSOR mang đến cho bạn thực tế kế hoạch thực hiện với số liệu thống kê thực hiện cho tuyên bố.

EXPLAIN PLAN lưu trữ dữ liệu này trong một PLAN_TABLE trong khi DBMS_XPLAN sử dụng chế độ xem V $ SQL_PLAN, V $ SQL_PLAN_STATISTICS và V $ SQL_PLAN_STATISTICS_ALL cho thông tin của nó.

Tuy nhiên, để DISPLAY_CURSOR thu thập số liệu thống kê thời gian thực tế thực tế cho thống kê đó, bạn cần đặt gợi ý /*+ gather_plan_statistics */. Nếu không, chỉ V $ SQL_PLAN được lấp đầy mà sẽ chỉ cung cấp cho bạn kế hoạch thực hiện nhưng không cung cấp số liệu thống kê thực thi thực tế. Chỉ với /*+ gather_plan_statistics */ trong đó V $ SQL_PLAN_STATISTICS được lấp đầy. Vì vậy, câu hỏi của tôi là, nếu tôi không sử dụng gợi ý gather_plan_statistics, sẽ GIẢI THÍCH KẾ HOẠCH và DISPLAY_CURSOR luôn cho tôi cùng một kế hoạch thực hiện (cho cùng một tuyên bố) không? Không.

Answer 1

Sự khác biệt không phải là rất tinh tế, chúng rất lớn.

Như bạn đã đề cập một cách chính xác, giải thích kế hoạch lưu trữ dữ liệu của nó trong plan_table và kế hoạch được truy vấn từ bảng đó. Điều này có nghĩa là sql KHÔNG được thực thi, chỉ có trình tối ưu hóa được yêu cầu cung cấp một kế hoạch. Trong thiết lập đó, kế hoạch phụ thuộc rất nhiều vào môi trường trình tối ưu hóa của phiên của bạn, trong đó bạn chạy kế hoạch giải thích.

Với DBMS_XPLAN.DISPLAY_CURSOR bạn nhận được gói như trước đây. Kế hoạch không được lưu trữ bằng cách phát hành DBMS_XPLAN.DISPLAY_CURSOR; nó được lưu trữ trong các cấu trúc v $ vì nó đã được thực thi.

Trong một phiên bạn có thể chạy

select * from dual; 
select * from table(dbms_xplan.display_cursor); 

Các truy vấn được thực hiện trong 'chọn từ kép', điều này cũng dẫn đến việc tạo ra một kế hoạch và rằng tôi được lưu giữ trong v $ cấu trúc. display_cursor chỉ tìm thấy con trỏ được thực thi cuối cùng và hiển thị kế hoạch mà nó theo sau. Với thiết lập này/* + gather_plan_statistics */không có giá trị gia tăng vì kế hoạch và số liệu thống kê của nó đã có trong shared_pool.

Câu hỏi khác của bạn, cho dù kế hoạch có luôn giống nhau hay không phụ thuộc vào nhiều yếu tố. Các biến có giống nhau không ?, bạn có đang sử dụng Chia sẻ con trỏ thích ứng không, bạn đang sử dụng tính năng ổn định kế hoạch SQL ...

Câu hỏi của bạn: đưa ra kế hoạch giải thích và hiển thị cùng một gói? Tôi sẽ không dựa vào điều đó vì với kế hoạch giải thích, kế hoạch này phụ thuộc vào môi trường tối ưu hóa phiên của bạn. display_cursor là cách tốt hơn, và tốt hơn là sử dụng một con trỏ có tên được tạo bởi ứng dụng. Nếu bạn không sử dụng SQL Plan Stability, kế hoạch có thể thay đổi khi số liệu thống kê của trình tối ưu hóa thay đổi. Nếu bạn sử dụng Chia sẻ con trỏ thích ứng, kế hoạch có thể thay đổi khi các biến thay đổi.

Có thể tìm thấy một chút đọc tốt về chi phí lấy mẫu tại blog Jonathan Lewis. Cũng từ Jonathan: gather_plan_statistics Tôi thường thông minh hơn để sử dụng cài đặt stats_level 'tất cả' để gỡ lỗi thay vì sử dụng/* + gather_plan_statistics */hint. Gợi ý thay đổi mã và tạo một sql_id mới.

Tôi hy vọng điều này sẽ hữu ích.