কোয়েরি স্টোর অনুসন্ধান কখনও শেষ করবেন না

Question

আমি শুরু থেকে বলবো যে আমার প্রশ্নের / সমস্যার অনুরূপ এই আগের, কিন্তু যেহেতু আমার নিশ্চিত না যদি কারণ বা শুরু তথ্য একই আছি, আমি আরো কিছু বিবরণ সঙ্গে আমার প্রশ্ন পোষ্ট করার সিদ্ধান্ত নিয়েছে।

হাতে ইস্যু:

• একটি অদ্ভুত সময়ে (ব্যবসায়ের দিনের শেষের দিকে) একটি উত্পাদনের উদাহরণটি ভ্রান্তভাবে আচরণ শুরু করে:
  • উদাহরণস্বরূপ উচ্চ সিপিইউ (~ 30% এর বেসলাইন থেকে এটি প্রায় দ্বিগুণ হয়ে গেছে এবং এখনও বাড়ছে)
  • লেনদেনের সংখ্যা / সেকেন্ড বৃদ্ধি (যদিও অ্যাপ্লিকেশন লোড কোনও পরিবর্তন দেখেনি)
  • নিষ্ক্রিয় সেশন সংখ্যা বৃদ্ধি
  • সেশনগুলির মধ্যে অদ্ভুত অবরুদ্ধ ইভেন্টগুলি যা এই আচরণটি কখনই প্রদর্শন করে না (এমনকী অচিরেই পড়া সেশনগুলিও ব্লক ঘটাচ্ছে)
  • ব্যবধানের জন্য শীর্ষ অপেক্ষাগুলি ছিল তালিকার প্রথম স্থানে অ পৃষ্ঠাগুলি ল্যাচ, লকগুলি ২ য় স্থান অধিকার করে

প্রাথমিক তদন্ত:

• sp_whoIsAtivetive ব্যবহার করে আমরা দেখেছি যে আমাদের মনিটরিং সরঞ্জাম দ্বারা সম্পাদিত একটি ক্যোয়ারী অত্যন্ত ধীরগতিতে চালিত হওয়ার এবং প্রচুর সিপিইউ দখল করার সিদ্ধান্ত নেয়, যা আগে ঘটেছিল না;
• এটির বিচ্ছিন্নতা স্তরটি পড়েনি;
• আমরা সেই পরিকল্পনার দিকে নজর দিয়েছিলাম যেখানে আমরা অদৃশ্য সংখ্যাগুলি দেখতে পেয়েছি: স্টেটমেন্টএস্টআরওস = "৩.৮684646ee + ০১০" প্রায় ১৫০ টিবি আনুমানিক ডেটা ফেরত রয়েছে
• আমরা সন্দেহ করেছি যে মনিটরিং সরঞ্জামটির একটি কোয়েরি মনিটর বৈশিষ্ট্যটি কারণ ছিল, তাই আমরা বৈশিষ্ট্যটি অক্ষম করে দিয়েছি (তারা আমাদের কোনও সরবরাহ সম্পর্কে সচেতন কিনা তা পরীক্ষা করার জন্য আমরা আমাদের সরবরাহকারীর সাথে একটি টিকিটও খুললাম)
• প্রথম ঘটনাটি থেকে, এটি আরও কয়েকবার ঘটেছিল, প্রতিবার আমরা যখন সেশনটি মেরে ফেলি তখন সমস্ত কিছু স্বাভাবিক হয়ে যায়;
• আমরা বুঝতে পেরেছি যে ক্যোয়ারী স্টোর পর্যবেক্ষণের জন্য বিএল-তে এমএস দ্বারা ব্যবহৃত ক্যোয়ারীগুলির মধ্যে একটির অনুরূপ - প্রশ্নগুলি যা সম্প্রতি পারফরম্যান্সে ফিরে এসেছিল (সময়ের সাথে বিভিন্ন পয়েন্টের তুলনা করা)
• আমরা একই ক্যোয়ারীটি ম্যানুয়ালি চালাই এবং একই আচরণটি দেখতে পাই (সিপিইউ ক্রমবর্ধমান, ল্যাচ অপেক্ষা, অপ্রত্যাশিত লকগুলি বাড়ানো ইত্যাদিতে ব্যবহৃত))

দোষী প্রশ্ন:

Select qt.query_sql_text, 
    q.query_id, 
    qt.query_text_id, 
    rs1.runtime_stats_id AS runtime_stats_id_1,
    interval_1 = DateAdd(minute, -(DateDiff(minute, getdate(), getutcdate())), rsi1.start_time), 
    p1.plan_id AS plan_1, 
    rs1.avg_duration AS avg_duration_1, 
    rs2.avg_duration AS avg_duration_2,
    p2.plan_id AS plan_2, 
    interval_2 = DateAdd(minute, -(DateDiff(minute, getdate(), getutcdate())), rsi2.start_time), 
    rs2.runtime_stats_id AS runtime_stats_id_2
From sys.query_store_query_text AS qt 
Inner Join sys.query_store_query AS q 
    ON qt.query_text_id = q.query_text_id 
Inner Join sys.query_store_plan AS p1 
    ON q.query_id = p1.query_id 
Inner Join sys.query_store_runtime_stats AS rs1 
    ON p1.plan_id = rs1.plan_id 
Inner Join sys.query_store_runtime_stats_interval AS rsi1 
    ON rsi1.runtime_stats_interval_id = rs1.runtime_stats_interval_id 
 Inner Join sys.query_store_plan AS p2 
    ON q.query_id = p2.query_id 
Inner Join sys.query_store_runtime_stats AS rs2 
    ON p2.plan_id = rs2.plan_id 
Inner Join sys.query_store_runtime_stats_interval AS rsi2 
    ON rsi2.runtime_stats_interval_id = rs2.runtime_stats_interval_id
Where rsi1.start_time > DATEADD(hour, -48, GETUTCDATE()) 
    AND rsi2.start_time > rsi1.start_time 
    AND p1.plan_id <> p2.plan_id
    AND rs2.avg_duration > rs1.avg_duration * 2
Order By q.query_id, rsi1.start_time, rsi2.start_time

সেটিংস এবং তথ্য:

• উইন্ডোজ সার্ভার 2012R2 ক্লাস্টারে এসকিউএল সার্ভার 2016 এসপি 1 সিই 4 এন্টারপ্রাইজ
• ক্যোয়ারী স্টোর সক্ষম হয়েছে এবং ডিফল্ট হিসাবে কনফিগার করা হয়েছে (কোনও সেটিংস পরিবর্তিত হয়নি)
• ডাটাবেস এসকিউএল 2005 উদাহরণ থেকে আমদানি করা (এবং এখনও সামঞ্জস্যের পর্যায়ে 100)

গবেষণামূলক পর্যবেক্ষণ:

• অত্যন্ত উদ্বেগের পরিসংখ্যানের কারণে আমরা খারাপ * অনুমানের পরিকল্পনায় ব্যবহৃত সমস্ত * পরিকল্পনা_পার্শবাদী ** অবজেক্ট নিয়েছি (এখনও কোন বাস্তব পরিকল্পনা হয়নি, কোয়েরিটি কখনই শেষ হয়নি) এবং পরীক্ষামূলক পরিসংখ্যান, পরিকল্পনায় ব্যবহৃত কিছু সূচকের কোনও পরিসংখ্যান ছিল না (ডিবিসিসি শ্যাওস্ট্যাটিকসগুলি কিছু ফেরেনি, সিস.স্ট্যাটস থেকে নির্বাচন করে কিছু সূচির জন্য ন্যূনাল স্ট্যাটাস_ডেট () ফাংশন দেখানো হয়েছে

দ্রুত এবং নোংরা সমাধান:

• ম্যানুয়ালি ক্যোয়ারী স্টোর সম্পর্কিত সিস্টেম আইটেমগুলিতে হারিয়ে যাওয়া পরিসংখ্যান তৈরি করুন
• নতুন সিই (ট্রেসফ্ল্যাগ) ব্যবহার করে ক্যোয়ারী চালাতে বাধ্য করুন - যা প্রয়োজনীয় পরিসংখ্যানগুলি তৈরি বা আপডেটও করবে বা or
• ডাটাবেসের সামঞ্জস্যতা স্তরকে ১৩০ এ পরিবর্তন করুন (সুতরাং এটি ডিফল্টরূপে নতুন সিই ব্যবহার করবে)

সুতরাং, আমার আসল প্রশ্নটি হ'ল:

কেন ক্যোয়ারী স্টোরের কোনও ক্যোয়ারী পুরো উদাহরণটিতে পারফরম্যান্স সমস্যার কারণ হতে পারে? আমরা কি কোয়েরি স্টোর সহ বাগ বাগানে রয়েছি?

PS: আমি কিছু ফাইল (মুদ্রণ পর্দা, আইও পরিসংখ্যান এবং পরিকল্পনা) কিছুক্ষণের মধ্যে আপলোড করব।

ড্রপবক্সে ফাইল যুক্ত হয়েছে ।

পরিকল্পনা 1 - উত্পাদনে প্রাথমিক উদ্বেগের প্রাক্কলিত পরিকল্পনা

পরিকল্পনা 2 - প্রকৃত পরিকল্পনা, পুরাতন সিই, একটি পরীক্ষামূলক এনভির মধ্যে (একই আচরণ, একই ভ্যাক্টির পরিসংখ্যান)

পরিকল্পনা 3 - প্রকৃত পরিকল্পনা, নতুন সিই, একটি পরীক্ষার env

Comments

আমরা ক্যোয়ারী স্টোরটি অক্ষম করে দিয়েছি, মূল কারণটি কী তা আমরা নিশ্চিত নই (নিশ্চিতভাবেই আমাদের 1 টির বেশি সমস্যা ছিল)। আমার শেষ দিকে, সিপিইউ ক্যোয়ারী স্টোর থেকে পরিসংখ্যান প্রদর্শন করার জন্য আমরা ক্লিক করা সমস্ত কিছুই র‍্যাম্প আপ করবে।

— এ_ভি

Answer 1

আমি উত্তরে যা বলেছি, পরীক্ষামূলক পরীক্ষায় দেখা গেছে যে সিস্টেমে প্ল্যান_পারস্পিস্টড * সিস্টেম অবজেক্টের উপর কোনও (কোনওটিই) নেই। আমার সন্দেহ হয় যে কারণ ডেটাবেসটি এসকিউএল 2005 উদাহরণ থেকে স্থানান্তরিত হয়েছে এবং সামঞ্জস্যতা স্তরের 100 এর জন্য কিছু সময়ের জন্য রাখা হয়েছে, সুতরাং নতুন সিই ব্যবহার করা যায় নি।

সারি গণনা পরীক্ষা:

Select count(1) from NoNameDB.sys.plan_persist_runtime_stats with (nolock) --60362   
Select count(1) from NoNameDB.sys.plan_persist_plan with (nolock) --1853    
Select count(1) from NoNameDB.sys.plan_persist_runtime_stats_interval with (nolock) --671    
Select count(1) from NoNameDB.sys.plan_persist_query with (nolock) --1091    
Select count(1) from NoNameDB.sys.plan_persist_query_text with (nolock) --911

এটি দেখিয়েছিল যে প্রাথমিক অনুমানগুলি ভুল ছিল। একটি ড্যাক সংযোগ সম্পন্ন হয়েছে, অন্যথায় সারণীগুলি ক্যোয়ারির জন্য উপলব্ধ নয়।

পরিসংখ্যান পরীক্ষা:

DBCC SHOW_STATISTICS ('sys.plan_persist_runtime_stats_interval', plan_persist_runtime_stats_interval_cidx);    
DBCC SHOW_STATISTICS ('sys.plan_persist_runtime_stats', plan_persist_runtime_stats_idx1);    
DBCC SHOW_STATISTICS ('sys.plan_persist_runtime_stats', plan_persist_runtime_stats_cidx);    
DBCC SHOW_STATISTICS ('sys.plan_persist_plan', plan_persist_plan_cidx);    
DBCC SHOW_STATISTICS ('sys.plan_persist_plan', plan_persist_plan_idx1);    
DBCC SHOW_STATISTICS ('sys.plan_persist_query', plan_persist_query_cidx)    
DBCC SHOW_STATISTICS ('sys.plan_persist_query_text', plan_persist_query_text_cidx);

এটি দেখিয়েছিল যে কিছু সূচকের খালি পরিসংখ্যান রয়েছে (নিখোঁজ, কোনওটি নয়, শূন্য)।

প্রাথমিক ফিক্স:

UPDATE STATISTICS sys.plan_persist_runtime_stats WITH fullscan;
UPDATE STATISTICS sys.plan_persist_plan WITH fullscan;
UPDATE STATISTICS sys.plan_persist_runtime_stats_interval WITH fullscan;
UPDATE STATISTICS sys.plan_persist_query WITH fullscan;
UPDATE STATISTICS sys.plan_persist_query_text WITH fullscan;

এই জাতীয় পরিসংখ্যানগুলি স্থির করে 10-10 সেকেন্ডের মধ্যে কোয়েরি শেষ করে।

দ্বিতীয় ফিক্স :

(কেবলমাত্র একটি পরীক্ষার পরিবেশে যাচাই করা হয়েছে) এবং সম্ভবত এটি যথাযথ, যেমন এটি কোয়েরির সেরা পরিসংখ্যানগুলি দেখিয়েছিল, তা ছিল ডাটাবেসের সামঞ্জস্যের স্তরটি ১৩০-এ পরিবর্তন করা The সাধারণ সংখ্যা পরিসংখ্যান (10 কে সারি)।

অন্তর্বর্তী ফিক্স :

DBCC TRACEON (2312) -- new CE

সিস্টেমের গোপন টেবিলগুলির পরিসংখ্যান সম্পর্কে কিছু সম্পর্কিত সহায়তা ।

Answer 2

অন্তর্নিহিত সমস্যাটি, যা আপনি যদি এসএসএমএসে আসল পরিকল্পনাটি খুলেন এবং সিপিইউ ব্যবহারের দিকে নজর রাখেন (বা এক্সএমএল পরীক্ষা করে দেখুন) তা দৃশ্যমান, নোড 32, একটি টিভিএফ। ধীর ক্যোয়ারী স্টোর অনুসন্ধানের অপরাধী ইন মেমরি টিভিএফগুলির বারবার অ্যাক্সেস করে ।

এই টিভিএফগুলি থেকে কতগুলি সারি ফিরে আসে তা বিবেচ্য নয়, কেবল তার সংখ্যাটি কতবার ব্যবহার করা হয়েছিল। আপনার পরিকল্পনাগুলি একাধিকবার পড়া থেকে দূরে রাখতে আপনি যা কিছু করতে পারেন তা ঠিক হয়ে যাবে।

আমার সীমিত ডিবাগিং (দক্ষতা এবং সময় ব্যয় উভয়) এর উপর ভিত্তি করে আমার অনুমানটি হ'ল ক্যোরি স্টোর ডেটার নির্দিষ্ট মেমরির উপাদানটির জন্য নির্ধারিত মেমরির সম্পূর্ণতা প্রতিটি টিভিএফের প্রয়োগের সাথে স্ক্যান করা হয়। আমি হয় আপনি এই মেমরি অ্যালোকেশন প্রভাবিত করার সক্ষম হয়েছে না sp_query_store_flush_dbবা DBCC FREESYSTEMCACHE।

সফল কাজকর্মের মধ্যে এখন পর্যন্ত পরিকল্পনার গাইড, হিন্টিং ( OPTION(HASH JOIN, LOOP JOIN)এতদিন আমার পক্ষে যথেষ্ট ভাল কাজ করেছে) এবং এজি-র কেবল-পঠনযোগ্য নোডে কোয়েরি স্টোর অনুসন্ধানগুলি চালানো অন্তর্ভুক্ত রয়েছে।