예상 데이터베이스 증가 예측

최근에 DBA 교육생으로 SQL Server 2008을 사용하기 시작했습니다. 데이터베이스의 크기를 계산해야하지만 최근 몇 개월 동안의 성장률과 향후 12 개월 동안의 예상 성장률을 추정해야합니다.

sp_spaceused 문을 사용하여 실제 크기를 계산할 수 있지만 다른 모든 것을 어떻게 계산합니까?

다른 답변은 기술적으로는 정확하지만 실제적으로는 정확하지 않습니다. 비즈니스에 문의해야 할 사항은 다음과 같습니다.

내가 목표로하는 시간대는 무엇입니까? 귀하의 경우 12 개월 번호를 찾고 있습니다.

그 기간 동안 데이터를 보관하거나 모든 데이터를 보관합니까? 일부 비즈니스에서는 지난 12 개월과 같이 특정 양의 데이터 만 보관해야합니다. 이 경우 데이터 증가 (이후 질문에 대한 답변)를 파악한 다음 마지막 12 개월로 되돌아 가야합니다. 데이터 볼륨이 커지면 지난 12 개월도 늘어나 기 때문에 "지금은 데이터 양이 100GB입니다"라고 말할 수는 없습니다. 시간은 일정하지만 데이터는 다릅니다.

추가 사용자를 추가 할 예정입니까? 예를 들어, 비즈니스가 새로운 영역으로 성장하거나 새로운 고객을 확보하고있을 수 있습니다. 이들이 사용자를 두 배로 늘리면 경우에 따라 데이터도 배가되기 시작합니다.

사업 규모가 커질 것으로 예상됩니까? 예를 들어 웹 사이트에서 판매를 추적하고 Super Bowl 또는 World Cup 광고를 시작하면 데이터 볼륨이 하키 스틱 성장 곡선에 도달 할 수 있습니다.

앱에 추가 기능을 추가 할 예정입니까? 앱이 갑자기 이미지 저장을 시작하면 데이터베이스 크기에 큰 영향을 미칩니다.

다른 소스의 데이터를 추가하거나 새 데이터를 기록합니까? 웹 사이트 클릭 캡처 또는 데이터웨어 하우스에서 소스를 추가하면 데이터 볼륨이 커집니다.

개발자 또는 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 백업 기록이 정기적으로 정리되면 분석 할 데이터가 많이 남지 않습니다.

Mark가 지적했듯이 백업에서 데이터베이스 증가 추세 인 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;

SSC- 데이터베이스 공간 용량 계획에 대한 Chad Miller의 설명에 따라 유용하게 사용할 수있는 또 다른 방법이 있습니다 . 그는 또한 days remaining어느 것이 매우 유용한 지에 중점을 둡니다 .

수학적 계산과 관련된 다른 방법이 있으며 이는 정확한 결과를 제공합니다. 이미 지적한 바와 같이 Microsoft 링크 아래에서 데이터베이스 크기를 계산하고 예측해야한다고 말했기 때문에 데이터 증가를 나타내는 것이 가장 좋습니다.

데이터베이스의 예상 크기

군집 지수의 추정 크기

힙 크기 추정

테이블의 예상 크기

이 코드가 도움이되기를 바랍니다.

백업 크기 기록 (MB)을 기반으로 작동하며 월별 최소 MB, 평균 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

브렌트 오자르의 게시물이 제자리에 있다고 생각합니다. 나는 방대한 DB 프로젝트에 있었고 여기에서하는 것과 똑같은 문제가 있었으며 그렇게 간단하지 않습니다.

적어도 실제로는 정확하지는 않지만 무언가를하는 것이 낫기 때문에 필요한 테이블과 작업 (또는 원하는 다른 방법, 크기를 쿼리하고 안정적으로 저장하는 것)을 설정하여 추적했습니다. DB와 모든 테이블에 매주 사용되는 행과 공간을 사용하여 가장 가능성있는 성장 곡선을 계획합니다. 백업 기록을 사용하는 것도 좋은 생각입니다. 그러나 방법에 관계없이 원격으로 신뢰할 수있는 데이터를 얻을 수있는 시간이 필요합니다.

그 외에는 실제로 상황에 따라 다릅니다. DB의 사용률이 이제 향후 6 개월 동안의 일부일 것입니다. 예를 들어 소프트웨어가 더 많은 기반을 확보하여 다가올 폭발적인 성장을 예측하는 것은 불가능합니다. DB의 크기를 두 배로 늘리는 연간 대량의 데이터 전송이있을 수 있지만 사실 이후에는 해당 질량에 대해서만 알 수 있습니다.

그러나 성장이 우려되는 경우에는 반드시 추적해야 할 일을해야합니다. 마지막으로 원하는 것은 6 개월 후 DB를 사용하여 원래의 평생 예측보다 2 배 더 큰 규모를 유지하는 것입니다. 고객에게 어떻게, 왜 그런 일이 있었는지 설명해야하며, 얼마나 더 많이 성장할 것인지 추측하지 않아도됩니다. 앞으로 6 개월 안에 새로운 데이터가 어디로 갔는지, 주어진 시간 동안 각 테이블의 상대적 증가량을 아는 것의 명백한 이점도 있습니다. 상대적으로 적은 노력으로 다른 트렌드, 잠재적 인 소프트웨어 문제 등에 대한 귀중한 정보를 제공 할 수 있기 때문입니다. .