আপনার আকারের অনুমান অনুসারে, আপনি কি সূচকগুলি দ্বারা স্থান গ্রহণের পরিমাণটি বিবেচনা করেছেন? এছাড়াও যদি আপনার কাছে এমন পাঠ্য ক্ষেত্র রয়েছে যা মাল্টি-বাইট ( N[VAR]CHAR
পরিবর্তে [VAR]CHAR
) হিসাবে সেট করা আছে এবং ইনপুট ফাইলগুলি ইউটিএফ -8 বা সাদামাটা এক-বাইট-প্রতি-চরিত্রের হয় তবে এটি আপনার স্টোরেজ প্রয়োজনীয়তার জন্য দুটি ফ্যাক্টর পর্যন্ত চাপিয়ে দেবে। আরও মনে রাখবেন যে আপনার যদি কোনও টেবিলে একটি ক্লাস্টারযুক্ত কী / সূচক থাকে তবে এটির আকারটি টেবিলের সমস্ত অন্যান্য সূচকে প্রভাবিত করে কারণ তারা প্রতিটি সারির জন্য ক্লাস্টারযুক্ত মানটি অন্তর্ভুক্ত করে (সুতরাং একটি টেবিলের এনসিএইচআর থাকলে একটি চরম উদাহরণ দেওয়া (10 ) কী যেখানে কোনও আইএনটি করবে এবং এটিই আপনার ক্লাস্টারযুক্ত কী / সূচক আপনি কেবলমাত্র ডেটা পৃষ্ঠাগুলিতে সারি প্রতি অতিরিক্ত 16 বাইট ব্যবহার করছেন না আপনি সেই টেবিলের অন্য সূচকগুলিতে সারি প্রতি 16 বাইটও নষ্ট করবেন ) ।
এছাড়াও, কিছু স্থান বরাদ্দ করা হবে তবে অব্যবহৃত হবে, কারণ ডিবি ইঞ্জিন মুছে ফেলার পরে কিছু বরাদ্দ রেখে দিয়েছে যাতে এটি আবার সেই টেবিলের নতুন ডেটার জন্য আবার ব্যবহার করা যেতে পারে বা সন্নিবেশ এবং মোছার প্যাটার্নের ফলে অনেক পৃষ্ঠা কেবলমাত্র অংশই ছেড়ে গেছে সম্পূর্ণ.
আপনি চালাতে পারেন:
SELECT o.name
, SUM(ps.reserved_page_count)/128.0 AS ReservedMB
, SUM(ps.used_page_count)/128.0 AS UsedMB
, SUM(ps.reserved_page_count-ps.used_page_count)/128.0 AS DiffMB
FROM sys.objects o
JOIN sys.dm_db_partition_stats ps ON o.object_id = ps.object_id
WHERE OBJECTPROPERTYEX(o.object_id, 'IsMSShipped') = 0
GROUP BY o.name
ORDER BY SUM(ps.reserved_page_count) DESC
কী টেবিলগুলি স্থান গ্রহণ করছে তা একবারে দেখুন।
এছাড়াও EXEC sp_spaceused
ডিবি মধ্যে চালানো দুটি ফলাফল সেট ফিরে আসবে। প্রথমটিতে ডেটা ফাইলগুলির জন্য ফাইল সিস্টেমে বরাদ্দকৃত মোট স্থানের তালিকা এবং এর মধ্যে কতটা অবিকৃত রয়েছে, দ্বিতীয়টি তালিকাবদ্ধ করে যে বরাদ্দকৃত স্পেসের পরিমাণ ডেটা পৃষ্ঠাগুলির জন্য, সূচী পৃষ্ঠাগুলির জন্য বা বর্তমানে অব্যবহৃত রয়েছে lists
sp_spaceused
প্রদত্ত বস্তুর দ্বারা ব্যবহৃত স্থানটিও ফিরে আসবে, তাই বিশ্লেষণের জন্য একটি টেবিল তৈরি করতে আপনি এটি লুপ করতে পারেন:
-- TEMP TABLES FOR ANALYSIS
CREATE TABLE #tTables (sName NVARCHAR(MAX), iRows BIGINT, iReservedKB BIGINT, iDataKB BIGINT, iIndexKB BIGINT, iUnusedKB BIGINT)
CREATE TABLE #tTmp (sName NVARCHAR(MAX), iRows BIGINT, sReservedKB NVARCHAR(MAX), sDataKB NVARCHAR(MAX), sIndexKB NVARCHAR(MAX), sUnusedKB NVARCHAR(MAX))
-- COLLECT SPACE USE PER TABLE
EXEC sp_msforeachtable 'INSERT #tTmp EXEC sp_spaceused [?];'
-- CONVERT NUMBER-AS-TEXT COLUMNS TO NUMBER TYPES FOR EASIER ANALYSIS
INSERT #tTables SELECT sName, iRows
, CAST(REPLACE(sReservedKB, ' KB', '') AS BIGINT)
, CAST(REPLACE(sDataKB , ' KB', '') AS BIGINT)
, CAST(REPLACE(sIndexKB , ' KB', '') AS BIGINT)
, CAST(REPLACE(sUnusedKB , ' KB', '') AS BIGINT)
FROM #tTmp
DROP TABLE #tTmp
-- DO SOME ANALYSIS
SELECT sName='TOTALS', iRows=SUM(iRows), iReservedKB=SUM(iReservedKB), iDataKB=SUM(iDataKB), iIndexKB=SUM(iIndexKB), iUnusedKB=SUM(iUnusedKB) FROM #tTables ORDER BY sName
SELECT * FROM #tTables ORDER BY iReservedKB DESC
-- CLEAN UP
DROP TABLE #tTables
উপরের কোডটি সমস্ত তালিকার আকারকে একটি তালিকায় আউটপুট দেবে, যোগফলের জন্য একটি একক সারিতে। প্রয়োজনে আরও বিভিন্ন বিবরণ পেতে বিভিন্ন সিস্টেম ভিউ (যেমন উপরের প্রথম ক্যোয়ারির মতো sys.objects
এবং sys.dm_db_partition_stats
ব্যবহৃত, ব্যবহার করতে পারেন http://technet.microsoft.com/en-us/library/ms177862.aspx ) প্রতিটি সূচক দ্বারা ব্যবহৃত স্থান।
একটি ডেটা ফাইলে তিনটি ক্লাস অব্যবহৃত স্থান রয়েছে:
- যা কোনও কিছুর জন্য বরাদ্দ করা হয়নি (এটি প্রথম কোনও ফলাফলের
sp_spaceused
সাথে নির্ধারিত ফলাফল ছাড়াই প্রদর্শিত হবে)
- যা কোনও বস্তুকে বরাদ্দ করা হয়েছে (সংরক্ষিত) কিন্তু বর্তমানে ব্যবহৃত হচ্ছে না (এটি "অব্যবহৃত" কাউন্টের
sp_spaceused
আউটপুটে দেখায় ।
- যেটি অংশ-ব্যবহৃত পৃষ্ঠাগুলিতে লক হয়েছে (এটি একক পৃষ্ঠার অংশগুলিতে সমস্ত কিছু বরাদ্দ করা হওয়ায় এটি ব্যবহার করা হবে বলে মনে হবে, একটি পৃষ্ঠা 8,192 বাইট দীর্ঘ)। এটি সনাক্ত / গণনা করা আরও শক্ত। এটি দুটি কারণের মিশ্রণের কারণে:
- পৃষ্ঠাগুলি বিভক্ত করুন। তথ্য যোগ পরার হিসাবে আপনি প্রায়ই অংশ খালি পৃষ্ঠা (স্টোরেজ ইঞ্জিন দিয়ে শেষ পারে সবসময় স্বাভাবিক পৃষ্ঠা সামগ্রীর, কিন্তু এই খুব অদক্ষ হবে), এবং সারি মুছে ফেলা হয়, পৃষ্ঠা সামগ্রীর স্বয়ংক্রিয়ভাবে বস্তাবন্দী হয় না (আবার তারা হতে পারে, কিন্তু অতিরিক্ত আই / ও বোঝা সাধারণত এর মূল্য থেকে দূরে থাকে)।
- স্টোরেজ ইঞ্জিন একাধিক পৃষ্ঠায় সারি বিভাজিত করবে না (এটি পৃষ্ঠার আকারের সাথে 8,192 বাইট-প্রতি-সারি সীমাটি থেকে আসে)। যদি আপনার সারিগুলি স্থির আকারের হয় এবং প্রতিটি 1,100 বাইট নেয় তবে আপনি সেই টেবিলের জন্য বরাদ্দকৃত প্রতিটি ডেটা ব্লকের কমপক্ষে 492 বাইট "নষ্ট" করতে যাচ্ছেন (7 সারিগুলি 7,700 বাইট নেয় এবং 8 তম ফিট হবে না তাই বাকী বাইটগুলি জিতেছে ' টি ব্যবহার করা হবে)। সারিগুলির বৃহত্তর, এটি আরও খারাপ হতে পারে। পরিবর্তনশীল দৈর্ঘ্যের সারিগুলির সাথে টেবিল / সূচকগুলি (যা সম্পূর্ণ স্থির দৈর্ঘ্যের তুলনায় অনেক বেশি সাধারণ) সাধারণত ভাল হয় (তবে বিষয়টি গণনা করা কম সহজ)।
এখানে আরেকটি সতর্কতা হ'ল বড় বস্তু ( TEXT
কলাম,[N]VARCHAR(MAX)
নির্দিষ্ট আকারের উপরের মানগুলি ইত্যাদি) যেমন সেগুলি পৃষ্ঠার বাইরে রাখে, মূল সারি ডেটাতে 8 বাইট নিয়ে অন্য কোথাও ডেটাতে পয়েন্টার ধরে রাখে) তাই প্রতি-সারি-সীমা-সীমাটি 8,192 বাইটস ভাঙতে পারে।
tl; dr: প্রাথমিকভাবে অনুমান করা স্বাভাবিকের চেয়ে প্রত্যাশিত ডাটাবেস আকারগুলির অনুমান করা আরও অনেক বেশি জড়িত হতে পারে।