প্রথম পরিকল্পনায় স্পুল পুনরাবৃত্তির কোনও কলুষিত সুবিধা রয়েছে কি?
এটি নির্ভর করে যা আপনি "কলসিযোগ্য" হিসাবে বিবেচনা করেন, তবে ব্যয় মডেল অনুসারে উত্তর হ্যাঁ। অবশ্যই এটি সত্য, কারণ অপ্টিমাইজার সর্বদা এটি খুঁজে পাওয়া সস্তার পরিকল্পনাটি পছন্দ করে।
আসল প্রশ্নটি হল কেন ব্যয় মডেল স্পুলের সাথে পরিকল্পনাকে পরিকল্পনার বাইরে পরিকল্পনার চেয়ে এত কম সস্তা বলে বিবেচনা করে। ডেল্টা স্টোরটিতে কোনও সারি যুক্ত হওয়ার আগে একটি তাজা টেবিলের জন্য (আপনার স্ক্রিপ্ট থেকে) আনুমানিক পরিকল্পনাগুলি বিবেচনা করুন:
DELETE Fact.RecordedMetricsDetail
WHERE MeasurementTime < DATEADD(day,-1,GETUTCDATE())
OPTION (RECOMPILE);
এই পরিকল্পনার জন্য আনুমানিক ব্যয় একটি বিশাল 771,734 ইউনিট :
ব্যয়টি প্রায় সমস্ত ক্লাস্টারড ইনডেক্স মুছার সাথে সম্পর্কিত, কারণ মুছে ফেলার ফলে এলোমেলো আই / ও প্রচুর পরিমাণে আসে expected এটি কেবলমাত্র জেনেরিক যুক্তি যা সমস্ত ডেটা পরিবর্তনের ক্ষেত্রে প্রযোজ্য। উদাহরণস্বরূপ, একটি বি-ট্রি ইনডেক্সে একটি আনর্ডারড সংশোধিত সংস্থার ফলে মূলত এলোমেলো I / O এর সাথে সম্পর্কিত উচ্চ I / O ব্যয় হবে।
ডেটা-চেঞ্জিং প্ল্যানসগুলি ক্রমানুসারে অ্যাক্সেসকে উত্সাহিত করবে এমন ক্রমে সারিগুলি উপস্থাপনের জন্য বাছাই করতে পারে যা ঠিক এই ব্যয়গুলির জন্য। এই ক্ষেত্রে প্রভাবটি আরও তীব্রতর হয় কারণ টেবিলটি বিভক্ত। খুব বিভক্ত, বাস্তবে; আপনার স্ক্রিপ্ট তাদের মধ্যে 15,000 তৈরি করে। একটি পার্টিশনযুক্ত টেবিলের এলোমেলো আপডেটগুলি বিশেষত উঁচু হয়ে থাকে কারণ পার্টিশনগুলি (সারি সেট) মিড-স্ট্রিমটি স্যুইচ করার জন্য পাশাপাশি একটি উচ্চ ব্যয়ও দেওয়া হয়।
সর্বশেষ প্রধান বিষয় বিবেচনা করার বিষয়টি হ'ল উপরের সাধারণ আপডেট ক্যোয়ারী (যেখানে 'আপডেট' অর্থ কোনও মুছে ফেলা সহ কোনও ডেটা-চেঞ্জিং অপারেশন) "রোউসেট শেয়ারিং" নামক একটি অপ্টিমাইজেশনের জন্য যোগ্যতা অর্জন করে, যেখানে একই অভ্যন্তরীণ রুসেট উভয় স্ক্যানিংয়ের জন্য ব্যবহৃত হয় টেবিল আপডেট করা হচ্ছে। মৃত্যুদন্ড কার্যকর করার পরিকল্পনাটি এখনও দুটি পৃথক অপারেটর দেখায়, তবে তবুও, কেবলমাত্র একটি রোউসেট ব্যবহৃত হয়।
আমি এটি উল্লেখ করেছি কারণ এই অপ্টিমাইজেশানটি প্রয়োগ করতে সক্ষম হওয়ার অর্থ অপটিমাইজার একটি কোড পাথ গ্রহণ করে যা এলোমেলো I / O এর ব্যয় হ্রাস করার জন্য স্পষ্টভাবে বাছাইয়ের সম্ভাব্য সুবিধাগুলি বিবেচনা করে না । যেখানে টেবিলটি একটি বি-ট্রি, এটি অর্থবোধ করে, কারণ কাঠামোটি সহজাতভাবে অর্ডার করা হয়, তাই সারিটি ভাগ করে নেওয়া সমস্ত সম্ভাব্য সুবিধা স্বয়ংক্রিয়ভাবে সরবরাহ করে।
গুরুত্বপূর্ণ ফলাফলটি হ'ল আপডেট অপারেটরের জন্য ব্যয় যুক্তি এই অর্ডারিং সুবিধাটিকে (ক্রমান্বয়ে I / O বা অন্যান্য অনুকূলিতকরণ প্রচার করে) বিবেচনা করে না যেখানে অন্তর্নিহিত অবজেক্টটি কলাম স্টোর। এটি কারণ কলাম স্টোর পরিবর্তনগুলি জায়গায় সঞ্চালিত হয় না; তারা একটি ব-দ্বীপের দোকান ব্যবহার করে। ব্যয়ের মডেল তাই বি-ট্রি বনাম কলাম স্টোরগুলিতে ভাগ করা-রোসেট আপডেটের মধ্যে পার্থক্য প্রতিফলিত করছে।
তবুও, একটি (খুব!) পার্টিশনযুক্ত কলাম স্টোরের বিশেষ ক্ষেত্রে, সংরক্ষণযোগ্য অর্ডার করার জন্য এখনও একটি সুবিধা হতে পারে, পরবর্তী অংশে যাওয়ার আগে একটি পার্টিশনে সমস্ত আপডেট করা এখনও I / O দৃষ্টিকোণ থেকে সুবিধাজনক হতে পারে ।
স্ট্যান্ডার্ড ব্যয়ের যুক্তি এখানে কলাম স্টোরগুলির জন্য পুনরায় ব্যবহার করা হয়েছে, সুতরাং পার্টিশন অর্ডার (প্রতিটি পার্টিশনের মধ্যে অর্ডার না থাকলেও) সংরক্ষণ করে এমন একটি পরিকল্পনা কম আটকানো হয়। আপডেট অপারেটরকে বাছাই করা ইনপুটের প্রয়োজন হিসাবে আমরা অনথিভুক্ত ট্রেস পতাকা 2332 ব্যবহার করে পরীক্ষা ক্যোয়ারিতে এটি দেখতে পারি। এটি DMLRequestSortআপডেটে সম্পত্তিটিকে সত্য হিসাবে সেট করে এবং অপ্টিমাইজারকে এমন একটি পরিকল্পনা তৈরি করতে বাধ্য করে যা পরের দিকে যাওয়ার আগে একটি পার্টিশনের জন্য সমস্ত সারি সরবরাহ করে:
DELETE Fact.RecordedMetricsDetail
WHERE MeasurementTime < DATEADD(day,-1,GETUTCDATE())
OPTION (RECOMPILE, QUERYTRACEON 2332);
এই পরিকল্পনার জন্য আনুমানিক ব্যয় 52.5174 ইউনিটে খুব কম 74
আপডেটে I / O ব্যয় কম অনুমানের কারণে ব্যয়ের এই হ্রাস সবই। প্রবর্তিত স্পুল কোনও কার্যকরী কার্য সম্পাদন করে না, পার্টিশনের ক্রমে আউটপুট গ্যারান্টি দিতে পারে তা ছাড়া আপডেটের সাথে প্রয়োজনীয় DMLRequestSort = true(কলাম স্টোরের সূচকের সিরিয়াল স্ক্যান এই গ্যারান্টিটি সরবরাহ করতে পারে না)। স্পুলের ব্যয় নিজেই তুলনামূলকভাবে কম বলে বিবেচিত হয়, বিশেষ করে আপডেটে ব্যয়টি (সম্ভবত অবাস্তব) হ্রাসের সাথে তুলনা করে।
আপডেট অপারেটরের অর্ডার করা ইনপুট প্রয়োজন কিনা সে বিষয়ে সিদ্ধান্তটি কোয়েরি অপ্টিমাইজেশনে খুব তাড়াতাড়ি করা হয়েছে। এই সিদ্ধান্তে ব্যবহৃত হিউরিস্টিকস কখনই নথিভুক্ত করা হয়নি, তবে এটি পরীক্ষা এবং ত্রুটির মাধ্যমে নির্ধারণ করা যেতে পারে। দেখে মনে হচ্ছে যে কোনও ডেল্টা স্টোরের আকার এই সিদ্ধান্তের একটি ইনপুট। একবার হয়ে গেলে, কোয়েরি সংকলনের জন্য পছন্দটি স্থায়ী। কোনও USE PLANইঙ্গিত সফল হবে না : পরিকল্পনার টার্গেটটি হয় আপডেটটিতে ইনপুট অর্ডার করেছে, বা তা হয় না।
কার্ডিনালিটির প্রাক্কলনটিকে কৃত্রিমভাবে সীমাবদ্ধ না করে এই ক্যোয়ারির জন্য স্বল্প ব্যয়ের পরিকল্পনা পাওয়ার আরও একটি উপায় রয়েছে। স্পুল এড়ানোর জন্য পর্যাপ্ত কম অনুমানের ফলস্বরূপ সম্ভবত ডিএমএলরেউকস্টর্টটি মিথ্যা হয়ে উঠবে, ফলস্বরূপ প্রত্যাশিত এলোমেলো I / O এর কারণে খুব বেশি উচ্চমানের পরিকল্পনার ব্যয় হবে। বিকল্পটি হ'ল 2332 (DMLRequestSort = সত্য) এর সাথে মিল রেখে ট্রেস পতাকা 8649 (সমান্তরাল পরিকল্পনা) ব্যবহার করা:
DELETE Fact.RecordedMetricsDetail
WHERE MeasurementTime < DATEADD(day,-1,GETUTCDATE())
OPTION (RECOMPILE, QUERYTRACEON 2332, QUERYTRACEON 8649);
পার্টিশন ব্যাচ-মোড সমান্তরাল স্ক্যান এবং একটি অর্ডার-সংরক্ষণ (সংগ্রহ করা) সংগ্রহ স্ট্রিম এক্সচেঞ্জ ব্যবহার করে এমন একটি পরিকল্পনার ফলস্বরূপ:
আপনার হার্ডওয়্যারে পার্টিশন অর্ডারের রান-টাইম কার্যকারিতার উপর নির্ভর করে, এটি তিনটির মধ্যে সেরা সঞ্চালন করতে পারে। এটি বলেছে যে কলাম স্টোরের জন্য বৃহত পরিবর্তনগুলি দুর্দান্ত ধারণা নয়, সুতরাং পার্টিশন-স্যুইচিং ধারণাটি অবশ্যই আরও ভাল। আপনি যদি দীর্ঘ সংকলনের সময়গুলি এবং পার্টিশনযুক্ত অবজেক্টগুলির সাথে প্রায়শই দেখতে পাওয়া উদ্দীপনা পরিকল্পনা পছন্দগুলি মোকাবেলা করতে পারেন - বিশেষত পার্টিশনের সংখ্যা বড় হলে।
অনেকগুলি, তুলনামূলকভাবে নতুন, বৈশিষ্ট্যগুলিকে একত্রিত করা, বিশেষত তাদের সীমাটির নিকটে, দুর্বল সম্পাদনের পরিকল্পনা পাওয়ার দুর্দান্ত উপায়। অপ্টিমাইজার সহায়তার গভীরতা সময়ের সাথে সাথে উন্নতি করতে ঝোঁক, তবে কলাম স্টোরের 15,000 পার্টিশন ব্যবহার করা সম্ভবত সর্বদা আপনাকে আকর্ষণীয় সময়ে বেঁচে থাকার অর্থ দেয়।
OPTION (QUERYRULEOFF EnforceHPandAccCard)করি স্পুলটি অদৃশ্য হয়ে যায়। আমি ধরে নিয়েছি এইচপি হতে পারে "হ্যালোইন সুরক্ষা"। তবে তারপরে কোনওUSE PLANইঙ্গিত দিয়ে সেই পরিকল্পনাটি ব্যবহার করার চেষ্টা ব্যর্থ হয়েছে (যেমন পরিকল্পনাটিও কাজের দিক থেকে ব্যবহার করার চেষ্টা করাOPTIMIZE FORহয়)