আমি অনলাইনে কোনও ভাল সংস্থান খুঁজে পাইনি, তাই আমি আরও কিছু গবেষণা চালিয়েছি এবং ভেবেছিলাম যে সেই গবেষণার উপর ভিত্তি করে আমরা ফলিত পুরো পাঠ্য রক্ষণাবেক্ষণ পরিকল্পনা পোস্ট করা কার্যকর হবে।
রক্ষণাবেক্ষণ কখন প্রয়োজন হয় তা নির্ধারণ করার জন্য আমাদের তাত্ত্বিক
আমাদের প্রাথমিক লক্ষ্যটি অন্তর্নিহিত সারণীতে ডেভলভ হওয়ার সাথে সাথে সামঞ্জস্যপূর্ণ পূর্ণ-পাঠ্য ক্যোয়ারী কর্মক্ষমতা ধরে রাখা। তবে বিভিন্ন কারণে আমাদের আমাদের প্রতিটি ডাটাবেসের বিরুদ্ধে প্রতি রাতে পূর্ণ-পাঠ্য প্রশ্নগুলির একটি প্রতিনিধি স্যুট চালু করা এবং রক্ষণাবেক্ষণ কখন প্রয়োজন হয় তা নির্ধারণ করার জন্য সেই প্রশ্নেরগুলির কার্যকারিতাটি ব্যবহার করা কঠিন। অতএব, আমরা থাম্বের এমন নিয়ম তৈরি করতে চাইছিলাম যা খুব দ্রুত গণনা করা যায় এবং পুরো-পাঠ্য সূচীর রক্ষণাবেক্ষণের প্রয়োজন হয় কিনা তা বোঝাতে এটি একটি হিউরিস্টিক হিসাবে ব্যবহার করা যেতে পারে।
এই অন্বেষণের সময়, আমরা দেখতে পেয়েছিলাম যে সিস্টেমের ক্যাটালগটি কোনও প্রদত্ত পূর্ণ-পাঠ্য সূচকে কীভাবে খণ্ডগুলিতে বিভক্ত করা হয় সে সম্পর্কে অনেক তথ্য সরবরাহ করে। তবে, কোনও অফিসিয়াল "ফ্র্যাগমেন্টেশন%" গণনা করা হয়নি (যেমন sys.dm_db_index_physical_stats এর মাধ্যমে বি-ট্রি ইনডেক্সের জন্য রয়েছে )। পূর্ণ-পাঠ্য খণ্ডের তথ্যের ভিত্তিতে, আমরা আমাদের নিজস্ব "পূর্ণ-পাঠ্য খণ্ড%" গণনা করার সিদ্ধান্ত নিয়েছি। এরপরে আমরা ডেভ সার্ভারটি বারবার 100 থেকে 25,000 সারিগুলির মধ্যে যে কোনও জায়গায় উত্পাদন ডেটার জন্য এক মিলিয়ন সারি কপিতে বারবার এলোমেলো আপডেট করতে, পূর্ণ-পাঠ্য খণ্ড রেকর্ড করতে এবং ব্যবহার করে একটি বেঞ্চমার্ক পূর্ণ-পাঠ্য ক্যোয়ারী সম্পাদন করতে ব্যবহার করি CONTAINSTABLE।
উপরের এবং নীচে চার্টগুলিতে প্রদর্শিত ফলাফলগুলি খুব আলোকসজ্জাজনক ছিল এবং দেখানো হয়েছিল যে আমরা তৈরি করা খণ্ডন পরিমাপটি পর্যবেক্ষণের পারফরম্যান্সের সাথে অত্যন্ত সংযুক্ত। যেহেতু এটি আমাদের উত্পাদনের গুণগত পর্যবেক্ষণগুলির সাথেও জড়িত, তাই আমাদের সম্পূর্ণ-পাঠ্য সূচিকাগুলি রক্ষণাবেক্ষণের প্রয়োজন হয় তা সিদ্ধান্ত নেওয়ার জন্য আমরা আমাদের হিউরিস্টিক হিসাবে টুকরো টুকরা% ব্যবহার করে আরামদায়ক।
রক্ষণাবেক্ষণ পরিকল্পনা
প্রতিটি পূর্ণ-পাঠ্য সূচকের জন্য একটি বিভাজন% গণনা করার জন্য আমরা নিম্নলিখিত কোডটি ব্যবহার করার সিদ্ধান্ত নিয়েছি। কমপক্ষে 10% বিভক্তকরণ সহ তুচ্ছ আকারের কোনও পূর্ণ-পাঠ্য সূচীগুলিকে আমাদের ওভার-নাইট রক্ষণাবেক্ষণ দ্বারা পুনর্নির্মাণের জন্য পতাকাঙ্কিত করা হবে।
-- Compute fragmentation information for all full-text indexes on the database
SELECT c.fulltext_catalog_id, c.name AS fulltext_catalog_name, i.change_tracking_state,
i.object_id, OBJECT_SCHEMA_NAME(i.object_id) + '.' + OBJECT_NAME(i.object_id) AS object_name,
f.num_fragments, f.fulltext_mb, f.largest_fragment_mb,
100.0 * (f.fulltext_mb - f.largest_fragment_mb) / NULLIF(f.fulltext_mb, 0) AS fulltext_fragmentation_in_percent
INTO #fulltextFragmentationDetails
FROM sys.fulltext_catalogs c
JOIN sys.fulltext_indexes i
ON i.fulltext_catalog_id = c.fulltext_catalog_id
JOIN (
-- Compute fragment data for each table with a full-text index
SELECT table_id,
COUNT(*) AS num_fragments,
CONVERT(DECIMAL(9,2), SUM(data_size/(1024.*1024.))) AS fulltext_mb,
CONVERT(DECIMAL(9,2), MAX(data_size/(1024.*1024.))) AS largest_fragment_mb
FROM sys.fulltext_index_fragments
GROUP BY table_id
) f
ON f.table_id = i.object_id
-- Apply a basic heuristic to determine any full-text indexes that are "too fragmented"
-- We have chosen the 10% threshold based on performance benchmarking on our own data
-- Our over-night maintenance will then drop and re-create any such indexes
SELECT *
FROM #fulltextFragmentationDetails
WHERE fulltext_fragmentation_in_percent >= 10
AND fulltext_mb >= 1 -- No need to bother with indexes of trivial size
এই অনুসন্ধানগুলি নীচের মত ফলাফল দেয় এবং এই ক্ষেত্রে সারি 1, 6 এবং 9 সারিগুলি সর্বোত্তম পারফরম্যান্সের জন্য খুব খণ্ডিত হিসাবে চিহ্নিত হবে কারণ পূর্ণ-পাঠ্য সূচী 1MB এর ওপরে এবং কমপক্ষে 10% খণ্ডিত হয়েছে।
রক্ষণাবেক্ষণ
আমাদের ইতিমধ্যে একটি রাতের রক্ষণাবেক্ষণ উইন্ডো রয়েছে, এবং খণ্ডের গণনা গণনা করা খুব সস্তা to সুতরাং আমরা প্রতি রাতে এই চেকটি চালিয়ে যাব এবং তারপরে 10% খণ্ডের দ্বারপ্রান্তের উপর ভিত্তি করে কেবলমাত্র একটি পূর্ণ-পাঠ্য সূচী পুনর্নির্মাণের আরও ব্যয়বহুল ক্রিয়াকলাপটি সম্পাদন করব।
পুনর্নির্মাণ বনাম পুনঃনির্মাণ বনাম ড্রপ / তৈরি করুন
এসকিউএল সার্ভার অফার করে REBUILDএবং REORGANIZEবিকল্পগুলি দেয়, তবে সেগুলি সম্পূর্ণরূপে কেবলমাত্র একটি পূর্ণ-পাঠ্য ক্যাটালগের জন্য উপলব্ধ (যাতে কোনও সংখ্যক পূর্ণ-পাঠ্য সূচী থাকতে পারে)) উত্তরাধিকারগত কারণে, আমাদের কাছে একটি একক পূর্ণ-পাঠ্য ক্যাটালগ রয়েছে যাতে আমাদের সমস্ত পূর্ণ-পাঠ্য সূচী রয়েছে। সুতরাং, আমরা এর পরিবর্তে পৃথক পূর্ণ-পাঠ্য সূচী স্তরে ( DROP FULLTEXT INDEX) এবং তারপরে ( ) পুনরায় তৈরি করতে CREATE FULLTEXT INDEXবেছে নিয়েছি।
যৌক্তিক উপায়ে সম্পূর্ণ পাঠ্য সূচীগুলি পৃথক ক্যাটালগগুলিতে ভেঙে এর REBUILDপরিবর্তে সঞ্চালন করা আরও আদর্শ হতে পারে তবে এর মধ্যে ড্রপ / তৈরি সমাধানটি আমাদের জন্য কাজ করবে।
