পরিসংখ্যান, বাস্তবায়ন পরিকল্পনা এবং 'আরোহী কী সমস্যা' বোঝা

Question

আমি পরিসংখ্যান, বাস্তবায়ন পরিকল্পনা, সঞ্চিত পদ্ধতি কার্যকর করার মধ্যকার সম্পর্ককে (ধারণামূলকভাবে) আরও ভাল করে বোঝার চেষ্টা করছি।

আমি কি এই কথাটি সঠিক করে বলছি যে স্টোরেজ পদ্ধতির কার্যকরকরণ পরিকল্পনা তৈরি করার সময় পরিসংখ্যানগুলি কেবল ব্যবহৃত হয়, এবং সেগুলি প্রকৃত বাস্তবায়নের প্রসঙ্গে ব্যবহার হয় না? অন্য কথায়, যদি এটি সত্য হয়, একবার পরিকল্পনাটি তৈরি হয়ে যায় (এবং ধরে নেওয়া হয় এটি সঠিকভাবে পুনরায় ব্যবহৃত হয়েছে), "আপ টু ডেট" পরিসংখ্যান কতটা গুরুত্বপূর্ণ?

আমি বিশেষত আমার পড়া একটি নিবন্ধ ( পরিসংখ্যান, সারি অনুমান এবং আরোহী তারিখ কলাম ) দ্বারা অনুপ্রাণিত হয়েছিল যা আমাদের ক্লায়েন্টের বেশ কয়েকটি ডাটাবেসের সাথে প্রতিদিনের মুখোমুখি একটির মতো একটি দৃশ্যের বর্ণনা দেয়।

আমাদের একটি বৃহত্তম সারণীতে আমাদের একটি আরোহণের তারিখ / সময় কলাম রয়েছে যা আমরা নির্দিষ্ট সঞ্চিত পদ্ধতি ব্যবহার করে নিয়মিত জিজ্ঞাসা করি।

যখন আপনার একদিনে এক লক্ষাধিক সারি যুক্ত হচ্ছে তখন আপনি কীভাবে মৃত্যুদন্ড কার্যকর করার পরিকল্পনাটি বাড়া থেকে আটকাবেন?

আমরা যদি এই সমস্যাটি মোকাবিলার জন্য ঘন ঘন পরিসংখ্যান আপডেট করছি, তবে এই সঞ্চিত পদ্ধতির প্রশ্নের অনুসন্ধানে বিকল্প (পুনরুদ্ধার) ইঙ্গিতটি ব্যবহার করা কি বোধগম্য হবে?

কোন পরামর্শ বা সুপারিশ প্রশংসা করা হবে।

আপডেট : আমি এসকিউএল সার্ভার 2012 (এসপি 1) ব্যবহার করছি।

Answer 1

আমি কি এই কথাটি সঠিক করে বলছি যে স্টোরেজ পদ্ধতির কার্যকরকরণ পরিকল্পনা তৈরি করার সময় পরিসংখ্যানগুলি কেবল ব্যবহৃত হয়, এবং সেগুলি প্রকৃত বাস্তবায়নের প্রসঙ্গে ব্যবহার হয় না?

না, যা ঘটে তা হ'ল সঞ্চিত পদ্ধতির কার্যকরকরণ পরিকল্পনাটি ক্যাশে করা হয়। পরিকল্পনা ধরে রাখা চালিয়ে যাওয়ার জন্য পর্যাপ্ত উপলব্ধ মেমরি রয়েছে তা ধরে নিলে, নিম্নলিখিতগুলির মধ্যে একটি না ঘটলে এটি পরিবর্তন হবে না ( এসকিউএল সার্ভার ডকুমেন্টেশনে এক্সিকিউশন প্ল্যান ক্যাচিং এবং পুনরায় ব্যবহার থেকে জোর দেওয়া):

• কোনও সারণীতে পরিবর্তন হয়েছে বা কোয়েরি দ্বারা রেফারেন্স হয়েছে (ALTER TABLE and ALTER VIEW)।
• একক পদ্ধতিতে পরিবর্তন করা হয়েছে, যা ক্যাশে (বিকল্প পদ্ধতি) থেকে সেই পদ্ধতির সমস্ত পরিকল্পনা বাদ দেয়।
• এক্সিকিউশন প্ল্যান দ্বারা ব্যবহৃত যে কোনও সূচীতে পরিবর্তন।
• এক্সিকিউশন প্ল্যান দ্বারা ব্যবহৃত পরিসংখ্যান সম্পর্কিত আপডেটগুলি বিবৃতি থেকে যেমন স্পষ্টভাবে উত্পন্ন হয় যেমন আপডেটের পরিসংখ্যান, বা স্বয়ংক্রিয়ভাবে উত্পন্ন হয়।
• এক্সিকিউশন পরিকল্পনা দ্বারা ব্যবহৃত একটি সূচক বাদ দেওয়া ping
• Sp_recompile এ একটি সুস্পষ্ট কল।
• কীগুলিতে বৃহত সংখ্যক পরিবর্তন (INSERT দ্বারা উত্পন্ন বা অন্য ব্যবহারকারীদের বিবৃতিগুলি মুছে ফেলা হয়েছে যা কোয়েরিতে উল্লেখ করা একটি সারণী পরিবর্তন করে)।
• ট্রিগারযুক্ত টেবিলগুলির জন্য, যদি sertedোকানো বা মুছে ফেলা সারণিতে সারিগুলির সংখ্যা উল্লেখযোগ্যভাবে বৃদ্ধি পায় grows
• WITH RECOMPILE বিকল্পটি ব্যবহার করে একটি সঞ্চিত পদ্ধতি কার্যকর করা।

সুতরাং যদি পরিসংখ্যান আপডেট করা হয় তবে ক্যাশেড প্ল্যানটি স্বয়ংক্রিয়ভাবে নতুন পরিসংখ্যানগুলিকে আমলে নেবে এবং পুনরায় সংযুক্ত হয়ে যাবে।

যখন আপনার একদিনে এক লক্ষাধিক সারি যুক্ত হচ্ছে তখন আপনি কীভাবে মৃত্যুদন্ড কার্যকর করার পরিকল্পনাটি বাড়া থেকে আটকাবেন?

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

আমরা যদি এই সমস্যাটি মোকাবিলার জন্য ঘন ঘন পরিসংখ্যান আপডেট করছি, তবে এই সঞ্চিত পদ্ধতির প্রশ্নের অনুসন্ধানে বিকল্প (পুনরুদ্ধার) ইঙ্গিতটি ব্যবহার করা কি বোধগম্য হবে?

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

Comments

RECOMPILEযাইহোক কোনও পরিসংখ্যান আপডেট হতে পারে না।

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

@ মার্টিনস্মিথ সঠিক! এটিকে আরও পরিষ্কার করার জন্য আমি সম্পাদনা করব।

— লোলিডিবিএ

@ নিম্নরূপ ডিবিএ আপনি কি নিম্নলিখিত বিষয়টি উল্লেখ করতে পারেন? dba.stackexchange.com/questions/207475/…

— lukaszwinski

Answer 2

আমি কি এই কথাটি ঠিক করেছিলাম যে পরিসংখ্যানগুলি শুধুমাত্র কার্যকর করার পরিকল্পনা তৈরি করার সময় ব্যবহৃত হয়

না, পুরানো পরিসংখ্যানগুলি প্রভাবিত বিবৃতিটির অনুকূল -সংক্রান্ত পুনঃসংশোধনের কারণ হতে পারে ।

আমাদের নিয়মিত জিজ্ঞাসা করা আমাদের বৃহত্তম সারণিতে আমাদের একটি আরোহণের তারিখ / সময় কলাম রয়েছে

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

• 2389 এবং 2390 পতাকা সন্ধান করুন । এটির প্রয়োজন মূল সমস্যা হিসাবে সমস্যাযুক্ত কলামের সাথে একটি সূচক বিদ্যমান। এটি পার্টিশনযুক্ত টেবিলগুলির সাথে কাজ করে না, এবং কেবলমাত্র এসকিউএল সার্ভার ২০১৪ সালে কার্যকর তবে যদি মূল কার্ডিনালিটির অনুমানক ব্যবহার করা হয়। যদি স্ট্যাটিসেস অবজেক্টটি ব্র্যান্ডেড স্ট্যান্ডার্ড থাকে তবে ট্রেস ফ্ল্যাগ 4139 এরও প্রয়োজন হতে পারে।

• SQL সার্ভার 2014. এ আপগ্রেড করুন নতুন cardinality মূল্নির্ধারক হিস্টোগ্রাম গড় ঘনত্ব তথ্য ব্যবহার করে পরলোক অনুমান করার জন্য যুক্তিবিজ্ঞান অন্তর্ভুক্ত করা হয়েছে। এটি 2389/2390 ট্রেস পতাকা কিছু গুরুত্বপূর্ণ পরিস্থিতিতে তুলনায় কম সঠিক হতে পারে ।

• ট্রেস পতাকা 2371 সহ বড় সারণীর জন্য আরও ঘন ঘন স্বয়ংক্রিয় পরিসংখ্যান আপডেটগুলি সক্ষম করুন । এই ট্রেস পতাকা সহ, 20% + 500 পরিবর্তনের পরে আপডেট করার পরিবর্তে কেবলমাত্র SQRT(1000 * Table rows)পরিবর্তন প্রয়োজন। এটি পূর্বে উল্লিখিতগুলির মতো সমাধানের মতো সম্পূর্ণ নয়, কারণ আপডেটগুলি এখনও প্রায়শই পর্যাপ্ত হতে পারে না।

যদি আপনার সমস্যার উত্স হিস্টোগ্রামের পূর্বনির্ধারিত মানগুলির উপর ভিত্তি করে এত ঘন ঘন পরিকল্পনার সংকলন না হয় তবে প্যারামিটার স্নিগ্ধের ফলে মাঝে মাঝে এইরকম খারাপ পরিকল্পনার ক্যাশিংয়ের প্রভাব সম্পর্কে আরও বিবেচনা করতে পারেন:

• ট্রেস পতাকা 4136 ব্যবহার করে প্যারামিটার স্নিফিং অক্ষম করা হচ্ছে
• OPTIMIZE FOR (@parameter = value)একটি পরিচিত প্রতিনিধি মান জন্য একটি পরিকল্পনা সংকলন ব্যবহার করে
• OPTIMIZE FOR (@parameter UNKNOWN)গড় বিতরণ ব্যবহার করে অনুকূলিত করতে ব্যবহার to
• ব্যবহার OPTIMIZE FOR UNKNOWN(4136 হিসাবে একই, তবে প্রতি কোয়েরি)
• OPTION (RECOMPILE)প্রতিটি সময় সংকলন ব্যবহার করে, নির্দিষ্ট মানটি স্নিগ্ধ করে। রানটাইম মানগুলির সিংহভাগ হিস্টোগ্রামের মধ্যে থাকলে এটি কার্যকর হতে পারে।

প্যারামিটার স্নিফিং, এমবেডিং এবং পুনরায় সংকলনের বিকল্পগুলি সম্পর্কে আরও তথ্যের জন্য এসকিউএলপারফরমেশন.কম এ আমার নিবন্ধটি দেখুন ।