अनुमानित डेटाबेस विकास

Question

मैंने हाल ही में SQL Server 2008 के साथ DBA प्रशिक्षु के रूप में काम करना शुरू किया। मुझे डेटाबेस के आकार की गणना करने की आवश्यकता है, लेकिन हाल के महीनों में इसकी वृद्धि और अगले 12 महीनों के लिए अनुमानित वृद्धि का अनुमान है।

मैं वास्तविक आकार की गणना करने के लिए sp_spaceused कथन का उपयोग कर सकता हूं लेकिन मैं बाकी सब चीजों की गणना कैसे कर सकता हूं?

Answer 1

अन्य उत्तर तकनीकी रूप से सही हैं, लेकिन वास्तविक दुनिया के सही नहीं हैं। यहां आपको व्यवसाय से पूछने की आवश्यकता है:

मैं किस समय क्षितिज के लिए लक्ष्य बना रहा हूं? आपके मामले में, आप 12 महीने की संख्या की तलाश कर रहे हैं।

उस समय के दौरान, क्या हम डेटा संग्रह करेंगे, या सभी डेटा रखेंगे? कुछ व्यवसायों में, आपको पिछले 12 महीनों की तरह केवल एक निश्चित मात्रा में डेटा रखने (या आवश्यक) की अनुमति है। उस स्थिति में, आपको डेटा वृद्धि का पता लगाने की आवश्यकता होगी (जो बाद के प्रश्नों का उत्तर देगा) लेकिन फिर अंतिम 12 महीनों में वापस आ जाएगी। आप बस यह नहीं कह सकते हैं, "अभी उस डेटा की मात्रा 100GB है," क्योंकि यदि आपका डेटा वॉल्यूम बढ़ रहा है, तो पिछले 12 महीने भी बढ़ रहे हैं। समय राशि स्थिर हो सकती है, लेकिन डेटा नहीं है।

क्या हम अतिरिक्त उपयोगकर्ता जोड़ेंगे? उदाहरण के लिए, व्यवसाय नए क्षेत्रों में बढ़ रहा हो सकता है या नए ग्राहक प्राप्त कर सकता है। यदि वे उपयोगकर्ता आधार को दोगुना करते हैं, तो कुछ मामलों में, डेटा दोगुना भी शुरू हो जाएगा।

क्या हम व्यापार की मात्रा बढ़ने की उम्मीद करते हैं? यदि आप उदाहरण के लिए किसी वेब साइट पर बिक्री पर नज़र रख रहे हैं, और आप सुपर बाउल या वर्ल्ड कप विज्ञापन चलाना शुरू करते हैं, तो आपका डेटा वॉल्यूम हॉकी स्टिक ग्रोथ कर्व से टकरा सकता है।

क्या हम ऐप में अतिरिक्त कार्यक्षमता जोड़ेंगे? यदि एप्लिकेशन अचानक छवियों को संग्रहीत करना शुरू कर देता है, तो यह नाटकीय रूप से डेटाबेस आकार को प्रभावित करेगा।

क्या हम दूसरे स्रोत से डेटा जोड़ेंगे, या नया डेटा लॉग करेंगे? यदि आप अतिरिक्त स्रोतों को जोड़ते हुए, वेब साइट क्लिक या किसी डेटा वेयरहाउस पर कब्जा करना शुरू करते हैं, तो डेटा की मात्रा बढ़ेगी।

क्या डेवलपर्स या DBA प्रदर्शन ट्यूनिंग इंडेक्स होंगे? यदि आप लोगों को अनुक्रमणिका बनाने जा रहे हैं, तो आप आसानी से अपने डेटा के आकार को दोगुना (या तिगुना, या चौगुना) कर सकते हैं, यह इस बात पर निर्भर करता है कि उन्हें कितनी मात्रा में मिला है।

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

Comments

हां, तो यह क्या है?

— मैक्स वर्नोन

यह इस बात पर निर्भर करता है कि लोग डेटाबेस में क्या डाल रहे हैं, हाँ।

— ब्रेंट ओजर

Answer 2

आप पिछले विकास के इतिहास के बिना भविष्य के विकास को सटीक रूप से प्रोजेक्ट नहीं कर सकते। हालाँकि, आप बैकअप इतिहास का उपयोग करके एक मोटा रुझान प्राप्त कर सकते हैं, जैसा कि ट्रेंडिंग डेटाबेस ग्रोथ फ्रॉम बैकअप में एरिन स्टेलैटो द्वारा विस्तृत है ।

Excel में निम्न क्वेरी का आउटपुट प्लॉट करें:

SELECT
    [Database] = [database_name]
    , [Month] = DATEPART(month,[backup_start_date])
    , [Backup Size MB] = AVG([backup_size]/1024/1024)
    , [Compressed Backup Size MB] = AVG([compressed_backup_size]/1024/1024)
    , [Compression Ratio] = AVG([backup_size]/[compressed_backup_size])
FROM 
    msdb.dbo.backupset
WHERE 
    [database_name] = N'YourDatabaseName'
AND [type] = 'D'
GROUP BY 
    [database_name]
    , DATEPART(mm, [backup_start_date]);

Comments

मैं इसे लगातार उपयोग करता हूं, फिर इसे वर्ष तक जाने के लिए संशोधित करता हूं यदि ऐसा होता है कि क्लाइंट सर्वर पर इतना इतिहास है। एक सर्वर के लिए इस तरह के डेटा को देखकर प्यार होता है।

मुझे @BrentOzar [यहाँ से बैकअप स्क्रिप्ट]) brentozar.com/archive/2012/03/… ) के साथ संयोजन करना भी पसंद है ।

Answer 3

आप डेटाबेस क्षमता योजना कैसे बना सकते हैं, इसके कई तरीके हैं।

एमएसडीबी बैकअप इतिहास यदि नियमित छंटनी हो जाती है, तो आपको विश्लेषण के लिए बहुत अधिक डेटा नहीं होना चाहिए

जैसा कि मार्क ने बताया, यह एरिन द्वारा वर्णित विधि का उपयोग करके किया जा सकता है - बैकअप से डेटाबेस की वृद्धि ट्रेंडिंग।

आप नीचे दिए गए बैकअप इतिहास से 12 महीनों की अवधि में डेटाबेस की वृद्धि का पता लगाने के लिए PIVOT का उपयोग कर सकते हैं:

DECLARE @startDate DATETIME;

SET @startDate = GetDate();

SELECT PVT.DatabaseName
    ,PVT.[0]
    ,PVT.[-1]
    ,PVT.[-2]
    ,PVT.[-3]
    ,PVT.[-4]
    ,PVT.[-5]
    ,PVT.[-6]
    ,PVT.[-7]
    ,PVT.[-8]
    ,PVT.[-9]
    ,PVT.[-10]
    ,PVT.[-11]
    ,PVT.[-12]
FROM (
    SELECT BS.database_name AS DatabaseName
        ,DATEDIFF(mm, @startDate, BS.backup_start_date) AS MonthsAgo
        ,CONVERT(NUMERIC(10, 1), AVG(BF.file_size / 1048576.0)) AS AvgSizeMB
    FROM msdb.dbo.backupset AS BS
    INNER JOIN msdb.dbo.backupfile AS BF ON BS.backup_set_id = BF.backup_set_id
    WHERE BS.database_name NOT IN (
            'master'
            ,'msdb'
            ,'model'
            ,'tempdb'
            )
        AND BS.database_name IN (
            SELECT db_name(database_id)
            FROM master.SYS.DATABASES
            WHERE state_desc = 'ONLINE'
            )
        AND BF.[file_type] = 'D'
        AND BS.backup_start_date BETWEEN DATEADD(yy, - 1, @startDate)
            AND @startDate
    GROUP BY BS.database_name
        ,DATEDIFF(mm, @startDate, BS.backup_start_date)
    ) AS BCKSTAT
PIVOT(SUM(BCKSTAT.AvgSizeMB) FOR BCKSTAT.MonthsAgo IN (
            [0]
            ,[-1]
            ,[-2]
            ,[-3]
            ,[-4]
            ,[-5]
            ,[-6]
            ,[-7]
            ,[-8]
            ,[-9]
            ,[-10]
            ,[-11]
            ,[-12]
            )) AS PVT
ORDER BY PVT.DatabaseName;

एक और तरीका है कि आप SSC - डेटाबेस स्पेस कैपेसिटी प्लानिंग पर चाड मिलर द्वारा वर्णित रूप में बहुत उपयोगी पाएंगे । वह भी ध्यान केंद्रित करता है days remainingजो बहुत उपयोगी है।

Comments

मैं क्वेरी के ऊपर उपयोग कर रहा हूं और यह मुझे SSISDB 11059.5 10233.6 9322.9 8338.8 7675.6 7075.1 6383.7 5592.6 4862.1 (0 के लिए -1, -2, -3) जैसे परिणाम दे रहा है। आदि ... इस मूल्य का क्या मतलब है? क्या इसका मतलब है कि एमबी में मेरी पंक्ति का आकार 11059 है और अगले महीने 10233 एमबी तक बढ़ जाएगा? मैं आउटपुट के साथ भ्रमित हूँ .. क्या आप कृपया मेरी सहायता कर सकते हैं

— Zerotoinfinity

Answer 4

गणितीय गणनाओं को शामिल करने की अन्य विधि है और यह सटीक परिणाम देगा। जैसा कि पहले ही बताया गया बैकअप डेटा वृद्धि को संदर्भित करने के लिए सबसे अच्छा होगा क्योंकि आपने कहा था कि आपको Microsoft लिंक्स के नीचे डेटाबेस के आकार की गणना करने और भविष्यवाणी करने की आवश्यकता है

डाटाबेस का अनुमानित आकार

क्लस्टर इंडेक्स का अनुमानित आकार

ढेर का अनुमानित आकार

तालिका का अनुमानित आकार

Answer 5

आशा है कि यह कोड मदद करता है:

बैकअप आकार के इतिहास (एमबी में) के आधार पर काम करता है, महीने को न्यूनतम एमबी, एवी एमबी, अधिकतम एमबी और एमबी में अन्य महीने से अंतर देता है।

सिस्टम डेटाबेस को छोड़कर सभी डेटाबेस को बैकअप के साथ सूचीबद्ध करता है।

-- T-SQL script - Analyses database growth using backup information (Last (12) months in that case
-- Looks only to FULL backups information
-- Parameters: Date GetDate() and nr of months to analyse

SET NOCOUNT ON
DECLARE @endDate datetime, @months smallint; 
SET @endDate = GetDate();  -- Data atual
SET @months = 12;          -- Nr. de meses a analisar

;WITH HIST AS 
   (SELECT BS.database_name AS DatabaseName 
          ,YEAR(BS.backup_start_date) * 100 
           + MONTH(BS.backup_start_date) AS YearMonth 
          ,CONVERT(numeric(10, 1), MIN(BS.backup_size / 1048576.0)) AS MinSizeMB 
          ,CONVERT(numeric(10, 1), MAX(BS.backup_size / 1048576.0)) AS MaxSizeMB 
          ,CONVERT(numeric(10, 1), AVG(BS.backup_size / 1048576.0)) AS AvgSizeMB 
    FROM msdb.dbo.backupset as BS 
    WHERE NOT BS.database_name IN 
              ('master', 'msdb', 'model', 'tempdb') 
          AND BS.type = 'D' 
          AND BS.backup_start_date BETWEEN DATEADD(mm, - @months, @endDate) AND     @endDate 
    GROUP BY BS.database_name 
            ,YEAR(BS.backup_start_date) 
            ,MONTH(BS.backup_start_date)) 
SELECT @@SERVERNAME
      ,MAIN.DatabaseName 
      ,MAIN.YearMonth 
      ,MAIN.MinSizeMB 
      ,MAIN.MaxSizeMB 
      ,MAIN.AvgSizeMB 
      ,MAIN.AvgSizeMB  
       - (SELECT TOP 1 SUB.AvgSizeMB 
          FROM HIST AS SUB 
          WHERE SUB.DatabaseName = MAIN.DatabaseName 
                AND SUB.YearMonth < MAIN.YearMonth 
          ORDER BY SUB.YearMonth DESC) AS GrowthMB 
FROM HIST AS MAIN 
ORDER BY MAIN.DatabaseName 
        ,MAIN.YearMonth

Answer 6

मुझे लगता है कि ब्रेंट ओजर की पोस्ट पर हाजिर है। मैं एक बड़े पैमाने पर ब्लोटिंग डीबी परियोजना में रहा हूं और आपके पास यहां बिल्कुल वही मुद्दा था, और यह इतना आसान नहीं है।

चूंकि कम से कम कुछ करना बेहतर है - भले ही वह वास्तव में सटीक नहीं है -, मैं आवश्यक तालिकाओं और एक नौकरी (या जो भी आप चाहते हैं अन्य विधि सेट करेंगे, कुछ भी आकार को क्वेरी करने और इसे कहीं मज़बूती से संग्रहीत करने के लिए) साप्ताहिक आधार पर DB और इसकी सभी तालिकाओं के लिए उपयोग की जाने वाली पंक्तियाँ और स्थान का उपयोग करें और सबसे संभावित विकास वक्र को प्रोजेक्ट करने के लिए उपयोग करें। बैकअप इतिहास का उपयोग करना भी एक महान विचार है। लेकिन विधि की परवाह किए बिना, आपको दूर से विश्वसनीय डेटा प्राप्त करने के लिए समय की आवश्यकता होती है।

इसके अलावा, यह वास्तव में आपकी स्थिति पर निर्भर करता है। यह आपके DB का उपयोग% हो सकता है अब यह केवल अगले 6 महीनों में क्या होगा इसका एक अंश है, उदाहरण के लिए जब आपका सॉफ़्टवेयर अधिक ज़मीन हासिल करता है, तो यह आने वाले विस्फोटक विकास की भविष्यवाणी करना असंभव बनाता है। यह वार्षिक बड़े पैमाने पर डेटा ट्रांसफ़र हो सकता है जो डीबी के आकार को दोगुना कर देगा, लेकिन आप केवल तथ्य के बाद उस द्रव्यमान के बारे में पता लगाएंगे।

लेकिन जैसा कि कहा गया है, अगर विकास चिंता का विषय है, तो आपको इसका ध्यान रखने के लिए कुछ करना चाहिए। आखिरी चीज जो आप चाहते हैं, अपने आप को 6 महीने से अब तक एक डीबी के साथ अपने मूल जीवनकाल प्रक्षेपण के रूप में दो बार बड़े पैमाने पर ढूंढना है, अपने ग्राहक को यह समझाना है कि ऐसा कैसे हुआ या क्यों हुआ, यह अनुमान लगाने के लिए भी शुरू नहीं हुआ कि यह कितना बढ़ेगा। अगले 6 महीनों में। यह जानने के कुछ बहुत स्पष्ट लाभ हैं कि नया डेटा कहां गया है और किसी दिए गए समय में प्रत्येक तालिका की सापेक्ष वृद्धि क्या है, क्योंकि यह अपेक्षाकृत छोटे प्रयासों के लिए विभिन्न रुझानों, संभावित सॉफ्टवेयर मुद्दों आदि पर बहुमूल्य जानकारी प्रदान कर सकता है। ।