পূর্ব-দ্রুত এসকিউএল কোয়েরি ধীরে চলতে শুরু করলে, আমি সমস্যার উত্সটি কোথায় খুঁজে পাব?


36

পটভূমি

আমার এসকিউএল সার্ভার ২০০৮ আর 2 এর বিপরীতে একটি ক্যোয়ারী চলছে যা প্রায় 12 টি বিভিন্ন "টেবিল"-এ যোগ দেয় এবং / অথবা বাম-যোগ দেয়। 50 মিলিয়ন সারি এবং প্রায় 300 টি আলাদা টেবিলের সাথে অনেকগুলি সারণী সহ ডাটাবেসটি মোটামুটি বড়। এটি একটি বৃহত-ইশ কোম্পানির জন্য যার সারা দেশে 10 টি গুদাম রয়েছে। সমস্ত গুদামগুলি ডাটাবেসে পড়ে এবং লিখতে থাকে। সুতরাং এটি বেশ বড় এবং বেশ ব্যস্ত।

আমার যে ক্যোয়ারী নিয়ে সমস্যা হচ্ছে সেটিকে দেখতে এমন কিছু দেখাচ্ছে:

select t1.something, t2.something, etc.
from Table1 t1
    inner join Table2 t2 on t1.id = t2.t1id
    left outer join (select * from table 3) t3 on t3.t1id = t1.t1id
    [etc]...
where t1.something = 123

লক্ষ্য করুন যে এর মধ্যে একটি যোগ দেয় এমন একটি অন-সম্পর্কযুক্ত সাব-কোয়েরিতে রয়েছে।

সমস্যাটি হ'ল এই সকালে শুরু হওয়া, সিস্টেমে কোনও পরিবর্তন ছাড়াই (যেটি আমি বা আমার দলের যে কেউই জানে), ক্যোয়ারীটি চালাতে প্রায় 2 মিনিট সময় নেয়, চালাতে এক ঘন্টা দেড় ঘন্টা সময় শুরু করে - যখন এটি মোটেই দৌড়ে গেল বাকী ডাটাবেস ঠিক জরিমানা বানাচ্ছে। আমি এই ক্যোয়ারীটি প্রায়শই চলে এমন স্প্রোকের বাইরে নিয়ে এসেছি এবং এসএসএমএস ডাব্লু / হার্ড-কোডেড প্যারামিটার ভেরিয়েবলগুলিতে একই স্বচ্ছলতা দিয়ে চালিয়েছি।

আশ্চর্যের বিষয় হ'ল আমি যখন অ-সম্পর্কিত সম্পর্কযুক্ত সাব-কোয়েরিটি নিই এবং এটি একটি টেম্প টেবিলের মধ্যে ফেলে দিই এবং তারপরে সাব-কোয়েরির পরিবর্তে এটি ব্যবহার করি, ক্যোয়ারীটি ঠিকঠাকভাবে চলে runs এছাড়াও (এবং এটি আমার কাছে সবচেয়ে আশ্চর্যজনক) যদি আমি কোয়েরার শেষে এই টুকরো কোডটি যুক্ত করি তবে ক্যোরিটি দুর্দান্তভাবে চলে:

and t.name like '%'

এই ছোট্ট পরীক্ষাগুলি থেকে আমি সিদ্ধান্ত নিয়েছি (সম্ভবত ভুলভাবে) এসকিউএল এর ক্যাশেড এক্সিকিউশন প্ল্যান কীভাবে সেট আপ করা হয় তার কারণে - ধীরগতির কারণ হ'ল - যখন কোয়েরিটি কিছুটা আলাদা, তখন এটি একটি নতুন এক্সিকিউশন প্ল্যান তৈরি করতে হবে।

আমার প্রশ্নটি হ'ল: যখন কোনও কোয়েরি যা দ্রুত চলতে শুরু করত হঠাৎ রাতের মাঝামাঝি থেকে ধীরে ধীরে চলতে শুরু করে এবং এই একটি ক্যোয়ারী ব্যতীত অন্য কোনও কিছুই প্রভাবিত হয় না, আমি কীভাবে এটির সমস্যা সমাধান করব এবং ভবিষ্যতে কীভাবে তা ঘটে যাওয়া থেকে রক্ষা করব? ? কীভাবে জানবো যে এসকিউএল এটিকে এত ধীর করে দেওয়ার জন্য অভ্যন্তরীণভাবে কী করছে (খারাপ জিজ্ঞাসাটি চলতে থাকলে আমি এর সম্পাদন পরিকল্পনাটি পেতে পারি তবে এটি চলবে না - সম্ভবত প্রত্যাশিত সম্পাদন পরিকল্পনা আমাকে কিছু দেবে?)? যদি এই সমস্যাটি কার্যকর করার পরিকল্পনার সাথে থাকে তবে আমি কীভাবে এসকিউএলকে এমন ভাবনা থেকে দূরে রাখব যে সত্যই কৃপণ বাস্তবায়ন পরিকল্পনাগুলি একটি ভাল ধারণা?

এছাড়াও, প্যারামিটার স্নিফিংয়ের ক্ষেত্রে এটি কোনও সমস্যা নয়। আমি এটি আগে দেখেছি, এবং এটি এটি নয়, যেহেতু আমি যখন এসএসএমএসে ভারিবেলগুলি হার্ড-কোড করি তখনও আমি ধীর পারফরম্যান্স পাই।


: আপনি ক্যোয়ারী পরিকল্পনা (ধীর এক) ভাগ গেল এখানে brentozar.com/pastetheplan
MJH

উত্তর:


31

যখন এমন কোয়েরি যা দ্রুত দৌড়তে দেরি করত হঠাৎ মাঝরাতে ধীরে ধীরে চলতে শুরু করে এবং এই প্রশ্নটি ব্যতীত অন্য কিছুই প্রভাবিত হয় না, আমি কীভাবে এটির সমস্যা সমাধান করব ...?

কার্যকর করার পরিকল্পনাটি এখনও ক্যাশে রয়েছে কিনা তা পরীক্ষা করে আপনি শুরু করতে পারেন। চেক করুন sys.dm_exec_query_stats, sys.dm_exec_procedure_statsএবং sys.dm_exec_cached_plans। যদি খারাপ বাস্তবায়ন পরিকল্পনাটি এখনও ক্যাশে থাকে তবে আপনি এটি বিশ্লেষণ করতে পারেন এবং আপনি কার্যকর করার পরিসংখ্যানও পরীক্ষা করতে পারেন। কার্যকর করার পরিসংখ্যানগুলিতে যৌক্তিক পাঠ, সিপিইউ সময় এবং সম্পাদনের সময় হিসাবে তথ্য থাকবে। এগুলি সমস্যাটি (যেমন, বৃহত স্ক্যান বনাম ব্লক করা) শক্তিশালী ইঙ্গিত দিতে পারে। কীভাবে ডেটাটি ব্যাখ্যা করবেন তা ব্যাখ্যা করার জন্য সমস্যা কোয়েরি সনাক্তকরণ দেখুন ।

এছাড়াও, প্যারামিটার স্নিফিংয়ের ক্ষেত্রে এটি কোনও সমস্যা নয়। আমি এটি আগে দেখেছি, এবং এটি এটি নয়, যেহেতু আমি যখন এসএসএমএসে ভারিবেলগুলি হার্ড-কোড করি তখনও আমি ধীর পারফরম্যান্স পাই।

আমি সন্তুষ্ট নই. এসএসএমএসে হার্ড-কোডিং ভেরিয়েবলগুলি প্রমাণ করে না যে অতীত খারাপ সম্পাদন পরিকল্পনাটি স্কিউড ইনপুটটির বিরুদ্ধে সংকলিত হয়নি। বিষয়টিতে খুব ভাল নিবন্ধের জন্য দয়া করে প্যারামিটার স্নিফিং, এম্বেডিং এবং RECOMPILE বিকল্পগুলি পড়ুনঅ্যাপ্লিকেশন ধীর, এসএসএমএসে দ্রুত? পারফরম্যান্স রহস্যগুলি বোঝা অন্য একটি দুর্দান্ত রেফারেন্স।

এই ছোট্ট পরীক্ষাগুলি থেকে আমি সিদ্ধান্ত নিয়েছি (সম্ভবত ভুলভাবে) এসকিউএল এর ক্যাশেড এক্সিকিউশন প্ল্যান কীভাবে সেট আপ করা হয় তার কারণে - ধীরগতির কারণ হ'ল - যখন কোয়েরিটি কিছুটা আলাদা, তখন এটি একটি নতুন এক্সিকিউশন প্ল্যান তৈরি করতে হবে।

এটি সহজে পরীক্ষা করা যায়। SET STATISTICS TIME ONসংকলন বনাম সম্পাদনের সময় আপনাকে দেখাবে। এসকিউএল সার্ভার: পরিসংখ্যান পারফরম্যান্স কাউন্টারগুলিও প্রকাশ করবে যে সংকলনটি কোনও সমস্যা কিনা (স্পষ্টতই, আমি এটি অসম্ভব বলে মনে করি)।

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

কী পরিমাপ করতে হবে এবং কী সন্ধান করতে হবে সে সম্পর্কে আরও সাধারণ আলোচনার জন্য, এসকিউএল সার্ভারের কার্যকারিতা কীভাবে বিশ্লেষণ করতে হয় তা দেখুন


7

এটি এসকিউএল সার্ভারে জটিল ক্যোয়ারী চালানোর একটি নিষেধাজ্ঞা ভাগ্যক্রমে, এটি প্রায়শই ঘটে না।

ক্যোয়ারির জন্য ক্যোয়ারী পরিকল্পনাটি দেখুন (যখন এটি ধীরগতিতে চলছে)। আমি অনুমান করছি যে আপনি টেস্টগুলিতে যোগদানের জন্য কোনও সূচী ছাড়াই এক বা একাধিকবার নেস্ট লুপ যোগদান করবেন। এটি সত্যই জিনিসকে ধীর করে দেয়। দ্রুত এগিয়ে যাওয়ার জন্য, এটি ঠিক করার উপায়টি একটি ইঙ্গিত সহ। ক্যোয়ারির শেষে নিম্নলিখিতগুলি যুক্ত করুন:

OPTION (MERGE JOIN, HASH JOIN)

এটি সাধারণত আমার জন্য অতীতের সমস্যার সমাধান করে দিয়েছে।

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


1
বাস্তবায়ন পরিকল্পনা প্রকৃতপক্ষে নেস্টেড লুপ জোড় ব্যবহার করছে। তবে, আমি যখন ইঙ্গিতটি আপনার প্রস্তাব অনুসারে রাখি তখন আমি এই ত্রুটিটি পেয়েছি: "ক্যোয়ারী প্রসেসর এই কোয়েরিতে সংজ্ঞায়িত ইঙ্গিতগুলির কারণে কোনও কোয়েরি প্ল্যান তৈরি করতে পারেনি any কোনও ইঙ্গিত নির্দিষ্ট না করে এবং SET FORCEPLAN ব্যবহার না করে কোয়েরিটি পুনরায় জমা দিন" " আমি অবশ্যই অপশন (লুপ জয়েন) যুক্ত করার পরে এটি কার্যকর করার পরিকল্পনা তৈরি করবে তবে ধীরে ধীরে চলতে আমার এখনও সমস্যা আছে। আপনি কি এই ইস্যুতে চালিত করেছেন? দেখে মনে হচ্ছে এটি লুপ যোগদানের প্রয়োজন।

টুইটার । । না আমি আসলে এই সমস্যাটি দেখিনি। সম্ভবত আপনার ক্যোয়ারী কিছু অ-ইক্যুইজিনগুলি করছে (সমান চিহ্নগুলি ব্যবহার করছে না) এবং অপ্টিমাইজারটি সেখানে নেস্টেড লুপটি ব্যবহার করতে হবে।
গর্ডন লিনফ

3

সাধারণত এটি একটি অনুপস্থিত সূচক যা এই ধরণের সমস্যার কারণ হয়।

আমি সাধারণত যা করি তা এসকিউএল ম্যানেজমেন্ট স্টুডিও ব্যবহার করে ক্যোয়ারি চালানো হয় এবং 'অন্তর্ভুক্ত প্রকৃত এক্সিকিউশন প্ল্যান (সিটিআরএল + এম) সক্ষম করে' এবং কোনটি যোগ দেয় তা সর্বাধিক শতাংশের মধ্যে রয়েছে তা সন্ধান করে।

অ্যাপ্লিকেশনটি বাধাটির উপর দৃষ্টি নিবদ্ধ করে না, তবে আপনি ফলাফলটি সন্ধান করে এটি "দ্রুত" খুঁজে পেতে পারেন।

উদাহরণ এখানে: 48PercentForTop


2
কোনও সূচক হঠাৎ করেই "নিখোঁজ" হবে না, সুতরাং এটি পারফরম্যান্সের উন্নতি করতে পারে তবে সমস্যাটি ব্যাখ্যা করে না
ফাউল

3

আমি সম্প্রতি এই একই সমস্যাটি নিয়েছি যা আমাকে এই পৃষ্ঠায় নিয়ে এসেছে।

@ মার্টিনস্মিথ যখন আপনার পরিসংখ্যান আপডেট করার এবং পরিকল্পনার ব্যাখ্যা দেওয়ার পরামর্শ দিয়েছিলেন তখন সে কিছু ছিল। আমি যুক্ত করতে চাই যে আপনার চলমান চাকরি / ক্যোয়ারীগুলি যাতে তালা তৈরি করতে পারে এবং এর ফলে প্রতিক্রিয়া সময়কে ধীর করতে পারে সেদিকে নজর দেওয়াও আপনার চেষ্টা করা উচিত।

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

আমি আশা করি এটি অন্য কাউকে সহায়তা করে


0

আপনি টি-এসকিউএল ced পদ্ধতিতে পারফরম্যান্সের সমস্যাটি দেখলে কোনও সার্ভার ব্যাকআপ বা কোনও সংরক্ষণাগার \ সূচক কাজ চলছে কিনা তাও আপনাকে পরীক্ষা করতে হবে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.