Database
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Database

Cách các kế hoạch song song bắt đầu - Phần 1

Loạt bài gồm năm phần này đi sâu vào cách khởi động các kế hoạch song song của chế độ hàng SQL Server. Phần đầu tiên này bao gồm vai trò của nhiệm vụ chính (điều phối viên) trong việc chuẩn bị kế hoạch để thực hiện song song. Nó bao gồm khởi tạo từng toán tử và thêm các trình cấu hình ẩn để thu thập dữ liệu hiệu suất thời gian chạy như số lượng hàng thực tế và thời gian đã trôi qua.

Thiết lập

Để cung cấp cơ sở cụ thể cho việc phân tích, chúng tôi sẽ theo dõi cách một truy vấn song song cụ thể bắt đầu thực thi. Tôi đã sử dụng Stack Overflow 2013 công khai cơ sở dữ liệu (tải chi tiết). Hình dạng kế hoạch mong muốn cũng có thể thu được dựa trên tập dữ liệu Stack Overflow 2010 nhỏ hơn nếu điều đó thuận tiện hơn. Nó có thể được tải xuống tại cùng một liên kết. Tôi đã thêm một chỉ mục không hợp nhất:

CREATE NONCLUSTERED INDEX PP
ON dbo.Posts
(
    PostTypeId ASC,
    CreationDate ASC
);

Môi trường thử nghiệm của tôi là SQL Server 2019 CU9 trên máy tính xách tay có 8 lõi và 16GB bộ nhớ được phân bổ cho phiên bản. Mức độ tương thích 150 được sử dụng độc quyền. Tôi đề cập đến những chi tiết đó để giúp bạn tái tạo kế hoạch mục tiêu nếu bạn muốn. Các nguyên tắc cơ bản về thực thi song song chế độ hàng không thay đổi kể từ SQL Server 2005, vì vậy cuộc thảo luận sau đây có thể áp dụng rộng rãi.

Truy vấn kiểm tra trả về tổng số câu hỏi và câu trả lời, được nhóm theo tháng và năm:

WITH 
    MonthlyPosts AS 
    (
        SELECT 
            P.PostTypeId, 
            CA.TheYear, 
            CA.TheMonth, 
            Latest = MAX(P.CreationDate)
        FROM dbo.Posts AS P
        CROSS APPLY 
        (
            VALUES
            (
                YEAR(P.CreationDate), 
                MONTH(P.CreationDate)
            )
        ) AS CA (TheYear, TheMonth)
        GROUP BY 
            P.PostTypeId, 
            CA.TheYear, 
            CA.TheMonth
    )
SELECT 
    rn = ROW_NUMBER() OVER (
        ORDER BY Q.TheYear, Q.TheMonth),
    Q.TheYear, 
    Q.TheMonth, 
    LatestQuestion = Q.Latest,
    LatestAnswer = A.Latest
FROM MonthlyPosts AS Q
JOIN MonthlyPosts AS A
    ON A.TheYear = Q.TheYear
    AND A.TheMonth = Q.TheMonth
WHERE 
    Q.PostTypeId = 1
    AND A.PostTypeId = 2
ORDER BY 
    Q.TheYear,
    Q.TheMonth
OPTION 
(
    USE HINT ('DISALLOW_BATCH_MODE'),
    USE HINT ('FORCE_DEFAULT_CARDINALITY_ESTIMATION'),
    ORDER GROUP,
    MAXDOP 2
);

Tôi đã sử dụng gợi ý để có được một kế hoạch chế độ hàng hình dạng cụ thể. Việc thực thi được giới hạn ở DOP 2 để làm cho một số chi tiết được hiển thị sau đó ngắn gọn hơn.

Kế hoạch thực hiện ước tính là (bấm để phóng to):

​​Nền

Trình tối ưu hóa truy vấn tạo ra một kế hoạch đã biên dịch duy nhất cho một lô. Mỗi câu lệnh trong lô được đánh dấu để thực hiện nối tiếp hoặc song song, tùy thuộc vào tính đủ điều kiện và chi phí ước tính.

Một kế hoạch song song chứa trao đổi (các toán tử song song). Trao đổi có thể xuất hiện trong luồng phân phối , luồng phân vùng lại hoặc thu thập các luồng biểu mẫu. Mỗi loại trao đổi này sử dụng các thành phần cơ bản giống nhau, chỉ là kết nối khác nhau, với số lượng đầu vào và đầu ra khác nhau. Để biết thêm thông tin cơ bản về thực thi song song chế độ hàng, hãy xem Kế hoạch thực thi song song - Nhánh và Chủ đề.

Hạ cấp DOP

Mức độ song song (DOP) cho một kế hoạch song song có thể được hạ cấp trong thời gian chạy nếu cần thiết. Một truy vấn song song có thể bắt đầu yêu cầu DOP 8, nhưng dần dần bị hạ cấp xuống DOP 4, DOP 2 và cuối cùng là DOP 1 do thiếu tài nguyên hệ thống tại thời điểm đó. Nếu bạn muốn thấy điều đó hoạt động, hãy xem đoạn video ngắn này của Erik Darling.

Việc chạy một kế hoạch song song trên một luồng đơn lẻ cũng có thể xảy ra khi một kế hoạch song song được lưu trong bộ nhớ cache được sử dụng lại bởi một phiên bị giới hạn ở DOP 1 bởi cài đặt môi trường (ví dụ:mặt nạ ái lực hoặc thống đốc tài nguyên). Xem Huyền thoại:SQL Server lưu trữ một kế hoạch nối tiếp với mọi gói song song để biết chi tiết.

Dù nguyên nhân là gì, thì việc hạ cấp DOP của một gói song song được lưu trong bộ nhớ cache không dẫn đến một kế hoạch nối tiếp mới được biên dịch. SQL Server sử dụng lại gói song song hiện có bằng cách tắt các cuộc trao đổi. Kết quả là một kế hoạch ‘song song’ thực thi trên một luồng duy nhất. Các trao đổi vẫn xuất hiện trong kế hoạch, nhưng chúng bị bỏ qua trong thời gian chạy.

SQL Server không thể thúc đẩy một kế hoạch nối tiếp để thực thi song song bằng cách thêm các trao đổi trong thời gian chạy. Điều đó sẽ yêu cầu một bản tổng hợp mới.

Khởi tạo gói song song

Một kế hoạch song song có tất cả các trao đổi cần thiết để sử dụng các chuỗi nhân viên bổ sung, nhưng có công việc thiết lập bổ sung cần thiết trong thời gian chạy trước khi có thể bắt đầu thực thi song song. Một ví dụ rõ ràng là các luồng nhân viên bổ sung phải được phân bổ cho các nhiệm vụ cụ thể trong kế hoạch, nhưng còn nhiều thứ hơn thế nữa.

Tôi sẽ bắt đầu tại điểm mà một kế hoạch song song đã được truy xuất từ ​​bộ nhớ cache của kế hoạch. Tại thời điểm này, chỉ tồn tại luồng ban đầu xử lý yêu cầu hiện tại. Chuỗi này đôi khi được gọi là “chuỗi điều phối viên” trong các kế hoạch song song, nhưng tôi thích các thuật ngữ “ nhiệm vụ chính hơn ”Hoặc“ nhân viên phụ huynh ”. Không có gì đặc biệt về chủ đề này; nó là cùng một chuỗi mà kết nối sử dụng để xử lý các yêu cầu của khách hàng và chạy các kế hoạch nối tiếp để hoàn thành.

Để nhấn mạnh điểm chỉ tồn tại một chuỗi duy nhất ngay bây giờ, tôi muốn bạn hình dung kế hoạch tại thời điểm này như sau:

Tôi sẽ sử dụng ảnh chụp màn hình từ Sentry One Plan Explorer hầu như chỉ trong bài đăng này, nhưng chỉ cho chế độ xem đầu tiên này, tôi cũng sẽ hiển thị phiên bản SSMS:

Trong cả hai cách biểu diễn, sự khác biệt chính là thiếu các biểu tượng song song trên mỗi nhà điều hành, mặc dù các sàn giao dịch vẫn tồn tại. Chỉ có tác vụ mẹ tồn tại ngay bây giờ, đang chạy trên chuỗi kết nối ban đầu. Không có chuỗi nhân viên bổ sung đã được đặt trước, tạo hoặc giao nhiệm vụ chưa. Hãy nhớ đến việc trình bày kế hoạch ở trên khi chúng ta tiếp tục.

Tạo kế hoạch thực thi

Kế hoạch tại thời điểm này về cơ bản chỉ là một khuôn mẫu có thể được sử dụng làm cơ sở cho bất kỳ quá trình thực thi nào trong tương lai. Để chuẩn bị sẵn sàng cho một lần chạy cụ thể, SQL Server cần điền vào các giá trị thời gian chạy như người dùng hiện tại, ngữ cảnh giao dịch, giá trị tham số, id cho bất kỳ đối tượng nào được tạo trong thời gian chạy (ví dụ:bảng và biến tạm thời), v.v.>

Đối với một kế hoạch song song, SQL Server cần thực hiện khá nhiều công việc chuẩn bị bổ sung để đưa bộ máy bên trong đến thời điểm có thể bắt đầu thực thi. Chuỗi công nhân của nhiệm vụ chính chịu trách nhiệm thực hiện hầu hết tất cả công việc này (và chắc chắn là tất cả công việc mà chúng tôi sẽ đề cập trong phần 1).

Quá trình chuyển đổi mẫu kế hoạch cho một lần chạy cụ thể được gọi là tạo kế hoạch thực thi . Đôi khi rất khó để giữ cho thuật ngữ thẳng hàng, vì các thuật ngữ thường bị quá tải và áp dụng sai (ngay cả bởi Microsoft), nhưng tôi sẽ cố gắng hết sức để nhất quán nhất có thể.

Bối cảnh thực thi

Bạn có thể nghĩ về một bối cảnh thực thi như một mẫu kế hoạch được điền với tất cả thông tin thời gian chạy cụ thể mà một chuỗi cụ thể cần. Kế hoạch có thể thực thi cho một sê-ri câu lệnh bao gồm một ngữ cảnh thực thi duy nhất, trong đó một luồng duy nhất chạy toàn bộ kế hoạch.

A song song kế hoạch thực thi chứa một bộ sưu tập ngữ cảnh thực thi :Một cho tác vụ mẹ và một cho mỗi luồng trong mỗi nhánh song song. Mỗi luồng công nhân song song bổ sung chạy một phần của kế hoạch tổng thể trong ngữ cảnh thực thi của riêng nó. Ví dụ, một kế hoạch song song với ba nhánh chạy tại DOP 8 có (1 + (3 * 8)) =25 bối cảnh thực thi. Các ngữ cảnh thực thi nối tiếp được lưu vào bộ nhớ đệm để sử dụng lại, nhưng các ngữ cảnh thực thi song song bổ sung thì không.

Tác vụ mẹ luôn tồn tại trước bất kỳ tác vụ song song bổ sung nào, vì vậy nó được gán ngữ cảnh thực thi bằng không . Các ngữ cảnh thực thi được sử dụng bởi các nhân viên song song sẽ được tạo sau đó, sau khi ngữ cảnh mẹ được khởi tạo hoàn toàn. Các ngữ cảnh bổ sung được sao chép từ ngữ cảnh gốc, sau đó được tùy chỉnh cho nhiệm vụ cụ thể của chúng (điều này được đề cập trong phần 2).

Có một số hoạt động liên quan đến việc khởi động ngữ cảnh thực thi bằng không. Việc cố gắng liệt kê tất cả chúng là không thực tế, nhưng sẽ rất hữu ích nếu bao gồm một số điều chính áp dụng cho truy vấn thử nghiệm của chúng tôi. Sẽ vẫn còn quá nhiều cho một danh sách, vì vậy tôi sẽ chia chúng thành các phần (hơi tùy ý):

1. Khởi tạo ngữ cảnh gốc

Khi chúng tôi gửi câu lệnh để thực thi, ngữ cảnh của tác vụ mẹ (ngữ cảnh thực thi bằng không) được khởi tạo bằng:

  • Tham chiếu đến giao dịch cơ sở (rõ ràng, ngầm định hoặc tự động cam kết). Các nhân viên song song sẽ chạy các giao dịch phụ, nhưng tất cả chúng đều nằm trong phạm vi của giao dịch cơ sở.
  • Danh sách các câu lệnh tham số và các giá trị hiện tại của chúng.
  • Một đối tượng bộ nhớ chính (PMO) được sử dụng để quản lý việc cấp và phân bổ bộ nhớ.
  • Một bản đồ được liên kết của các toán tử (các nút truy vấn) trong kế hoạch thực thi.
  • Một nhà máy cho bất kỳ đối tượng lớn nào được yêu cầu (đốm màu) xử lý.
  • Khóa các lớp để theo dõi nhiều khóa được giữ trong một khoảng thời gian trong quá trình thực thi. Không phải tất cả các gói đều yêu cầu khóa lớp vì các nhà khai thác phát trực tuyến hoàn toàn thường khóa và mở khóa các hàng riêng lẻ theo trình tự.
  • Khoản cấp bộ nhớ ước tính cho truy vấn.
  • Cấp cho bộ nhớ chế độ hàng phản hồi cấu trúc cho từng toán tử (SQL Server 2019).

Nhiều thứ trong số này sẽ được sử dụng hoặc tham chiếu bởi các tác vụ song song sau này, vì vậy chúng cần phải tồn tại ở phạm vi mẹ trước.

2. Siêu dữ liệu ngữ cảnh gốc

Các tác vụ chính tiếp theo được thực hiện là:

  • Kiểm tra chi phí truy vấn ước tính nằm trong giới hạn do các tùy chọn cấu hình giới hạn chi phí của thống đốc truy vấn đặt ra.
  • Đang cập nhật sử dụng chỉ mục hồ sơ - được hiển thị thông qua sys.dm_db_index_usage_stats .
  • Tạo các giá trị biểu thức được lưu trong bộ nhớ cache (hằng số thời gian chạy).
  • Tạo danh sách toán tử lập hồ sơ được sử dụng để thu thập các chỉ số thời gian chạy như số lượng hàng và thời gian, nếu điều này đã được yêu cầu cho quá trình thực thi hiện tại. Bản thân những người lập hồ sơ vẫn chưa được tạo, chỉ là danh sách.
  • Chụp nhanh lượt đợi đối với tính năng chờ phiên được hiển thị qua sys.dm_exec_session_wait_stats .

3. DOP và cấp bộ nhớ

Bối cảnh nhiệm vụ chính bây giờ:

  • Tính toán mức độ song song trong thời gian chạy ( DOP ). Điều này bị ảnh hưởng bởi số lượng nhân viên tự do (xem phần “Hạ cấp DOP” trước đó), nơi họ có thể được đặt giữa các nút và một số cờ theo dõi.
  • Đặt trước số lượng chủ đề cần thiết. Bước này là kế toán thuần túy - bản thân các chủ đề có thể không tồn tại vào thời điểm này. SQL Server theo dõi số luồng tối đa mà nó được phép có. Chủ đề đặt trước số trừ từ số đó. Khi các chủ đề kết thúc, số lượng tối đa lại được tăng lên.
  • Đặt thời gian chờ cấp bộ nhớ .
  • Tính toán mức cấp bộ nhớ, bao gồm cả bộ nhớ cần thiết cho bộ đệm trao đổi.
  • Nhận được quyền cấp bộ nhớ thông qua semaphore tài nguyên thích hợp .
  • Tạo một đối tượng người quản lý để xử lý các quy trình con song song . Nhiệm vụ cha là quá trình cấp cao nhất; các tác vụ bổ sung còn được gọi là quy trình con .

Trong khi các chuỗi được "dành riêng" tại thời điểm này, SQL Server vẫn có thể gặp phải THREADPOOL đợi sau khi nó cố gắng sử dụng một trong các chuỗi "dành riêng". Việc đặt trước đảm bảo SQL Server sẽ luôn duy trì xung quanh số lượng luồng tối đa được định cấu hình của nó, nhưng luồng vật lý có thể không khả dụng ngay lập tức từ nhóm luồng . Khi điều đó xảy ra, một luồng mới sẽ cần được khởi động bởi hệ điều hành, quá trình này có thể mất một chút thời gian. Để biết thêm về điều đó, hãy xem THREADPOOL Chờ đợi bất thường của Josh Darnell.

4. Thiết lập quét truy vấn

Các kế hoạch chế độ hàng thực thi trong lặp đi lặp lại thời trang, bắt đầu từ gốc. Kế hoạch mà chúng tôi có vào lúc này vẫn chưa có khả năng thực hiện phương thức này. Phần lớn nó vẫn là một mẫu, ngay cả khi nó đã chứa một lượng lớn thông tin cụ thể về thực thi.

SQL Server cần chuyển đổi cấu trúc hiện tại thành một cây trình vòng lặp , mỗi phương thức có các phương thức như Open , GetRowClose . Các phương thức của trình vòng lặp được kết nối với các phương thức con của chúng thông qua các con trỏ hàm. Ví dụ:gọi GetRow trên thư mục gốc các cuộc gọi đệ quy GetRow trên các toán tử con cho đến khi đạt đến cấp độ lá và một hàng bắt đầu 'bong bóng' cây. Để được cập nhật chi tiết, hãy xem Trình lặp lại, Kế hoạch truy vấn và Tại sao chúng chạy ngược lại.

Kết thúc Phần 1

Chúng tôi đã đạt được tiến bộ tốt khi thiết lập bối cảnh thực thi cho tác vụ mẹ. Trong phần 2, chúng ta sẽ theo dõi khi SQL Server xây dựng cây quét truy vấn cần thiết để thực thi lặp đi lặp lại.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. IGNORE_DUP_KEY chậm hơn trên các chỉ mục được nhóm

  2. Cách chạy công việc từ xa từ IRI Workbench

  3. Áp dụng các quy tắc trường sử dụng phân loại

  4. SQL giữa toán tử

  5. Toán tử SQL không bằng (! =) Cho người mới bắt đầu