Làm th? nào đ? gi?i quy?t v?n đ? ch?n x?y ra do khóa leo thang trong SQL Server

D?ch tiêu đ? D?ch tiêu đ?
ID c?a bài: 323630 - Xem s?n ph?m mà bài này áp d?ng vào.
Bung t?t c? | Thu g?n t?t c?

? Trang này

TÓM T?T

Khóa leo thang là quá tr?nh chuy?n đ?i r?t nhi?u h?t m?n ? khóa (ví d? như hàng ho?c trang ? khóa) vào b?ng khóa. Microsoft SQL Máy ch? đ?ng s? xác đ?nh khi nào đ? th?c hi?n các khóa leo thang. Khi th?c hi?n đi?u này quy?t đ?nh, SQL Server s? đưa vào tài kho?n s? ? khóa đư?c t? ch?c vào m?t c? th? quét, s? lư?ng các ? khóa đư?c t? ch?c b?i các giao d?ch toàn b?, và b? nh? đang đư?c s? d?ng cho ? khóa trong h? th?ng như m?t toàn th?. Thông thư?ng, SQL Server-k?t qu? m?c đ?nh hành vi trong khóa leo thang x?y ra ch? t?i nh?ng đi?m nơi nó s? c?i thi?n hi?u su?t ho?c khi b?n ph?i gi?m quá nhi?u h? th?ng khóa b? nh? đ?n m?t m?c đ? h?p l? hơn. Tuy nhiên, m?t s? thi?t k? ?ng d?ng ho?c truy v?n có th? kích ho?t khóa leo thang t?i m?t th?i đi?m khi nó là không mong mu?n, và escalated b?ng khóa có th? ngăn ch?n ngư?i dùng khác. Bài vi?t này th?o lu?n v? làm th? nào đ? xác đ?nh xem khóa leo thang là gây ra ch?n và làm th? nào đ? đ?i phó v?i leo thang không mong mu?n khóa.

THÔNG TIN THÊM

Làm th? nào đ? xác đ?nh li?u leo thang Lock là gây ra ch?n

Leo thang khóa không gây ra v?n đ? ch?n nh?t. Đ? xác đ?nh li?u leo thang khóa là x?y ra trong kho?ng th?i gian khi b?n kinh nghi?m ch?n các v?n đ?, b?t đ?u m?t d?u v?t SQL Profiler bao g?m các Khóa: leo thang s? ki?n. N?u b?n không th?y b?t k? Khóa: leo thang s? ki?n, leo thang khóa là không x?y ra trên máy ch? c?a b?n và các thông tin trong bài vi?t này không áp d?ng cho t?nh h?nh c?a b?n.

N?u khóa leo thang là x?y ra, h?y ki?m ch?ng r?ng escalated b?ng khóa là ch?n ngư?i dùng khác.

Cho bi?t thêm thông tin v? làm th? nào đ? xác đ?nh đ?u ch?n và như th? nào đ? xác đ?nh các khóa tài nguyên t? ch?c b?i b? ch?n đ?u đó là ch?n khác máy ch? quá tr?nh ID (SPID), nh?p vào s? bài vi?t sau đây đ? xem bài vi?t trong cơ s? ki?n th?c Microsoft:
224453S? hi?u bi?t và gi?i quy?t các SQL Server 7.0 hay 2000 ch?n v?n đ?
N?u khóa là ch?n ngư?i dùng khác b?t c? đi?u g? khác hơn là m?t ? khóa TAB (b?ng c?p) v?i m?t ch? đ? khóa s (chia s?), ho?c X (đ?c quy?n), leo thang khóa không ph?i là v?n đ?. Đ?c bi?t, n?u TAB khóa là m?t khóa ? đ?nh (ví d? như khóa ch? đ? IS, IU ho?c IX), đây không ph?i là các k?t qu? c?a khóa leo thang. N?u v?n đ? ch?n c?a b?n đang không đư?c gây ra b?i khóa leo thang, xem bài vi?t Q224453 đ? x? l? s? c? bư?c.

Làm th? nào đ? ngăn ch?n leo thang Lock

Cách đơn gi?n nh?t và an toàn nh?t đ? ngăn ch?n leo thang khóa là đ? gi? cho các giao d?ch ng?n và đ? gi?m d?u chân khóa truy v?n đ?t ti?n như v?y r?ng các ngư?ng leo thang khóa không đư?c vư?t quá. Có m?t s? cách đ? có đư?c m?c tiêu này, nhi?u ngư?i trong s? đó đư?c li?t kê:
  • Phá v? các ho?t đ?ng l?n lô thành nhi?u nh? hơn ho?t đ?ng kinh doanh. Ví d?, gi? s? b?n ch?y truy v?n sau đây đ? lo?i b? m?t vài h? sơ c? trăm ngàn t? m?t b?ng ki?m toán, và sau đó b?n th?y là nó gây ra m?t leo thang khóa ch?n ngư?i s? d?ng khác:
    DELETE FROM LogMessages WHERE LogDate < '2/1/2002'						
    B?ng cách lo?i b? nh?ng h? sơ này vài trăm t?i m?t th?i đi?m, b?n có th? đáng k? gi?m s? ? khóa mà tích l?y cho m?i giao d?ch và ngăn ch?n các khóa leo thang. Ví dụ:
    SET ROWCOUNT 500
    delete_more:
         DELETE FROM LogMessages WHERE LogDate < '2/1/2002'
    IF @@ROWCOUNT > 0 GOTO delete_more
    SET ROWCOUNT 0
  • Gi?m phát th?i khóa các truy v?n b?ng cách truy v?n như hi?u qu? nh?t có th?. L?n quét ho?c m?t s? l?n các tra c?u Bookmark có th? tăng cơ h?i c?a leo thang khóa; thêm vào đó, nó làm tăng cơ h?i deadlocks, và nói chung b?t l?i ?nh hư?ng concurrency và hi?u su?t. Sau khi b?n t?m th?y các truy v?n mà nguyên nhân leo thang khóa, t?m ki?m cơ h?i đ? t?o m?i ch? s? ho?c thêm c?t vào m?t ch? s? hi?n có đ? lo?i b? ch? s? ho?c b?ng quét và đ? t?i đa hóa hi?u qu? c?a ch? m?c t?m ki?m. Xem xét vi?c dán các truy v?n vào m?t c?a s? truy v?n truy v?n Analyzer đ? th?c hi?n m?t phân tích t? đ?ng ch? s? trên nó. Đ? làm như v?y, trên các Truy vấn tr?nh đơn, nh?p vào Ch? s? ch?nh thu?t s? trong SQL Server 2000 ho?c nh?p chu?t Th?c hi?n phân tích ch? s? trong SQL Server 7.0.

    M?t trong nh?ng m?c tiêu c?a t?i ưu hóa này là làm cho ch? m?c t?m ki?m l?i nhu?n hàng càng ít càng t?t đ? gi?m thi?u chi phí Tra c?u (t?i đa hóa s? ch?n l?c c?a các ch? s? cho đ?c bi?t là đánh d?u truy v?n). N?u SQL Server ư?c tính r?ng m?t nhà đi?u hành h?p l? trang đánh d?u Lookup có th? tr? v? nhi?u hàng, nó có th? s? d?ng m?t PREFETCH đ? th?c hi?n vi?c tra c?u d?u trang. N?u SQL H? ph?c v? s? d?ng PREFETCH cho m?t tra c?u d?u trang, nó ph?i làm tăng các giao d?ch cô l?p c?p c?a m?t ph?n c?a các truy v?n đ? l?p l?i đ?c cho m?t ph?n c?a các truy v?n. Đi?u này có ngh?a r?ng nh?ng g? có th? trông gi?ng như m?t l?a ch?n tuyên b? ? m?c đ? cam k?t đ?c cách ly có th? có đư?c nhi?u ngàn khóa ? khóa (trên c? hai ch? s? t?p h?p và m?t ch? s? nonclustered), mà có th? gây như v?y m?t truy v?n đ? vư?t quá ngư?ng leo thang khóa. Đây là đ?c bi?t là quan tr?ng n?u b?n th?y r?ng escalated khóa là m?t khóa dùng chung b?ng, trong đó, Tuy nhiên, không đư?c thư?ng đư?c th?y ? c?p đ? chi cam k?t s? cô l?p m?c đ?nh. N?u m?t đi?u kho?n Bookmark Lookup nh?n PREFETCH gây ra s? leo thang, xem xét thêm thêm c?t ch? s? nonclustered xu?t hi?n trong ch? m?c T?m ki?m ho?c nhà đi?u hành h?p l? ch? s? quét dư?i Lookup Bookmark h?p l? nhà đi?u hành trong k? ho?ch truy v?n. Có th? t?o ra m?t ch? s? bao g?m (m?t ch? s? bao g?m t?t c? các c?t trong m?t b?ng đ? đư?c s? d?ng trong truy v?n), ho?c t?i ít nh?t là m?t ch? s? n?m trên các c?t đư?c s? d?ng cho tiêu chí tham gia ho?c trong WHERE kho?n n?u bao g?m t?t c? m?i th? trong danh sách ch?n c?t là không th?c t?.

    M?t tham gia l?ng nhau Loop c?ng có th? s? d?ng PREFETCH, và đi?u này gây ra cùng m?t hành vi khóa.

    Đ? 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:
    260652Tham gia l?ng nhau v?ng l?p có s? d?ng m?t "d?u trang LOOKUP...V?I PREFETCH"có th? gi? ? khóa dài hơn
  • Leo thang khóa không th? x?y ra n?u m?t d?ch v? SPID khác nhau là hi?n nay đang n?m gi? m?t khóa không tương thích b?ng. Khóa leo thang luôn leo thang m?t b?ng khóa, và không bao gi? đ? trang ? khóa. Ngoài ra, n?u m?t leo thang khóa n? l?c không thành công v? m?t SPID gi? m?t không tương thích TAB khóa, truy v?n đó leo thang đ? c? g?ng không ch?n trong khi ch? đ?i m?t khóa TAB. Thay vào đó, nó v?n ti?p t?c đ? có đư?c các ? khóa c?a nó c?p ban đ?u, hơn h?t (hàng, ch?a khóa, ho?c trang), đ?nh k? làm cho leo thang thêm c?. V? v?y, m?t trong nh?ng phương pháp đ? ngăn ch?n leo thang khóa trên m?t b?ng c? th? là đ? có đư?c đ? gi? m?t ? khóa trên m?t k?t n?i khác nhau là không tương thích v?i các escalated khóa lo?i. M?t IX (? đ?nh đ?c quy?n), ? m?c đ? b?ng khóa không khóa b?t k? hàng ho?c trang, nhưng nó là v?n không tương thích v?i m?t S (chia s?) escalated ho?c x (đ?c quy?n) TAB khóa. Ví d?, gi? s? r?ng b?n ph?i ch?y m?t công vi?c th?c thi mà S?a đ?i m?t s? l?n các hàng trong các mytable b?ng và đó đ? gây ra ch?n x?y ra v? c?a khóa leo thang. N?u công vi?c này luôn luôn hoàn thành trong ít hơn m?t gi?, b?n có th? t?o m?t công vi?c Transact-SQL có ch?a m? sau đây, và l?ch tr?nh công vi?c m?i đ? b?t đ?u m?t vài phút trư?c khi công vi?c th?c thi th?i gian b?t đ?u:
    BEGIN TRAN
    SELECT * FROM mytable (UPDLOCK, HOLDLOCK) WHERE 1=0
    WAITFOR DELAY '1:00:00'
    COMMIT TRAN				
    Truy v?n này mua l?i và gi? m?t khóa IX trên mytable trong m?t gi?, mà ngăn c?n khóa leo thang trên bàn trong th?i gian đó. Lô này không s?a đ?i b?t k? d? li?u ho?c ch?n các truy v?n (tr? khi truy v?n khác bu?c m?t b?ng khóa g?i ? TABLOCK ho?c n?u m?t ngư?i qu?n tr? đ? vô hi?u hoá trang ho?c hàng ? khóa b?ng cách s? d?ng m?t sp_indexoption th? t?c đư?c lưu tr?).
Ngoài ra, b?n có th? vô hi?u hóa khóa leo thang b?ng cách cho phép d?u v?t c? 1211. Tuy nhiên, này c? water vô hi?u hoá t?t c? các khóa leo thang trên toàn c?u trong th? hi?n c?a SQL Server. Khóa leo thang ph?c v? m?t m?c đích r?t h?u ích trong SQL Máy ch? c?a t?i đa hóa hi?u qu? c?a các truy v?n n?u không làm ch?m l?i xu?ng b?ng chi phí c?a vi?c mua và phát hành hàng ngh?n ? khóa. Khóa leo thang c?ng giúp gi?m thi?u b? nh? c?n thi?t đ? theo d?i các ? khóa. B? nh? SQL Server có th? t? đ?ng phân b? cho các c?u trúc khóa là h?u h?n, v? v?y n?u b?n vô hi?u hóa khóa leo thang và b? nh? khóa m?c l?n đ?, c? g?ng c?p phát ? khóa b? sung cho b?t k? truy v?n có th? th?t b?i và nh?ng l?i sau x?y ra:

L?i: 1204, m?c đ? nghiêm tr?ng: 19 Nhà nư?c: 1
SQL Server không th? có đư?c m?t ngu?n l?c khóa vào lúc này. Ch?y l?i tuyên b? c?a b?n khi có r?t ít ngư?i dùng ho?t đ?ng ho?c yêu c?u h? th?ng qu?n tr? viên đ? ki?m tra c?u h?nh nào v? khóa và b? nh? máy ch? SQL.
Chú ý Khi x?y ra m?t l?i "1204", nó d?ng ch? bi?n c?a các tuyên b? hi?n t?i và gây ra m?t cu?n ngư?c ho?t đ?ng giao d?ch. Cu?n ngư?c chính nó có th? ch?n ngư?i dùng ho?c d?n đ?n m?t cơ s? d? li?u dài th?i gian ph?c h?i n?u b?n kh?i đ?ng l?i d?ch v? SQL Server.

B?ng cách s? d?ng m?t g?i ? khóa như ROWLOCK ch? thay đ?i k? ho?ch ban đ?u khóa. Khóa g?i ? không ngăn ch?n leo thang khóa.

Các phương pháp khác ngăn ng?a khóa leo thang mà s? đư?c th?o lu?n trư?c đó trong bài vi?t này là l?a ch?n t?t hơn so v?i vi?c cho phép các water c?. Ngoài ra, các phương pháp khác thư?ng k?t qu? trong t?t hơn hi?u su?t cho truy v?n hơn vô hi?u hóa khóa leo thang cho toàn b? Ví d?. Microsoft khuy?n cáo cho phép này d?u v?t c? duy nh?t đ? gi?m thi?u nghiêm tr?ng ngăn ch?n đó gây ra b?i leo thang khóa trong khi các tùy ch?n khác, ch?ng h?n như nh?ng th?o lu?n trư?c đó trong bài vi?t này, đang đư?c đi?u tra. Đ? kích ho?t m?t d?u v?t c? do đó nó đ? đư?c trên b?t c? khi nào SQL Server b?t đ?u, thêm nó như m?t máy ch? tham s? kh?i đ?ng.

Thêm m?t tham s? kh?i đ?ng máy ch?, nh?p chu?t ph?i vào các máy ch? trong qu?n l? doanh nghi?p SQL, b?m Thu?c tính, và sau đó vào các T?ng quát tab, b?m vào Tham s? kh?i đ?ng, và sau đó thêm các tham s? sau đây (đúng như đư?c hi?n th?):
-T1211
B?n ph?i chu k? d?ch v? SQL Server cho m?t tham s? kh?i đ?ng m?i có hi?u l?c. N?u b?n ch?y truy v?n sau đây trong truy v?n Analyzer c? water có hi?u l?c ngay l?p t?c:
DBCC TRACEON (1211, -1)				
Tuy nhiên, n?u b?n không thêm các -T1211 tham s? kh?i đ?ng, tác d?ng c?a m?t traceon l?nh là b? m?t khi các d?ch v? SQL Server cycled. B?t Qu?c k? water ngăn ng?a b?t k? trong tương lai khóa escalations, nhưng nó không ph?i đ?o ngư?c b?t k? escalations khóa đ? x?y ra trong m?t ho?t đ?ng giao d?ch.

Thu?c tính

ID c?a bài: 323630 - L?n xem xét sau cùng: 27 Tháng Tám 2011 - Xem xét l?i: 2.0
Áp d?ng
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 7.0 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
T? khóa: 
kbsqlsetup kbinfo kbmt KB323630 KbMtvi
Máy d?ch
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:323630

Cung cấp Phản hồi

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com