ডাটাবেস আকার - MDF খুব বড়?


10

আমি একটি এসকিউএল সার্ভার 2005 ডাটাবেস বজায় রাখছি যা প্রায় 2.9Tb ডেটা হোস্ট করে (2 x 1.45Tb - আমার কাছে একটি কাঁচা স্কিমা এবং একটি অ্যানালাইসিস স্কিমা রয়েছে তাই মূলত ডেটা ইনজাস্ট করা দুটি কপি)। পুনরুদ্ধার মডেলটি সিম্প্লে এবং এটি .ldf6 জিবিতে।

যে কারণেই হোক না কেন, এটি .mdf7.5Tb। এখন, অ্যানালাইসিস টেবিলগুলিতে কেবলমাত্র 2-3 টি অতিরিক্ত কলাম রয়েছে এবং অনেকগুলি NVARCHAR(MAX)কলামও নয় যা থেকে (আমি ভুল করে বুঝতে পেরেছি - দয়া করে আমাকে ভুল করে সংশোধন করুন) অতিরিক্ত স্থান বরাদ্দের কারণ হতে পারে। এটি এখনই ডাটাবেস সঙ্কুচিত করার পরে - এটি আগে 9Tb ডলার ছিল। কোন চিন্তা?

এবং, দয়া করে, আপনার যদি অতিরিক্ত প্রশ্ন থাকে তবে আমাকে জানান - আমি ডেটাবেস প্রশাসন এবং অপ্টিমাইজেশানের প্রচেষ্টায় খুব নতুন (আমি সাধারণত কাজের এই দিকটি করি না :))।

অনেক ধন্যবাদ!

Andrija


ধন্যবাদ মার্ক - যেভাবেই আমি এই প্রশ্নটিকে সেখানে স্থানান্তর করতে পারি বা আমার কি পুনরায় পোস্ট করার দরকার আছে?

চিয়ার্স - আপনি সম্ভবত অনুমান করতে পারেন, আমি এখানে নতুন আছি :)

উত্তর:


11

আপনার আকারের অনুমান অনুসারে, আপনি কি সূচকগুলি দ্বারা স্থান গ্রহণের পরিমাণটি বিবেচনা করেছেন? এছাড়াও যদি আপনার কাছে এমন পাঠ্য ক্ষেত্র রয়েছে যা মাল্টি-বাইট ( 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 ) প্রতিটি সূচক দ্বারা ব্যবহৃত স্থান।


একটি ডেটা ফাইলে তিনটি ক্লাস অব্যবহৃত স্থান রয়েছে:

  1. যা কোনও কিছুর জন্য বরাদ্দ করা হয়নি (এটি প্রথম কোনও ফলাফলের sp_spaceusedসাথে নির্ধারিত ফলাফল ছাড়াই প্রদর্শিত হবে)
  2. যা কোনও বস্তুকে বরাদ্দ করা হয়েছে (সংরক্ষিত) কিন্তু বর্তমানে ব্যবহৃত হচ্ছে না (এটি "অব্যবহৃত" কাউন্টের sp_spaceusedআউটপুটে দেখায় ।
  3. যেটি অংশ-ব্যবহৃত পৃষ্ঠাগুলিতে লক হয়েছে (এটি একক পৃষ্ঠার অংশগুলিতে সমস্ত কিছু বরাদ্দ করা হওয়ায় এটি ব্যবহার করা হবে বলে মনে হবে, একটি পৃষ্ঠা 8,192 বাইট দীর্ঘ)। এটি সনাক্ত / গণনা করা আরও শক্ত। এটি দুটি কারণের মিশ্রণের কারণে:
    • পৃষ্ঠাগুলি বিভক্ত করুন। তথ্য যোগ পরার হিসাবে আপনি প্রায়ই অংশ খালি পৃষ্ঠা (স্টোরেজ ইঞ্জিন দিয়ে শেষ পারে সবসময় স্বাভাবিক পৃষ্ঠা সামগ্রীর, কিন্তু এই খুব অদক্ষ হবে), এবং সারি মুছে ফেলা হয়, পৃষ্ঠা সামগ্রীর স্বয়ংক্রিয়ভাবে বস্তাবন্দী হয় না (আবার তারা হতে পারে, কিন্তু অতিরিক্ত আই / ও বোঝা সাধারণত এর মূল্য থেকে দূরে থাকে)।
    • স্টোরেজ ইঞ্জিন একাধিক পৃষ্ঠায় সারি বিভাজিত করবে না (এটি পৃষ্ঠার আকারের সাথে 8,192 বাইট-প্রতি-সারি সীমাটি থেকে আসে)। যদি আপনার সারিগুলি স্থির আকারের হয় এবং প্রতিটি 1,100 বাইট নেয় তবে আপনি সেই টেবিলের জন্য বরাদ্দকৃত প্রতিটি ডেটা ব্লকের কমপক্ষে 492 বাইট "নষ্ট" করতে যাচ্ছেন (7 সারিগুলি 7,700 বাইট নেয় এবং 8 তম ফিট হবে না তাই বাকী বাইটগুলি জিতেছে ' টি ব্যবহার করা হবে)। সারিগুলির বৃহত্তর, এটি আরও খারাপ হতে পারে। পরিবর্তনশীল দৈর্ঘ্যের সারিগুলির সাথে টেবিল / সূচকগুলি (যা সম্পূর্ণ স্থির দৈর্ঘ্যের তুলনায় অনেক বেশি সাধারণ) সাধারণত ভাল হয় (তবে বিষয়টি গণনা করা কম সহজ)।
      এখানে আরেকটি সতর্কতা হ'ল বড় বস্তু ( TEXTকলাম,[N]VARCHAR(MAX) নির্দিষ্ট আকারের উপরের মানগুলি ইত্যাদি) যেমন সেগুলি পৃষ্ঠার বাইরে রাখে, মূল সারি ডেটাতে 8 বাইট নিয়ে অন্য কোথাও ডেটাতে পয়েন্টার ধরে রাখে) তাই প্রতি-সারি-সীমা-সীমাটি 8,192 বাইটস ভাঙতে পারে।

tl; dr: প্রাথমিকভাবে অনুমান করা স্বাভাবিকের চেয়ে প্রত্যাশিত ডাটাবেস আকারগুলির অনুমান করা আরও অনেক বেশি জড়িত হতে পারে।


ডেভিড - বিস্তারিত প্রতিক্রিয়া জন্য আপনাকে অনেক ধন্যবাদ! আমি এখনই ডিবিটিকে বিশ্লেষণ করছি এবং আপনার এবং কেনেথের প্রতিক্রিয়া উভয়ই ডাটাবেসের আকারকে প্রভাবিত করার কারণগুলি সম্পর্কে আমার বোঝার ক্ষেত্রে প্রচুর সহায়ক হয়েছে। আমি দক্ষতার সাথে সর্বদা উদ্বিগ্ন (উভয়ই ডেটা ইনজেশন এবং ডেটা ব্যবহারের ক্ষেত্রে আসে) এবং আপনার ছেলেরা যে তথ্য সরবরাহ করেছে তা অমূল্য!
Andrija_Bgd

6

sp_spaceusedআপনার ডাটাবেস চালানোর চেষ্টা করুন । উদাহরণ হিসাবে এটি ফিরে আসে:

reserved           data               index_size         unused
------------------ ------------------ ------------------ ------------------
6032 KB            2624 KB            1664 KB            1744 KB

ডাটাবেসের শুধু তে এটি চালানোর জন্য USEডাটাবেসের তারপর চালানো sp_spaceused

এটি এখনও অব্যবহৃত স্থানের একটি দুর্দান্ত কাজ দেখায় আপনি আবার সঙ্কুচিত করতে চেষ্টা করতে পারেন। কখনও কখনও আমি এটি একাধিক চেষ্টা লাগে না। এছাড়াও কখনও কখনও আমি দেখতে পাই যে সম্পূর্ণ ডাটাবেসের চেয়ে পৃথক ফাইল সঙ্কুচিত করা সবচেয়ে ভাল কাজ করে। তবে আপনি যা খুঁজে পেতে পারেন তা হল আপনার কাছে 2.9Tb ডেটা এবং অন্য 4+ টিবি সূচক রয়েছে যা ক্ষেত্রে 7.5TB বেশ যুক্তিসঙ্গত। আপনি যদি প্রতিটি টেবিলের জায়গার পরিমাণ (ডেটা ও সূচী) অনুভব করতে চান তবে আপনি sp_spaceusedএকটি টেবিল পর্যায়েও চালাতে পারেন । আপনি নিম্নলিখিত কমান্ডটি ব্যবহার করে এটি ডাটাবেসের সমস্ত টেবিল জুড়ে চালাতে পারেন:

EXEC sp_msforeachtable 'EXEC sp_spaceused [?];'

যদিও সুষ্ঠু সতর্কতা sp_msforeachtable অননুমোদিত, অসমর্থিত এবং টেবিল মিস করতে পরিচিত। অন্যদিকে আমি নিজে এটির সাথে মোটামুটি ভাগ্য পেয়েছি।

এর সবই বলা হচ্ছে যে আপনার ডাটাবেসে আপনার প্রত্যাশিত বৃদ্ধির উপর নির্ভর করে খালি জায়গার একটি নির্দিষ্ট শতাংশ থাকতে হবে। মূলত আপনি এটি নিশ্চিত করতে চান যে আপনার যে কোনও জায়গায় 6 মাস থেকে কয়েক বছর ধরে কয়েক বছরের বৃদ্ধির স্থান রয়েছে। এছাড়াও আপনি আপনার autogrowthসেটিংস আপনার অবস্থার সাথে উপযুক্ত কিনা তা নিশ্চিত করতে আপনার সেটিংস পরীক্ষা করতে চাইবেন । বিশেষত আপনার ডাটাবেসের আকার দেওয়া হয়েছে আপনি%% ব্যবহার করতে চান না autogrowth


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

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

-1

এসকিউএল ম্যানেজমেন্ট স্টুডিও ব্যবহার করে, 1. ডাটাবেসটিতে রাইট ক্লিক করুন তারপরে 2. টাস্ক-> সঙ্কুচিত -> ফাইলগুলিতে ক্লিক করুন

আপনি একটি ডায়ালগ দেখতে পাবেন যা দেখায়: ক। বর্তমানে বরাদ্দ স্থান খ। উপলব্ধ মুক্ত স্থান + (% মুক্ত)

যদি আপনার% ফ্রি 50% এর বেশি হয় তবে আপনি ফাইলটি সঙ্কুচিত করার কথা বিবেচনা করতে পারেন। আমি এই হিটটি 90% হিসাবে দেখেছি। আমি যদি ফাইলটি সঙ্কুচিত করার সিদ্ধান্ত নিই তবে আমি এটি বর্তমান বরাদ্দ জায়গার চেয়ে সাধারণত 2 বা 3 জিগ সেট করে থাকি। আমার বেশিরভাগ ডাটাবেস 50gigs এর চেয়ে কম are সুতরাং আপনার যদি আরও বড় ফাইল থাকে তবে আপনি এটি 10 ​​টি জিগ বড় করে তুলতে পারেন। আমি সাধারণত সঙ্কুচিত হওয়া নিয়েই উদ্বিগ্ন থাকি যদি আমি অন্য সার্ভারে ডাটাবেস স্থানান্তর করতে যাচ্ছি তবে আপনি যে কোনও বিকাশের পৃষ্ঠায় সঙ্কুচিত সমস্যাগুলি সম্পর্কে সমস্ত পড়তে পারেন।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.