বিকল্প (প্রস্তাবনা) সর্বদা দ্রুত; কেন?

Question

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

ক্যোরি বিশ্লেষক বা আমার সি # প্রোগ্রামের মাধ্যমে কোয়েরি কার্যকর করা হয় এমন ক্ষেত্রে এটি ঘটে SqlCommand.ExecuteReader()। কল করা (না কল করা) DBCC FREEPROCCACHEবা DBCC dropcleanbuffersকোনও পার্থক্য করে না; অনুসন্ধানের ফলাফলগুলি সর্বদা তাত্ক্ষণিকভাবে OPTION (RECOMPILE)এবং এটি ছাড়া পাঁচ মিনিটেরও বেশি ফিরানো হয় । ক্যোয়ারি সর্বদা একই পরামিতিগুলির সাথে ডাকা হয় [এই পরীক্ষার স্বার্থে]।

আমি এসকিউএল সার্ভার 2008 ব্যবহার করছি।

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

এমন একটি কোয়েরি থাকা কি অত্যন্ত অস্বাভাবিক যে প্রতি একক কলটিতে একটি সংশোধন ইঙ্গিত দরকার?

এন্ট্রি-স্তরের প্রশ্নের জন্য দুঃখিত তবে আমি সত্যিই এর মাথা বা লেজ তৈরি করতে পারি না।

আপডেট: আমাকে কোয়েরি পোস্ট করতে বলা হয়েছে ...

select acctNo,min(date) earliestDate 
from( 
    select acctNo,tradeDate as date 
    from datafeed_trans 
    where feedid=@feedID and feedDate=@feedDate 

    union 

    select acctNo,feedDate as date 
    from datafeed_money 
    where feedid=@feedID and feedDate=@feedDate 

    union 

    select acctNo,feedDate as date 
    from datafeed_jnl 
    where feedid=@feedID and feedDate=@feedDate 
)t1 
group by t1.acctNo
OPTION(RECOMPILE)

ক্যোয়ারি অ্যানালাইজারের কাছ থেকে পরীক্ষা চালানোর সময়, আমি নিম্নলিখিত লাইনগুলি পূর্বে চাপিয়ে দিই:

declare @feedID int
select @feedID=20

declare @feedDate datetime
select @feedDate='1/2/2009'

আমার সি # প্রোগ্রাম থেকে এটিকে কল করার সময়, প্যারামিটারগুলি SqlCommand.Parametersসম্পত্তির মধ্য দিয়ে যায় ।

এই আলোচনার উদ্দেশ্যগুলির জন্য, আপনি ধরে নিতে পারেন যে প্যারামিটারগুলি কখনই পরিবর্তিত হয় না কারণ আমরা কারণ হিসাবে উপ-অনুকূল পরামিতিগুলির গন্ধকে বাতিল করতে পারি।

Comments

কোয়েরিটির প্যারামিটারগুলি কী কী? এই নিবন্ধটি দেখুন। ব্লগস.এমএসডিএন / বি / টুরগাইস / আর্কাইভ / ২০১৩ / ০৯ / ১০ / Bas মূলত, এসকিউএল প্রথমটি যখন প্রম্পটটি সংকলিত হয় তখন পরামিতিগুলির উপর ভিত্তি করে কোয়েরি প্ল্যান উত্পন্ন করার চেষ্টা করে। এটি এমন একটি পরিকল্পনা তৈরি করতে পারে যা আপনি যখন আলাদা, সম্ভবত আরও বাস্তবসম্মত পরামিতিগুলি পাস করতে শুরু করেন তখন অনুকূল নয়

— স্পার্কি

কোয়েরি এখানে তালিকাবদ্ধ করার জন্য যথেষ্ট সংক্ষিপ্ত? আমি মনে করি স্পার্কি সঠিক এবং এটি সম্ভবত প্যারামিটার স্নিফিংয়ের সাথে সম্পর্কিত, আমার একটি একই সমস্যা ছিল যা এই চমৎকার নিবন্ধটি না পড়া পর্যন্ত আমাকে হ্যাক

— ক্রিস

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

— চাদ ডেকার

এটি প্যারামিটারগুলি এবং ভেরিয়েবলগুলির মানগুলিকে স্নিগ্ধ করার কারণে বা এটি আরও বেশি সরলকরণের কারণেই এটি ঘটতে পারে। বৃহত্তর simplifications উদাহরণ ধ্বসে করা হবে X = @X OR @X IS NULLথেকে X=@Xএবং একটি চাইতে করণ দেখুন এখানে অথবা predicates নিচে উইন্ডোতে ফাংশন সঙ্গে একটি দৃশ্য বিরুদ্ধে আরও ঠেলাঠেলি

— মার্টিন স্মিথ

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

— মার্টিন স্মিথ

Answer 1

এমন সময় রয়েছে যা ব্যবহার করে OPTION(RECOMPILE)বোঝা যায়। আমার অভিজ্ঞতায় আপনি যখন ডায়নামিক এসকিউএল ব্যবহার করছেন কেবলমাত্র তখনই এটি কার্যকর হবে। এটি আপনার পরিস্থিতিতে বোধগম্য হয় কিনা তা আবিষ্কার করার আগে আমি আপনার পরিসংখ্যান পুনর্নির্মাণের পরামর্শ দেব। নিম্নলিখিত চালিয়ে এটি করা যেতে পারে:

EXEC sp_updatestats

এবং তারপরে আপনার কার্যকরকরণের পরিকল্পনাটি পুনরায় তৈরি করা হচ্ছে। এটি নিশ্চিত করবে যে আপনার কার্যকর করার পরিকল্পনাটি তৈরি হওয়ার সময় এটি সর্বশেষ তথ্য ব্যবহার করবে।

যুক্ত করা OPTION(RECOMPILE)আপনার ক্যোয়ারির প্রয়োগের সাথে সাথে প্রতিটি সময় কার্যকর করা পরিকল্পনা পুনর্নির্মাণ করে। আমি এটি বর্ণিত শুনিনি creates a new lookup strategyতবে সম্ভবত আমরা একই জিনিসটির জন্য বিভিন্ন পদ ব্যবহার করছি।

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

সংক্ষেপে - আমি OPTION(RECOMPILE)এখানে কোনও উপকার হবে এমন কোনও কারণ দেখছি না । আমার সন্দেহ হয় আপনার কেবলমাত্র আপনার পরিসংখ্যান এবং আপনার সম্পাদন পরিকল্পনা আপডেট করা দরকার। আপনার পরিস্থিতির উপর নির্ভর করে পুনর্নির্মাণ পরিসংখ্যানগুলি ডিবিএ কাজের একটি অপরিহার্য অংশ হতে পারে। আপনার পরিসংখ্যান আপডেট করার পরেও যদি আপনার সমস্যা হয় তবে আমি উভয় কার্যকর করার পরিকল্পনা পোস্ট করার পরামর্শ দেব।

এবং আপনার প্রশ্নের উত্তর দেওয়ার জন্য - হ্যাঁ, আমি বলব যে আপনি যখনই ক্যোয়ারি চালিয়ে যাবেন তখন আপনার সেরা বিকল্পটি কার্যকর করার পরিকল্পনাটি পুনরায় সংশোধন করা অত্যন্ত অস্বাভাবিক।

Comments

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

— চাদ ডেকার

টেবিল-ভেরিয়েবলগুলির সাথে কাজ করার আমি এটিই খুঁজে পেয়েছি, এসকিউএল সর্বদা মনে করে যে এর মধ্যে একটি একক সারি রয়েছে it এটিতে কয়েক হাজার সারি থাকায় এটি সমস্যা হয়ে দাঁড়ায়।

— অ্যালেক্স জুলুকভস্কি

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

— গ্রো

Answer 2

প্রায়শই যখন কোনও ক্যোয়ারি চালাতে রান থেকে শুরু করার মধ্যে এক তীব্র পার্থক্য থাকে আমি দেখতে পাই এটি প্রায়শই 5 টির মধ্যে একটি।

1. পরিসংখ্যান- পরিসংখ্যান পুরানো হয়। একটি ডাটাবেস সারণী এবং সূচকগুলিতে বিভিন্ন কলামে মানের ধরণের পরিসীমা এবং বন্টন সম্পর্কিত পরিসংখ্যান সঞ্চয় করে। এটি কোয়েরি ইঞ্জিনটিকে কীভাবে এটি করবে তার জন্য আক্রমণটির "পরিকল্পনা" বিকাশ করতে সহায়তা করে, উদাহরণস্বরূপ, এটি হ্যাশ ব্যবহার করে টেবিলের মধ্যে কীগুলির সাথে মেলে বা পুরো সেটটি সন্ধান করার জন্য কী ধরণের পদ্ধতি ব্যবহার করবে। আপনি পুরো ডাটাবেসে আপডেট স্ট্যাটিস্টিকস বা কিছু নির্দিষ্ট সারণী বা সূচী কল করতে পারেন। এটি ক্যোয়ারিকে এক রান থেকে অন্য দিকে ধীর করে দেয় কারণ পরিসংখ্যানগুলির মেয়াদ শেষ হয়ে গেলে, সম্ভবত এটির ক্যোয়ারী পরিকল্পনাটি একই ক্যোয়ারির জন্য সদ্য প্রবেশ করানো বা পরিবর্তিত ডেটার জন্য অনুকূল নয় (আরও নীচে পরে ব্যাখ্যা করা হয়েছে)। উত্পাদনের ডেটাবেজে তাত্ক্ষণিকভাবে পরিসংখ্যান আপডেট করা ঠিক হবে না কারণ নমুনার পরিমাণের পরিমাণের উপর নির্ভর করে কিছু ওভারহেড থাকবে, ধীর হয়ে যাবে এবং পিছিয়ে থাকবে। আপনি পরিসংখ্যান আপডেট করার জন্য একটি পূর্ণ স্ক্যান বা স্যাম্পলিং ব্যবহার করতেও চয়ন করতে পারেন। আপনি যদি ক্যোয়ারী প্ল্যানের দিকে নজর দেন তবে আপনি কমান্ডটি ব্যবহার করে সূচীর উপরের পরিসংখ্যানগুলিও দেখতে পাবেনডিবিসিসি শ্যাওপ্যাটিস্টিকস (টেবিলের নাম, সূচক নাম) । এটি আপনাকে জিজ্ঞাসার পরিকল্পনাটি তার পদ্ধতির উপর ভিত্তি করে ব্যবহার করার জন্য কীগুলির বিতরণ এবং ব্যাপ্তিগুলি দেখায়।

2. প্যারামিটার স্নিফফিং - ক্যোয়ারী প্ল্যানটি যে ক্যাশে করা হয়েছে আপনি যে বিশেষ প্যারামিটারগুলি দিয়ে যাচ্ছেন তা যথাযথ নয়, যদিও ক্যোরি নিজেই পরিবর্তন হয়নি। উদাহরণস্বরূপ, আপনি যদি এমন একটি প্যারামিটারে পাস করেন যা কেবল 1,000,000 সারিগুলির মধ্যে 10 টি পুনরুদ্ধার করে, তবে তৈরি করা ক্যোয়ারী প্ল্যানটি হ্যাশ জোড় ব্যবহার করতে পারে, তবে আপনি যে প্যারামিটারটি উত্তীর্ণ করেছেন তা যদি 1,000,000 সারিগুলির 750,000 ব্যবহার করে তবে তৈরি পরিকল্পনাটি হতে পারে সূচক স্ক্যান বা টেবিল স্ক্যান এমন পরিস্থিতিতে আপনি এসকিউএল বিবৃতিটি অপশন (পুনরুদ্ধার) বা একটি এসপি ব্যবহারের জন্য পুনরায় ব্যবহারের জন্য বলতে পারেন। ইঞ্জিনকে বলতে এটি একটি "একক ব্যবহারের পরিকল্পনা" এবং ক্যাশেড প্ল্যানটি ব্যবহার না করা যা সম্ভবত প্রয়োগ হয় না। কীভাবে এই সিদ্ধান্ত নেবেন সে সম্পর্কে কোনও নিয়ম নেই, ব্যবহারকারীরা কীভাবে ক্যোয়ারী ব্যবহার করবেন তা জানার উপর নির্ভর করে।

3. সূচি - এটি সম্ভবত যে ক্যোরির পরিবর্তন হয়নি, তবে অন্য কোথাও পরিবর্তন যেমন খুব দরকারী সূচক অপসারণের ফলে ক্যোয়ারিটি ধীর হয়ে গেছে।

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

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

সাধারণভাবে আপনি যখন কোনও কোয়েরি লেখেন, আপনার টেবিলে নির্দিষ্ট ডেটা কীভাবে বিতরণ করা হয় তার কিছুটা মানসিক চিত্র আপনার থাকা উচিত। উদাহরণস্বরূপ একটি কলামে, সমানভাবে বিতরণযোগ্য বিভিন্ন মান থাকতে পারে, বা এটি স্কিউ করা যেতে পারে, সময়ের ৮০% নির্দিষ্ট মানের মান থাকে, সময়ের সাথে সাথে বিতরণটি ঘন ঘন পরিবর্তিত হবে বা মোটামুটি স্থির থাকবে। এটি আপনাকে দক্ষ ক্যোয়ারী কীভাবে তৈরি করবেন তার একটি আরও ভাল ধারণা দেবে। তবে ডিবাগিং ক্যোয়ারী পারফরম্যান্সের সময় কেন এটি ধীর বা অকার্যকর তা নিয়ে একটি অনুমান তৈরির ভিত্তি রয়েছে a

Comments

ধন্যবাদ বন্ধু. এটি দুর্দান্ত তথ্য। আমি যখন আমার প্রশ্নটি প্রাথমিকভাবে পোস্ট করি তখন আমি আপনার উত্তরটি বুঝতে পারি না তবে এখন এটি আমার কাছে সঠিক ধারণা দেয়।

— চাদ ডেকার

প্যারামেটার স্নিফফিং আমার অস্তিত্বের পক্ষে সর্বকালের বৃহত্তম নিষিদ্ধ। এমনকি একটি ব্যর্থ সাক্ষাত্কারের প্রশ্ন না হওয়া পর্যন্ত আমি এই আদেশটি সম্পর্কে জানতাম না। প্যারামিটার স্নিফিংয়ের আমার সমাধানটি সর্বদা প্যারামিটারের মানগুলি হ্যাশ করা এবং "এবং {হ্যাশ} = {হ্যাশ}" সংযোজন করা ছিল যাতে স্কুলটি সর্বদা বিভিন্ন মানের জন্য আলাদা ছিল। একটি হ্যাক, কিন্তু এটি কাজ করে।

— জেরেমি বয়ড

Answer 3

অপশন (রিকম্পাইল) খুব সহায়ক হতে পারে এমন পরিস্থিতিতে (@ কোডকোবয়আরগ দ্বারা প্রদত্ত) দুর্দান্ত তালিকায় যুক্ত করতে,

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

Comments

আমার 5 টি টেবিল ভেরিয়েবলের সাথে একটি প্রশ্ন রয়েছে। আমার মেশিনে এটি আধ ঘন্টারও বেশি সময় ধরে চালায়। আমার সহকর্মীর মেশিনে এটি <1 সেকেন্ডে কার্যকর হয়। মেশিনগুলির অনুরূপ হার্ডওয়্যার এবং একই এসকিউএল সার্ভার সংস্করণ রয়েছে। যদি আমরা উভয়ই বিকল্প (পুনরুদ্ধার) যুক্ত করি তবে এটি উভয় মেশিনে 2 সেকেন্ডের মধ্যে কার্যকর হয়। সব ক্ষেত্রেই এসএসএমএসে ফাঁসির পরীক্ষা করা হয়। এই পার্থক্যের কারণ কী হতে পারে?

— আদম

অপশন (পুনঃসংযোগ) ছাড়াই আপনি নিজের মেশিনে এবং আপনার সহকর্মীদের মেশিনে এর জন্য কার্যকরকরণ পরিকল্পনার তুলনা করতে পারেন? এটি পার্থক্যের উত্সটি দেখায়।

— ডিডরাইট

অস্থায়ী টেবিলের জন্য, এটি কি একই অবস্থা?

— মুফ্লিক্স

@ মুফ্লিক্স: ভাল প্রশ্ন। অস্থায়ী টেবিলগুলির জন্য প্রভাবটি একই বলে আমি বিশ্বাস করি না, যেহেতু তাদের পরিসংখ্যান রয়েছে এবং ইঞ্জিনটি অন্য টেবিলের মতো স্বয়ংক্রিয় পুনঃসংযোগ পছন্দ করা উচিত, আমি বিশ্বাস করি (তবে নিশ্চিত নয়)। আরও কেউ নিশ্চয়ই বৃহত্তর সুনিশ্চিততার সাথে জানেন।

— ডিওরাইট

অস্থায়ী সারণীতে থাকা পরিসংখ্যানগুলি স্বয়ংক্রিয়ভাবে আপডেট হয় না বা পুনরায় সংযুক্ত হয় না তাই প্রোগ্রামারকে এটি করা দরকার।

— জে মাইকেল উয়ের্থ

Answer 4

টিউনিং কোয়েরির আগে প্রথম ক্রিয়াগুলি হ'ল সূচি এবং পরিসংখ্যানকে আবার নকশা করা / পুনর্নির্মাণ করা, অন্যথায় আপনি নিজের সময় নষ্ট করছেন।

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

উদাহরণ হিসাবে: সূচি তৈরি করুন idx01_datafeed_trans ডেটাফিড_ট্রেসগুলিতে (ফিডিড, ফিডডেট) ইনক্লুড (অ্যাক্টনো, ট্রেডডেট)

যদি পরিকল্পনাটি স্থিতিশীল হয় বা আপনি এটি স্থিতিশীল করতে পারেন তবে আপনি একটি নির্ধারিত কার্যকরকরণ পরিকল্পনাটি সংরক্ষণ এবং ব্যবহার করতে sp_executesql ('sql বাক্য') দিয়ে বাক্যটি কার্যকর করতে পারেন।

পরিকল্পনাটি যদি অস্থিতিশীল হয় তবে প্রতিবার কার্যকর করার পরিকল্পনার মূল্যায়ন করতে এবং তৈরি করতে আপনাকে একটি অ্যাড-হক স্টেটমেন্ট বা এক্সইসি ('স্কিল বাক্য') ব্যবহার করতে হবে। (বা "পুনঃসংযোগ সহ" একটি সঞ্চিত পদ্ধতি)।

আশা করি এটা সাহায্য করবে.

Answer 5

এই প্রশ্নটিকে ঘৃণা করছে কিন্তু এমন একটি ব্যাখ্যা রয়েছে যা কেউ বিবেচনা করেছে বলে মনে হচ্ছে না।

পরিসংখ্যান - পরিসংখ্যান উপলব্ধ বা বিভ্রান্তিকর নয়

নীচের সমস্তগুলি সত্য হলে:

1. কলামগুলি ফিডিড এবং ফিডডেট সম্ভবত খুব বেশি সংযুক্ত হতে পারে (যেমন একটি ফিড আইডি একটি ফিডের তারিখের চেয়ে আরও নির্দিষ্ট এবং তারিখের প্যারামিটার অপ্রয়োজনীয় তথ্য)।
2. অনুক্রমিক কলাম হিসাবে উভয় কলামের সাথে কোনও সূচক নেই।
3. এই উভয় কলামে কোনও ম্যানুয়ালি তৈরি করা পরিসংখ্যান নেই।

তারপরে স্ক্যুয়াল সার্ভারটি ভুলভাবে ধরে নেওয়া যেতে পারে যে কলামগুলি অসামঞ্জস্যিত, উভয় বিধিনিষেধ প্রয়োগ করার জন্য প্রত্যাশিত কার্ডিনালিটির অনুমানের চেয়ে কম এবং দুর্বল নির্বাহের পরিকল্পনাটি নির্বাচিত হচ্ছে leading এই ক্ষেত্রে সমাধানটি হ'ল দুটি কলামকে সংযুক্ত করে একটি পরিসংখ্যান অবজেক্ট তৈরি করা হবে যা কোনও ব্যয়বহুল ক্রিয়াকলাপ নয়।