সংযোজন: এসকিউএল সার্ভার 2012 এই অঞ্চলে কিছু উন্নত পারফরম্যান্স দেখায় তবে নীচে উল্লিখিত নির্দিষ্ট সমস্যাগুলি মোকাবেলা করছে বলে মনে হয় না। এটি স্পষ্টতই
এসকিউএল সার্ভার ২০১২ এর পরে পরবর্তী বড় সংস্করণে স্থির করা উচিত !
আপনার পরিকল্পনাটি দেখায় যে একক সন্নিবেশকরা প্যারামিটারাইজড পদ্ধতি ব্যবহার করছে (সম্ভবত স্বয়ংক্রিয়ভাবে প্যারামিটারাইজড) তাই পার্স / সংকলনের সময়টি ন্যূনতম হওয়া উচিত।
আমি ভেবেছিলাম আমি এটিকে আরও কিছুটা অনুসন্ধান করব যদিও এইভাবে একটি লুপ ( স্ক্রিপ্ট ) সেটআপ করেছি এবং VALUESধারাগুলির সংখ্যা সামঞ্জস্য করার এবং সংকলনের সময়টি রেকর্ড করার চেষ্টা করেছি ।
তারপরে আমি ক্লোজের প্রতি গড় সংকলন সময় পাওয়ার জন্য সংকলনের সময়টিকে সারিগুলির সংখ্যা দ্বারা বিভক্ত করেছি। ফলাফলগুলি নীচে রয়েছে
250 টি VALUESধারা অবধি সংকলন সময় / ক্লোজের উপস্থিতি অবধি সামান্য wardর্ধ্বমুখী প্রবণতা রয়েছে তবে খুব বেশি নাটকীয় কিছুই নেই।
তবে তারপরে হঠাৎ পরিবর্তন ঘটে।
তথ্যের সেই অংশটি নীচে দেখানো হয়েছে।
+------+----------------+-------------+---------------+---------------+
| Rows | CachedPlanSize | CompileTime | CompileMemory | Duration/Rows |
+------+----------------+-------------+---------------+---------------+
| 245 | 528 | 41 | 2400 | 0.167346939 |
| 246 | 528 | 40 | 2416 | 0.162601626 |
| 247 | 528 | 38 | 2416 | 0.153846154 |
| 248 | 528 | 39 | 2432 | 0.157258065 |
| 249 | 528 | 39 | 2432 | 0.156626506 |
| 250 | 528 | 40 | 2448 | 0.16 |
| 251 | 400 | 273 | 3488 | 1.087649402 |
| 252 | 400 | 274 | 3496 | 1.087301587 |
| 253 | 400 | 282 | 3520 | 1.114624506 |
| 254 | 408 | 279 | 3544 | 1.098425197 |
| 255 | 408 | 290 | 3552 | 1.137254902 |
+------+----------------+-------------+---------------+---------------+
ক্যাশেড পরিকল্পনার আকার যা রৈখিকভাবে বৃদ্ধি পেয়ে হঠাৎ হ্রাস পেয়েছিল তবে কমপাইলটাইম 7 গুন এবং কমপাইল মেমোরি অঙ্কুরিত হয়। এটি অটো প্যারামিট্রাইজড (এক হাজার প্যারামিটার সহ) অ প্যারামাইট্রাইজড হওয়ার পরিকল্পনার মধ্যে কাট অফ পয়েন্ট। এরপরে এটি রৈখিকভাবে কম দক্ষ হবে বলে মনে হচ্ছে (একটি নির্দিষ্ট সময়ে প্রক্রিয়াজাতকরণের মান ধারাগুলির শর্তে)।
কেন এটি হওয়া উচিত তা নিশ্চিত নয়। সম্ভবত যখন এটি নির্দিষ্ট আক্ষরিক মানগুলির জন্য একটি পরিকল্পনা সংকলন করছে তখন অবশ্যই এমন কিছু ক্রিয়াকলাপ সম্পাদন করতে হবে যা রৈখিকভাবে স্কেল না করে (যেমন বাছাইকরণ)।
আমি সম্পূর্ণ নকল সারি সমন্বিত একটি কোয়েরি চেষ্টা করেছিলাম এবং ধ্রুবকের টেবিলের আউটপুটটির ক্রমকেও প্রভাবিত করে না (এবং আপনি যেমন বাছাইয়ের সময় গাদা সময় সন্নিবেশ করছেন তখন এটি ক্যাশেড ক্যোয়ারী পরিকল্পনার আকারকে প্রভাবিত করবে না বলে মনে হয়) তা করলেও তা অর্থহীন হবে)।
তবুও যদি একটি ক্লাস্টারড ইনডেক্সটি টেবিলে যুক্ত করা হয় তবে পরিকল্পনাটি এখনও একটি স্পষ্ট ধরণের ধাপ দেখায় যাতে রান টাইমে কোনও সাজানো এড়ানোর জন্য এটি সংকলন সময়ে বাছাই করা মনে হয় না।
আমি এটি একটি ডিবাগারে দেখার চেষ্টা করেছি তবে এসকিউএল সার্ভার ২০০৮ এর আমার সংস্করণটির জন্য সর্বজনীন চিহ্নগুলি যাতে উপলব্ধ হয় না বলে মনে হয় তার পরিবর্তে আমাকে সমতুল্যটি দেখতে হবে UNION ALL এসকিউএল সার্ভার ২০০৫- নির্মাণটি দেখতে হবে।
একটি সাধারণ স্ট্যাক ট্রেস নীচে রয়েছে
sqlservr.exe!FastDBCSToUnicode() + 0xac bytes
sqlservr.exe!nls_sqlhilo() + 0x35 bytes
sqlservr.exe!CXVariant::CmpCompareStr() + 0x2b bytes
sqlservr.exe!CXVariantPerformCompare<167,167>::Compare() + 0x18 bytes
sqlservr.exe!CXVariant::CmpCompare() + 0x11f67d bytes
sqlservr.exe!CConstraintItvl::PcnstrItvlUnion() + 0xe2 bytes
sqlservr.exe!CConstraintProp::PcnstrUnion() + 0x35e bytes
sqlservr.exe!CLogOp_BaseSetOp::PcnstrDerive() + 0x11a bytes
sqlservr.exe!CLogOpArg::PcnstrDeriveHandler() + 0x18f bytes
sqlservr.exe!CLogOpArg::DeriveGroupProperties() + 0xa9 bytes
sqlservr.exe!COpArg::DeriveNormalizedGroupProperties() + 0x40 bytes
sqlservr.exe!COptExpr::DeriveGroupProperties() + 0x18a bytes
sqlservr.exe!COptExpr::DeriveGroupProperties() + 0x146 bytes
sqlservr.exe!COptExpr::DeriveGroupProperties() + 0x146 bytes
sqlservr.exe!COptExpr::DeriveGroupProperties() + 0x146 bytes
sqlservr.exe!CQuery::PqoBuild() + 0x3cb bytes
sqlservr.exe!CStmtQuery::InitQuery() + 0x167 bytes
sqlservr.exe!CStmtDML::InitNormal() + 0xf0 bytes
sqlservr.exe!CStmtDML::Init() + 0x1b bytes
sqlservr.exe!CCompPlan::FCompileStep() + 0x176 bytes
sqlservr.exe!CSQLSource::FCompile() + 0x741 bytes
sqlservr.exe!CSQLSource::FCompWrapper() + 0x922be bytes
sqlservr.exe!CSQLSource::Transform() + 0x120431 bytes
sqlservr.exe!CSQLSource::Compile() + 0x2ff bytes
স্ট্যাক ট্রেসটিতে নামগুলি বন্ধ করে স্ট্রিংয়ের সাথে তুলনা করে অনেক সময় ব্যয় করা হয় বলে মনে হয়।
এই কেবি নিবন্ধটি ইঙ্গিত দেয় যা সাধারণকরণDeriveNormalizedGroupProperties বলা হত এর সাথে সম্পর্কিত কোয়েরি প্রসেসিংয়ের স্টেজ
এই পর্যায়ে এখন বাঁধাই বা বীজগণিত বলা হয় এবং এটি পূর্ববর্তী পার্স পর্যায় থেকে পার্সে গাছের আউটপুট নেয় এবং একটি বীজবৃক্ষিত এক্সপ্রেশন ট্রি (ক্যোয়ারী প্রসেসর ট্রি) অপ্টিমাইজেশনে এগিয়ে যায় (এই ক্ষেত্রে তুচ্ছ পরিকল্পনা অপ্টিমাইজেশন) [রেফ] ।
আমি আরও একটি পরীক্ষা ( স্ক্রিপ্ট ) চেষ্টা করেছিলাম যা মূল পরীক্ষাটি আবার চালানো হয়েছিল তবে তিনটি ভিন্ন ভিন্ন মামলার দিকে তাকিয়ে ছিল।
- প্রথম নাম এবং শেষ নাম কোনও নকল ছাড়াই 10 অক্ষরের দৈর্ঘ্যের স্ট্রিং।
- প্রথম নাম এবং লাস্ট নেম স্ট্রিংস দৈর্ঘ্যের 50 টির নকল ছাড়াই with
- সমস্ত সদৃশ সহ 10 টি অক্ষরের দৈর্ঘ্যের প্রথম নাম এবং শেষ নাম স্ট্রিং।
এটি স্পষ্টভাবে দেখা যায় যে স্ট্রিংগুলি খারাপ জিনিসগুলি আরও দীর্ঘায়িত করে এবং বিপরীতক্রমে আরও ভাল জিনিসগুলি আরও নকল হয়। পূর্বে উল্লিখিত সদৃশগুলি ক্যাশেড পরিকল্পনার আকারকে প্রভাবিত করে না তাই আমি ধরে নিয়েছি বীজগণিত এক্সপ্রেশন ট্রি নিজেই নির্মাণ করার সময় সেখানে সদৃশ সনাক্তকরণের প্রক্রিয়া থাকতে হবে।
সম্পাদন করা
এই তথ্যটি যেখানে লিভারেজ করা হয়েছে সেখানে এক জায়গায় @ লিভেন এখানে দেখিয়েছেন
SELECT *
FROM (VALUES ('Lieven1', 1),
('Lieven2', 2),
('Lieven3', 3))Test (name, ID)
ORDER BY name, 1/ (ID - ID)
কারণ সংকলনের সময় এটি নির্ধারণ করতে পারে যে Nameকলামটির কোনও সদৃশ নেই এটি 1/ (ID - ID)রান সময়কালে গৌণ এক্সপ্রেশন দ্বারা অর্ডার এড়িয়ে যায় (পরিকল্পনার মধ্যে কেবল একটি ORDER BYকলাম থাকে) এবং শূন্য ত্রুটির দ্বারা কোনও বিভাজন উত্থাপিত হয় না। যদি নকলগুলি টেবিলের সাথে যুক্ত করা হয় তবে সারণি অপারেটর কলাম দ্বারা দুটি ক্রম দেখায় এবং প্রত্যাশিত ত্রুটি উত্থাপিত হয়।
