Làm cách nào để tăng hiệu năng của các truy vấn mới trong MS SQL Server?

Tôi có trang web ASP.NET sở hữu bộ đệm dữ liệu độc lập và dữ liệu không thay đổi trong thời gian dài, do đó không cần truy vấn SQL Server lần thứ hai với cùng một truy vấn. Tôi cần cải thiện hiệu năng của các truy vấn lần đầu tiên (còn nguyên) đến SQL Server đó. Một số truy vấn xử lý nhiều dữ liệu đến mức chúng có thể khiến SQL Server sử dụng tempdb. Tôi không sử dụng biến bảng tạm thời hoặc bảng tạm thời, vì vậy SQL Server quyết định tự sử dụng tempdbbất cứ khi nào cần.

Kích thước db của tôi là 16Gb, tôi có sẵn 32Gb RAM vật lý trên máy chủ của mình.

Tôi hiểu rằng chiến lược lưu trữ bộ đệm của MS SQL Server cố gắng giữ dữ liệu trong RAM để tăng tốc hiệu suất của các truy vấn tương tự nếu chúng cần được tải lại cùng một dữ liệu. Ngoài ra, nó sẽ cố gắng sử dụng RAM có sẵn thay vì tempdb để tăng tốc hiệu suất mà không gây ra truy cập đĩa.

Tôi cho rằng khi truy vấn cần lưu trữ thứ gì đó trong tempdb thì SQL Server xuất hiện và không có đủ RAM, SQL Server có 2 lựa chọn:

1) để tải một số dữ liệu được lưu trong bộ nhớ cache và sử dụng RAM không thay vì tempdb để tránh ghi đĩa

2) giữ dữ liệu được lưu trong bộ nhớ cache cho các truy vấn trong tương lai và bắt đầu sử dụng tempdb, điều này gây ra việc ghi vào đĩa chậm.

Tôi không biết SQL Server sẽ lựa chọn gì trong tình huống này, nhưng tôi muốn lựa chọn số 1 vì tôi chỉ quan tâm đến hiệu năng của các truy vấn lần đầu (trinh nữ), vì tôi không bao giờ gửi lại truy vấn tương tự cho SQL Server nữa (mặc dù tôi có thể gửi truy vấn tương tự).

Chiến lược bộ nhớ đệm SQL Server cho kịch bản này là gì?

Làm thế nào để cân bằng việc sử dụng RAM giữa việc tránh tempdb cho các truy vấn còn nguyên và tốc độ của truy vấn lần thứ hai?

Có thể định cấu hình Máy chủ SQL theo cách mà nó sẽ đưa ra lựa chọn số 1 không? Nếu có thì làm thế nào?

Làm thế nào khác tôi có thể tăng hiệu suất của tất cả các truy vấn SQL nguyên bản?

Vì tôi không biết về chiến lược bộ đệm của SQL Server, tôi muốn đặt cơ sở dữ liệu trên RAM Disk. Điều này sẽ đảm bảo rằng bất kỳ truy vấn mới nào cũng có tốc độ tải dữ liệu không được lưu trữ cao ngay cả khi SQL Server luôn đưa ra lựa chọn số 1. Rủi ro của nó là SQL Server có thể bắt đầu sử dụng nhiều tempdb hơn với ít RAM hơn (chỉ còn lại 16Gb sau khi tôi sử dụng 16Gb cho RAM Disk) nếu nó tiếp tục đưa ra lựa chọn # 2, điều này sẽ làm chậm các truy vấn không rõ ràng đó tempdb.

Tôi quan tâm đến giải pháp cho SQL 2008 R2, nhưng tôi đoán có lẽ giống với SQL 2008, SQL 2005 và có thể là SQL 2000.

Làm rõ:

Không có ứng dụng nào khác chạy trên hộp đó, nó dành riêng cho SQL Server . Trang web chạy trên hộp riêng biệt.

Đó là SQL Server 2008 R2 Phiên bản tiêu chuẩn 64 bit trên Windows Server 2008 R2 Enterprise 64 bit.

Tôi chỉ chạy các truy vấn chỉ đọc và cơ sở dữ liệu được đặt thành chỉ đọc .

Hãy giả sử rằng đã có chỉ số tốt . Câu hỏi này là về việc SQL Server đưa ra lựa chọn số 1 so với lựa chọn số 2, làm thế nào để đưa ra lựa chọn, nếu có cách nào để kiểm soát nó và nếu RAM Disk giúp nó đưa ra lựa chọn phù hợp cho các truy vấn mới.

Câu hỏi của bạn về cơ bản có thể được đánh giá lại là 'Bộ nhớ truy vấn cấp hoạt động như thế nào?'. Đọc tốt về chủ đề này là Hiểu về cấp bộ nhớ máy chủ SQL . Trước khi một truy vấn được đưa vào thực thi, nó có thể yêu cầu cấp bộ nhớ cho các loại và băm và các hoạt động đói bộ nhớ khác. Cấp bộ nhớ này là một ước tính . Dựa trên trạng thái hệ thống hiện tại (số lượng yêu cầu đang chạy và đang chờ xử lý, bộ nhớ khả dụng, v.v.), hệ thống cấp cho truy vấn một bộ nhớ cấp tối đa số lượng yêu cầu. Khi bộ nhớ được cấp, truy vấn sẽ bắt đầu thực thi (nó có thể phải đợi trong hàng đợi 'tài nguyên semaphore' đáng sợ trước khi nhận được cấp). Khi thực hiện, cấp bộ nhớ được đảm bảotheo hệ thống. Lượng bộ nhớ này có thể được chia sẻ với các trang dữ liệu (vì chúng luôn có thể xả vào đĩa) nhưng không bao giờ với việc sử dụng bộ nhớ khác (nghĩa là nó không thể bị đánh cắp '). Vì vậy, khi truy vấn bắt đầu yêu cầu bộ nhớ đã cam kết từ cấp của nó, công cụ sẽ triển khai cái mà bạn gọi là 'chiến lược số 1': các trang dữ liệu có thể bị đuổi (xóa nếu bẩn) để cung cấp cho truy vấn bộ nhớ mà nó đã hứa. Bây giờ nếu ước tính là chính xác và khoản trợ cấp là 100% bộ nhớ được yêu cầu, truy vấn sẽ không 'tràn'. Nhưng nếu ước tính không chính xác (nắm rõ các ước tính về số lượng, do đó phải tuân theo các số liệu thống kê cũ) hoặc nếu truy vấn không nhận được toàn bộ khoản trợ cấp mà nó đã yêu cầu, truy vấn sẽ 'tràn ra'. Đây là khi tempdb đi vào hình ảnh và hiệu suất thường là xe tăng.

Núm duy nhất mà bạn có theo ý mình kiểm soát thứ gì đó trong quy trình này là Thống đốc tài nguyên . Vì RG có thể được sử dụng để chỉ định cài đặt MIN cho nhóm, nên nó có thể được sử dụng để dự trữ bộ nhớ cho một khối lượng công việc nhất định để nó thực sự được cấp bộ nhớ mà nó yêu cầu. Tất nhiên, sau khi bạn thực hiện một cuộc điều tra thích hợp cho thấy rằng việc giảm các khoản trợ cấp bộ nhớ là thủ phạm và tất nhiên sau khi tác động lên các khối lượng công việc khác được đánh giá. Và thử nghiệm, tất nhiên.

Bây giờ hãy trở lại câu hỏi ban đầu của bạn. Nếu cuộc điều tra của bạn là chính xác (rất lớn nếu) tôi muốn chỉ ra hai vấn đề:

• bạn chạy trong các truy vấn sản xuất yêu cầu cấp bộ nhớ cho một trang web . Đây là một không lớn không có. Cấp bộ nhớ là dấu hiệu của các truy vấn phân tích không có chỗ trong việc phục vụ các yêu cầu HTTP.
• truy vấn của bạn có thể không phải là sự kiện nhận được cấp bộ nhớ mà họ yêu cầu. Một lần nữa, thậm chí không có gì cho khối lượng công việc quan trọng có độ trễ như các trang web.

Vì vậy, những gì nói với tôi là bạn có một vấn đề thiết kế và kiến ​​trúc cơ bản. Các trang web được điều khiển độ trễ và sẽ tạo ra một OLTP như khối lượng công việc, không có cấp bộ nhớ và không có áp lực bộ nhớ đối với các truy vấn. Chưa kể không có sự cố tràn. Các truy vấn phân tích nên được chạy trong các công việc ngoại tuyến và lưu trữ các kết quả được xử lý trước để có sẵn nhanh chóng khi các yêu cầu HTTP mong muốn chúng.

Những gì bạn chưa đề cập là loại truy vấn nào được chạy trên cơ sở dữ liệu và nếu có các chỉ mục phù hợp để tăng tốc hiệu suất của các truy vấn của bạn.

Bạn cũng cần đảm bảo nếu có bất kỳ ứng dụng nào khác đang chạy trên cùng một hộp. Mặc dù hộp có 32 GB RAM, bạn đã đặt bất kỳ cài đặt bộ nhớ tối đa nào trên máy chủ cơ sở dữ liệu để đặt bất kỳ giới hạn nhân tạo nào. Nếu có các ứng dụng chạy trên cùng một máy chủ thì SQL và các ứng dụng khác có thể đang cạnh tranh tài nguyên và lưu ý rằng SQL rất đói bộ nhớ.

SQL Server sẽ sử dụng tempdb để sắp xếp nội bộ hoặc băm tham gia / tổng hợp hoặc toán tử bộ đệm, v.v. và bạn không thể kiểm soát hành vi này. Những gì bạn có thể làm là giới hạn số lượng dữ liệu được trả lại.

Bạn đã kiểm tra số liệu thống kê chờ đợi trên hộp này? Mỗi khi SQL Server chờ trên một tài nguyên, SQL Server sẽ theo dõi tài nguyên chờ và xem thông tin đó có ích.

Nhìn vào các truy vấn chẩn đoán Glenn Berry và đó sẽ là một khởi đầu tốt cho bạn.

Ngoài ra, hãy xem PARAMETERIZATION FORCED như được đề cập trong http://weblogs.sqlteam.com/dang/archive/2009/06/27/Forced-Parameterization-A-Turbo-Button.aspx

Câu hỏi này hiện đang đọc giống như một giải pháp tìm kiếm một vấn đề. Bạn đã quyết định rằng một đĩa RAM là giải pháp và bạn muốn ai đó xác nhận sự lựa chọn đó. Xin lỗi, sẽ không xảy ra.

Nếu bạn đã đo lường và quan sát sự cố tràn sang tempdb, gần như chắc chắn đó sẽ là do hoạt động sắp xếp hoặc băm và cấp bộ nhớ truy vấn không đủ. Tùy thuộc vào khối lượng dữ liệu cần xử lý, điều này có thể không thể tránh khỏi nhưng tỷ lệ tốt là truy vấn và / hoặc lập chỉ mục có thể được cải thiện để tránh điều đó.

Hãy xem Quản lý bộ đệm để hiểu rõ hơn về cách SQL Server quản lý bộ nhớ và Quản lý bộ nhớ SQL Server Giải thích cho một số công cụ cơ bản và truy vấn DMV để hiểu nơi bộ nhớ của bạn được phân bổ.

Làm thế nào khác tôi có thể tăng hiệu suất của tất cả các truy vấn SQL nguyên bản?

Đây là một chủ đề lớn. Đăng truy vấn và kế hoạch và bạn sẽ nhận được phản hồi được nhắm mục tiêu.