একটি ধ্রুব স্ক্যান হয় 0 সেকেন্ড বা 2-3 মিনিট লাগে

Question

নীচের মত একটি কোয়েরি যেমন কোনও সারি ফেরত না দেওয়ার গ্যারান্টিযুক্ত, আমাদের সার্ভারগুলির মধ্যে 0 থেকে 160 সেকেন্ড পর্যন্ত যে কোনও কিছু নেয়:

select col1, col2, col3
from tab1
where 0 = 1

দুই সপ্তাহ আগে, 48 ঘন্টার ব্যবধানে এটি ছয়বার হয়েছিল। গত সপ্তাহে একই ক্যোয়ারীটি ~ 0 সেকেন্ড নিয়েছিল। আমার কাছে আমাদের অ্যাপ্লিকেশনটির এসকিউএলগুলির লগ রয়েছে তবে এখনও কোনও সন্দেহভাজন খুঁজে পাওয়া যায় নি। তদতিরিক্ত, আমি ভেবেছিলাম শীর্ষস্থানীয় 0 / যেখানে 0 = 1 ধরণের কোয়েরি কখনই ডেটা পৃষ্ঠাগুলিতে আঘাত করে না, তাই এটি সারি / পৃষ্ঠা / সারণী-স্তরের ডেটা লকগুলির সাথে প্রতিরোধী হওয়া উচিত? স্কিমার কোনও (পরিচিত) এসকিউএল দ্বারা স্পর্শ করা হয়নি।

যেহেতু সমস্যাটি সামঞ্জস্যপূর্ণ নয় এবং সার্ভারটি খুব ভারী বোঝার মধ্যে রয়েছে আমি এসকিউএল প্রোফাইলার সংযুক্ত করার আগে যা ঘটছে তার পিছনে তত্ত্বটি বুঝতে চাই। এই বিলম্বের সময় অন্যান্য প্রশ্নগুলি সমস্যা ছাড়াই চলে। অ্যাপ্লিকেশনটিতে একটি পরিচিত সমস্যা হ'ল গতিশীলভাবে তৈরি এসকিউএল কোয়েরিগুলির একটি উচ্চ সংখ্যা - 48 ঘন্টা সময়কাল ধরে মোট 850 কে মোট (লগইন) ক্যোয়ারীগুলির প্রায় 200k অনন্য ক্যোয়ারী, এটি কি এই জাতীয় সমস্যার সৃষ্টি করতে পারে?

সার্ভারটি এসকিউএল সার্ভার 2005 স্ট্যান্ডার্ড সংস্করণ, 96 গিগাবাইট র‌্যাম, সান এবং 4 সিপিইউ / 16 কোরে ডিস্ক চালাচ্ছে। ডাটাবেস ফাইল এবং ফাইলগ্রুপগুলি ভালভাবে অনুকূলিত হয়েছে এবং কোনও সমস্যা হওয়া উচিত নয় (তবে আমরা এটি আলাদাভাবে দেখছি)।

যে কোনও পয়েন্টার যেখানে দেখতে হবে তা প্রশংসিত।

সম্পাদনা: নিখুঁত! এক্সিকিউশন প্ল্যান যুক্ত করতে ক্যোয়ারীটি পুনরায় খেলুন এবং এতে 1 মিনিট 35 সেকেন্ড লেগেছিল। এখানে কার্য সম্পাদনের পরিকল্পনা এবং স্ক্রিনশটটি ক্যোয়ারির সময়কাল দেখায়:

সম্পাদনা 2: দ্বিতীয় রানের জন্য পরিসংখ্যানের সময় বিবরণ। এখনই ধারাবাহিকভাবে ধীর বলে মনে হচ্ছে, তাই আমরা প্রোফাইলার এবং পারফিউম সংযুক্ত হব:

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

Comments

আপনি দয়া করে কার্যকর করার পরিকল্পনা অন্তর্ভুক্ত করতে পারেন? মৃত্যুদন্ড কার্যকর হওয়ার আগে ক্যোরি উইন্ডোতে সিটিআরএল + এম।

— ক্রেগ এফ্রেইন

এটি লক সমস্যা হতে পারে? অন্য সেশনগুলির ডিএমএল বিবৃতিগুলি টেবিলে নির্বাচনগুলি ব্লক করে (যা এসকিউএল সার্ভার 2005 এ ডিফল্ট আচরণ)

— a_horse_with_no_name

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

— ইভেন্টহরিজন

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

— ক্রেগ এফ্রেইন

অনেকটা এরকম দেখতে পাওয়া একটি কেস দেখেছি। এটি আপডেটের পরিসংখ্যানকে ট্রিগার করে চলেছে (স্বয়ংক্রিয় আপডেটের পরিসংখ্যান চালু করা হয়েছিল এবং রক্ষণাবেক্ষণের পরিকল্পনাটি নষ্ট হয়ে গিয়েছিল)।

— জোশুয়া

Answer 1

এটি এমন একটি ... WHERE 0 = 1দফা সহ উপস্থিত ISহয় যাতে টেবিলে একটি উদ্দেশ্য ভাগ করে নেওয়া ( ) লক করার জন্য এখনও প্রয়োজনীয়তা থাকবে । আসুন এটি প্রমাণ করুন:

আমি একটি পরীক্ষার টেবিল তৈরি করে শুরু করব:

use TestDb1;
go

create table dbo.MyTestTable1
(
    Id int identity(1, 1) not null,
    SomeInt int not null
);
go

insert into dbo.MyTestTable1 (SomeInt)
values (10), (20), (30), (40), (50);
go

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

use TestDb1;
go

begin tran;
    select
        Id, SomeInt
    from dbo.MyTestTable1 with (tablockx);
--commit tran;

আমি sys.dm_tran_locksডিএমভিকে দেখে একচেটিয়া লকটি যাচাই করতে পারি । তারপরে অন্য একটি সেশনে (নতুন ক্যোয়ারী উইন্ডো) আপনার ক্যোয়ারীটি ঠিক তাই করে:

use TestDb1;
go

select
    Id, SomeInt
from dbo.MyTestTable1
where 0 = 1;

প্রথম নজরে আমি দেখতে পাচ্ছি যে এটি সম্পূর্ণ হচ্ছে না। এদিকে তাকালে sys.dm_exec_requests, আমি দেখতে পাচ্ছি ঠিক কেন এটি ঘটেছে:

select
    r.session_id,
    r.status,
    r.wait_type,
    r.wait_time,
    r.wait_resource,
    r.blocking_session_id
from sys.dm_exec_requests r
cross apply sys.dm_exec_sql_text(r.sql_handle) st
where st.text like '%where 0 = 1%'
and r.session_id <> @@spid;

আমি এখানে দেখতে পাচ্ছি যে আমার ... WHERE 0 = 1ক্যোয়ারীটি ISএই অবজেক্টের জন্য একটি লকের জন্য অপেক্ষা করছে (যা বস্তু_আইডি অনুবাদ করে dbo.MyTestTable1)।

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

আমরা কেবল অনুমান করতে পারি, সুতরাং যখন "দীর্ঘ সময় নিচ্ছে" তখন আপনাকে যা করা দরকার তা হ'ল সেই অনুরোধটি কী করছে যে এটি এত দীর্ঘ সময় নিচ্ছে। যদি এটি কোনও কিছুর অপেক্ষায় থাকে, তবে এটি কী অপেক্ষা করছে তা দেখুন।

Answer 2

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

এটি কোনও সমস্যা হতে পারে কিনা তা দেখতে sys.dm_os_schedulers এবং sys.dm_os_waiting_tasks দেখুন।

Comments

একটি ভাল পরামর্শ, কিন্তু সমস্যাটি সর্বোপরি একটি মূর্খ লক হয়ে শেষ হয়েছিল।

— ইভেন্টহরিজন

আমি সত্যিই নিশ্চিত হইনি, যেহেতু 700 জন কর্মী প্রচুর, তবে এটি চেক করা সহজ ছিল (এবং এইভাবে বাদ দিন)

— সাসচা রামবিউড