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


15

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

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

সম্পাদনা করুন: আরও গবেষণা এই উত্তর না দেওয়া প্রশ্নকে দেখায় , যা নিবিড়ভাবে সম্পর্কিত বলে মনে হচ্ছে এবং ম্যানুয়াল রক্ষণাবেক্ষণের কিছু ফর্ম ALTER INDEX...REORGANIZEএকটি বিকল্প হতে পারে।


প্রাথমিক গবেষণা

এই টেবিলগুলি সম্পর্কে মেটাডেটা এখানে দেখা যাবে sys.dm_db_partition_stats:

-- The system base table that contains one row for every column in the system
SELECT row_count,
    (reserved_page_count * 8 * 1024.0) / row_count AS bytes_per_row, 
    reserved_page_count/128. AS space_mb
FROM sys.dm_db_partition_stats
WHERE object_id = OBJECT_ID('sys.syscolpars')
    AND index_id = 1
-- row_count:       15,600,859
-- bytes_per_row:   278.08
-- space_mb:        4,136

যাইহোক, sys.dm_db_index_physical_statsএই টেবিলগুলির খণ্ডন দেখে সমর্থন করে না:

-- No fragmentation data is returned by sys.dm_db_index_physical_stats
SELECT *
FROM sys.dm_db_index_physical_stats(
    DB_ID(),
    OBJECT_ID('sys.syscolpars'),
    NULL,
    NULL,
    'DETAILED'
)

ওলা হ্যালেনগ্রেনের স্ক্রিপ্টগুলিতেis_ms_shipped = 1 অবজেক্টগুলির জন্য ডিফ্র্যাগেশনেশন বিবেচনা করার জন্য একটি পরামিতি রয়েছে , তবে প্রক্রিয়াটি এই পরামিতি সক্ষম থাকা সত্ত্বেও সিস্টেম বেস টেবিলগুলিকে নিঃশব্দে উপেক্ষা করে। ওলা স্পষ্ট করে জানিয়েছিলেন যে এটি প্রত্যাশিত আচরণ; কেবলমাত্র ব্যবহারকারীর টেবিলগুলি (সিস্টেম সারণী নয়) যা এমএস_শিপযুক্ত (যেমন msdb.dbo.backupset) বিবেচনা করা হয়।

-- Returns code 0 (successful), but does not do any work for system base tables.
-- Instead of the expected commands to update statistics and reorganize indexes,
-- no commands are generated. The script seems to assume the target tables will
-- appear in sys.tables, but this does not appear to be a valid assumption for
-- system tables like sys.sysrowsets or sys.syscolpars.
DECLARE @result int;
EXEC @result = IndexOptimize @Databases = 'Test',
        @FragmentationLow = 'INDEX_REORGANIZE',
        @FragmentationMedium = 'INDEX_REORGANIZE',
        @FragmentationHigh = 'INDEX_REORGANIZE',
        @PageCountLevel = 0,
        @UpdateStatistics = 'ALL',
        @Indexes = '%Test.sys.sysrowsets.%',
        -- Proc works properly if targeting a non-system table instead
        --@Indexes = '%Test.dbo.Numbers.%',
        @MSShippedObjects = 'Y',
        @Execute = 'N';
PRINT(@result);


অতিরিক্ত অনুরোধ তথ্য

আমি সিস্টেমের টেবিল বাফার পুল ব্যবহারের তদন্তের নীচে হারুনের ক্যোয়ারীর অভিযোজনটি ব্যবহার করেছি এবং এটিতে দেখা গেছে যে বাফার পুলে দশ গিগাবাইট সিস্টেমের টেবিল রয়েছে কেবল একটি ডাটাবেসের জন্য, সেই জায়গার ~ 80% কিছু ক্ষেত্রে ফাঁকা জায়গা রয়েছে being ।

-- Compute buffer pool usage by system table
SELECT OBJECT_NAME(p.object_id),
    COUNT(b.page_id) pages,
    SUM(b.free_space_in_bytes/8192.0) free_pages
FROM sys.dm_os_buffer_descriptors b
JOIN sys.allocation_units a
    ON a.allocation_unit_id = b.allocation_unit_id
JOIN sys.partitions p
    ON p.partition_id = a.container_id
    AND p.object_id < 1000 -- A loose proxy for system tables
WHERE b.database_id = DB_ID()
GROUP BY p.object_id
ORDER BY pages DESC

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

উত্তর:


11

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

আপনি দেখতে পারেন কত পৃষ্ঠা ব্যবহার করা হচ্ছে, এবং আপনি দেখতে পারেন কত মুক্ত স্থান হয় পৃষ্ঠাগুলি মেমরি হয় ( page_free_space_percentসর্বদা NULLবরাদ্দ DMF মধ্যে, কিন্তু এই হল বাফার না DMV থেকে পাওয়া) - এই আপনি কিছু ধারণা দিতে হবে আপনি যদি উদ্বিগ্ন হন তবে সত্যিই এমন কিছু যা আপনার সম্পর্কে উদ্বিগ্ন হওয়া উচিত:

SELECT 
  Number_of_Pages = COUNT(*), 
  Number_of_Pages_In_Memory = COUNT(b.page_id),
  Avg_Free_Space = AVG(b.free_space_in_bytes/8192.0) 
FROM sys.dm_db_database_page_allocations
(
  DB_ID(),
  OBJECT_ID(N'sys.syscolpars'),
  NULL,NULL,'DETAILED'
) AS p
LEFT OUTER JOIN sys.dm_os_buffer_descriptors AS b
ON b.database_id = DB_ID() 
AND b.page_id = p.allocated_page_page_id 
AND b.file_id = p.allocated_page_file_id;

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

যদি আপনার পৃষ্ঠাগুলির সংখ্যা বড় হয় এবং মুক্ত স্থানটি "উচ্চ" হয় তবে ঠিক আছে, তবে সম্ভবত আমি এসকিউএল সার্ভারকে তার নিজের স্ব-রক্ষণাবেক্ষণের জন্য খুব বেশি ক্রেডিট দিচ্ছি। আপনি যেমন অন্য প্রশ্ন থেকে দেখিয়েছেন , এটি কাজ করে ...

ALTER INDEX ALL ON sys.syscolpars REORGANIZE;

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

সম্ভবত আপনি নিজের রক্ষণাবেক্ষণের অংশ হিসাবে এটি পর্যায়ক্রমে করতে পারেন, যদি এটি আপনাকে ভাল বোধ করে এবং / অথবা আপনার কোনও প্রমাণ রয়েছে যে এটির আপনার সিস্টেমে কোনও ইতিবাচক প্রভাব রয়েছে।


আমরা কী করতে পেরেছি তার সংক্ষিপ্তসারে আমি আরও একটি উত্তর যুক্ত করেছি, এবং তারপরে এখানে পূর্ববর্তী মন্তব্যগুলি পরিষ্কার করেছি। আপনার সাহায্যের জন্য আবার ধন্যবাদ!
জিওফ প্যাটারসন

7

হারুনের উত্তরের দিকনির্দেশের পাশাপাশি অতিরিক্ত গবেষণার উপর ভিত্তি করে, আমি যে পদ্ধতি গ্রহণ করেছি সে সম্পর্কে এখানে একটি দ্রুত লেখার ব্যবস্থা রয়েছে।

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

আমি তারপরে সমস্ত সিস্টেম বেস টেবিলগুলিতে I ALTER INDEX ... REORGANIZE সম্পাদন করার জন্য একটি পদ্ধতি তৈরি করেছি । আমাদের বেশিরভাগ (আব) ব্যবহৃত ডেভ সার্ভারগুলিতে এই প্রক্রিয়াটি সম্পাদন করে দেখানো হয়েছিল যে সিস্টেম বেস টেবিলগুলির সংশ্লেষিত আকারটি 50 গিগাবাইট পর্যন্ত ছাঁটা হয়েছিল (সিস্টেমে 5 এমএম ইউজার টেবিল সহ, সুতরাং স্পষ্টতই একটি চরম কেস)।

আমাদের রাতের রক্ষণাবেক্ষণের একটি কাজ, যা বিভিন্ন ইউনিট পরীক্ষা এবং বিকাশ দ্বারা নির্মিত অনেকগুলি ব্যবহারকারীর টেবিল পরিষ্কার করতে সহায়তা করে, পূর্বে এটি শেষ করতে ~ 50 মিনিট সময় নিচ্ছিল। একটি সংমিশ্রণ sp_whoisactive, sys.dm_os_waiting_tasksএবং DBCC PAGEদেখিয়েছেন যে অপেক্ষা করছে আমি / সিস্টেম বেস টেবিলের উপর হে প্রাধান্য ছিল।

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

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


আপনার প্রশ্ন এবং উত্তর উভয় জন্য +1 - অভ্যন্তরীণ একটি কালো বক্স একটি বিট আছে, এবং আপনি সাহায্য করেছেন কি পারফরম্যান্সের জন্য সত্যিই একটি কদর্য দৃশ্যকল্প (এমনকি যদি আপনার মত দেখায় কিছু হালকা চালা হয় একটি প্রান্ত-কেস)।
ম্যাক্স ভার্নন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.