ประมาณการการเติบโตของฐานข้อมูลที่คาดการณ์ไว้

ฉันเพิ่งเริ่มทำงานกับ SQL Server 2008 ในฐานะผู้ฝึกหัด DBA ฉันต้องการคำนวณขนาดของฐานข้อมูล แต่ยังประเมินการเติบโตในช่วงหลายเดือนที่ผ่านมาและการเติบโตที่คาดการณ์ไว้ในอีก 12 เดือนข้างหน้า

ฉันสามารถใช้คำสั่ง sp_spaceused เพื่อคำนวณขนาดจริง แต่ฉันจะคำนวณทุกอย่างได้อย่างไร

คำตอบอื่น ๆ นั้นถูกต้องทางเทคนิค แต่ไม่ถูกต้องในโลกแห่งความจริง นี่คือสิ่งที่คุณต้องถามธุรกิจ:

ฉันกำลังเล็งไปที่ขอบฟ้ากี่โมง ในกรณีของคุณคุณกำลังมองหาหมายเลข 12 เดือน

ในช่วงเวลานั้นเราจะเก็บข้อมูลหรือเก็บข้อมูลทั้งหมดหรือไม่ ในบางธุรกิจคุณได้รับอนุญาตให้ (หรือต้อง) เก็บข้อมูลจำนวนหนึ่งเช่น 12 เดือนที่ผ่านมาเท่านั้น ในกรณีนี้คุณจะต้องทราบถึงการเติบโตของข้อมูล (ซึ่งคำถามต่อไปนี้จะตอบ) แต่จากนั้นย้อนกลับไปในรอบ 12 เดือนที่ผ่านมา คุณไม่สามารถพูดได้ว่า "ตอนนี้ปริมาณข้อมูลคือ 100GB" เพราะถ้าปริมาณข้อมูลของคุณเพิ่มขึ้น 12 เดือนที่ผ่านมาก็เพิ่มขึ้นเช่นกัน จำนวนเวลาอาจคงที่ แต่ข้อมูลไม่ได้

เราจะเพิ่มผู้ใช้เพิ่มเติมหรือไม่ ตัวอย่างเช่นธุรกิจอาจเติบโตไปสู่ดินแดนใหม่หรือการหาลูกค้าใหม่ หากพวกเขาเพิ่มฐานผู้ใช้เป็นสองเท่าดังนั้นในบางกรณีข้อมูลก็จะเริ่มเพิ่มเป็นสองเท่าเช่นกัน

เราคาดหวังว่าปริมาณธุรกิจจะเติบโตหรือไม่ ตัวอย่างเช่นหากคุณกำลังติดตามยอดขายในเว็บไซต์และคุณเริ่มใช้โฆษณา Super Bowl หรือฟุตบอลโลกปริมาณข้อมูลของคุณสามารถเข้าถึงเส้นกราฟการเติบโตของไม้ฮอกกี้ได้

เราจะเพิ่มฟังก์ชันการทำงานเพิ่มเติมในแอปหรือไม่ หากแอปเริ่มเก็บรูปภาพอย่างฉับพลันสิ่งนี้จะส่งผลกระทบต่อขนาดฐานข้อมูลอย่างมาก

เราจะเพิ่มข้อมูลจากแหล่งอื่นหรือบันทึกข้อมูลใหม่หรือไม่ หากคุณเริ่มจับภาพการคลิกเว็บไซต์หรือในคลังข้อมูลการเพิ่มแหล่งข้อมูลเพิ่มเติมปริมาณข้อมูลจะเพิ่มขึ้น

นักพัฒนาหรือ DBA จะเป็นดัชนีการปรับแต่งประสิทธิภาพหรือไม่ หากคุณต้องการให้ผู้คนสร้างดัชนีคุณสามารถเพิ่มขนาดของข้อมูลของคุณเป็นสองเท่า (หรือสามเท่าหรือสี่เท่า) ขึ้นอยู่กับว่าพวกเขามีปัญหามากแค่ไหน

และตราบใดที่คุณถามคำถามเหล่านี้คุณควรถามด้วยว่าการแสดงนั้นคาดว่าจะเหมือนเดิมลดลงหรือดีขึ้นหรือไม่ ฉันชอบการทำแผนที่การเติบโตที่คาดการณ์ไว้ในแผนภูมิเส้นแล้วเปรียบเทียบการลงทุนด้านฮาร์ดแวร์และพนักงานในช่วงเวลาเดียวกัน

คุณไม่สามารถคาดการณ์การเติบโตในอนาคตได้อย่างถูกต้องหากไม่มีประวัติการเติบโตก่อนหน้านี้ แต่คุณสามารถโกงและได้รับแนวโน้มหยาบโดยใช้ประวัติการสำรองข้อมูลเป็นรายละเอียดโดย Erin Stellato ในฐานข้อมูลได้รับความนิยมการเจริญเติบโตจากการสำรองข้อมูล

ลงจุดผลลัพธ์ของแบบสอบถามต่อไปนี้ใน 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]);

มีหลายวิธีที่คุณสามารถวางแผนความจุของฐานข้อมูลได้

ประวัติการสำรองข้อมูล msdb หากได้รับการตัดแต่งเป็นประจำคุณจะไม่เหลือข้อมูลมากพอสำหรับการวิเคราะห์

ดังที่มาร์คชี้ให้เห็นว่ามันสามารถทำได้โดยใช้วิธีการที่อธิบายโดย Erin - แนวโน้มการเติบโตของฐานข้อมูลจากการสำรองข้อมูล

คุณสามารถใช้ PIVOT เพื่อค้นหาการเติบโตของฐานข้อมูลในช่วง 12 เดือนจากประวัติการสำรองดังนี้

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;

ไม่มีทางที่คุณจะพบว่ามีประโยชน์จริงๆตามที่อธิบายไว้อย่างดีอีกคือการวางแผนฐานข้อมูลพื้นที่ความจุ - ชาดมิลเลอร์เอสเอส เขายังเน้นdays remainingที่มีประโยชน์มาก

มีวิธีอื่นที่เกี่ยวข้องกับการคำนวณทางคณิตศาสตร์และสิ่งนี้จะให้ผลลัพธ์ที่ถูกต้อง ดังที่ข้อมูลสำรองชี้ไปแล้วจะดีที่สุดในการอ้างถึงการเติบโตของข้อมูลเนื่องจากคุณบอกว่าคุณจำเป็นต้องคำนวณและทำนายขนาดของฐานข้อมูลด้านล่างลิงก์ Microsoft จะช่วยให้คุณ

ขนาดโดยประมาณของฐานข้อมูล

ขนาดโดยประมาณของดัชนีแบบคลัสเตอร์

ขนาดโดยประมาณของกอง

ขนาดโดยประมาณของตาราง

หวังว่ารหัสนี้ช่วย:

ทำงานตามประวัติขนาดการสำรองข้อมูล (เป็น MB), ให้เดือนโดยเดือน MB ต่ำสุด, avg MB, สูงสุด MB และแตกต่างจากเดือนอื่น MB

แสดงรายการฐานข้อมูลทั้งหมดที่มีการสำรองข้อมูลยกเว้นฐานข้อมูลระบบ

-- 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

ฉันคิดว่าโพสต์ของ Brent Ozar เป็นจุดบน ฉันได้รับในโครงการ DB bloating อย่างมากและมีปัญหาเดียวกันกับที่คุณทำที่นี่และมันก็ไม่ง่าย

อย่างน้อยก็ทำสิ่งที่ดีกว่า - แม้ว่าจะไม่ถูกต้องจริง ๆ - ฉันจะตั้งค่าตารางและงานที่ต้องการ (หรือวิธีอื่นที่คุณต้องการอะไรก็ได้ที่จะถามขนาดและจัดเก็บไว้ที่ไหนสักแห่งที่เชื่อถือได้) แถวและพื้นที่ที่ใช้สำหรับ DB และตารางทั้งหมดเป็นประจำทุกสัปดาห์และใช้มันเพื่อคาดคะเนเส้นกราฟการเติบโตที่เป็นไปได้มากที่สุด การใช้ประวัติการสำรองข้อมูลเป็นความคิดที่ดีเช่นกัน แต่ไม่ว่าจะใช้วิธีใดคุณต้องใช้เวลาในการรับข้อมูลที่เชื่อถือได้จากระยะไกล

นอกจากนั้นมันขึ้นอยู่กับสถานการณ์ของคุณ อาจเป็นการใช้งาน% ของฐานข้อมูลของคุณตอนนี้เป็นเพียงเศษเสี้ยวของสิ่งที่จะเกิดขึ้นในอีก 6 เดือนข้างหน้าเช่นเมื่อซอฟต์แวร์ของคุณมีพื้นที่มากขึ้นทำให้ไม่สามารถคาดการณ์การเติบโตที่กำลังมาแรง อาจมีการถ่ายโอนข้อมูลจำนวนมากเป็นรายปีซึ่งจะเพิ่มขนาดของ DB เป็นสองเท่า แต่คุณจะพบเฉพาะข้อมูลเกี่ยวกับมวลนั้นหลังจากข้อเท็จจริง

แต่อย่างที่บอกถ้าการเจริญเติบโตเป็นเรื่องที่กังวลคุณควรทำอะไรบางอย่างเพื่อติดตามมัน สิ่งสุดท้ายที่คุณต้องการคือการหาตัวคุณเอง 6 เดือนจากนี้ด้วยฐานข้อมูลขนาดใหญ่เป็นสองเท่าของอายุการใช้งานเดิมโดยต้องอธิบายให้ลูกค้าของคุณทราบว่าทำไมหรือทำไมจึงเกิดขึ้นไม่ต้องพูดถึงว่าต้องเริ่มเดาว่า ในอีก 6 เดือนข้างหน้า นอกจากนี้ยังมีประโยชน์บางอย่างที่ชัดเจนของการทราบว่าข้อมูลใหม่หายไปไหนและการเติบโตที่สัมพันธ์กันของแต่ละตารางในระยะเวลาที่กำหนดเนื่องจากสามารถให้ข้อมูลที่มีค่าเกี่ยวกับแนวโน้มที่แตกต่างกันปัญหาซอฟต์แวร์ที่อาจเกิดขึ้นเป็นต้น .