डेटाबेस का आकार - एमडीएफ बहुत बड़ा है?

10

मैं एक SQL सर्वर 2005 डेटाबेस बना रहा हूं जो लगभग 2.9Tb डेटा (2 x 1.45Tb - मेरे पास एक रॉ स्कीमा और एक ANALYSIS स्कीमा है, इसलिए मूल रूप से डेटा की दो प्रतियाँ होती हैं)। रिकवरी मॉडल SIMPLE है और .ldf6Gb पर है।

जो भी कारण के लिए, .mdf7.5Tb है। अब, ANALYSIS टेबलों में केवल 2-3 अतिरिक्त कॉलम हैं और न जाने कितने NVARCHAR(MAX)कॉलम हैं, जो मैंने (शायद मैं गलत तरीके से समझा हो - कृपया मुझे गलत समझें तो) अतिरिक्त स्थान आवंटन का कारण बन सकता है। डेटाबेस को अभी सिकोड़ने के बाद - यह उससे पहले ~ 9Tb पर था। कोई विचार?

और, कृपया, मुझे बताएं कि क्या आपके पास अतिरिक्त प्रश्न हैं - मैं डेटाबेस प्रशासन और अनुकूलन प्रयासों के लिए बहुत नया हूं (मैं आमतौर पर नौकरी के इस पक्ष को नहीं करता हूं :))।

बहुत धन्यवाद!

Andrija

sql-server sql-server-2005 shrink

— Andrija_Bgd
स्रोत

धन्यवाद मार्क - किसी भी तरह से मैं इस प्रश्न को वहां स्थानांतरित कर सकता हूं या मुझे फिर से पोस्ट करने की आवश्यकता है?

चीयर्स - जैसा कि आप शायद अनुमान लगा सकते हैं, मैं यहां नया हूं :)

11

आपके आकार के अनुमानों में, क्या आपने इंडेक्स द्वारा ली गई जगह की मात्रा को ध्यान में रखा है? यदि आपके पास ऐसे टेक्स्ट फ़ील्ड हैं जो मल्टी-बाइट ( N[VAR]CHARबजाय [VAR]CHAR) के रूप में सेट किए गए हैं और इनपुट फाइलें UTF-8 या प्लेन एक-बाइट-प्रति-वर्ण हैं तो यह आपकी स्टोरेज आवश्यकताओं को दो के कारक तक बढ़ा देगा। इसके अलावा याद रखें कि यदि आपके पास एक मेज पर एक गुच्छेदार कुंजी / सूचकांक है, तो इसका आकार तालिका के अन्य सभी अनुक्रमों को प्रभावित करता है क्योंकि वे हर पंक्ति के लिए संकुल कुंजी मान शामिल करते हैं _{(इसलिए यदि तालिका में NCHAR है तो एक चरम उदाहरण देने के लिए (10) ) कुंजी जहां एक INT करता है और वह आपकी संकुल कुंजी / अनुक्रमणिका है जो आप न केवल डेटा पृष्ठों में प्रति पंक्ति अतिरिक्त 16 बाइट्स का उपयोग कर रहे हैं, आप उस तालिका के प्रत्येक अन्य सूचकांक में प्रति पंक्ति 16 बाइट बर्बाद भी करते हैं )} ।

इसके अलावा, कुछ स्थान आवंटित किया जाएगा, लेकिन अप्रयुक्त, या तो क्योंकि DB इंजन ने हटाए जाने के बाद आवंटित किए गए कुछ स्थान को छोड़ दिया है ताकि इसे उस तालिका में नए डेटा के लिए जल्दी से फिर से उपयोग किया जा सके या क्योंकि आवेषण और डिलीट का पैटर्न केवल कई पृष्ठों को छोड़ दिया है पूर्ण।

तुम दौड़ सकते हो:

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डीबी दो परिणाम सेट लौटाएगा। पहली डेटा फ़ाइलों के लिए फाइलसिस्टम में आवंटित कुल स्थान को सूचीबद्ध करता है और उसमें से कितना असंबद्ध है, दूसरी सूची डेटा पृष्ठों के लिए कितना आवंटित स्थान का उपयोग करता है, सूचकांक पृष्ठों के लिए, या वर्तमान में अप्रयुक्त है।

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और अधिक विवरण प्राप्त करने के लिए http://technet.microsoft.com/en-us/library/ms177862.aspxsys.dm_db_partition_stats देखें ) प्रत्येक सूचकांक द्वारा उपयोग किया जाने वाला स्थान।

डेटा फ़ाइल में अप्रयुक्त स्थान के तीन वर्ग हैं:

वह जो किसी चीज़ के लिए आवंटित नहीं किया गया है (यह पहले परिणाम sp_spaceusedमें कोई वस्तु निर्दिष्ट नहीं से पता चलता है )
वह जो किसी ऑब्जेक्ट (आरक्षित) को आवंटित किया गया है, लेकिन वर्तमान में उपयोग नहीं किया गया है (यह sp_spaceusedआउटपुट में "अप्रयुक्त" गिनती में दिखाता है ।
वह भाग-उपयोग किए गए पृष्ठों में बंद है (यह सब कुछ के रूप में उपयोग करने के लिए उपयोग किया जाएगा, जो एकल पृष्ठ भाग में आवंटित किया गया है, एक पृष्ठ 8,192 बाइट्स लंबा है)। यह पता लगाना / गणना करना कठिन है। यह दो कारकों के मिश्रण के कारण है:
- स्प्लिट पेज। जैसा कि डेटा जोड़ा जाता है आप अक्सर भाग खाली पन्नों के साथ समाप्त हो जाते हैं (भंडारण इंजन हमेशा पृष्ठ सामग्री को सामान्य कर सकता है , लेकिन यह बहुत अक्षम होगा), और पंक्तियों को हटा दिया जाता है पृष्ठ सामग्री स्वचालित रूप से पैक नहीं की जाती है (फिर से वे हो सकते हैं, लेकिन अतिरिक्त आई / ओ लोड आम तौर पर है अब तक इसके लायक) से।
- भंडारण इंजन कई पृष्ठों पर एक पंक्ति को विभाजित नहीं करेगा (यह पृष्ठ आकार के साथ जहां 8,192 बाइट-प्रति-पंक्ति सीमा आती है)। यदि आपकी पंक्तियां निश्चित आकार की हैं और प्रत्येक में 1,100 बाइट्स हैं, तो आप उस टेबल पर आवंटित प्रत्येक डेटा ब्लॉक के कम से कम 492 बाइट्स को "बर्बाद" करने जा रहे हैं (7 पंक्तियां 7,700 बाइट्स लेती हैं और एक 8 वें फिट नहीं होगा इसलिए बचे हुए बाइट्स जीत गए ' t का उपयोग किया जाए)। पंक्तियाँ जितनी व्यापक होंगी, यह उतना ही बुरा हो सकता है। चर / अनुक्रमित चर लंबाई पंक्तियों के साथ (जो पूरी तरह से तय लंबाई की तुलना में कहीं अधिक सामान्य हैं) आम तौर पर बेहतर (लेकिन इस मामले की गणना करने के लिए कम आसान हैं)।
  यहाँ एक और चेतावनी बड़ी वस्तुओं ( TEXTकॉलम,[N]VARCHAR(MAX) एक निश्चित आकार और इतने पर) के रूप में वे ऑफ-पेज रखा जाता है, तो बस मुख्य पंक्ति डेटा में 8 बाइट्स को कहीं और डेटा के लिए एक पॉइंटर रखने के लिए) तो 8,192 बाइट्स-प्रति-पंक्ति-सीमा को तोड़ सकते हैं।

tl; dr: आरंभिक डेटाबेस के आकार का अनुमान लगाना बहुत अधिक शामिल हो सकता है, क्योंकि शुरुआत में यह स्वाभाविक है।

— डेविड स्पिलेट
स्रोत

डेविड - विस्तृत प्रतिक्रिया के लिए बहुत बहुत धन्यवाद! मैं अभी db का विश्लेषण कर रहा हूं और डेटाबेस के आकार को प्रभावित करने वाले कारकों के बारे में मेरी समझ में आपकी और केनेथ की दोनों प्रतिक्रियाएं काफी मददगार रही हैं। मैं हमेशा दक्षता के साथ चिंतित हूँ (दोनों जब यह डेटा अंतर्ग्रहण और डेटा उपयोग की बात आती है) और आपके द्वारा उपलब्ध कराई गई जानकारी अमूल्य है!

— एंड्रीजा_बग्ड

6

sp_spaceusedअपने डेटाबेस पर चलने का प्रयास करें। एक उदाहरण के रूप में यह रिटर्न:

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

डेटाबेस पर इसे चलाने के लिए सिर्फ USEडेटाबेस को चलाएं sp_spaceused।

यदि यह अभी भी अप्रयुक्त स्थान का एक बड़ा सौदा दिखाता है तो आप फिर से सिकुड़ने की कोशिश कर सकते हैं। कभी-कभी मुझे लगता है कि यह कई कोशिशें करता है। इसके अलावा कभी-कभी मुझे लगता है कि डेटाबेस के बजाय समग्र रूप से व्यक्तिगत फ़ाइल को सिकोड़ना सबसे अच्छा काम करता है। हालाँकि आपको जो मिल सकता है वह यह है कि आपके पास 2.9Tb डेटा और अन्य 4 + Tb अनुक्रमित हैं, जिस स्थिति में 7.5TB बहुत उचित है। यदि आप प्रत्येक तालिका के स्थान (डेटा और सूचकांक) की मात्रा प्राप्त करना चाहते हैं तो आप sp_spaceusedटेबल स्तर पर भी दौड़ सकते हैं । आप निम्न आदेश का उपयोग करके डेटाबेस में सभी तालिकाओं में इसे चला सकते हैं:

EXEC sp_msforeachtable 'EXEC sp_spaceused [?];'

हालांकि निष्पक्ष चेतावनी sp_msforeachtable अनिर्दिष्ट है, असमर्थित है और तालिकाओं को याद करने के लिए जाना जाता है। दूसरी ओर मैं खुद इसके साथ किस्मत की एक उचित राशि है।

कहा जा रहा है कि आपके डेटाबेस में आपके अपेक्षित विकास के आधार पर एक निश्चित प्रतिशत खाली जगह है। मूल रूप से आप यह सुनिश्चित करना चाहते हैं कि आपके पास 6 महीने से लेकर कुछ साल की वृद्धि के लिए कहीं भी जगह हो। इसके अलावा, आप autogrowthयह सुनिश्चित करने के लिए अपनी सेटिंग्स की जांच करना चाहेंगे कि वे आपकी स्थिति के लिए उपयुक्त हैं। विशेष रूप से आपके डेटाबेस का आकार जिसे आप% का उपयोग नहीं करना चाहते हैं autogrowth।

— केनेथ फिशर
स्रोत

धन्यवाद! मैंने sp_spaceused का उपयोग किया था और ऐसा लगता है कि वास्तविक डेटा वास्तव में अंतरिक्ष की संकेतित मात्रा को लेता है, जितना अजीब मुझे लगता है कि मुझे फ्लैट फ़ाइलों का वास्तविक आकार दिया गया था जो लोड किए गए थे ... संकेत छोटे हैं (मैं हेवन) टी किसी भी अतिरिक्त लोगों को बनाया क्योंकि वे मेरे मामले में मदद की तुलना में अधिक बाधा बन गए होंगे) तो मुझे लगता है कि यह सिर्फ वास्तविक तालिकाओं में बड़े हैं ... आपकी मदद के लिए एक लाख धन्यवाद!

— एंड्रियाजा_ग्ड

डेटाबेस फ्लैट फ़ाइलों की तुलना में अधिक स्थान लेते हैं। पंक्ति और तालिका संरचनाओं के लिए ओवरहेड की एक निश्चित मात्रा और पृष्ठ संरचना के कारण कचरे की एक निश्चित मात्रा होती है।

— केनेथ फिशर

-1

SQL प्रबंधन स्टूडियो का उपयोग, 1. फिर डेटाबेस पर क्लिक करें 2. कार्य पर क्लिक करें-> सिकोड़ें -> फ़ाइलें

आपको एक डायलॉग दिखाई देगा जो दिखाता है: a। वर्तमान में आवंटित स्थान b। उपलब्ध मुक्त स्थान + (% मुक्त)

यदि आपका% Free 50% से अधिक है तो आप फ़ाइल को सिकोड़ने पर विचार कर सकते हैं। मैंने इस हिट को 90% तक देखा है। यदि मैं फ़ाइल को सिकोड़ने का निर्णय लेता हूं तो आमतौर पर मैं इसे वर्तमान आवंटित स्थान से 2 या 3 गुना अधिक सेट करता हूं। मेरे अधिकांश डेटाबेस 50 जीआईजी से कम हैं। तो अगर आपके पास बहुत बड़ी फाइल है तो आप इसे 10 गिग बड़े बना सकते हैं। मैं आमतौर पर केवल सिकुड़ने के बारे में चिंता करता हूं यदि मैं डेटाबेस को किसी अन्य सर्वर पर स्थानांतरित करने जा रहा हूं, तो आप किसी भी sql पेज पर सिकुड़ते मुद्दों के बारे में पढ़ सकते हैं।

— क्लार्क वेरा
स्रोत