2008-08-13 33 views
27

Đây là câu hỏi tôi đã hỏi trên diễn đàn khác nhận được một số câu trả lời hợp lý, nhưng tôi muốn xem liệu có ai ở đây có thông tin chi tiết hơn không.Thời gian truy vấn từ ứng dụng web nhưng chạy tốt từ studio quản lý

Vấn đề là bạn có một trong các trang trong ứng dụng web định thời gian khi cuộc gọi được lưu trữ, vì vậy bạn sử dụng Sql Profiler hoặc nhật ký theo dõi ứng dụng để tìm truy vấn và dán vào studio quản lý để tìm hiểu lý do tại sao nó chạy chậm. Nhưng bạn chạy nó từ đó và nó chỉ blazes cùng, trở về trong ít hơn một giây mỗi lần.

Trường hợp cụ thể của tôi đã sử dụng ASP.NET 2.0 và Sql Server 2005, nhưng tôi nghĩ rằng vấn đề có thể áp dụng cho bất kỳ hệ thống RDBMS nào.

+0

Tôi gặp vấn đề tương tự và http://stackoverflow.com/questions/250713/sqldataadapter-fill-method-slow giải quyết được vấn đề của mình – David

Trả lời

26

Đây là những gì tôi đã học được cho đến nay từ nghiên cứu của tôi.

.NET gửi trong cài đặt kết nối không giống với những gì bạn nhận được khi đăng nhập vào studio quản lý. Đây là những gì bạn nhìn thấy nếu bạn sniff các kết nối với SQL Profiler:

-- network protocol: TCP/IP 
set quoted_identifier off 
set arithabort off 
set numeric_roundabort off 
set ansi_warnings on 
set ansi_padding on 
set ansi_nulls off 
set concat_null_yields_null on 
set cursor_close_on_commit off 
set implicit_transactions off 
set language us_english 
set dateformat mdy 
set datefirst 7 
set transaction isolation level read committed 

Tôi bây giờ dán những thiết lập trong trên mỗi truy vấn mà tôi chạy khi đăng nhập vào máy chủ SQL, để đảm bảo các thiết lập đều giống nhau.

Đối với trường hợp này, tôi đã thử từng cài đặt riêng lẻ, sau khi ngắt kết nối và kết nối lại, và thấy rằng việc thay đổi arithabort từ tắt sang giảm truy vấn vấn đề từ 90 giây xuống còn 1 giây.

Giải thích có thể xảy ra nhất liên quan đến đánh hơi thông số, là một kỹ thuật mà Sql Server sử dụng để chọn những gì nó nghĩ là kế hoạch truy vấn hiệu quả nhất. Khi bạn thay đổi một trong các cài đặt kết nối, trình tối ưu hóa truy vấn có thể chọn một gói khác, và trong trường hợp này, nó dường như đã chọn một thiết lập xấu.

Nhưng tôi không hoàn toàn bị thuyết phục về điều này. Tôi đã thử so sánh các kế hoạch truy vấn thực tế sau khi thay đổi cài đặt này và tôi chưa thấy sự khác biệt hiển thị bất kỳ thay đổi nào.

Có điều gì khác về cài đặt arithabort có thể khiến truy vấn chạy chậm trong một số trường hợp không?

Giải pháp có vẻ đơn giản: Chỉ cần đặt arithabort vào phần đầu của quy trình được lưu trữ. Nhưng điều này có thể dẫn đến vấn đề ngược lại: thay đổi các tham số truy vấn và đột nhiên nó chạy nhanh hơn với 'off' hơn 'on'.

Hiện tại, tôi đang chạy quy trình 'với biên dịch lại' để đảm bảo gói được khôi phục mỗi lần. Đó là Ok cho báo cáo đặc biệt này, vì nó có thể mất một giây để biên dịch lại, và điều này không quá đáng chú ý trên một báo cáo mất 1-10 giây để trở lại (đó là một con quái vật).

Nhưng đó không phải là tùy chọn cho các truy vấn khác chạy thường xuyên hơn nhiều và cần phải quay lại nhanh nhất có thể, chỉ trong vài phần nghìn giây.

+1

+1 Lấy các cài đặt đó từ SQL Profiler và dán chúng vào Management Studio là một mẹo tuyệt vời và đã giúp tôi tải. –

+3

+1 SET ARITHABORT OFF là đủ để làm cho truy vấn trước khi hết thời gian của tôi bắt đầu hoạt động tốt đẹp. – Spud

+1

@ eric-z-beard Bạn đặt các giá trị này ở đâu? Bên trong SP hoặc trước EXEC sp_whatever từ .NET – djandreski

0

Hãy thử thay đổi giá trị timeout SelectCommand:

DataAdapter.SelectCommand.CommandTimeout = 120; 
+0

Đây không phải là giải pháp! Đó là cách giải quyết! – Icet

1

thử nghiệm này trên một hộp dàn đầu tiên, thay đổi nó về mặt kĩ máy chủ cho máy chủ sql

khai báo @option int

bộ @option = @@ tùy chọn | 64

exec sp_configure 'tùy chọn người dùng, @option

RECONFIGURE

2

Bạn đã bật ASP.NET truy tìm chưa? Tôi đã có một trường hợp mà nó không phải là thủ tục lưu trữ SQL chính nó là vấn đề, nó là một thực tế là thủ tục trả về 5000 hàng và ứng dụng đã cố gắng tạo Databound ListItems với 5000 mục đó gây ra vấn đề.

Bạn có thể xem xét thời gian thực hiện giữa các chức năng của ứng dụng web cũng như theo dõi để giúp theo dõi mọi thứ.

0

Bạn có thể thử sử dụng lệnh sp_who2 để xem quy trình nào đang được đề cập đang thực hiện. Điều này sẽ cho bạn thấy nếu nó bị chặn bởi một quá trình khác, hoặc sử dụng một số lượng quá nhiều CPU và/hoặc thời gian io.

1

Cùng vấn đề với dịch vụ báo cáo SQL. Hãy thử để kiểm tra loại biến, Tôi đã gửi loại biến khác nhau để SQL như gửi varchar tại nơi nó nên là số nguyên, hoặc một cái gì đó như thế. Sau khi tôi đồng bộ hóa các loại biến trong Dịch vụ báo cáo và trong thủ tục lưu sẵn trên SQL, tôi đã giải quyết được sự cố.

6

Tôi đã gặp sự cố tương tự. Hãy thử thiết lập với tùy chọn "WITH RECOMPILE" trên sproc tạo ra để buộc hệ thống tính toán lại kế hoạch thực thi mỗi khi nó được gọi. Đôi khi bộ xử lý truy vấn bị nhầm lẫn trong các thủ tục được lưu trữ phức tạp với nhiều câu lệnh phân nhánh hoặc trường hợp và chỉ cần thực hiện một kế hoạch thực hiện tối ưu phụ thực sự. Nếu điều đó dường như "khắc phục" sự cố, có thể bạn sẽ cần phải xác minh số liệu thống kê được cập nhật và/hoặc chia nhỏ sproc.

Bạn cũng có thể xác nhận điều này bằng cách định hình sproc. Khi bạn thực hiện nó từ SQL Managment Studio, làm thế nào để so sánh với IO khi bạn cấu hình nó từ ứng dụng ASP.NET. Nếu họ rất nhiều, nó chỉ tái thực thi rằng nó kéo một kế hoạch thực hiện xấu.

0

Chúng tôi đã gặp vấn đề tương tự và đây là những gì chúng tôi đã phát hiện.

kích thước nhật ký cơ sở dữ liệu của chúng tôi được giữ ở mức mặc định (814 MB) và tăng trưởng tự động là 10%. Trên máy chủ, bộ nhớ máy chủ tối đa cũng được giữ ở cài đặt mặc định (2147483647 MB).

Khi nhật ký của chúng tôi đầy và cần thiết để phát triển, nó đã sử dụng tất cả bộ nhớ từ máy chủ và không còn gì để chạy mã để nó hết thời gian chờ. Những gì chúng tôi đã kết thúc làm là đặt kích thước ban đầu của tệp nhật ký cơ sở dữ liệu thành 1 MB và bộ nhớ máy chủ tối đa là 2048 MB. Điều này ngay lập tức khắc phục được sự cố của chúng tôi. Tất nhiên, bạn có thể thay đổi hai thuộc tính này để phù hợp với nhu cầu của bạn nhưng đây là một ý tưởng cho một người nào đó chạy vào vấn đề định thời khi thực hiện một thủ tục được lưu trữ qua mã nhưng nó chạy siêu nhanh trong SSMS và các giải pháp trên không giúp được gì.

Các vấn đề liên quan