Sch-M WAIT SQL सर्वर 2014 में Sch-S को ब्लॉक करता है लेकिन SQL Server 2008 R2 को नहीं?

Question

हमने हाल ही में SQL 2008 R2 से अपने उत्पादन उदाहरणों को ब्रांड नए SQL 2014 सर्वर पर माइग्रेट किया है। यहां एक दिलचस्प परिदृश्य है जिसे हमने सेवा ब्रोकर के उपयोग के साथ उजागर किया है। के Broker Enabled = trueसाथ MyServiceऔर साथ एक डेटाबेस पर विचार करें MyQueue। इस कतार में जहर संदेश हैंडलिंग अक्षम है। कतार में संदेशों के साथ कम से कम 2 सक्रिय वार्तालाप हैं।

एक प्रक्रिया में (SPID 100) निष्पादित करें:

BEGIN TRANSACTION;
DECLARE @conversation_group_id UNIQUEIDENTIFIER;
RECEIVE TOP (1) @conversation_group_id = conversation_handle FROM MyQueue;

ध्यान दें कि हम लेन-देन को खुला छोड़ देते हैं। कल्पना कीजिए कि यह एक .NET प्रोग्राम है जो कुछ बाहरी संसाधनों पर लंबे समय से प्रतीक्षा कर रहा है। वाया sys.dm_tran_locksहम देखते हैं कि इस SPID को कतार में IX लॉक दिया गया है।

| type   | resource_id | mode | status | spid |
| OBJECT | 277576027   | IX   | GRANT  | 100  |

एक अलग प्रक्रिया में (SPID 101) पांच बार निष्पादित होती है :

BEGIN TRANSACTION;
DECLARE @conversation_group_id UNIQUEIDENTIFIER;
RECEIVE TOP (1) @conversation_group_id = conversation_handle FROM MyQueue;
ROLLBACK TRANSACTION;

यहां कुंजी यह है कि हम पांच बार लेनदेन वापस कर रहे हैं । यह जहर संदेश हैंडलिंग पृष्ठभूमि तर्क में निर्मित चलाता है। हालांकि कतार अक्षम नहीं होती है (क्योंकि यह अक्षम नहीं होने के लिए कॉन्फ़िगर किया गया है), एक पृष्ठभूमि कार्य अभी भी काम करने और एक broker_queue_disabledघटना को आग लगाने की कोशिश कर रहा है । इसलिए अब अगर हम sys.dm_tran_locksफिर से क्वेरी करते हैं तो हमें एक अलग एसपीएड (जिसके साथ जुड़ा हुआ है BRKR TASK) एक Sch-M लॉक पर प्रतीक्षा करते हुए दिखाई देगा ।

| type   | resource_id | mode  | status | spid |
| OBJECT | 277576027   | IX    | GRANT  | 100  |
| OBJECT | 277576027   | Sch-M | WAIT   | 36   |

अब तक, सब कुछ समझ में आता है।

अंत में, एक अलग प्रक्रिया (SPID 102) पर, उस कतार का उपयोग करके किसी सेवा को SEND करने का प्रयास करें:

BEGIN TRANSACTION;
DECLARE @ch uniqueidentifier;
BEGIN DIALOG @ch FROM SERVICE [MyService] TO SERVICE 'MyService';
SEND ON CONVERSATION @ch ('HELLO WORLD');

SENDआदेश अवरुद्ध है। यदि हम फिर से sys.dm_tran_locksदेखें तो हम देखते हैं कि यह प्रक्रिया Sch-S लॉक पर प्रतीक्षा कर रही है। निष्पादन से sp_who2हमें पता चलता है कि SPID 102 को SPID 36 द्वारा अवरुद्ध किया गया है।

| type   | resource_id | mode  | status | spid |
| OBJECT | 277576027   | IX    | GRANT  | 100  |
| OBJECT | 277576027   | Sch-M | WAIT   | 36   |
| OBJECT | 277576027   | Sch-S | WAIT   | 102  |

एक Sch-M लॉक एक Sch-M लॉक पर क्यों इंतज़ार कर रहा है?

यह व्यवहार SQL 2008 R2 में पूरी तरह से अलग है! इस सटीक समान परिदृश्य का उपयोग करते हुए, हमारे अभी तक डिक्रिप्टेड 2008R2 उदाहरणों पर चल रहा है, SENDकमांड सहित अंतिम बैच प्रतीक्षा Sch-M लॉक द्वारा अवरुद्ध नहीं होता है ।

SQL 2012 या 2014 में लॉकिंग व्यवहार बदल गया है? क्या शायद कुछ डेटाबेस या सर्वर सेटिंग है जो इस लॉकिंग व्यवहार को प्रभावित कर सकती है?

Comments

संभव बग की तरह लगता है। क्या आपने नवीनतम एसपी और सीयू लगाया है?

— मैक्स वर्नोन

@MaxVernon हम 12.00.2370 चला रहे हैं

— जोसेफ Daigle

आप सर्जक और लक्ष्य के रूप में एक ही सेवा का उपयोग कर रहे हैं। SENDब्लॉक, जबकि जाँच सर्जक कतार। लक्ष्य कतार SENDपर ब्लॉक नहीं होगा , यह केवल उछाल और वितरण के लिए उपयोग करेगा । यदि आप दो (हमेशा एक अच्छा विचार) अलग करते हैं तो आपको समस्या नहीं होगी। sys.transmission_queue

— रेमस रूसु

धन्यवाद @RemusRusanu हालांकि यह उदाहरण बदले हुए व्यवहार को प्रदर्शित करने के लिए आंशिक रूप से विरोधाभासी है, आपकी टिप वह है जिसे हम अपनी सेवाओं और कतारों को डिज़ाइन करते समय ध्यान में रखेंगे।

— जोसेफ Daigle

Answer 1

SQL Server 2008 R2 और SQL Server 2012 के बीच व्यवहार में परिवर्तन हुआ। 2008 R2 का कार्यान्वयन प्रलेखित 'शिथिल फीफो' शब्दार्थ के साथ असंगत था :

एक आराम से, पहले-आउट (एफआईएफओ) फैशन में ताले दिए गए हैं। हालांकि आदेश सख्त एफआईएफओ नहीं है, यह वांछनीय गुणों को संरक्षित करता है जैसे भुखमरी से बचना और अनावश्यक गतिरोध और अवरोध को कम करने के लिए काम करता है।

नए लॉक अनुरोध जहां अनुरोधकर्ता अभी तक संसाधन पर ताला नहीं लगाता है यदि अनुरोधित मोड, स्वीकृत अनुरोधों के संघ और लंबित अनुरोधों के मोड के साथ असंगत है।

एक रूपांतरण अनुरोध केवल तभी अवरुद्ध हो जाता है जब अनुरोधित मोड सभी स्वीकृत मोडों के मिलन के साथ असंगत है, उस मोड को छोड़कर जिसमें रूपांतरण अनुरोध मूल रूप से दिया गया था।

2008 R2 में, Sch-Sदी गई और प्रतीक्षा अनुरोधों के मिलन के साथ असंगत होने के बावजूद एक नया लॉक अनुरोध प्रदान किया गया था, जिससे लॉक भुखमरी हो सकती है। 2012 में, Sch-Sलॉक अनुरोध अवरुद्ध है।

नीचे दी गई प्रजनन स्क्रिप्ट सेवा ब्रोकर कतार के बजाय नियमित तालिकाओं का उपयोग करती है:

-- Session 1
CREATE TABLE dbo.LockTest (col1 integer NULL);

INSERT dbo.LockTest (col1) VALUES (1);

BEGIN TRANSACTION;

-- Will hold row-X, Pag-IX, and Tab-IX
INSERT dbo.LockTest (col1) VALUES (2);

-- Session 2
-- Blocked waiting on Sch-M
TRUNCATE TABLE dbo.LockTest;

-- Session 3
-- Takes Sch-S only
-- Not blocked in 2008 R2
SELECT * FROM dbo.LockTest AS LT WITH (READUNCOMMITTED);

सारांश में, 2008 R2 ने डिज़ाइन के अनुसार व्यवहार नहीं किया। SQL सर्वर 2012 में समस्या ठीक किया गया था।