আমি আপনার প্রশ্নের উত্তরগুলি তাদের জিজ্ঞাসার চেয়ে আলাদা অর্ডারে দেব।
৪. এটি কি আরও বড় সমস্যার লক্ষণ?
নতুন cardinality মূল্নির্ধারক SQL সার্ভার 2016 সালে সমস্যা অবদান যেতে পারে। এসকিউএল সার্ভার 2012 লেগ্যাসি সিই ব্যবহার করে এবং আপনি সেই সংস্করণে আপনার সমস্যাটি অনুভব করেন নি। নতুন কার্ডিনালিটি অনুমানকারী আপনার ডেটা সম্পর্কে বিভিন্ন ধারনা তৈরি করে এবং একই এসকিউএল জন্য বিভিন্ন কোয়েরি পরিকল্পনা তৈরি করতে পারে। আপনার কোয়েরি এবং আপনার ডেটা নির্ভর করে উত্তরাধিকারী সিই সহ কিছু প্রশ্নের জন্য আপনি আরও ভাল পারফরম্যান্স অনুভব করতে পারেন। সুতরাং, আপনার ডেটা মডেলের কিছু অংশ নতুন সিই জন্য সেরা ম্যাচ নাও হতে পারে। এটি ঠিক আছে, তবে আপাতত আপনার প্রয়োজন হতে পারে নতুন সিই এর চারপাশে কাজ করার।
আমি দৈনিক পরিসংখ্যান আপডেটের সাথেও বেমানান ক্যোয়ারি পারফরম্যান্সের সাথে উদ্বিগ্ন হব। একটি গুরুত্বপূর্ণ বিষয় লক্ষণীয় হ'ল সমস্ত টেবিলগুলিতে পরিসংখ্যান সংগ্রহ করা ক্যাশে থেকে সমস্ত ক্যোয়ারী পরিকল্পনা কার্যকরভাবে মুছে ফেলবে, সুতরাং আপনার কাছে পরিসংখ্যান নিয়ে সমস্যা হতে পারে বা এটি প্যারামিটার স্নিফিংয়ের সাথে করতে পারে। আপনার ডেটা মডেল, ডেটা পরিবর্তনের হার, পরিসংখ্যান আপডেট করার নীতিমালা, আপনি কীভাবে আপনার কোডটি কল করছেন ইত্যাদি সম্পর্কে প্রচুর তথ্য ছাড়াই একটি সংকল্প করা কঠিন make এসকিউএল সার্ভার ২০১ প্যারামিটার স্নিফিংয়ের জন্য কিছু ডাটাবেস স্তর সেটিংস সরবরাহ করে যা সহায়ক হতে পারে , তবে এটি কেবলমাত্র একটি সমস্যাযুক্ত কোয়েরির পরিবর্তে আপনার পুরো অ্যাপ্লিকেশনটিকে প্রভাবিত করতে পারে।
আমি একটি উদাহরণের দৃশ্য ফেলে দেব যা এই আচরণের দিকে পরিচালিত করতে পারে। তুমি বলেছিলে:
কিছু ব্যবহারকারীর 1 অনুমতি রেকর্ড থাকতে পারে, কিছু, 20k অবধি।
ধরুন আপনি সমস্ত টেবিলের পরিসংখ্যান সংগ্রহ করেছেন যা সমস্ত ক্যোয়ারী পরিকল্পনা মুছে ফেলে। উপরে উল্লিখিত বিষয়গুলির উপর নির্ভর করে, যদি দিনের প্রথম ক্যোয়ারী কেবলমাত্র 1 টি অনুমতি রেকর্ডযুক্ত কোনও ব্যবহারকারীর বিরুদ্ধে হয় তবে এসকিউএল সার্ভার এমন একটি পরিকল্পনা ক্যাশে করতে পারে যা 1 রেকর্ডযুক্ত ব্যবহারকারীদের জন্য ভাল কাজ করে তবে 20k রেকর্ডযুক্ত ব্যবহারকারীদের সাথে ভয়ঙ্করভাবে কাজ করে। দিনের প্রথম ক্যোয়ারী যদি 20k রেকর্ডযুক্ত ব্যবহারকারীর বিরুদ্ধে হয় তবে আপনি 20k রেকর্ডের জন্য একটি ভাল পরিকল্পনা পেতে পারেন। কোডটি যখন কোনও ব্যবহারকারীর বিরুদ্ধে 1 টি রেকর্ড সহ চালানো হয় তখন এটি সর্বাধিক অনুকূল ক্যোয়ারী নাও হতে পারে তবে এটি এমএসে এখনও শেষ হতে পারে। এটি সত্যিই প্যারামিটার স্নিফিংয়ের মতো শব্দ করে। এটি ব্যাখ্যা করে যে আপনি কেন সবসময় সমস্যাটি দেখেন না বা কেন কখনও কখনও প্রদর্শিত হতে কয়েক ঘন্টা সময় লাগে।
১. নতুন সূচি কী সমস্যার সমাধান করবে, যার ফলে এটি আবার কখনও খারাপ পরিকল্পনা বাছাই করে না?
আমি মনে করি আপনি যে সূচকগুলি যুক্ত করেছেন তার মধ্যে একটি সমস্যা বাধা দেবে কারণ সূচকের মাধ্যমে প্রয়োজনীয় ডেটা অ্যাক্সেস করা টেবিলের বিপরীতে একটি ক্লাস্টারড ইনডেক্স স্ক্যান করার চেয়ে সস্তা হবে, বিশেষত যখন স্ক্যানটি প্রথম দিকে শেষ করতে পারে না। আসুন ক্যোয়ারী পরিকল্পনার খারাপ অংশটি জুম করি:
SQL সার্ভার এর আনুমানিক হিসেব অনুসারে শুধুমাত্র এক সারি এ যোগ থেকে ফেরত পাঠানো হবে [Permission]এবং [Project]। বাইরের ইনপুটটিতে প্রতিটি সারির জন্য এটি একটি ক্লাস্টারড ইনডেক্স স্ক্যান চালু করবে [Appointment]। সমস্ত সারি এই টেবিল থেকে স্ক্যান করা হবে, তবে কেবল ফিল্টারিংয়ের সাথে মেলে যারা [Start]যোগদান অপারেটরে ফিরে আসবে। জোড় অপারেটরের মধ্যে ফলাফল আরও কমে যায়।
উপরে বর্ণিত ক্যোয়ারী পরিকল্পনাটি ঠিকঠাক হতে পারে যদি সত্যিই যুক্ত হওয়ার বাইরের ইনপুটটিতে কেবল একটি সারি প্রেরণ করা হয়। যাইহোক, যদি যোগদান থেকে কার্ডিনালিটির অনুমানটি ভুল হয় এবং আমরা 1000 সারি বলি, তবে এসকিউএল সার্ভারটি 1000 টি ক্লাস্টারড সূচক স্ক্যান করবে [Appointment]। ক্যোয়ারী পরিকল্পনার কার্যকারিতা অনুমানের বিষয়ে খুব সংবেদনশীল।
এই ক্যোয়ারী পরিকল্পনাটি আর কখনও না পাওয়ার সবচেয়ে সহজ উপায় হ'ল [Appointment]টেবিলের বিপরীতে একটি কভারিং সূচক তৈরি করা । কিছু সূচকের মতো [ProjectId]এবং [Start]এটি করা উচিত। দেখে মনে হচ্ছে এটি হ'ল [idx_appointment_start]সূচকটি যা আপনি সমস্যার সমাধানের জন্য তৈরি করেছেন। আরেকটি উপায় ক্যোয়ারী পরিকল্পনা অবচয় থেকে SQL সার্ভার নিরুৎসাহিত করতে এ যোগ থেকে cardinality অনুমান ঠিক হয় [Permission]এবং [Project]। কোডগুলি পরিবর্তন করা, পরিসংখ্যান আপডেট করা, উত্তরাধিকারসূত্রে সিই ব্যবহার করা, বহু-কলামের পরিসংখ্যান তৈরি করা, এসকিউএল সার্ভারকে স্থানীয় ভেরিয়েবল সম্পর্কে যেমন একটি RECOMPILEইঙ্গিত সহ আরও তথ্য প্রদান করা বা সেই সারিগুলিকে একটি টেম্প টেবিলের মধ্যে রূপান্তরিত করা, বা সেই সারিগুলিকে একটি টেম্পলেটে পরিণত করার অন্তর্ভুক্ত রয়েছে ways যখন আপনার এমএস স্তরের প্রতিক্রিয়া সময় প্রয়োজন হয় বা কোনও ওআরএম এর মাধ্যমে কোড লিখতে হয় তখন সেই কৌশলগুলির মধ্যে অনেকগুলিই ভাল দৃষ্টিভঙ্গি নয়।
আপনি যে সূচকটি তৈরি করেছেন [AppointmentAttendee]তা সমস্যা সমাধানের প্রত্যক্ষ উপায় নয়। তবে, আপনি সূচকে একাধিক কলামের পরিসংখ্যান পাবেন এবং সেই পরিসংখ্যানগুলি খারাপ জিজ্ঞাসা পরিকল্পনাটিকে নিরুৎসাহিত করতে পারে। সূচকটি ডেটা অ্যাক্সেসের আরও কার্যকর উপায় সরবরাহ করতে পারে যা খারাপ জিজ্ঞাসা পরিকল্পনাটিকে নিরুৎসাহিত করতে পারে, তবে আমি মনে করি না যে কোনও ধরণের গ্যারান্টি নেই যে কেবল সূচকটি আবার চালু হবে না [AppointmentAttendee]।
৩. আমি কীভাবে নিশ্চিত করব যে এটি অন্য কোয়েরি / পরিকল্পনায় না ঘটে?
আপনি কেন এই প্রশ্ন জিজ্ঞাসা করছেন তা আমি বুঝতে পেরেছি তবে এটি অত্যন্ত বিস্তৃত। আমার একমাত্র পরামর্শ হ'ল ক্যোয়ারী পরিকল্পনার অস্থিরতার মূল কারণটি আরও ভালভাবে বোঝার চেষ্টা করা, আপনার কাজের চাপের জন্য আপনার সঠিক সূচক তৈরি হয়েছে তা যাচাই করা এবং আপনার কাজের চাপ যত্ন সহকারে পরীক্ষা করা ও নিরীক্ষণ করা। মাইক্রোসফ্টের এসকিউএল সার্ভার ২০১ in-তে নতুন সিই দ্বারা সৃষ্ট ক্যোয়ারী প্ল্যান রিগ্রেশনগুলি মোকাবেলা করার জন্য কিছু সাধারণ পরামর্শ রয়েছে :
কোডটির সর্বশেষ সংস্করণে ক্যোয়ারী প্রসেসর আপগ্রেড করার জন্য প্রস্তাবিত কর্মপ্রবাহটি হ'ল:
ডাটাবেস সামঞ্জস্যতা স্তর পরিবর্তন না করেই এসকিউএল সার্ভার ২০১ 2016 এ একটি ডেটাবেস আপগ্রেড করুন (এটি আগে স্তরে রাখুন)
ডাটাবেসে ক্যোয়ারী স্টোর সক্ষম করুন। ক্যোয়ারী স্টোরটি সক্ষম ও ব্যবহার সম্পর্কে আরও তথ্যের জন্য ক্যোয়ারী স্টোরটি ব্যবহার করে পর্যবেক্ষণ কর্মক্ষমতা দেখুন।
কাজের চাপের প্রতিনিধি ডেটা সংগ্রহ করার জন্য পর্যাপ্ত সময় অপেক্ষা করুন।
ডাটাবেসের সামঞ্জস্যের স্তরটি 130 এ পরিবর্তন করুন
এসকিউএল সার্ভার ম্যানেজমেন্ট স্টুডিও ব্যবহার করে, সামঞ্জস্যতা স্তর পরিবর্তনের পরে নির্দিষ্ট প্রশ্নের উপর পারফরম্যান্স রিগ্রেশন রয়েছে কিনা তা নির্ধারণ করুন
যেসব ক্ষেত্রে রিগ্রেশন রয়েছে সেখানে কোয়েরি স্টোরের পূর্ব পরিকল্পনাটি জোর করে।
যদি এমন কোয়েরি প্ল্যান থাকে যা জোর করে ব্যর্থ হয় বা কর্মক্ষমতা এখনও অপর্যাপ্ত থাকে তবে সামঞ্জস্যতার স্তরটিকে পূর্বের সেটিংয়ে ফিরিয়ে নেওয়া এবং তারপরে মাইক্রোসফ্ট গ্রাহক সমর্থনকে জড়িত করার বিষয়টি বিবেচনা করুন।
আমি বলছি না যে আপনাকে এসকিউএল সার্ভার 2012 এ ডাউনগ্রেড করতে হবে এবং আবার শুরু করতে হবে, তবে বর্ণিত সাধারণ কৌশলটি আপনার পক্ষে কার্যকর হতে পারে।
২. এখন যে পরিকল্পনাটি ভালভাবে কাজ করে তা কি আমার "জোর" করা উচিত?
এটি সম্পূর্ণ আপনার উপর নির্ভর করে। আপনি যদি বিশ্বাস করেন যে আপনার কাছে একটি কোয়েরি পরিকল্পনা রয়েছে যা সমস্ত সম্ভাব্য ইনপুট পরামিতিগুলির জন্য ভাল কাজ করে, ক্যোয়ারী স্টোরের কার্যকারিতা নিয়ে স্বাচ্ছন্দ্যবোধ করে এবং মানসিক শান্তি চায় যা কোয়েরি পরিকল্পনা জোর করে আসে তবে এর জন্য যান it রিগ্রেশনগুলি রয়েছে এমন কোয়েরি পরিকল্পনাগুলি বাধ্য করা মাইক্রোসফ্টের সর্বোপরি এসকিউএল সার্ভার ২০১ to-এ উন্নীত নীতিমালার অংশ।
