এসকিউএল সংকলনগুলি এসকিউএল সার্ভারের কার্য সম্পাদনকে কতটা খারাপভাবে প্রভাবিত করে?


20

আমি একটি এসকিউএল সার্ভার 2005 এর একটি উদাহরণ লিখছি এবং আমি পারফমনের SQLServer:SQL Statistics - SQL Compilations/secমেট্রিকের মাধ্যমে দেখতে পাচ্ছি যে গড় প্রায় 170 বা তার বেশি।

আমি এসকিউএল প্রোফাইলারকে বেতার দিয়েছি এবং এসপি: সংকলন বা এসকিউএল: ইভেন্টগুলি সংকলন করেছিলাম। স্পষ্টত তাদের অস্তিত্ব নেই। আমি খুঁজে পেয়েছি Stored Procedure/SP:Recompileএবং TSQL/SQL:StmtRecompileঘটনা। আমি প্রোফাইলারটিতে যে পরিমাণ ডেটা দেখছি তা বোঝায় যে এগুলি দেখার মতো ভুল ঘটনা, যদিও আমি নিশ্চিত নই।

আমার প্রশ্ন তাই। এর যে কোনও একটির উত্তর দুর্দান্ত great

  1. এসকিউএল সার্ভারে ঠিক কী সংকলন করছে তা আমি কীভাবে দেখতে পারি?
  2. আমি কি ভুল মেট্রিকগুলি দেখার জন্য বেছে নিয়েছি? পারফমন বা এসকিউএল প্রোফাইলার হয়?
  3. শুভেচ্ছার সঙ্গে Stored Procedure/SP:Recompileএবং TSQL/SQL:StmtRecompileএসকিউএল প্রোফাইলার ঘটনা ... তারা স্থিতিকাল মেট্রিক অন্তর্ভুক্ত করবেন না। সিস্টেমে এই ইভেন্টগুলির প্রভাব দেখার জন্য যদি তারা কোনও উপায় না দেয় তবে আমি কীভাবে সিস্টেমে এই ইভেন্টগুলির প্রভাবটি নির্ধারণ করতে পারি।

উত্তর:


33

এসকিউএল সংকলন / সেকেন্ড একটি ভাল মেট্রিক, তবে কেবলমাত্র ব্যাচ অনুরোধ / সেকেন্ডের সাথে মিলিত হলে । নিজেই, প্রতি সেকেন্ডে সংকলনগুলি আপনাকে সত্যি বেশি কিছু বলে না।

আপনি 170 দেখতে পাচ্ছেন sec তবে যদি আপনার ব্যাচের রেকর্ড প্রতি সেকেন্ডটি প্রায় 5000 পরিমাপ করে তবে সেকেন্ডে 170 সংকলন মোটেও খারাপ নয়। এটি থাম্বের একটি সাধারণ নিয়ম যা সংকলন / সেকেন্ড মোট ব্যাচের অনুরোধ / সেকেন্ডের চেয়ে 10% বা তার চেয়ে কম হওয়া উচিত ।

আপনি যদি সত্যই ক্যাশে হচ্ছেন তা খতিয়ে দেখতে চান, তবে উপযুক্ত ডিএমভিগুলি ব্যবহার করে নিম্নলিখিত কোয়েরিটি চালান:

select
    db_name(st.dbid) as database_name,
    cp.bucketid,
    cp.usecounts,
    cp.size_in_bytes,
    cp.objtype,
    st.text
from sys.dm_exec_cached_plans cp
cross apply sys.dm_exec_sql_text(cp.plan_handle) st

সমস্ত একক ব্যবহারের পরিকল্পনা পেতে (একটি গণনা):

;with PlanCacheCte as 
(
    select
        db_name(st.dbid) as database_name,
        cp.bucketid,
        cp.usecounts,
        cp.size_in_bytes,
        cp.objtype,
        st.text
    from sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_sql_text(cp.plan_handle) st
)
select count(*)
from PlanCacheCte
where usecounts = 1

সমস্ত ক্যাশেড পরিকল্পনার তুলনায় আপনি কতগুলি একক-ব্যবহারের গণনা পরিকল্পনার অনুপাত পেতে:

declare @single_use_counts int, @multi_use_counts int

;with PlanCacheCte as 
(
    select
        db_name(st.dbid) as database_name,
        cp.bucketid,
        cp.usecounts,
        cp.size_in_bytes,
        cp.objtype,
        st.text
    from sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_sql_text(cp.plan_handle) st
    where cp.cacheobjtype = 'Compiled Plan'
)
select @single_use_counts = count(*)
from PlanCacheCte
where usecounts = 1

;with PlanCacheCte as 
(
    select
        db_name(st.dbid) as database_name,
        cp.bucketid,
        cp.usecounts,
        cp.size_in_bytes,
        cp.objtype,
        st.text
    from sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_sql_text(cp.plan_handle) st
    where cp.cacheobjtype = 'Compiled Plan'
)
select @multi_use_counts = count(*)
from PlanCacheCte
where usecounts > 1

select
    @single_use_counts as single_use_counts,
    @multi_use_counts as multi_use_counts,
    @single_use_counts * 1.0 / (@single_use_counts + @multi_use_counts) * 100
        as percent_single_use_counts

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


9

তিনটি প্রাসঙ্গিক কাউন্টার রয়েছে যা পারফমন (বা অন্য কোনও তৃতীয় পক্ষের সমাধান) ব্যবহার করে রেকর্ড করা উচিত। মূল বিষয়টি হ'ল এই পরিসংখ্যানটি কোনওভাবে রেকর্ড করা

  • এসকিউএল পরিসংখ্যান \ ব্যাচের অনুরোধ / সেকেন্ড
  • এসকিউএল পরিসংখ্যান \ এসকিউএল সংকলন / সেকেন্ড
  • এসকিউএল পরিসংখ্যান \ এসকিউএল পুনরায় সংকলন / সেকেন্ড

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

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

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

SELECT TOP 50
    qs.plan_generation_num,
    qs.execution_count,
    qs.statement_start_offset,
    qs.statement_end_offset,
    st.text
    FROM sys.dm_exec_query_stats qs
    CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
    WHERE qs.plan_generation_num > 1
    ORDER BY qs.plan_generation_num DESC

আপনি যদি সিপিইউ ব্যবহারের জন্য পরিসংখ্যানগুলিও রেকর্ড করেন তবে এটি ঠিক কতটা ব্যথা করে এবং আপনার ফিক্সগুলি কতটা সহায়তা করে তা খুঁজে বের করার জন্য সমস্ত পরিসংখ্যান একত্রে সম্পর্কযুক্ত হতে পারে। অনুশীলনে, আমি দেখতে পেয়েছি যে মূল স্প্রোকের জন্য কেবলমাত্র একটি খারাপ কুয়ের পরিকল্পনা কৌশলও একটি সার্ভারকে তার হাঁটুতে আনতে পারে; স্পষ্টতই ওয়াইএমএমভি।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.