আমরা সম্প্রতি এসকিউএল 2008 আর 2 থেকে ব্র্যান্ডের নতুন এসকিউএল 2014 সার্ভারগুলিতে আমাদের উত্পাদন উদাহরণগুলি স্থানান্তরিত করেছি। এখানে একটি আকর্ষণীয় দৃশ্য যা আমাদের পরিষেবা ব্রোকারের ব্যবহারের সাথে আমরা উন্মোচিত করেছি। সঙ্গে একটি ডাটাবেস বিবেচনা Broker Enabled = true
সঙ্গে MyService
এবং MyQueue
। বিষাক্ত বার্তা হ্যান্ডলিং এই সারিটিতে অক্ষম। সারিতে বার্তাগুলির সাথে কমপক্ষে 2 টি সক্রিয় কথোপকথন রয়েছে।
একটি প্রক্রিয়ায় (এসপিআইডি 100) সম্পাদন করুন:
BEGIN TRANSACTION;
DECLARE @conversation_group_id UNIQUEIDENTIFIER;
RECEIVE TOP (1) @conversation_group_id = conversation_handle FROM MyQueue;
নোট করুন যে আমরা লেনদেনটি উন্মুক্ত রেখেছি। কল্পনা করুন যে এটি একটি। নেট প্রোগ্রাম যা কিছু বাহ্যিক সংস্থার জন্য দীর্ঘ সময় অপেক্ষা করে। এর মাধ্যমে sys.dm_tran_locks
আমরা দেখতে যে এই SPID কিউ উপর একটি নবম লক মঞ্জুর করা হয়েছে।
| type | resource_id | mode | status | spid |
| OBJECT | 277576027 | IX | GRANT | 100 |
একটি পৃথক প্রক্রিয়াতে (এসপিআইডি 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
) কোনও এস-এম লকটিতে অপেক্ষা করা।
| type | resource_id | mode | status | spid |
| OBJECT | 277576027 | IX | GRANT | 100 |
| OBJECT | 277576027 | Sch-M | WAIT | 36 |
এখনও অবধি, সমস্ত কিছু বোধগম্য হয়।
অবশেষে, একটি আলাদা প্রক্রিয়াতে (এসপিআইডি 102), সেই সারিটি ব্যবহার করে কোনও পরিষেবাতে প্রেরণের চেষ্টা করুন:
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
আমরা দেখতে পাই যে এই প্রক্রিয়াটি কোনও এস-এস লকটিতে অপেক্ষা করছে। কার্যকর করে sp_who2
আমরা দেখতে পেলাম যে এসপিআইডি 102 এসপিআইডি 36 দ্বারা অবরুদ্ধ।
| type | resource_id | mode | status | spid |
| OBJECT | 277576027 | IX | GRANT | 100 |
| OBJECT | 277576027 | Sch-M | WAIT | 36 |
| OBJECT | 277576027 | Sch-S | WAIT | 102 |
কেন একটি এস-এস লক অপেক্ষা করছে এমন কোনও এস-এম লকটিতে অপেক্ষা করছে?
এসকিউএল ২০০৮ আর 2 এ এই আচরণটি সম্পূর্ণ আলাদা! এই একই একই পরিস্থিতিটি ব্যবহার করে, আমাদের এখনও অবধি-বাতিল-হওয়া ২০০৮ -২-এর দৃষ্টান্তগুলিতে চলমান, SEND
কমান্ড সহ চূড়ান্ত ব্যাচটি অপেক্ষারত এস-এম লক দ্বারা আটকাবে না ।
এসকিউএল 2012 বা 2014 এ লকিংয়ের আচরণটি পরিবর্তিত হয়েছে? সম্ভবত এমন কোনও ডাটাবেস বা সার্ভার সেটিং রয়েছে যা এই লকিং আচরণকে প্রভাবিত করতে পারে?
SEND
ব্লক সময় চেক ইনিশিয়েটরের কিউ। লক্ষ্য কাতারে SEND
অবরুদ্ধ করবে না , এটি কেবল বাউন্স করে সরবরাহ করার জন্য ব্যবহার করবে । আপনি যদি দুজনকে আলাদা করেন (সর্বদা একটি ভাল ধারণা) আপনার সমস্যা হবে না। sys.transmission_queue