আমাদের কাছে একটি দুর্দান্ত ডাটাবেস, প্রায় 1 টিবি, একটি শক্তিশালী সার্ভারে এসকিউএল সার্ভার 2014 চলছে। সবকিছু কয়েক বছর ধরে ভাল কাজ করে। প্রায় 2 সপ্তাহ আগে, আমরা একটি সম্পূর্ণ রক্ষণাবেক্ষণ করেছি, যার মধ্যে রয়েছে: সমস্ত সফ্টওয়্যার আপডেট ইনস্টল করুন; সমস্ত সূচি এবং কমপ্যাক্ট ডিবি ফাইল পুনর্নির্মাণ করুন। তবে, আমরা আশা করিনি যে নির্দিষ্ট পর্যায়ে যখন ডিবি'র সিপিইউ ব্যবহারের প্রকৃত চাপ একই ছিল তখন 100% এরও বেশি বেড়ে 150% হয় to
অনেক সমস্যার সমাধানের পরেও আমরা এটিকে একটি খুব সাধারণ প্রশ্নে সংকীর্ণ করেছি, তবে আমরা কোনও সমাধান খুঁজে পাইনি। ক্যোয়ারী অত্যন্ত সহজ:
select top 1 EventID from EventLog with (nolock) order by EventIDএটি সর্বদা প্রায় 1.5 সেকেন্ড সময় নেয়! তবে, "ডেস্ক" এর সাথে একটি অনুরূপ ক্যোয়ারী সর্বদা প্রায় 0 এমএস লাগে:
select top 1 EventID from EventLog with (nolock) order by EventID descপিটিবেলে প্রায় 500 মিলিয়ন সারি রয়েছে; বিগিন্ট (আইডেন্টিটি কলাম) এর ডেটা টাইপ সহ EventIDপ্রাথমিক ক্লাস্টারড ইনডেক্স কলাম (অর্ডার করা ASC)। শীর্ষে টেবিলের মধ্যে একাধিক থ্রেড ডেটা tingোকানো রয়েছে (বৃহত্তর ইভেন্টআইডি) এবং নীচে থেকে 1 টি থ্রেড মুছে ফেলা হবে (ছোট ইভেন্টআইডি)।
এসএমএসে, আমরা যাচাই করেছিলাম যে দুটি ক্যোয়ারী সর্বদা একই কার্যকরকরণ পরিকল্পনা ব্যবহার করে:
ক্লাস্টারড ইনডেক্স স্ক্যান;
আনুমানিক এবং আসল সারি সংখ্যা উভয়ই 1;
নির্ধারিত এবং মৃত্যুদন্ড কার্যকর করার জন্য আসল সংখ্যা উভয়ই 1;
আনুমানিক I / O খরচ 8500 (মনে হয় বেশি)
যদি ধারাবাহিকভাবে চালানো হয় তবে উভয়ের জন্য ক্যোয়ারি ব্যয় একই 50%।
আমি সূচকের পরিসংখ্যান আপডেট করেছি with fullscan, সমস্যাটি অব্যাহত রয়েছে; আমি আবার সূচকটি পুনর্নির্মাণ করেছি, এবং মনে হচ্ছে সমস্যাটি অর্ধ দিনের জন্য চলে গেছে তবে ফিরে এসেছিল।
আমি এর সাথে আইও পরিসংখ্যান চালু করেছি:
set statistics io onতারপরে ক্রমাগতভাবে দুটি প্রশ্নের দৌড়ে এবং নিম্নলিখিত তথ্যটি খুঁজে পেয়েছেন:
(প্রথম প্রশ্নের জন্য, ধীর একটি)
টেবিল 'পিটিবেল'। স্ক্যান কাউন্ট 1, লজিকাল 404070 রিডিজ, ফিজিকাল রিড 0, রিড-ফরোয়ার্ড 0, লব লজিকাল রিড 0, লব ফিজিকাল 0, লব রিড-ফরোডড 0
(দ্বিতীয় প্রশ্নের জন্য, দ্রুত একটি)
টেবিল 'পিটিবেল'। স্ক্যান কাউন্ট 1, লজিকাল রিডস 4, ফিজিকাল রিড 0, রিড-ফরোয়ার্ড রিড 0, লব লজিকাল রিড 0, লব ফিজিকাল 0, লব রিড-ফরোয়ার্ড 0
লজিকাল রিডের বিশাল পার্থক্যটি নোট করুন। সূচকটি উভয় ক্ষেত্রেই ব্যবহৃত হয়।
সূচী বিভাজন কিছুটা ব্যাখ্যা করতে পারে, তবে আমি বিশ্বাস করি এর প্রভাব খুব কম; এবং সমস্যা আগে কখনও ঘটেনি। আরেকটি প্রমাণ হ'ল যদি আমি এই জাতীয় একটি কোয়েরি চালাই:
select * from EventLog with (nolock) where EventID=xxxx এমনকি যদি আমি টেবিলের সবচেয়ে ছোট ইভেন্টআইডিএক্সএক্সএক্সএক্সএক্স সেট করি তবে ক্যোরিটি সর্বদা দ্রুত বজ্র হয়।
আমরা চেক করেছি এবং লকিং / ব্লক করার কোনও সমস্যা নেই।
দ্রষ্টব্য: আমি কেবল উপরের বিষয়টি সহজ করার চেষ্টা করেছি। "পিটিবেল" আসলে "ইভেন্টলগ"; PIDহয়EventID ।
আমি NOLOCKইঙ্গিত ছাড়াই একই ফলাফল পরীক্ষা পেয়েছি ।
কেউ সাহায্য করতে পারেন?
এক্সএমএলে আরও বিশদ ক্যোয়ারী কার্যকর করার পরিকল্পনা নিম্নরূপ:
https://www.brentozar.com/pastetheplan/?id=SJ3eiVnob
https://www.brentozar.com/pastetheplan/?id=r1rOjVhoZ
আমি মনে করি না যে তৈরি টেবিলের বিবৃতি প্রদান করা গুরুত্বপূর্ণ। এটি একটি পুরানো ডাটাবেস এবং রক্ষণাবেক্ষণ পর্যন্ত দীর্ঘকাল ধরে পুরোপুরি ঠিকঠাক চলছে। আমরা আমাদের অনেক গবেষণা করেছি এবং এটিকে আমার প্রশ্নের প্রদত্ত তথ্যে সংকুচিত করেছি।
EventIDপ্রাথমিক কী হিসাবে কলামটি সারণীটি সাধারণত তৈরি করা হয়েছিল , যা identityপ্রকারের কলাম bigint। এই মুহুর্তে, আমি অনুমান করি যে সমস্যাটি সূচক বিভাজন নিয়ে। সূচী পুনর্নির্মাণের ঠিক পরে, সমস্যাটি অর্ধদিনের জন্য চলে গেছে বলে মনে হচ্ছে; তবে কেন এত তাড়াতাড়ি ফিরে এলো ...?
