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

Trình duyệt của bạn không được hỗ trợ

Bạn cần cập nhật trình duyệt của mình để sử dụng trang web.

Cập nhật lên Internet Explorer phiên bản mới nhất.

Mô tả của SQL Server chặn gây ra bởi biên dịch ổ khóa

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:263889
TÓM TẮT
Trong Microsoft SQL Server, chỉ có một bản sao của một kế hoạch thủ tục được lưu trữ thường là trong bộ nhớ cache tại một thời điểm. Thi hành điều này đòi hỏi phải đăng thường kì trên một số phần của quá trình biên soạn, và đồng bộ hóa này được thực hiện một phần bằng cách sử dụng biên dịch ổ khóa. Nếu nhiều kết nối đồng thời đang chạy cùng một lưu trữ thủ tục và một khóa biên dịch phải được lấy cho rằng thủ tục được lưu trữ mỗi khi nó là chạy, hệ thống quá trình ID (SPID) có thể bắt đầu để chặn nhau khi họ mỗi cố gắng để có được một khóa biên dịch độc quyền trên đối tượng.
THÔNG TIN THÊM
Thủ tục được lưu trữ đựa là một lời giải thích cho ổ khóa biên dịch trên một thủ tục được lưu trữ hoặc kích hoạt. Các giải pháp trong trường hợp này là để làm giảm hoặc loại bỏ các recompiles. Cho một lời giải thích những lý do phổ biến nhất mà một thủ tục được lưu trữ có thể phải được biên và cho một số thông tin hữu ích về việc giảm tần số của recompiles, xem bài viết cơ sở kiến thức Microsoft sau:
243586 Xử lý sự cố thủ tục được lưu trữ đựa
Một kịch bản trong đó biên dịch ổ khóa xảy ra là khi các điều kiện sau là đúng:
  • Người sử dụng người điều hành các thủ tục được lưu trữ không phải là chủ sở hữu của các thủ tục.
  • Thủ tục được lưu trữ tên không phải là hoàn toàn đủ điều kiện với tên của chủ sở hữu đối tượng.
Ví dụ, nếu người sử dụng "dbo" sở hữu đối tượng dbo.mystoredproc và người dùng khác, "Harry," chạy thủ tục này được lưu trữ bằng cách sử dụng lệnh "exec mystoredproc," việc tra cứu ban đầu bộ nhớ cache bằng tên đối tượng không thành công vì các đối tượng không đủ điều kiện chủ sở hữu. (Nó không được biết cho dù một thủ tục được lưu trữ được đặt tên Harry.mystoredproc tồn tại. Vì vậy, SQL Server không thể chắc chắn rằng kế hoạch lưu trữ cho dbo.mystoredproc là điều đúng để thực hiện.) SQL Server sau đó lấy được một biên dịch độc quyền khóa về thủ tục và làm cho chuẩn bị để biên dịch các thủ tục. Điều này bao gồm việc giải quyết tên đối tượng cho một đối tượng của bạn. Trước khi máy chủ SQL biên dịch các kế hoạch, SQL Server sử dụng ID đối tượng này để thực hiện một tìm kiếm chính xác hơn của bộ nhớ cache của thủ tục và có thể xác định vị trí một kế hoạch biên dịch trước đó thậm chí không có chủ sở hữu bằng cấp.

Nếu một kế hoạch hiện tại được tìm thấy, SQL Server reuses kế hoạch lưu trữ và không thực sự biên dịch các thủ tục được lưu trữ. Tuy nhiên, việc thiếu các chủ sở hữu bằng cấp lực lượng SQL Server để thực hiện một tra cứu bộ nhớ cache thứ hai và có được một biên dịch độc quyền khóa trước khi chương trình xác định rằng kế hoạch thực hiện được lưu trữ hiện có thể được tái sử dụng. Việc thu thập các khóa và thực hiện tra cứu và các công việc khác cần thiết để tiếp cận với thời điểm này có thể giới thiệu một sự chậm trễ cho các ổ khóa biên dịch dẫn đến chặn. Đây là đặc biệt đúng nếu nhiều người sử dụng không phải là chủ sở hữu các thủ tục được lưu trữ chạy đồng thời các thủ tục mà không cung cấp tên của chủ sở hữu. Lưu ý rằng ngay cả khi bạn không thấy SPID đang chờ biên dịch ổ khóa, thiếu văn bằng chủ sở hữu có thể giới thiệu sự chậm trễ trong thực hiện thủ tục được lưu trữ và làm cho việc sử dụng CPU cao không cần thiết.

Các chuỗi sự kiện sau đây sẽ được ghi lại trong một dấu vết SQL Server Profiler khi vấn đề này xảy ra. (Để theo dõi các sự kiện liên quan đến bộ nhớ cache, bạn phải cho phép sự kiện tiên tiến. Để làm điều này, bấmTuỳ chọn trên các Công cụ trình đơn, và sau đó chọn Tất cả các lớp học tổ chức sự kiện.)

Sự kiện classVăn bản
RPC: bắt đầumystoredproc
SP:CacheMissmystoredproc
SP:ExecContextHitmystoredproc
SP: bắt đầumystoredproc
......

SP:CacheMissxảy ra khi việc tra cứu bộ nhớ cache theo tên không. Sau đây SP:ExecContextHit chỉ ra rằng một kế hoạch lưu trữ kết hợp cuối cùng đã được tìm thấy trong bộ nhớ cache sau khi đối tượng không rõ tên đã được giải quyết cho một đối tượng của bạn. Tùy thuộc vào hoàn cảnh, SP:CacheHitcó thể xuất hiện thay vìSP:ExecContextHit.

Các giải pháp cho vấn đề này biên dịch khóa là để đảm bảo rằng tham chiếu đến thủ tục được lưu trữ được đủ điều kiện chủ sở hữu. (Thay vì của exec mystoredproc, sử dụng exec dbo.mystoredproc.) Trong khi chủ sở hữu bằng cấp là quan trọng vì lý do hiệu suất, bạn không phải vượt qua vòng loại proc đã lưu với tên cơ sở dữ liệu để ngăn chặn việc tra cứu bổ sung bộ nhớ cache.

Ngăn chặn đó gây ra bởi biên dịch ổ khóa có thể phát hiện bằng cách sử dụng tập lệnh chặn chẳng hạn như những người được xác định trong bài viết cơ sở kiến thức Microsoft sau:
251004 INF: Làm thế nào để giám sát SQL Server 7.0 chặn
271509 INF: Làm thế nào để giám sát SQL Server 2000 chặn
Sau đây là một số đặc điểm điển hình của biên dịch chặn mà có thể được quan sát thấy trong đầu ra tập lệnh chặn:
  • lastwaittype Đối với bị chặn và (thường) chặn SPID là LCK_M_X (độc quyền) và waitresource là dạng "TAB: dbid:object_id Biên [[dịch]],"nơi"object_id"là đối tượng của các thủ tục được lưu trữ ID.
  • Chức năng chặn có waittype 0x0000, tình trạng runnable. Blockees có waittype 0x000e (độc quyền khóa), trạng thái ngủ.
  • Mặc dù thời gian của các sự cố chặn có thể dài, không có không có dịch vụ SPID duy nhất là chặn SPID khác trong một thời gian dài. Người ta lăn chặn. Ngay sau khi một trình biên dịch được hoàn tất, một dịch vụ SPID mất hơn vai trò của bộ chặn đứng đầu trong một vài giây hoặc ít hơn, và như vậy.
Các thông tin sau đây là từ một bản chụp sysprocesses trong loại củachặn:
   spid  blocked  waittype  waittime  lastwaittype  waitresource   ----  -------  --------  --------  ------------  -------------------------      221    29      0x000e    2141      LCK_M_X       TAB: 6:834102 [[COMPILE]]   228    29      0x000e    2235      LCK_M_X       TAB: 6:834102 [[COMPILE]]    29   214      0x000e    3937      LCK_M_X       TAB: 6:834102 [[COMPILE]]    13   214      0x000e    1094      LCK_M_X       TAB: 6:834102 [[COMPILE]]    68   214      0x000e    1968      LCK_M_X       TAB: 6:834102 [[COMPILE]]   214     0      0x0000       0      LCK_M_X       TAB: 6:834102 [[COMPILE]]
Trong các waitresourcecột ("6:834102"), 6 là cơ sở dữ liệu ID và 834102 là đối tượng của bạn. Lưu ý rằng ID đối tượng này thuộc về một thủ tục được lưu trữ, không để một bảng (mặc dù loại khóa "TAB").

Chú ý
  • Nếu bạn đang sử dụng SQL Server 2005, nhiều người trong số các hệ thống bảng từ SQL Server 2000 bây giờ được thực hiện như một tập hợp các lượt xem. Những quan điểm được gọi là lượt xem khả năng tương thích, và họ có ý nghĩa cho tương thích ngược chỉ. Số lần xem khả năng tương thích vạch trần cùng một siêu dữ liệu đã có sẵn trong SQL Server 2000. Để biết thêm chi tiết về ánh xạ giữa các bảng SQL Server 2000 hệ thống và quan điểm hệ thống SQL Server 2005, xem chủ đề "Lập bản đồ SQL Server 2000 hệ thống bảng để SQL Server 2005 hệ thống xem" trong SQL Server 2005 sách trực tuyến.
  • Nếu tên của bạn được lưu trữ thủ tục bắt đầu với tiền tố "sp_" và không phải là trong cơ sở dữ liệu tổng thể, bạn nhìn thấySP:CacheMissvượt qua vòng trước khi bộ nhớ đệm hit cho mỗi thực hiện ngay cả khi bạn chủ sở hữu-loại thủ tục được lưu trữ. Điều này là do tiền tố sp_ nói với SQL Server các thủ tục được lưu trữ là một hệ thống lưu trữ thủ tục, và hệ thống lưu trữ thủ tục có độ phân giải khác nhau tên quy tắc. (Vị trí "ưa thích" là trong cơ sở dữ liệu tổng thể.) Tên của người dùng tạo ra các thủ tục được lưu trữ nên không bắt đầu với "sp_".
  • Nếu một thủ tục chủ sở hữu đủ điều kiện được thực hiện với một trường hợp khác nhau hơn thủ tục chủ sở hữu đủ điều kiện được lập làm, các thủ tục đủ điều kiện chủ sở hữu có thể có được mộtCacheMiss hoặc yêu cầu một biên dịch khóa nhưng cuối cùng sử dụng lưu trữ kế hoạch. Do đó, điều này sẽ không thực sự biên dịch các thủ tục và không nên làm cho nhiều của một trên cao. Nhưng trong một số tình huống, yêu cầu một khóa biên dịch có thể gây ra một tình huống "chặn chuỗi" nếu có rất nhiều SPID cố gắng để thực hiện thủ tục tương tự với một trường hợp khác nhau hơn so với các thủ tục được lập làm. Điều này đúng bất kể số thứ tự sắp xếp hoặc collation mà đang được sử dụng trên máy chủ hoặc trên cơ sở dữ liệu. Lý do cho hành vi này là rằng các thuật toán mà đang được sử dụng để tìm các thủ tục trong bộ nhớ cache dựa trên giá trị băm (vì lý do hiệu suất), mà có thể thay đổi nếu các trường hợp là khác nhau.

    Các workaround là thả và tạo ra các thủ tục với trường hợp tương tự như các thủ tục được thi hành bởi các ứng dụng. Bạn cũng có thể chắc chắn rằng các thủ tục được thực thi từ tất cả các ứng dụng sử dụng trường hợp tương tự.
  • Nếu bạn cố gắng thực hiện một thủ tục được lưu trữ như là một sự kiện ngôn ngữ thay vì theo một RPC, SQL Server phải phân tích và biên dịch truy vấn sự kiện ngôn ngữ thăm, xác định các truy vấn cố gắng để thực hiện thủ tục cụ thể, và sau đó cố gắng tìm ra một kế hoạch trong bộ nhớ cache cho rằng thủ tục. Để tránh tình trạng này trong đó SQL Server phải phân tích và biên dịch các sự kiện ngôn ngữ, đảm bảo rằng các truy vấn được gửi đến SQL như một RPC.

    Để biết thêm chi tiết, xem phần "Hệ thống lưu trữ thủ tục" trong sách Online bài viết "Tạo một thủ tục Stored."


Các vấn đề đã xác định

Dưới đây là một số vấn đề đã biết rằng có thể ngăn chặn bộ nhớ đệm kế hoạch:
  • Bạn sử dụng các biến BLOB như một tham số thủ tục lưu trữ. Để biết thêm thông tin, hãy bấm vào số bài viết sau để xem bài viết trong Cơ sở Kiến thức Microsoft:
    2380435 Khắc phục: Kế hoạch truy vấn cho một thủ tục được lưu trữ là không cache nếu sử dụng các thủ tục được lưu trữ một BLOB biến và biến được dùng trong một chuỗi chức năng trong Microsoft SQL Server 2008
  • Bạn sử dụng khóa đối XỨNG mở trong một lưu trữ thủ tục/truy vấn lô. Để biết thêm chi tiết, xem mục blog MSDN sau đây:

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

Thuộc tính

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

  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • kbinfo kbmt KB263889 KbMtvi
Phản hồi
src="https://c1.microsoft.com/c.gif?DI=4050&did=1&t=">cker.init();