Kısa süre önce SQL Server 2008 ile DBA stajyeri olarak çalışmaya başladım. Veritabanının boyutunu hesaplamam gerekiyor, ancak son aylardaki büyümesini ve önümüzdeki 12 ay için öngörülen büyümeyi tahmin etmem gerekiyor.
Gerçek boyutu hesaplamak için sp_spaceused deyimini kullanabilirsiniz, ancak diğer her şeyi nasıl hesaplayabilirim?
Yanıtlar:
Diğer cevaplar teknik olarak doğrudur, ancak gerçek dünyada doğru değildir. İşletmeye sormak için gerekenler:
Ne zaman ufkunu hedefliyorum? Sizin durumunuzda, 12 aylık bir sayı arıyorsunuz.
Bu süre boyunca, verileri arşivliyor muyuz yoksa tüm verileri saklıyor muyuz? Bazı işletmelerde, son 12 ay gibi yalnızca belirli bir miktarda veri bulundurmanıza izin verilir (veya zorunlu tutulur). Bu durumda, veri büyümesini (sonraki soruların cevaplayacağı) anlamanız gerekir, ancak son 12 aya geri dönmeniz gerekir. "Şu anda bu miktar 100 GB" diyemezsiniz, çünkü veri hacminiz büyüyorsa, son 12 ay da büyüyor. Zaman miktarı sabit olabilir, ancak veriler sabit değildir.
Ek kullanıcılar ekleyecek miyiz? Örneğin, işletme yeni bölgelere doğru büyüyor veya yeni müşteriler kazanıyor olabilir. Kullanıcı tabanını ikiye katlarlarsa, bazı durumlarda veriler de ikiye katlanmaya başlar.
İş hacminin büyümesini bekliyor muyuz? Örneğin, bir web sitesindeki satışları izliyorsanız ve Super Bowl veya Dünya Kupası reklamları yayınlamaya başlıyorsanız, veri hacminiz hokey sopası büyüme eğrisine çarpabilir.
Uygulamaya ek işlevler ekleyecek miyiz? Uygulama aniden görüntüleri depolamaya başlarsa, bu veritabanı boyutunu önemli ölçüde etkiler.
Başka bir kaynaktan veri ekleyecek miyiz, yoksa yeni veriler kaydedecek miyiz? Web sitesi tıklamaları yakalamaya başlarsanız veya bir veri ambarında ek kaynaklar eklerseniz, veri hacmi artar.
Geliştiriciler veya DBA'lar performans ayarlama endeksleri olacak mı? Kullanıcıların dizin oluşturmalarına izin verirseniz, verilerinizin ne kadar aşırı hevesli olduğuna bağlı olarak verilerinizin boyutunu kolayca iki katına çıkarabilir (veya üçe katlayabilir veya dört katına çıkarabilirsiniz).
Ve bu soruları sorduğunuz sürece, performansın aynı kalması, bozulması ya da iyileşmesi bekleniyor mu diye sormalısınız. Öngörülen büyümeyi çizgi grafiğinde haritalamayı ve ardından aynı zaman çizelgesinde donanım ve personel eğitimi yatırımlarını karşılaştırmayı seviyorum.
Daha önceki bir büyüme geçmişi olmadan gelecekteki büyümeyi doğru bir şekilde yansıtamazsınız. Bununla birlikte, Eğilimlerden Büyüyen Veritabanı Büyümesi'nde Erin Stellato'nun detaylandırdığı gibi yedekleme geçmişini kullanarak hile yapabilir ve kaba bir trend elde edebilirsiniz .
Excel'de aşağıdaki sorgunun çıktısını çizin:
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]);Veritabanı kapasite planlaması yapmanın birçok yolu vardır.
msdb yedekleme geçmişi düzenli olarak kesilirse, analiz için fazla veri kalmayacaksınız
Mark'ın işaret ettiği gibi, Erin tarafından tarif edilen yöntem kullanılarak yapılabilir - yedeklemeden trend veritabanı büyümesi.
PIVOT'u, yedekleme geçmişinden 12 aylık bir süre içinde aşağıdaki gibi veritabanı büyümesini bulmak için bile kullanabilirsiniz:
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;Chad Miller'ın SSC - Veritabanı Alanı Kapasite Planlaması konusunda mükemmel bir şekilde tarif edildiği gibi gerçekten kullanışlı bulmanın başka bir yolu var . Ayrıca days remaininghangisinin çok yararlı olduğuna da odaklanıyor .
Matematiksel hesaplamaları içeren başka bir yöntem daha vardır ve bu doğru sonuçlar verecektir. Zaten işaret ettiğimiz yedeklemeler veri büyümesine atıfta bulunacağından, Microsoft bağlantılarının altındaki veritabanı boyutunu hesaplamanız ve tahmin etmeniz gerektiğini söylediğiniz için
Veritabanının Boyutunu Tahmin Et
Umarım bu kod yardımcı olur:
Yedekleme boyutu geçmişine (MB cinsinden) dayanarak çalışır, aydan aya MB, ortalama MB, maksimum MB ve diğer aydan MB cinsinden fark verir.
Sistem veritabanları hariç yedekli tüm veritabanlarını listeler.
-- 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.YearMonthBence Brent Ozar'ın görevi yerinde. Çok şişkin bir DB projesinde bulundum ve burada yaptığınızla aynı sorunu yaşadım ve bu o kadar basit değil.
En azından bir şey yapmak daha iyi olduğu için - gerçekten doğru olmasa bile - izlemek için gerekli tabloları ve bir işi (veya istediğiniz herhangi bir yöntemi, sadece boyutları sorgulamak ve güvenilir bir yerde saklamak için) herhangi bir şey ayarlardım DB ve tüm tabloları için haftalık olarak kullanılan satırlar ve alan ve bunu en olası büyüme eğrisini yansıtmak için kullanın. Yedekleme geçmişini kullanmak da harika bir fikir. Ancak yönteme bakılmaksızın, uzaktan güvenilir veri elde etmek için zamana ihtiyacınız vardır.
Bunun dışında gerçekten durumunuza bağlı. DB'nizin% 'si artık önümüzdeki 6 ay içinde olacağının sadece bir kısmı olabilir, örneğin yazılımınız daha fazla yer kazandığında, gelecekteki patlayıcı büyümeyi tahmin etmeyi imkansız hale getirir. DB'nin büyüklüğünü iki katına çıkaracak yıllık büyük veri aktarımları olabilir, ancak bu kütle hakkında yalnızca bu gerçeği öğreneceksiniz.
Ancak, dediğim gibi, eğer büyüme bir endişe ise, onu takip etmek için kesinlikle bir şeyler yapmalısınız. İstediğiniz son şey, 6 ay sonra kendinizi orijinal yaşam boyu projeksiyonundan iki kat daha büyük bir DB ile bulmak, müşterinize bunun nasıl veya neden olduğunu açıklamak zorunda kalmak, ne kadar daha fazla büyüyeceğini tahmin etmeye başlamak zorunda kalmamak bile önümüzdeki 6 ay içinde. Aynı zamanda, yeni verilerin nereye gittiğini ve belirli bir sürede her tablonun göreceli büyümesinin ne olduğunu bilmenin çok belirgin faydaları vardır, çünkü nispeten küçük çabalar için farklı eğilimler, potansiyel yazılım sorunları vb. .