ইউএটি এবং পিআরডি সার্ভারে কার্যকরকরণ পরিকল্পনার পার্থক্য


39

আমি বুঝতে চাই যে কেন ইউএটি (3 সেকেন্ডে রান) বনাম পিআরডি (23 সেকেন্ডে চালানো) তে একই ক্যোয়ারির প্রয়োগে এত বিশাল পার্থক্য থাকবে?

ইউএটি এবং পিআরডি দু'জনেরই সঠিক ডেটা এবং সূচী রয়েছে।

প্রশ্ন:

set statistics io on;
set statistics time on;

SELECT CONF_NO,
       'DE',
       'Duplicate Email Address ''' + RTRIM(EMAIL_ADDRESS) + ''' in Maintenance',
       CONF_TARGET_NO
FROM   CONF_TARGET ct
WHERE  CONF_NO = 161
       AND LEFT(INTERNET_USER_ID, 6) != 'ICONF-'
       AND ( ( REGISTRATION_TYPE = 'I'
               AND (SELECT COUNT(1)
                    FROM   PORTFOLIO
                    WHERE  EMAIL_ADDRESS = ct.EMAIL_ADDRESS
                           AND DEACTIVATED_YN = 'N') > 1 )
              OR ( REGISTRATION_TYPE = 'K'
                   AND (SELECT COUNT(1)
                        FROM   CAPITAL_MARKET
                        WHERE  EMAIL_ADDRESS = ct.EMAIL_ADDRESS
                               AND DEACTIVATED_YN = 'N') > 1 ) ) 

ইউএটি চালু:

SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.
SQL Server parse and compile time: 
   CPU time = 11 ms, elapsed time = 11 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

(3 row(s) affected)
Table 'Worktable'. Scan count 256, logical reads 1304616, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'PORTFOLIO'. Scan count 1, logical reads 84761, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CAPITAL_MARKET'. Scan count 256, logical reads 9472, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CONF_TARGET'. Scan count 1, logical reads 100, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row(s) affected)

 SQL Server Execution Times:
   CPU time = 2418 ms,  elapsed time = 2442 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

এখানে চিত্র বর্ণনা লিখুন

পিআরডি-তে:

SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

(3 row(s) affected)
Table 'PORTFOLIO'. Scan count 256, logical reads 21698816, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CAPITAL_MARKET'. Scan count 256, logical reads 9472, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CONF_TARGET'. Scan count 1, logical reads 100, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row(s) affected)

 SQL Server Execution Times:
   CPU time = 23937 ms,  elapsed time = 23935 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

এখানে চিত্র বর্ণনা লিখুন

নোট করুন যে পিআরডি-তে কোয়েরিটি একটি অনুপস্থিত সূচকের পরামর্শ দেয় এবং এটি যেমন আমি পরীক্ষা করেছি ততটাই উপকারী তবে এটি আলোচনার বিষয় নয়।

আমি কেবল এটি বুঝতে চাই: ইউএটি অন - এসকিএল সার্ভার কেন একটি কর্মী টেবিল তৈরি করে এবং পিআরডি-তে এটি তৈরি করে না? এটি ইউএডি-তে একটি টেবিল স্পুল তৈরি করে, পিআরডিতে নয়। এছাড়াও, ইউএটি বনাম পিআরডি-তে মৃত্যুদন্ড কার্যকর করার সময় এত আলাদা কেন?

বিঃদ্রঃ :

আমি উভয় সার্ভারে এসকিএল সার্ভার 2008 আর 2 আরটিএম চালাচ্ছি (খুব শীঘ্রই সর্বশেষ এসপি সহ প্যাচ করতে যাচ্ছি)।

ইউএটি: সর্বাধিক মেমরি 8 জিবি। ম্যাক্সডপ, প্রসেসরের অ্যাফিনিটি এবং সর্বাধিক কর্মী থ্রেড 0 হয়।

Logical to Physical Processor Map:
*-------  Physical Processor 0
-*------  Physical Processor 1
--*-----  Physical Processor 2
---*----  Physical Processor 3
----*---  Physical Processor 4
-----*--  Physical Processor 5
------*-  Physical Processor 6
-------*  Physical Processor 7

Logical Processor to Socket Map:
****----  Socket 0
----****  Socket 1

Logical Processor to NUMA Node Map:
********  NUMA Node 0

প্রোড: সর্বোচ্চ মেমরি 60 জিবি GB ম্যাক্সডপ, প্রসেসরের অ্যাফিনিটি এবং সর্বাধিক কর্মী থ্রেড 0 হয়।

Logical to Physical Processor Map:
**--------------  Physical Processor 0 (Hyperthreaded)
--**------------  Physical Processor 1 (Hyperthreaded)
----**----------  Physical Processor 2 (Hyperthreaded)
------**--------  Physical Processor 3 (Hyperthreaded)
--------**------  Physical Processor 4 (Hyperthreaded)
----------**----  Physical Processor 5 (Hyperthreaded)
------------**--  Physical Processor 6 (Hyperthreaded)
--------------**  Physical Processor 7 (Hyperthreaded)

Logical Processor to Socket Map:
********--------  Socket 0
--------********  Socket 1

Logical Processor to NUMA Node Map:
********--------  NUMA Node 0
--------********  NUMA Node 1

হালনাগাদ :

ইউএটি এক্সিকিউশন প্ল্যান এক্সএমএল:

http://pastebin.com/z0PWvw8m

প্রড এক্সিকিউশন প্ল্যান এক্সএমএল:

http://pastebin.com/GWTY16YY

ইউএএটি এক্সিকিউশন প্ল্যান এক্সএমএল - প্ল্যান উত্সাহিত পিওআরডি সহ:

http://pastebin.com/74u3Ntr0

সার্ভার কনফিগারেশন:

প্রোড: পাওয়ারজেড আর 720xd - ইনটেল (আর) জিয়ন (আর) সিপিইউ E5-2637 ভি 2 @ 3.50GHz।

ইউএএটি: পাওয়ারএজ 2950 - ইন্টেল (আর) জিয়ন (আর) সিপিইউ এক্স5460 @ 3.16GHz

আমি উত্তর.সেক্ল্পার পারফরম্যান্স ডটকম পোস্ট করেছি


হালনাগাদ :

পরামর্শের জন্য @ সোয়াশেককে ধন্যবাদ

পিআরডি-তে সর্বোচ্চ মেমরিটি 60 গিগাবাইট থেকে 7680 এমবিতে পরিবর্তন করা, আমি পিআরডিতে একই পরিকল্পনা উত্পন্ন করতে সক্ষম। ক্যোয়ারীটি ইউএটি হিসাবে একই সময়ে সম্পন্ন হয়।

এখন আমার বুঝতে হবে - কেন? এছাড়াও, এর মাধ্যমে, আমি পুরানো সার্ভারটি প্রতিস্থাপনের জন্য এই দৈত্য সার্ভারকে ন্যায়সঙ্গত করতে সক্ষম হবো না!

উত্তর:


43

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

ওয়ার্কস্পেস মেমরি

বিভিন্ন ধরণের এবং হ্যাশগুলির মতো মেমরি গ্রাসকারী পুনরুদ্ধারযুক্ত পরিকল্পনাগুলির জন্য, বাফার পুলের আকার (অন্যান্য জিনিসগুলির মধ্যে) রানটাইমের সময় ক্যোয়ারীতে সর্বাধিক পরিমাণ মেমরি অনুদানের উপলব্ধ থাকতে পারে তা নির্ধারণ করে।

এসকিউএল সার্ভারে 2012 (সমস্ত সংস্করণ) এই সংখ্যাটি কোয়েরি পরিকল্পনার মূল নোডে, Optimizer Hardware Dependenciesবিভাগে উল্লিখিত হয়েছে Estimated Available Memory Grant। 2012 এর আগের সংস্করণগুলি এই পরিকল্পনার শো পরিকল্পনায় রিপোর্ট করে না।

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

কর্মক্ষেত্রের মেমরি অনুদান আপনার ক্ষেত্রে কোনও ফ্যাক্টর নয়, তবে এটি সম্পর্কে জেনে রাখা মূল্যবান।

তথ্য এক্সেস

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

প্রশ্নটিতে প্রদর্শিত ক্যোয়ারী পরিকল্পনাগুলিতে ক্লাস্টারড ইনডেক্স স্ক্যানগুলি বারবার অ্যাক্সেসের একটি উদাহরণ; নেস্টেড লুপস আধা জয়েন্টের প্রতিটি পুনরাবৃত্তির জন্য স্ক্যানগুলি রিওয়াউন্ড (পুনরাবৃত্ত, পারস্পরিক সম্পর্কের কোনও পরিবর্তন ছাড়াই) করা হয়। আধা অংশের বাইরের ইনপুটটি 28.7874 সারি অনুমান করে এবং এই স্ক্যানগুলির জন্য ক্যোয়ারী প্ল্যান বৈশিষ্ট্যগুলি ফলাফল হিসাবে 27.7874 এ অনুমানিত রিওয়াইন্ডগুলি দেখায়।

আবার, SQL সার্ভার 2012 সালে শুধুমাত্র পরিকল্পনার মূল পুনরুক্তিকারীর সংখ্যা দেখায় Estimated Pages Cachedমধ্যে Optimizer Hardware Dependenciesঅধ্যায়। এই সংখ্যাটি ব্যয়বহুল অ্যালগরিদমের একটি ইনপুট প্রতিবেদন করে যা ক্যাশে থেকে বারবার পৃষ্ঠার অ্যাক্সেসের সুযোগের জন্য অ্যাকাউন্ট হিসাবে দেখায়।

এর প্রভাবটি হ'ল উচ্চতর কনফিগার করা সর্বাধিক বাফার পুল আকারের সাথে একটি ইনস্টলেশন স্ক্যানগুলির (বা সিক্স) ব্যয় হ্রাস করতে পারে যা একটি ছোট সর্বাধিক বাফার পুল আকারের সাথে ইনস্টলেশনের চেয়ে একই পৃষ্ঠাগুলিকে একাধিকবার পড়বে।

সাধারণ পরিকল্পনায়, রিবাউন্ড স্ক্যানের ব্যয় হ্রাস (estimated number of executions) * (estimated CPU + estimated I/O)আনুমানিক অপারেটরের ব্যয়ের সাথে তুলনা করে দেখা যায় , যা কম হবে। অর্ধ যোগদান এবং ইউনিয়নের প্রভাবের কারণে উদাহরণ পরিকল্পনাগুলিতে গণনা আরও জটিল।

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

পরিকল্পনা পছন্দ

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

এই নির্দিষ্ট ক্ষেত্রে আরও উল্লেখযোগ্য বিষয় হল, অপ্টিমাইজারের পরিকল্পনার পছন্দগুলি যাইহোক ভুল সংখ্যার ভিত্তিতে। ক্লাস্টারড ইনডেক্স সিক থেকে প্রাপ্ত সারিগুলির আনুমানিক সংখ্যা ২৮.7878 whereas৪, যেখানে রানটাইমের সময় ২৫। টি সারি মুখোমুখি হয় - প্রায় এক মাত্রার ক্রম। অপ্টিমাইজারের সেই 28.7874 সারিগুলির মধ্যে মূল্যগুলির প্রত্যাশিত বিতরণ সম্পর্কে আমরা সরাসরি তথ্য দেখতে পারি না, তবে এটি খুব মারাত্মকভাবে ভুল হওয়ারও সম্ভাবনা রয়েছে is

যখন অনুমানগুলি এটি ভুল হয় তবে পরিকল্পনার নির্বাচন এবং রানটাইম পারফরম্যান্স মূলত সুযোগের চেয়ে ভাল হয় না। ইনডেক্স স্পুলের পরিকল্পনাটি স্ক্যানটির পুনরাবৃত্তি করার চেয়ে আরও ভাল সম্পাদন করার জন্য ঘটেছে , তবে বাফার পুলের আকার বাড়ানো অস্বাভাবিকতার কারণ বলে মনে করা একেবারেই ভুল।

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

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


18

পল হোয়াইট একটি চমকপ্রদ পদ্ধতিতে পিছনের কারণটি ব্যাখ্যা করেছেন - যখন আরও স্মৃতি সহ সার্ভারগুলিতে চালিত হয় তখন স্কুয়েল সার্ভার আচরণ behavior

এছাড়াও, ইস্যুটি প্রথমে চিহ্নিত করার জন্য @ সোয়াশেককে একটি বিশাল ধন্যবাদ ।

মাইক্রোসফ্ট দিয়ে একটি কেস খুললেন এবং নীচে যা প্রস্তাবিত হয়েছিল।

স্টার্টআপ প্যারামিটার হিসাবে ট্রেস পতাকা T2335 ব্যবহার করে সমস্যার সমাধান করা হয়েছে is

KB2413549 - বিশাল পরিমাণ মেমরি ব্যবহার একটি অদক্ষ পরিকল্পনা হতে পারে SQL সার্ভার মধ্যে আরো বিস্তারিত জানার এটা বর্ণনা করা হয়েছে।

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


13

সর্বাধিক মেমরি সেটিংস এবং হাইপারথ্রেডিং উভয়ই পরিকল্পনার পছন্দকে প্রভাবিত করতে পারে।

অতিরিক্তভাবে, আমি লক্ষ্য করেছি যে আপনার "সেট" বিকল্পগুলি প্রতিটি পরিবেশে আলাদা:

ইউএটি-তে স্টেটমেন্টসেটপশনস:

ANSI_NULLS="true" 
ANSI_PADDING="true" 
ANSI_WARNINGS="true" 
ARITHABORT="true" 
CONCAT_NULL_YIELDS_NULL="true" 
NUMERIC_ROUNDABORT="false" 
QUOTED_IDENTIFIER="true" 

প্রোডাক্টের উপর স্টেটমেন্টসেটপশনস:

ANSI_NULLS="true" 
ANSI_PADDING="true" 
ANSI_WARNINGS="true" 
ARITHABORT="false" 
CONCAT_NULL_YIELDS_NULL="true"
NUMERIC_ROUNDABORT="false"
QUOTED_IDENTIFIER="true" 

এসকিউএল এসইটি বিকল্পগুলির উপর ভিত্তি করে বিভিন্ন পরিকল্পনা তৈরি করতে পারে। আপনি বিভিন্ন এসএসএমএস সেশন থেকে, বা অ্যাপ্লিকেশন থেকে বিভিন্ন মৃত্যুদণ্ড কার্যকর করা থেকে যদি পরিকল্পনাটি ক্যাপচার করে থাকেন তবে এটি প্রায়শই ঘটে।

নিশ্চিত করুন যে বিকাশকারীরা ধারাবাহিক সংযোগের স্ট্রিং ব্যবহার করছে।


2
আপনি উল্লেখ করে ঠিক বলেছেন যে ম্যাক্স মেমোরি এবং হাইপারথ্রেডিং পরিকল্পনার ক্যাশেগুলিকে প্রভাবিত করতে পারে তবে আমি কী এবং কেন এ ঘটনা ঘটেছে তা সম্পর্কে বিস্তারিত জানতে চাই। আপনার উত্তর প্রশংসা করুন।
কিন শাহ

2
হিসাবে আমান্ডা বললেন, যদি সেট অপশন ARITHABORT পার্থক্য হতে পারে আপনি তাকান উচিত dba.stackexchange.com/questions/9840/...
ওআরএ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.