LATCH_EX রিসোর্স মেটাডাটা_এসকিউএনসেকেন্ডারটির জন্য অপেক্ষা করছে

Question

আমাদের কাছে একটি প্রক্রিয়া রয়েছে যা একটি প্রতিবেদন তৈরি করে। ক্লায়েন্টের পক্ষ থেকে, প্রক্রিয়াটি কনফিগারযোগ্য সংখ্যক কর্মী থ্রেডের বিভাজন করে প্রতিবেদনের জন্য অনেকগুলি ডেটা তৈরি করে যা অনেকের মধ্যে একটি স্টোরের সাথে মিলিত হয় (সম্ভাব্য কয়েক হাজার, সাধারণত কয়েক ডজন)। প্রতিটি কর্মী থ্রেড একটি ওয়েব পরিষেবা কল করে যা একটি সঞ্চিত প্রক্রিয়া চালায়।

প্রতিটি অংশ প্রক্রিয়াকরণের জন্য ডাটাবেস প্রক্রিয়া একটি # সাময়িক সারণীতে একগুচ্ছ ডেটা সংগ্রহ করে। প্রতিটি প্রক্রিয়াজাতকরণের শেষে, ডেটা টেম্পডবিতে একটি স্থায়ী টেবিলকে লেখা হয়। শেষ অবধি, প্রক্রিয়া শেষে ক্লায়েন্ট সাইডের একটি থ্রেড স্থায়ী টেম্পডিবি টেবিল থেকে সমস্ত ডেটা অনুরোধ করে।

এই প্রতিবেদনটি যত বেশি ব্যবহারকারী চালাবেন তত ধীরে ধীরে। আমি ডাটাবেসের ক্রিয়াকলাপটি বিশ্লেষণ করেছি। এক পর্যায়ে, আমি 35 টি পৃথক অনুরোধগুলি প্রক্রিয়াটির এক পর্যায়ে অবরুদ্ধ দেখেছি। এই সব SPIDs টাইপ 50 MS অপেক্ষা করছে অনুক্রম ছিল LATCH_EXসম্পদ METADATA_SEQUENCE_GENERATOR (00000010E13CA1A8)। একটি এসপিআইডি-র এই সংস্থান রয়েছে এবং অন্য সমস্তগুলি অবরুদ্ধ করছে। ওয়েব অনুসন্ধানে এই অপেক্ষার উত্স সম্পর্কে আমি কিছুই পাইনি।

টেম্পিডবিতে আমরা যে টেবিলটি ব্যবহার করছি তার একটি IDENTITY(1,1)কলাম রয়েছে। এই এসপিআইডিগুলি কি আইডেন্টিটি কলামের জন্য অপেক্ষা করছে? ব্লকিং কমাতে বা দূর করতে আমরা কোন পদ্ধতি ব্যবহার করতে পারি?

সার্ভারটি একটি গুচ্ছের অংশ। সার্ভারটি 64-বিট এসকিউএল সার্ভার 2012 স্ট্যান্ডার্ড সংস্করণ এসপি 1 64-বিট উইন্ডোজ 2008 আর 2 এন্টারপ্রাইজে চলছে on সার্ভারে GB৪ জিবি র‌্যাম এবং ৪৮ টি প্রসেসর রয়েছে তবে এটি স্ট্যান্ডার্ড সংস্করণ হওয়ায় ডাটাবেসটি কেবল 16 টি ব্যবহার করতে পারে।

(নোট করুন যে এই সমস্ত তথ্য ধরে রাখার জন্য টেম্পিডবিতে স্থায়ী টেবিল ব্যবহারের নকশায় আমি শিহরিত হই না that এটি পরিবর্তন করা আকর্ষণীয় প্রযুক্তিগত এবং রাজনৈতিক চ্যালেঞ্জ হতে পারে তবে আমি পরামর্শের জন্য উন্মুক্ত))

আপডেট 4/23/2013

আমরা মাইক্রোসফ্টের সাথে একটি সমর্থন কেস খুলেছি। আমরা আরও জানার সাথে সাথে এই প্রশ্নটি আপডেট করব।

আপডেট 5/10/2013

এসকিউএল সার্ভার সমর্থন প্রকৌশলী সম্মত হয়েছেন যে অপেক্ষাগুলি আইডেন্টিটি কলামের কারণে হয়েছিল। পরিচয় অপসারণ অপেক্ষার অপসারণ করে। আমরা এসকিউএল ২০০৮ আর 2 তে সমস্যাটির নকল করতে পারিনি; এটি কেবলমাত্র এসকিউএল ২০১২ এ ঘটেছে।

Comments

প্রক্রিয়াটি কি # টেম্পোরারি টেবিলগুলি থেকে স্থায়ী টেবিলটিতে মূলত ডেটা অনুলিপি করে, বা এই পদক্ষেপে অতিরিক্ত রূপান্তর যুক্তি ঘটছে?

— জন সেগেল

যে ধাপে এটি অপেক্ষা করছে, এটি কোনও একক স্টোরের ইনভেস্টরি রেকর্ডগুলি রূপান্তর ছাড়াই স্থায়ী টেবিলের মধ্যে অনুলিপি করছে। আমরা পুরো সময় স্থায়ী টেবিলের অভ্যন্তরে পরিচালনা করতে পারতাম, তবে আমি মনে করি যে প্রোগ্রামারটি ডেটাতে ঘন ঘন আপডেটগুলি পিএজে লকগুলিতে রূপান্তরিত করা থেকে বিরত রাখতে হোল্ডিং এরিয়া হিসাবে একটি # টেম্পোরারি টেবিলটি ব্যবহার করা পছন্দ করেছিল।

— পল উইলিয়ামস

Answer 1

ধরে নিচ্ছি যে আপনি সমস্যাটি পরিচয়ের মানগুলির উত্সের ক্ষেত্রে বিচ্ছিন্ন করতে পারেন (পরীক্ষাটি হিসাবে সেই কলামটি সরিয়ে দেওয়ার চেষ্টা করুন), আমি যা প্রস্তাব করব তা হ'ল:

1. IDENTITYচূড়ান্ত সারণীতে কলাম থেকে সম্পত্তি সরান ।
2. প্রতিটি # সাময়িক সারণীতে পরিচয় মান উত্পন্ন করুন।
3. চূড়ান্ত টেবিলটি লোড করার সময়, নির্দিষ্ট স্টোরের জন্য পদক্ষেপ 2 থেকে পরিচয় মানগুলির সাথে একটি সংখ্যক সনাক্তকারীকে একত্রিত করুন।

সুতরাং যদি আপনার কাছে আইডির 3 এবং 4 থাকে তবে আপনি চূড়ান্ত আইডি মানগুলি দিয়ে শেষ করতে পারেন:

3000000001
3000000002
3000000003
...
4000000001
4000000002
...

বা এর অনুরূপ কিছু। আপনি ধারণা পেতে।

এটি IDENTITYচূড়ান্ত ফলাফলের স্বতন্ত্রতা সংরক্ষণের সময় প্রজন্মের ক্রমিকের ক্রমটি অপসারণ করবে ।

বিকল্প হিসাবে, প্রক্রিয়াটি কীভাবে কাজ করে তার উপর নির্ভর করে # সাময়িক সারণীতে চূড়ান্ত গণনা করা ID মান সন্নিবেশ করান। তারপরে আপনি UNION ALLডেটা অনুলিপি করার প্রয়োজনীয়তা হ্রাস করে একত্রে সেগুলি দেখতে এমন একটি ভিউ তৈরি করতে পারেন ।

Comments

প্রতিক্রিয়ার জন্য আপনাকে ধন্যবাদ. আমি যদি তাতে সমস্যা হয় তবে কিছু উত্পাদিত কী ব্যবহার করা (বা কোনও কী নেই) এটি সমাধান করতে পারে। আমরা এই সমস্যাটি সম্পর্কে মাইক্রোসফ্টের সাথে একটি মামলা খুলেছি। আমি এখানে ফলাফল পোস্ট করব এবং আপনার উত্তরটি তারা গ্রহণ করবে যদি তারা এই সমস্যাটিকে সম্মত করে।

— পল উইলিয়ামস

@ পল: দয়া করে আমাকে জানান; আমি ঠিক কৌতূহলী। আপনার মত আমিও এই ল্যাচ সম্পর্কে ওয়েবে কিছু খুঁজে পাচ্ছিলাম না তবে এটি অবশ্যই পরিচয় / সিকোয়েন্স সিরিয়ালাইজেশন reasonable বাধা এটি বলা শক্ত বা না, যদিও 30+ টি থ্রেডের সাথে মানগুলির জন্য প্রতিযোগিতা করে, সম্ভবত এটি সম্ভবত বলে মনে হয়। আপনি প্রতিটি # সাম্প্রতিক টেবিল থেকে সিরিজের অনুলিপি চেষ্টা করতে পারেন (সমান্তরাল পরিবর্তে) এটি সাহায্য করে কিনা তা দেখার জন্য।

— জন সেগেল

এসকিউএল সার্ভার ইঞ্জিনিয়ার সম্মত হয়েছিল এটি সম্ভবত IDENTITYকলাম। আমরা এটি ইতিমধ্যে প্রশস্ত ক্লাস্টারযুক্ত সূচক থেকে সরিয়ে নিয়ে কলামটি পুরোপুরি সরিয়ে ফেলেছি। এটি প্রয়োজনীয় ছিল না। এরপরে, এই LATCH_EX অপেক্ষা করে চলে গেল। আমরা এসকিউএল ২০০৮ আর 2-এর অপেক্ষার সদৃশ করতে পারিনি। সমস্যাটি কেবল এসকিউএল সার্ভারে হয়েছে 2012

— পল উইলিয়ামস

@ পল: অনুসরণ করার জন্য ধন্যবাদ খুব আকর্ষণীয়. আমি অনুমান করছি যে IDENTITYমানগুলি তৈরি করে কোডটি নতুন সিকোয়েন্স প্রজন্মের স্টাফ ব্যবহার করতে পুনরায় লিখিত হয়েছিল যা ২০১২ সালে নতুন ছিল <<2012 এ, আপনি একটি ভিন্ন ল্যাচ প্রকার দেখতে পাবেন, যদিও কোনও পারফ ইস্যু না থাকলে, তবে মনে হয় সেখানে ছিল কোড একটি রিগ্রেশন। যে কোনও ইভেন্টে, IDENTITYকলামটি সরিয়ে ফেলা নিরাপদ জিনিস thing

— জন সেগেল

পরিচয়ের পরিবর্তে আপনি একটি 'সিকোয়েন্স' (যা এসকিউএল 2012 এ নতুন) ব্যবহার করার চেষ্টা করতে পারেন

— বোগদান ম্যাক্সিম

Answer 2

(আপডেট হয়েছে ফেব্রুয়ারী 2019)

এটি একটি পুরানো পোস্ট, যা বলেছিল যে আমি শেষ পর্যন্ত মাইক্রোসফ্টকে বোঝাতে পেরেছি যে এটি ঘটে আসলেই একটি ত্রুটি।

আপডেট: এমএস ত্রুটিটি নিশ্চিত করেছে এবং এটি 12628722 এর একটি # বরাদ্দ করেছে।

আমি এই পোস্টটি গত নভেম্বর 2018 এ দেখেছি যখন আমরা স্কেল সার্ভার 2005 থেকে স্কেল সার্ভার 2017 এ আপগ্রেড করার পরে আমরা অনেকটা একইরকম ভোগান্তি পোহাতে শুরু করেছি 3. একটি ৩.৩ মিলিয়ন সারি টেবিল যা 10 সেকেন্ডে বাল্ক সন্নিবেশে লাগত হঠাৎই 10 নেওয়া শুরু করেছিল Identityকলামগুলির সাথে টেবিলগুলিতে মিনিট ।

দেখা যাচ্ছে এর পিছনে দুটি সমস্যা রয়েছে:

1. মাইক্রোসফ্ট বাল্ক সন্নিবেশকে সমান্তরালভাবে চালিত করতে বাধ্য করতে স্কেল সার্ভার ২০১৪-তে আচরণটি পরিবর্তন করেছে - পূর্ববর্তী সংস্করণগুলিতে বাল্ক সন্নিবেশকে একটি সিরিয়ালযুক্ত পরিকল্পনা দেওয়া হয়েছিল।
2. আমাদের 32 টি কোর বাক্সে সমান্তরালভাবে একবার চলার পরে ইঞ্জিনটি প্রকৃত কাজটি করার চেয়ে একে অপরের লক করে আরও বেশি সময় ব্যয় করেছিল।

আমাকে 4 সপ্তাহ সময় নিয়েছে তবে ছুটির ঠিক পরে আমি সান্তার কাছ থেকে বিচ্ছিন্নভাবে উপস্থিত হয়েছি - নিশ্চিত হওয়া যে সমস্যাটি আসলেই একটি ত্রুটি ছিল।

এটি সংশোধন না করা পর্যন্ত আমরা কয়েকটি সম্ভাব্য কাজের ক্ষেত্র পেয়েছি:

1. কোরিয়ায় Option (MaxDop 1)বাল্ক সন্নিবেশটিকে সিরিয়ালযুক্ত পরিকল্পনায় ফিরিয়ে আনতে ব্যবহার করুন ।
2. এটি কাস্ট করে পরিচয় কলামটি মাস্ক করুন (উদাঃ Select Cast(MyIdentityColumn As Integer) As MyIdentityColumn)
   • এটি ব্যবহার করার সময় পরিচয় সম্পত্তি অনুলিপি করা থেকে বাধা দেয় SELECT...INTO
3. উপরে বর্ণিত হিসাবে পরিচয় কলামটি সরান।
4. ডাটাবেস সামঞ্জস্যতা মোডটি SQL সার্ভারে 2012 এ পরিবর্তন করুন বা একটি সিরিয়ালযুক্ত পরিকল্পনাটি পুনরায় প্রতিষ্ঠিত করতে নিম্নতর করুন lower

আপডেট: ফিক্স এমএস বাস্তবায়ন করবে এই Serialized পরিকল্পনাটি ব্যবহার করে এই ধরণের সন্নিবেশগুলি ফিরিয়ে দেওয়া হবে । এটি SQL সার্ভার 2017 সিইউ 14 এর জন্য পরিকল্পনা করা হয়েছে ( এসকিউএল সার্ভারের অন্য সংস্করণগুলির কোনও খবর নেই - দুঃখিত!) কার্যকর করা হলে, সার্ভার স্তরে বা এর মাধ্যমে ট্রেস পতাকা 9492 চালু করা দরকারDBCC TraceOn ।