সঞ্চিত পদ্ধতির ক্যাশে থেকে অনুপস্থিত হওয়ার পরিকল্পনা কী কী?
WITH RECOMPILE- গতিশীল এসকিউএল
- এনক্রিপ্টড কোড
- উল্লেখযোগ্য ডেটা পরিবর্তন
- পরিসংখ্যান আপডেট করুন
- আর কি?
আমি সম্প্রতি 2 টি সার্ভার (এসকিউএল সার্ভার 2008 আর 2 এবং এসকিউএল সার্ভার 2012) এ কাজ করেছি যা খুব রিসোর্স-নিবিড় স্টোরেজ পদ্ধতিগুলির জন্য ক্যাশে পরিকল্পনা করে না। অনেকগুলি, সম্ভবত সবগুলিই, স্টোরেজ পদ্ধতির ভিতরে থাকা বিবৃতিগুলিরও ক্যাশে পরিকল্পনা ছিল না। সঞ্চিত কিছু প্রক্রিয়া সেকেন্ডে কয়েকবারের মতো প্রায়শই ঘন ঘন সম্পাদন করে।
যাই হোক না কেন কোনও স্মৃতির চাপ নেই। একটি সার্ভারের প্রয়োজনের তুলনায় অনেক বেশি হার্ডওয়্যার রয়েছে।
আমি ভেবেছিলাম অনুপস্থিত পরিকল্পনাগুলি সঞ্চিত পদ্ধতির মাঝখানে অস্থায়ী টেবিল তৈরির কারণে হয়েছিল তবে এটি এসকিউএল সার্ভার 2000 বা তার আগের তথ্যগুলির পুরানো তথ্য বলে মনে হচ্ছে। এসকিউএল সার্ভার ২০০৫ থেকে শুরু করে, ডিডিএল-এর পরে বিবৃতিগুলির জন্য বিবৃতি স্তরে পুনরুদ্ধারগুলি ঘটে। সব ক্ষেত্রেই কি এটি সত্য বা এটি নতুন সংস্করণে এখনও ঘটতে পারে?
অনুপস্থিত পরিকল্পনার অপরাধী আর কী হতে পারে? আমি এই বিষয়টিতে কয়েকটি নিবন্ধ রেখেছি, তবে কিছুই মানায় না।
অ্যাডহক কাজের চাপের জন্য অনুকূলিতকরণটি এই সপ্তাহে আমি যে সার্ভারটিতে দেখছি তাতে সক্ষম করা হয়েছে। সঞ্চিত পদ্ধতিগুলির মধ্যে একটি কেবলমাত্র একবারে কার্যকর করা হয়। আমার কাছে তার একটি কোড আছে। প্রতি মিনিটে 100 বারের বেশি কার্যকর করা হচ্ছে এমনটির জন্য আমার কাছে কোড নেই তবে আমি এটি পেতে পারি। আমি কোডটি পোস্ট করতে সক্ষম হব না, তবে আমি আমার প্রশ্নের সাথে এটি বর্ণনা করতে পারি।
আমি বিশ্বাস করি না যে কেউ প্রক্রিয়া ক্যাশে মুক্ত করছে বা পরিষ্কার বাফার ফেলে দিচ্ছে। এই ক্লায়েন্টটি তাদের অন্যতম পর্যবেক্ষণ সরঞ্জাম হিসাবে সোলারউইন্ডস ডিপিএ ব্যবহার করছে। ডিপিএ একদিনে একবার ডেকে আনা স্টোর প্রোক-তে বিবৃতি দেওয়ার জন্য একটি কার্যকর করার পরিকল্পনা গ্রহণ করেছিল। অ-সরজযোগ্য WHEREধারাটির কারণে এই বিবৃতিটিতে প্রচুর পরিমাণে পঠন রয়েছে । ডিপিএ যদি বিবৃতিটি ধারণ করে, তবে এটি একটি অনুমানিত পরিকল্পনা এবং এক সময় পরিকল্পনার ক্যাশে ছিল was সমস্যা সমাধানের সময় কেবল সেখানে নেই। আমি তাদের sp_WhoIsActiveএকটি টেবিলে লগিং শুরু করব ।
আমি ব্যবহার করছি sp_BlitzCache। (আমি ব্রেন্ট ওজার আনলিমিটেডের জন্য কাজ করি) এটি সম্পূর্ণ সঞ্চিত পদ্ধতির পরিকল্পনার পাশাপাশি স্বতন্ত্র বিবৃতিগুলির উপস্থিতিগুলির পরিকল্পনাগুলি প্রদর্শন করবে। যদি এগুলির অস্তিত্ব না থাকে তবে এটির একটি সতর্কতার জন্য এটি রয়েছে "" আমরা এই ক্যোয়ারির জন্য কোনও পরিকল্পনা খুঁজে পাইনি this এর সম্ভাব্য কারণগুলির মধ্যে ডায়নামিক এসকিউএল, RECOMPILEইঙ্গিত এবং এনক্রিপ্টড কোড অন্তর্ভুক্ত রয়েছে। " এবং সেই সতর্কতা বিবৃতিতেও রয়েছে।
টিএফ 2371 জায়গা নেই। আমি অপেক্ষা পরিসংখ্যান তাকান। সার্ভারটি বেশ উদাস। PLE 130,000 এরও বেশি।
আমার কাছে এখন আরও 2 টি সঞ্চিত পদ্ধতির কোড রয়েছে। এর মধ্যে একটি গতিশীল এসকিউএল ব্যবহার করছে exec (@sql)যাতে এটির জন্য কেন পরিকল্পনা নেই তা আমরা জানি। তবে অন্যটি, এবং এটি হ'ল যা প্রতি মিনিটে 100 বারের বেশি চলছে, সাধারণের বাইরে কিছুই নেই। একমাত্র যেটির মধ্যে দাঁড়িয়ে আছে তা হল 1000 টিরও বেশি লাইনের কোডের মাঝে অস্থায়ী সারণী তৈরি করা হচ্ছে। এটি সন্তানের সঞ্চিত প্রক্রিয়াগুলির একটি গুচ্ছকেও কল করে।
এসকিউএল সার্ভার ২০০৮-এ প্ল্যান ক্যাচিংয়ের বিষয়ে , আমি কোনও আক্ষরিক> = 8 কে দেখছি না, তবে অন্য কোনও সঞ্চিত প্রক্রিয়া বলার আগে একটি সঞ্চিত পদ্ধতিতে বাল্ক সন্নিবেশ সম্পর্কে একটি মন্তব্য রয়েছে। তবে যে বাইরের সঞ্চিত পদ্ধতিটি আমি দেখছি তাতে বাল্ক সন্নিবেশ উপস্থিত হয় না। নিবন্ধটির "রিকম্পিলেশন থ্রেশহোল্ড" বিভাগটি আকর্ষণীয়। অস্থায়ী টেবিলগুলির জন্য আমি যা দেখছি তা হ'ল টন ইনসার্ট (এর ফলে কয়েক মিলিয়ন সারি হতে পারে), কিছু আপডেট এবং মুছে ফেলা। তাই অস্থায়ী টেবিলগুলিতে প্রচুর ডেটা পরিবর্তন হয়। লক্ষ লক্ষ।