সূচকগুলি কি স্মৃতি গ্রহণ করে?

আমি কেবল এসকিউএল সার্ভারে মেমরির ব্যবহার সম্পর্কে শিখতে শুরু করছি। এসকিউএল সার্ভার ২০০৮ আর 2 "ঘোস্ট মেমোরি" প্রশ্নের উত্তরে কোয়েরিটি ব্যবহার করার সময় ? , আমি আবিষ্কার করেছি যে একটি একক ডাটাবেস বাফার পুলে স্থান সিংহের অংশ গ্রহণ করছে। আরও তাকাতে, ব্যবহার করে sys.allocation_unitsএবং sys.indexes, আমি নিশ্চিত করেছি যে এটি সম্ভবত ডাটাবেসে সূচকের ভারী ব্যবহারের কারণে ঘটেছে। বেশিরভাগ সূচি ক্লাস্টারযুক্ত।

আরেকটি ডাটাবেস বিকাশকারী বিশ্বাস করেন যে সার্ভারে আমাদের মেমরির সমস্যা রয়েছে - যে অনুসন্ধানগুলি দীর্ঘস্থায়ী হতে শুরু করে কারণ কোনও স্মৃতি উপলব্ধ নেই।

এখানে আমার প্রশ্নটি হ'ল - এই সূচকগুলির ব্যবহার এবং বাফার পুলে তাদের অস্তিত্ব কী অন্যান্য প্রক্রিয়াগুলির জন্য উপলব্ধ স্মৃতি থেকে দূরে সরিয়ে দেয়?

sql-server sql-server-2008

— JHFB
সূত্র

"Another database developer believes we are having memory issues on the server"- কিসের ভিত্তিতে? সার্ভারের কতটা র‌্যাম রয়েছে, উদাহরণ মেমরি সেটিংস কী এবং পদ্ধতি ক্যাশে কতটা মেমরি গ্রাস করছে?

— জন সেগেল

বর্ধিত ক্যোয়ারী বারের উপর ভিত্তি করে এবং টাস্ক ম্যানেজারের দিকে তাকানো - যা আমার গবেষণাটি নির্দেশ করেছে এটি একটি "নোংরা, নোংরা মিথ্যাবাদী" (ধন্যবাদ ব্রেন্ট ওজার - ব্রেক্টজার / অর্চিভ / ২০১ive / ১৯ / ১৯ )। আমার মনে হতে পারে কোনও মেমোরি সমস্যা নেই - আমি এই মন্তব্য এবং উত্তরগুলিতে প্রদত্ত সমস্ত পরামর্শ অনুসরণ করছি!

— জেএইচএফবি

যেহেতু আমরা এখানে 8 টি বল গড়িয়ে যাচ্ছি, আমার মনে হয়

— ক্যোরিগুলি ধীরগতিতে চলেছে

উত্তর:

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

আপনার মেমরির সমস্যাগুলি সম্ভবত আপনার টেবিলগুলিতে সূচী না থেকে । স্মৃতির সমস্যাগুলিতে ডুব দিন, সমস্যাগুলি আসলে কী? আপনি কি কম জীবনকাল প্রত্যাশা করছেন ? আপনার স্মৃতিটি সার্ভারে কনফিগার করা কীভাবে? সর্বাধিক সার্ভারের মেমরিটি কি বাফার পুলের আকারকে কম সীমাবদ্ধ করে?

আপনার ডেটা ক্যাশে সূচক পৃষ্ঠাগুলির একটি বিচ্ছেদ পেতে, আপনি নীচের ক্যোয়ারী চালাতে পারেন:

select
    count(*) as total_page_count,
    count(*) * 8 as total_consumption_kb,
    sum(row_count) as total_row_count
from sys.dm_os_buffer_descriptors
where page_type = 'INDEX_PAGE'
group by page_type

ডাটাবেসের মাধ্যমে এই পরিসংখ্যানগুলি পেতে:

select
    db_name(database_id) as database_name,
    count(*) as total_page_count,
    count(*) * 8 as total_consumption_kb,
    sum(row_count) as total_row_count
from sys.dm_os_buffer_descriptors
where page_type = 'INDEX_PAGE'
group by database_id
order by total_consumption_kb desc

— টমাস স্ট্রিংগার
সূত্র

ডিসেন্ট (?) পৃষ্ঠার আয়ু - 4234. আমাকে বাফার ক্যাশে হিট অনুপাত নিয়ে গবেষণা করতে হবে এবং অন্যান্য অংশগুলি সন্ধান করতে হবে।

— জেএইচএফবি

পিএলই মোটেই মেমরির চাপ দেখাচ্ছে না। থাম্বের নিয়ম হিসাবে 1000 এরও বেশি কিছু (অবশ্যই, এটি সর্বদা "এটি নির্ভর করে") গ্রহণযোগ্য।

— টমাস স্ট্রিংগার

বাফার ক্যাশে হিট অনুপাত খুব বিভ্রান্তিকর, বা বাইরে এবং অকেজো হতে পারে। দেখুন বাফার ক্যাশে হিট অনুপাত: গ্রেট SQL সার্ভার বিতর্ক @JonathanKehayias দ্বারা।

— মার্ক স্টোরী-স্মিথ

@ মার্কস্টোরি-স্মিথ উল্লেখ করেছেন, পয়েন্টারের জন্য ধন্যবাদ!

— থমাস স্ট্রিংগার

@ জেএফএফবি আসুন একটি পদক্ষেপ পিছনে নেওয়া যাক। কীসের ফলে আপনি মনে করেন যে আপনি স্মৃতিচারণ করছেন?

— থমাস স্ট্রিংগার

সূচকগুলি হ্যাঁ, বাফার পুলের জায়গা গ্রাস করে। এটি আপনার ইন্ডেক্সিং কৌশলটির সাথে যত্ন নেওয়ার এবং নকলকে হ্রাস করার আরও একটি কারণ।

আমি নিশ্চিত করেছি যে এটি সম্ভবত ডেটাবেজে সূচকের ভারী ব্যবহারের কারণে ঘটে। বেশিরভাগ সূচি ক্লাস্টারযুক্ত।

মনে রাখবেন যে একটি ক্লাস্টার্ড সূচকটি টেবিল । একটি হিপ (যা সাধারণত অযাচিত হয়) এর উপরে এবং তার উপরে ক্লাস্টারড ইনডেক্সের জন্য বিদ্যমান কেবলমাত্র ওভারহেড হ'ল এই টেবিলের জন্য সমস্ত নন-ক্লাস্টারযুক্ত সূচীতে ক্লাস্টার কী'র অন্তর্ভুক্ত। এই কারণেই সংকীর্ণ ক্লাস্টার কী পছন্দ করা হয়।

ক্লাস্টার কী পছন্দগুলিতে কিম্বারলে ট্রিপসের নিবন্ধগুলি এর জন্য দুর্দান্ত রেফারেন্স।

— মার্ক স্টোরি-স্মিথ
সূত্র

+1 যে মিস ট্র্রিপের নিবন্ধগুলি ক্লাস্টারিং কীগুলির জন্য ইপিক ...

— ফ্যাব্রিকিও আরাউজো