Bạn hiện đang ngoại tuyến, hãy chờ internet để kết nối lại

Làm thế nào để khắc phục hiệu suất của các quảng cáo-Hoc truy vấn trong SQL Server

QUAN TRỌNG: Bài viết này được dịch bằng phần mềm dịch máy của Microsoft chứ không phải do con người dịch. Microsoft cung cấp các bài viết do con người dịch và cả các bài viết do máy dịch để bạn có thể truy cập vào tất cả các bài viết trong Cơ sở Kiến thức của chúng tôi bằng ngôn ngữ của bạn. Tuy nhiên, bài viết do máy dịch không phải lúc nào cũng hoàn hảo. Loại bài viết này có thể chứa các sai sót về từ vựng, cú pháp hoặc ngữ pháp, giống như một người nước ngoài có thể mắc sai sót khi nói ngôn ngữ của bạn. Microsoft không chịu trách nhiệm về bất kỳ sự thiếu chính xác, sai sót hoặc thiệt hại nào do việc dịch sai nội dung hoặc do hoạt động sử dụng của khách hàng gây ra. Microsoft cũng thường xuyên cập nhật phần mềm dịch máy này.

Nhấp chuột vào đây để xem bản tiếng Anh của bài viết này:243588
TÓM TẮT
Bài viết này mô tả làm thế nào để khắc phục sự chậm hiệu suất của nhiều đồng thời quảng cáo-hoc truy vấn trong Microsoft SQL Server. Nếu bạn đã không xác định các nguồn gốc chính xác của vấn đề của bạn, xem các bài viết sau đây trong Microsoft Kho tàng kiến thức trước khi bạn tiếp tục:
224587 Làm thế nào để gỡ rối ứng dụng hiệu suất với SQL Server

Bài viết này giả định rằng bạn đã sử dụng KB 224587 để thu hẹp phạm vi của vấn đề và rằng bạn đã nắm bắt một giám sát hiệu suất Windows NT log và SQL Profiler theo dõi chi tiết rằng các các cụ thể quầy, sự kiện, và dữ liệu cột.

Đặc điểm về các vấn đề hiệu suất

Các vấn đề hiệu suất có đặc điểm như sau:
  • Truy vấn ngắn quảng cáo-hoc thường có một rất ngắn kết quả thời gian chậm tổng thể hệ thống tốc khi một số lượng đồng thời người dùng chạy các truy vấn.
  • Rất cao hoặc 100 phần trăm CPU sử dụng.
  • Không có liên kết chặn trong các thời kỳ chậm hiệu suất.

    Bạn có thể nhanh chóng tìm chặn bằng cách kiểm tra các BLK cột ở đầu ra của các sp_who hệ thống lưu trữ thủ tục. Nếu BLK cột không phải là 0 đối với một số hệ thống quá trình ID (SPID), có đang cản trở.
  • Trong một số trường hợp, bộ nhớ máy chủ nhấn mạnh, và bạn có thể nhận được lỗi tương tự như các lỗi sau đây:
    Lỗi: 701, mức độ nghiêm trọng: 17, bang: 1
    Đó là không đủ bộ nhớ hệ thống để chạy truy vấn này.
    - hay -
    Msg 8645 người, Mức độ 17, bang 1, thủ tục, dòng 1
    Một thời gian ra đã xảy ra trong khi chờ đợi cho bộ nhớ nguồn lực để thực hiện truy vấn. Tái chạy truy vấn.

Cải tiến trong truy vấn biên dịch

Vì của cải tiến trong hệ thống kiến trúc bắt đầu trong SQL Server 7.0, cụ thể là tối ưu hóa truy vấn, bạn có thể nhận thấy một sự khác biệt trong hệ thống tài nguyên sử dụng bởi ứng dụng so với phiên bản trước của SQL Hệ phục vụ. Cụ thể, SQL Server 7.0 có thể hiển thị tăng trong cả hai CPU hay sử dụng bộ nhớ, nhưng các phiên bản trước đó của SQL Server là đĩa IO ràng buộc. Những thay đổi này có thể được truy tìm đến hai yếu tố:
  • Tham gia băm và merge
  • Truy vấn biên soạn lần
Phiên bản trước của SQL Server dựa hoàn toàn vào vòng lặp lồng nhau lặp đi lặp lại để thực hiện tham gia. Tham gia lồng nhau vòng vốn đã sử dụng đĩa IO. Bắt đầu với SQL Server 7.0, băm và merge tham gia được giới thiệu. Tham gia băm và merge làm nhiều hơn nữa trong bộ nhớ chế biến hơn tham gia lồng nhau vòng lặp. Kết quả hợp lý Điều này là rằng CPU và sử dụng bộ nhớ cao khi các kỹ thuật này tham gia là được sử dụng. Để biết thêm chi tiết về tham gia băm và merge, xem sự "hiểu biết Hash tham gia"và"Sự hiểu biết hợp nhất tham gia"các chủ đề trong SQL Server 7.0 sách Trực tuyến.

Truy vấn biên soạn lần bị ảnh hưởng bởi vì các truy vấn tôi ưu hoa có nhiều tùy chọn và thông tin có sẵn hơn trong phiên bản trước SQL Server, bao gồm cả mới băm và hợp nhất tham gia kỹ thuật, cải thiện tìm kiếm các thuật toán, và cột thống kê. Thông tin bổ sung này cho phép các truy vấn cụ tôi ưu hoa để chọn phương pháp hiệu quả nhất để lấy dữ liệu truy vấn. Tuy nhiên, phân tích và xem xét các kỹ thuật mới và thông tin đòi hỏi thời gian xử lý. Này sử dụng CPU tăng có thể dẫn đến truy vấn trình biên dịch lần được dài hơn trong phiên bản trước của SQL Server.

Đối với hầu hết các truy vấn, sự gia tăng này trong thời gian biên dịch bù đắp bởi một giảm trong thời gian thực hiện. Các hiệu ứng tổng thể là truy vấn chạy nhanh hơn hơn trong phiên bản trước của SQL Server. Một ngoại lệ, tuy nhiên, xảy ra với rất nhỏ, đơn giản, OLTP-loại queries có rất thấp thực hiện lần. Cho các truy vấn này, quá trình tạo ra một kế hoạch truy vấn có thể có một bằng hoặc lớn hơn chi phí hơn so với thực hiện truy vấn. Do đó, các truy vấn có thể thực hiện hơi chậm hơn so với các phiên bản trước đó của SQL Server. Bởi vì sự khác biệt là thường trong mili giây, các hiệu ứng này không nhận thấy đối với một đặc biệt truy vấn nếu nó được thực thi cá nhân. Tuy nhiên, bạn có thể nhận thấy rằng tổng thể hệ thống sử dụng CPU là cao hơn trong phiên bản trước của SQL Server nếu lớn các con số của các truy vấn quảng cáo-hoc được thực hiện đồng thời bởi một số lượng người dùng.

Phát triển các truy vấn parameterized

SQL Server 7.0 sử dụng một số kỹ thuật mới, chẳng hạn như bộ nhớ đệm quảng cáo-hoc truy vấn và tự động parameterization. Tuy nhiên, các truy vấn đó SQL Server 7,0 tự động parameterizes giới hạn. Sử dụng các phương pháp sau đây để làm cho chắc chắn rằng kế hoạch truy vấn được vec và có thể được tái sử dụng hiệu quả hơn:
  • Tham số dấu OLE DB và ODBC API cho phép tham số phải được xác định với một dấu chấm hỏi khi người dùng gửi truy vấn. Điều này có thể rất hữu ích trong bất kỳ ứng dụng, đặc biệt là cho các ứng dụng trung tầng có thế hệ truy vấn mô-đun nơi sử dụng thủ tục được lưu trữ là không có sẵn. Kế hoạch truy vấn là được tạo ra cho các truy vấn có tham số dấu hiệu có thể được tái sử dụng bởi bất kỳ khách hàng mà thực hiện truy vấn tương tự, ngay cả khi các giá trị tham số khác nhau được quy định. Để biết thêm chi tiết, xem chủ đề "Tham số dấu" trong SQL Server 7.0 sách Trực tuyến.
  • sp_executesql Các sp_executesql thủ tục được lưu trữ được gọi là của nhà cung cấp OLE DB hoặc trình điều khiển ODBC khi đánh dấu thông số được sử dụng trong một ứng dụng. Tuy nhiên, nó cũng có thể được gọi là trực tiếp bởi ứng dụng khác hoặc trong một thủ tục được lưu trữ để một cách rõ ràng parameterize quảng cáo-hoc truy vấn. Điều này có thể rất hữu ích trong các ứng dụng hoặc thực thi tập tin mà tuyên bố thi công được sử dụng để thực hiện động SQL phát biểu. Không giống như sp_executesql, các báo cáo chạy không cho phép parameterization. Điều này giới hạn cơ hội tái sử dụng kế hoạch truy vấn. Để biết thêm chi tiết, xem các "sp_executesql (T-SQL)" và "Bằng cách sử dụng sp_executesql" các chủ đề trong SQL Server 7.0 Sách trực tuyến.
  • Thủ tục được lưu trữ Thủ tục được lưu trữ có nhiều lợi ích, bao gồm cả khả năng parameterize truy vấn và tái sử dụng thực hiện kế hoạch. Để biết thêm chi tiết, xem các Các chủ đề "Stored thủ tục" và "Lập trình thủ tục lưu trữ" trong SQL Server 7,0 Sách trực tuyến.

Xem dữ liệu hiệu suất giám sát

Sử dụng Nhật ký hiệu suất màn hình để xác định hệ thống mà nguồn tài nguyên đang gây ra các nút cổ chai. Đăng nhập màn hình hiệu suất có thể cung cấp cho bạn một bức tranh tổng thể của hệ thống và giúp tập trung sự chú ý của bạn khi bạn xem dữ liệu SQL Profiler. Xem xét các dữ liệu hiệu suất màn hình từ thời gian khi hiệu suất được tốt thông qua thời gian hiệu suất giảm. Xác định các Số lượt truy cập mà đã bị ảnh hưởng đầu tiên, và sau đó xác định sau đây vấn đề là phù hợp nhất với tình hình của bạn:
  • Đối tượng: quá trình
    Số lượt truy cập: bộ vi xử lý
    Ví dụ: SQL Máy chủ
  • Đối tượng: bộ vi xử lý
    Số lượt truy cập: % thời gian xử lý
    Ví dụ: Kiểm tra mỗi trường hợp bộ xử lý
  • Đối tượng: SQL Server: bộ đệm Manager
    Số lượt truy cập: miễn phí Bộ đệm
  • Đối tượng: SQL Server: bộ đệm Manager
    Số lượt truy cập: Trang bị đánh cắp Count
  • Đối tượng: SQL Server: bộ nhớ Manager
    Số lượt truy cập: bộ nhớ Tài trợ đang chờ giải quyết
  • Đối tượng: SQL Server: SQL thống kê
    Số lượt truy cập: SQL Biên tập/sec
Nếu việc sử dụng CPU, SQL biên dịch/giây, và miễn phí bộ đệm quầy là cao, và các quầy bộ nhớ cấp chờ giải quyết và đánh cắp trang Count là thấp, điều này chỉ ra rằng CPU là các nút cổ chai. Tập trung vào làm thế nào để có hiệu quả parameterize và tái sử dụng kế hoạch truy vấn để tránh chi phí kế hoạch truy vấn thế hệ, và xem phần "Nhóm SQL Profiler vết theo sự kiện lớp" bài viết này. Nếu miễn phí bộ đệm và SQL biên dịch/sec quầy là thấp, và đánh cắp trang Count và bộ nhớ và tài trợ đang chờ quầy là cao, SQL Máy chủ là bộ nhớ hạn chế. Tập trung vào việc tìm kiếm truy vấn nơi tham gia băm là sử dụng và có thể được thay đổi để lặp tham gia, và xem các "nhóm the SQL Profiler dấu vết của thời gian"phần của bài viết này. Cho biết thêm thông tin về những quầy, sử dụng tên truy cập để tìm kiếm các SQL Server 7.0 sách Online.

Xem dữ liệu SQL Profiler

Khi bạn đang giải quyết các vấn đề hiệu suất, nó là vô cùng có giá trị để xem dữ liệu SQL Profiler. Bạn không cần phải xem xét tất cả các dữ liệu mà bạn bị bắt; được chọn lọc. SQL Profiler giúp bạn để có hiệu quả xem các dữ liệu được quay. Trên các Thuộc tính Tab (trên các Tệp trình đơn, nhấp vào Thuộc tính), SQL Profiler cho phép bạn để giới hạn các dữ liệu được hiển thị bằng cách loại bỏ dữ liệu cột hoặc các sự kiện, nhóm hay phân loại theo dữ liệu cột, và áp dụng các bộ lọc. Bạn có thể tìm kiếm dấu vết toàn bộ hoặc chỉ có một cột cụ thể cho giá trị cụ thể (trên các Chỉnh sửa trình đơn, nhấp vào Tìm ). Bạn cũng có thể tiết kiệm một bảng SQL Server SQL Profiler, dữ liệu (trên các Tệp trình đơn, điểm đến Löu laøm, và sau đó nhấp vào Dấu vết Bảng), và sau đó chạy truy vấn SQL chống lại nó.

Chú ý Hãy chắc chắn rằng bạn chỉ lọc một tập tin đã lưu dấu vết. Nếu bạn làm theo các bước trên một dấu vết hoạt động, bạn có nguy cơ mất dữ liệu bị bắt kể từ vết đã được bắt đầu. Lưu một dấu vết hoạt động vào một tập tin hoặc bảng đầu tiên (trên các Tệp trình đơn, nhấp vào Löu laøm ), và sau đó mở lại nó (trên các Tệp trình đơn, nhấp vào Mở) trước khi bạn tiếp tục. Khi bạn làm việc với một tập tin đã lưu water, các lọc không loại bỏ vĩnh viễn dữ liệu; dữ liệu là chỉ ẩn, không xóa. Bạn có thể thêm và loại bỏ các sự kiện và dữ liệu cột để giúp tập trung tìm kiếm của bạn.

Bạn cũng nên tập trung vào các lĩnh vực mà bạn nhận được lợi nhất. Các sau các yếu tố có thể giúp tăng hiệu suất ứng dụng nhưng không nhất thiết phải đến mức độ tương tự. Trước khi bạn thực hiện bất kỳ thay đổi, xác định cách có hiệu quả những thay đổi có thể tùy thuộc vào các yếu tố sau:
  • Làm thế nào thường xuyên chạy truy vấn
  • Bao nhiêu cải tiến truy vấn có thể được cải thiện
Ví dụ, việc giảm thời gian thực hiện của một truy vấn duy nhất từ 1,5 giây để 1,2 giây không có thể hữu ích nếu truy vấn không được thực hiện thường xuyên trong suốt cả ngày. Tuy nhiên, nếu các truy vấn được thực hiện rất thường xuyên bởi một số lượng người sử dụng đồng thời, việc cải thiện hiệu suất có thể rất hiệu quả. Ngược lại, việc cải thiện một truy vấn duy nhất từ 6 phút 3 giây có thể không mang lại một sự gia tăng đáng chú ý trong hiệu suất tổng thể nếu nó là hiếm khi được sử dụng. Sử dụng các nhóm và lọc kỹ thuật trong SQL Profiler và của bạn kiến thức của các ứng dụng để ước tính những ảnh hưởng của một truy vấn cụ thể hoặc thủ tục trước khi bạn thực hiện bất kỳ thay đổi. Tập trung vào những thay đổi có hiệu quả nhất đầu tiên, và sau đó tiếp tục với lặp đi lặp lại qua các truy vấn và thủ tục cho đến khi bạn đạt đến một mức độ nơi có đủ cải thiện.

Sau khi bạn lưu một dấu vết SQL Profiler vào một tập tin hoặc bảng, mở lại dấu vết trong SQL Profiler và xem xét lại nội dung. Nhóm các SQL Profiler truy nguyên, hãy làm theo các bước sau:
  • Nhóm SQL Profiler vết theo thời gian thực hiện:
    1. Trên các Tệp trình đơn, nhấp vào Thuộc tính.
    2. Bấm vào các Dữ liệu cột tab, và sau đó dưới Các nhóm, bấm LÊN để di chuyển Thời gian. Nhấp vào XUỐNG để loại bỏ tất cả khác cột.
    3. Bấm vào các Sự kiện tab, và sau đó loại bỏ tất cả sự kiện ngoại trừ TSQL SQL:StmtCompletedTSQL RPC: hoàn thành. Điều này cho phép bạn tập trung vào chỉ là các truy vấn mà đang thực thi.
    4. Nhấp vào Ok.
    Nhóm theo thời gian cho phép để dễ dàng xem SQL phát biểu, lô, và thủ tục đang chạy các slowest. Xem xét các water khi vấn đề xảy ra, và tạo ra một đường cơ sở của hiệu suất tốt. Bạn có thể lọc theo bắt đầu thời gian để phá vỡ vết thành phần khi hiệu suất là phần tốt và riêng biệt khi hiệu suất là người nghèo. Tìm các truy vấn với thời gian dài nhất khi hiệu suất là tốt. Đây là rất có thể là gốc của vấn đề. Khi hiệu suất tổng thể hệ thống giảm, ngay cả tốt truy vấn có thể hiển thị thời gian dài vì họ đang chờ đợi cho tài nguyên hệ thống.

    Xem xét kế hoạch thực hiện cho các truy vấn mà hầu hết thường xuyên có thời gian dài. Nếu bạn thấy rằng một băm tham gia đang được sử dụng, xem xét việc sử dụng các LOOP tham gia truy vấn gợi ý để buộc một tham gia vòng lặp lồng nhau cho truy vấn. Nếu thời gian thực hiện cho truy vấn bằng cách sử dụng một tham gia vòng lặp là ít hơn, bằng, hoặc thậm chí hơi cao hơn so với thời gian thực hiện với sự tham gia băm, tham gia một vòng lặp có thể một lựa chọn tốt hơn nếu máy tính đang trải qua bộ nhớ cao và sử dụng CPU. Bởi giảm căng thẳng trên nút cổ chai tài nguyên (CPU và bộ nhớ), bạn có thể cải thiện hiệu suất tổng thể hệ thống. Để biết thêm thông tin về tham gia vòng LẶP truy vấn gợi ý, xem chủ đề "Chọn (T-SQL)" trong SQL Server 7.0 sách trực tuyến.
  • Nhóm SQL Profiler vết theo sự kiện lớp:
    1. Trên các Tệp trình đơn, nhấp vào Thuộc tính.
    2. Bấm vào các Dữ liệu cột tab, và sau đó theo các Các nhóm nhóm này, bấm LÊN để di chuyển Sự kiện ClassVăn bản với Sự kiện Lớp học trên đầu trang. Nhấp vào XUỐNG để loại bỏ tất cả các cột khác theo các Các nhóm nhóm.
    3. Bấm vào các Sự kiện tab, và sau đó làm cho chắc chắn rằng tất cả các sự kiện được bao gồm.
    4. Nhấp vào Ok.

Loại sự kiện

Để xem những gì các loại của các sự kiện đang xảy ra trên máy tính đang chạy SQL Server và như thế nào thường xuyên các sự kiện xảy ra, nhóm của các Sự kiện Lớp học cột. Tìm kiếm này cột cho các sự kiện sau đây:
  • MISC: Chuẩn bị SQL và Exec chuẩn bị SQL; CON CHẠY: Cursorprepare Một Chuẩn bị SQL sự kiện chỉ ra rằng một lệnh SQL được chuẩn bị sẵn sàng để sử dụng với một thiết lập kết quả mặc định (phía khách hàng con trỏ) sử dụng SQLPrepare/SQLExecute (ODBC) hoặc ICommandText::Prepare/ICommandText::Execute (cho OLE DB) với mặc định tùy chọn con trỏ chuột: chuyển tiếp chỉ, chỉ, đọc rowset kích thước = 1. Một Cursorprepare sự kiện chỉ ra rằng một con trỏ phía máy chủ đã được chuẩn bị trên một SQL tuyên bố bằng cách sử dụng SQLPrepare/SQLExecute (cho ODBC) hoặc ICommandText::Prepare/ICommandText::Execute (cho OLE DB) với một trong các tùy chọn con trỏ chuột trước thiết lập một giá trị không mặc định. Một Exec chuẩn bị sẵn sàng SQL sự kiện chỉ ra rằng một trong trước đó loại hiện có chuẩn bị cáo đã được thực hiện. Nếu bạn xem lần xuất hiện thường xuyên của các các sự kiện, ứng dụng của bạn là sử dụng các mô hình chuẩn bị/thực hiện khi nó mở ra kết quả của bộ. Nếu vậy, bạn phải xác định nếu bạn đang sử dụng chuẩn bị/thực hiện mô hình một cách chính xác.

    Lý tưởng nhất, một ứng dụng chuẩn bị một lệnh SQL một khi và thực hiện nó nhiều lần để cho cụ tôi ưu hoa không phải biên dịch một kế hoạch mới mỗi khi bản tuyên bố được thi hành. Mỗi khi bạn chạy một chuẩn bị sẵn sàng tuyên bố, bạn tiết kiệm chi phí biên soạn truy vấn. Nếu bạn chỉ định thực hiện một truy vấn một thời gian, Microsoft recommends mà bạn không chuẩn cho nó. Chuẩn bị và sau đó thực hiện một lệnh SQL đòi hỏi ba mạng roundtrips: một để chuẩn bị các báo cáo, một thực thi các báo cáo, và một để unprepare các báo cáo. Chuẩn bị con chạy phía máy chủ yêu cầu tối thiểu năm vòng chuyến đi: một để chuẩn cho con trỏ, một để thực hiện hoặc mở nó, một trong hoặc nhiều hơn nữa để Lấy từ nó, một để đóng nó, và một để unprepare nó. Thực hiện các truy vấn chỉ đòi hỏi một roundtrip.

    Để xem làm thế nào có hiệu quả của bạn ứng dụng này sử dụng mô hình chuẩn bị/thực thi, so sánh số lần này hai sự kiện (chuẩn bị và thực thi) xảy ra. Số lượng Exec chuẩn bị SQL sự kiện sẽ lớn hơn nhiều so với Tổng nguồn Chuẩn bị SQLCursorPrepare sự kiện (ít nhất là ba đến năm lần lớn hơn là một ước tính tốt). Điều này chỉ ra rằng phát biểu chuẩn bị đang được dùng lại thường xuyên, đủ để khắc phục sự tăng chi phí để tạo ra chúng. Nếu số lượng Chuẩn bị SQLCursorPrepare sự kiện là khoảng tương đương với số lượng Exec chuẩn bị SQL các sự kiện, điều này có thể cho thấy rằng các ứng dụng không phải là có hiệu quả sử dụng mô hình chuẩn bị/thực hiện. Cố gắng để chuẩn bị một tuyên bố một thời gian và tái sử dụng nó càng nhiều càng tốt. Bạn cũng có thể thay đổi ứng dụng của bạn để chuẩn bị phát biểu một thời gian và tái sử dụng những phát biểu.

    Ứng dụng phải được cụ thể bằng văn bản để sử dụng các mô hình chuẩn bị/thực thi một cách hiệu quả. Các trọn đời của một xử lý một tuyên bố chuẩn bị được kiểm soát bởi bao lâu bạn giữ HSTMT mở trong ODBC hoặc vật ICommandText OLE DB. Một trong những phổ biến thực hành là để có được một HSTMT, chuẩn bị một lệnh SQL, thực hiện các chuẩn bị sẵn sàng tuyên bố, và sau đó HSTMT, qua đó thua xử lý các chuẩn bị không có kế hoạch. Nếu bạn làm điều này, bạn không nhận được bất kỳ lợi ích từ chuẩn bị/thực hiện mô hình. Trong thực tế, bạn có thể xem một sự xuống cấp hiệu suất vì thêm trên cao của mạng roundtrips. Ứng dụng phải có một phương pháp để nhớ cache HSTMT hoặc đối tượng với chuẩn bị tuyên bố xử lý và truy cập chúng cho tái sử dụng. Trình điều khiển hoặc nhà cung cấp không làm điều này tự động; các ứng dụng chịu trách nhiệm cho việc thực hiện, duy trì và sử dụng thông tin này. Nếu ứng dụng không thể làm như vậy, hãy xem xét bằng cách sử dụng tham số dấu thay vì các chuẩn bị/thực hiện phương pháp.
  • Bằng cách sử dụng tham số dấu Các ứng dụng có thể sử dụng tham số dấu để tối ưu hóa việc sử dụng các cùng Transact lệnh-SQL nhiều lần với đầu vào khác nhau và các giá trị đầu ra. Lần đầu tiên mà một truy vấn được thực thi, nó chuẩn bị như một truy vấn parameterized, và SQL Server tạo ra và lưu trữ một kế hoạch parameterized cho truy vấn. Đối với các cuộc gọi tiếp theo để truy vấn tương tự bằng cách sử dụng một trong hai các thông cùng hoặc khác nhau số, SQL Server không phải tạo ra một kế hoạch mới của truy vấn; SQL Server có thể tái sử dụng hiện tại truy vấn kế hoạch bởi thay thế các tham số hiện tại.

    Nếu ứng dụng sử dụng tham số dấu với các cuộc gọi đến SQLExecDirect (ODBC) hoặc ICommandText::Execute (cho OLE DB), trình điều khiển hoặc nhà cung cấp tự động gói sản phẩm các lệnh SQL và thực hiện nó như một sp_executesql cuộc gọi. Các báo cáo không phải được chuẩn bị và thực hiện một cách riêng biệt. Khi SQL Server sẽ nhận được một cuộc gọi đến sp_executesql, nó tự động kiểm tra bộ nhớ cache của thủ tục cho một kế hoạch phù hợp và reuses rằng kế hoạch hoặc tạo ra một kế hoạch mới.

    Để xác định nếu bạn ứng dụng này hiện đang sử dụng tham số dấu, bạn có thể tìm kiếm cácVăn bản cột trong SQL Profiler vết cho "sp_executesql." Tuy nhiên, bởi vì sp_executesql có thể được gọi là trực tiếp, không phải tất cả các trường hợp cho thấy việc sử dụng tham số dấu.

    Để biết thêm thông tin về chuẩn bị/thực hiện mẫu, xem "sử dụng thực hiện kế hoạch bộ nhớ đệm và lại" chủ đề trong SQL Server 7.0 sách Trực tuyến. Để biết thêm thông tin về dấu hiệu tham số, xem tham số" Đánh dấu"chủ đề trong SQL Server 7.0 sách trực tuyến.
  • SP: hoàn thành Năng động SQL phát biểu thực hiện với lệnh thi công hiển thị như là một SP: hoàn thành sự kiện với các văn bản "Năng động SQL." Mở rộng các SP: hoàn thành sự kiện, và sau đó tìm kiếm cho bất kỳ lần xuất hiện mà có "năng động SQL"như các văn bản. Nếu có rất nhiều người trong số những sự kiện này, bạn có thể cải thiện hiệu suất của ứng dụng bằng cách sử dụng sp_executesql thay vì của tuyên bố thi công. Các sp_executesql lưu trữ thủ tục giấy phép SQL Server để tái sử dụng thực hiện kế hoạch nếu truy vấn tương tự được thực thi một lần nữa bằng cách sử dụng tham số khác nhau. Khi bạn sử dụng các EXECUTE tuyên bố, kế hoạch không vec, và nó không phải sử dụng lại trừ khi các truy vấn được thực thi một lần nữa bằng cách sử dụng các tham số tương tự.

    Để xác định truy vấn hoặc thủ tục sử dụng năng động SQL sự kiện với thi công tuyên bố, lưu ý các ID kết nối và bắt đầu thời gian của cho mỗi sự kiện. Tách các water (hủy bỏ Sự kiện ClassVăn bản từ các Các nhóm tiêu đề). Sau khi bạn tách vết, nó được sắp xếp trong Thứ tự thời gian. Bạn có thể lọc dấu vết của kết nối ID (trên các Các bộ lọc thẻ), và sau đó loại bỏ tất cả các lớp học sự kiện ngoại trừ các SP: bắt đầuSP: hoàn thành các sự kiện cho tăng dễ đọc. Bạn có thể sau đó tìm kiếm các Bắt đầu thời gian của sự kiện này (ngày các Chỉnh sửa trình đơn, nhấp vàoTìm). Các kết quả hiển thị khi bắt đầu sự kiện SQL năng động. Nếu sự kiện này diễn ra trong một thủ tục được lưu trữ, các sự kiện xuất hiện giữa các SP: bắt đầuSP: hoàn thành các sự kiện cho rằng thủ tục. Nếu sự kiện này đã không xảy ra trong một lưu trữ thủ tục, nó đã được thực hiện như một truy vấn quảng cáo-hoc, và bạn có thể sử dụng các dữ liệu cột)Tên ứng dụng, NT Tên người dùngvà những người khác) để xác định nơi lệnh được thực thi. Để xác định các văn bản của lệnh và bối cảnh nơi nó đã được thực hiện, bạn cũng có thể thêm các lớp học tổ chức sự kiện, chẳng hạn như SQL:BatchCompletedSQL:RPCCompleted.

    Sau khi bạn xác định nơi các tuyên bố EXECUTE là được sử dụng, xem xét việc thay thế nó bằng một cuộc gọi đến sp_executesql. Ví dụ, hãy xem xét kịch bản sau đây nơi thi công lệnh được sử dụng với động SQL. Một thủ tục phải mất một tên bảng, ID, và idValue như đầu vào tham số, và sau đó thực hiện một tuyên bố chọn từ các bảng dựa trên giá trị ID. Bằng cách sử dụng một tuyên bố thi công, các thủ tục trông tương tự như mã sau đây:
    drop proc dynamicUsingEXECUTE		  go create proc dynamicUsingEXECUTE @table sysname, @idName varchar(10),		  @idValue varchar(10) as declare @query nvarchar(4000) -- Build query string		  with parameter. -- Notice the use of escape quotes. select @query = 'select *		  from ' + @table + ' where ' + @idName + ' = ''' + @idValue + '''' exec (@query)		  go
    Giả định rằng các truy vấn không tự động vec, nếu bạn thực hiện thủ tục này đối với các tiêu đề bảng trong các quán rượu cơ sở dữ liệu mẫu hai lần với các giá trị khác nhau cho các @ idValue tham số, SQL Server phải tạo ra một kế hoạch riêng biệt truy vấn cho mỗi thực hiện. Ví dụ:
    exec dynamicUsingEXECUTE		  'titles', 'title_id', 'MC2222' go exec dynamicUsingEXECUTE 'titles',		  'title_id', 'BU7832'
    Chú ý Trong ví dụ này, các truy vấn là đơn giản đủ rằng SQL Server có thể tự động parameterize nó và thực sự tái sử dụng kế hoạch thực hiện. Tuy nhiên, Nếu điều này là một truy vấn phức tạp SQL Server có thể không tự động parameterize, Sử dụng SQL Server có thể không lại kế hoạch để thực hiện thứ hai nếu các @ idValue tham số được thay đổi. Giới hạn truy vấn đơn giản sau những phức tạp của các ví dụ.

    Bạn có thể viết lại thủ tục này sử dụng sp_executesql thay vì của tuyên bố thi công. Hỗ trợ cho tham số thay thế làm cho sp_executesql hiệu quả hơn bởi vì nó tạo ra thực hiện các kế hoạch thêm có khả năng được tái sử dụng bởi máy chủ SQL. Ví dụ:
    drop proc dynamicUsingSP_EXECUTESQL go create proc		  dynamicUsingSP_EXECUTESQL @table sysname, @idName varchar(10), @idValue		  varchar(10) as declare @query nvarchar(4000) -- Build query string with		  parameter select @query = 'select * from ' + @table + ' where ' + @idName + ' =		  @idValue' -- Now execute with parameter exec sp_executesql @query, N'@idValue		  varchar(10)', @idValue go exec dynamicUsingSP_EXECUTESQL 'titles', 'title_id',		  'MC2222' go exec dynamicUsingSP_EXECUTESQL 'titles', 'title_id',		  'BU7832'
    Trong ví dụ này, lần đầu tiên mà các sp_executesql tuyên bố được thi hành, SQL Server tạo ra một kế hoạch parameterized Đối với những tuyên bố chọn từ tiêu đề với title_id như tham số. Để thực hiện thứ hai, SQL Server reuses các kế hoạch với các giá trị tham số mới. Để biết thêm thông tin về sp_executesql, xem "sp_executesql (T-SQL)" và "Bằng cách sử dụng sp_executesql" chủ đề trong SQL Server 7.0 sách trực tuyến.
  • SP:RECOMPILES Sự kiện này chỉ ra rằng một thủ tục được lưu trữ biên trong thời gian thực hiện. Nhiều recompile sự kiện cho thấy rằng máy chủ SQL là sử dụng tài nguyên cho biên soạn truy vấn thay vì thực hiện truy vấn.
Nếu bạn không thấy bất kỳ của những sự kiện này, ứng dụng này đang thực hiện chỉ quảng cáo-hoc truy vấn đối với SQL Server. Trừ khi SQL Server xác định nó có thể tự động parameterize một số truy vấn hoặc nếu như vậy tham số được sử dụng nhiều lần, mỗi truy vấn được thực thi đòi hỏi máy chủ SQL để tạo ra một kế hoạch thực hiện mới. SQL Server Performance Giám sát nên hiển thị nhiều SQL biên dịch/sec. Điều này có thể là CPU chuyên sâu cho nhiều người sử dụng đồng thời. Để làm việc xung quanh vấn đề này, tìm thấy thường xuyên nhất thực hiện truy vấn, và xem xét việc tạo ra các thủ tục được lưu trữ cho các truy vấn này, bằng cách sử dụng tham số đánh dấu, hoặc bằng cách sử dụng sp_executesql.
THAM KHẢO
Để biết thêm chi tiết về giám sát và gỡ rối các vấn đề hiệu suất trong SQL Server, nhấp vào số bài viết sau để xem các bài viết trong cơ sở kiến thức Microsoft:
224587Làm thế nào để gỡ rối ứng dụng hiệu suất với SQL Server
224453 INF: Sự hiểu biết và giải quyết SQL Server 7.0 hay 2000 chặn vấn đề
243586 Xử lý sự cố thủ tục được lưu trữ đựa
243589 Làm thế nào để khắc phục sự cố truy vấn chậm-chạy SQL Server 7.0 hoặc sau này
251004 INF: Làm thế nào để giám sát SQL Server 7.0 chặn
PERF mon perfmon xấu người nghèo chậm chậm chạp kbswept kbSQLServ2000Sweep

Cảnh báo: Bài viết này được dịch tự động

Thuộc tính

ID Bài viết: 243588 - Xem lại Lần cuối: 08/21/2011 10:47:00 - Bản sửa đổi: 2.0

Microsoft SQL Server 7.0 Standard Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 2000 64-bit Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Standard Edition

  • kbhowtomaster kbhowto kbinfo kbmt KB243588 KbMtvi
Phản hồi
id=1&t=">