Saya baru-baru ini mulai bekerja dengan SQL Server 2008 sebagai trainee DBA. Saya perlu menghitung ukuran database tetapi juga memperkirakan pertumbuhannya selama beberapa bulan terakhir dan pertumbuhan yang diprediksi untuk 12 bulan ke depan.
Saya bisa menggunakan pernyataan sp_spaceused untuk menghitung ukuran sebenarnya tetapi bagaimana cara menghitung semuanya?
Jawaban:
Jawaban lainnya secara teknis benar, tetapi tidak benar di dunia nyata. Inilah yang perlu Anda tanyakan pada bisnis:
Cakrawala waktu apa yang saya tuju? Dalam kasus Anda, Anda sedang mencari nomor 12 bulan.
Selama waktu itu, apakah kita akan mengarsipkan data, atau menyimpan semua data? Di beberapa bisnis, Anda diizinkan untuk (atau diharuskan) hanya menyimpan sejumlah data tertentu, seperti 12 bulan terakhir. Dalam hal ini, Anda harus mencari tahu pertumbuhan data (yang akan dijawab pertanyaan berikutnya) tetapi kemudian kembali ke 12 bulan terakhir bergulir. Anda tidak bisa mengatakan, "Saat ini jumlah data 100GB," karena jika volume data Anda bertambah, maka 12 bulan terakhir juga bertambah. Jumlah waktu mungkin konstan, tetapi data tidak.
Apakah kami akan menambahkan pengguna tambahan? Misalnya, bisnis mungkin tumbuh ke wilayah baru atau mendapatkan pelanggan baru. Jika mereka menggandakan basis pengguna, maka dalam beberapa kasus, data juga akan mulai berlipat ganda.
Apakah kita berharap volume bisnis akan tumbuh? Jika Anda melacak penjualan di situs web, misalnya, dan Anda mulai menjalankan iklan Super Bowl atau Piala Dunia, volume data Anda dapat mengenai kurva pertumbuhan tongkat hoki.
Apakah kita akan menambahkan fungsionalitas tambahan di aplikasi? Jika aplikasi tiba-tiba mulai menyimpan gambar, ini akan secara dramatis mempengaruhi ukuran basis data.
Apakah kita akan menambahkan data dari sumber lain, atau mencatat data baru? Jika Anda mulai menangkap klik situs web, atau di gudang data, menambahkan sumber tambahan, maka volume data akan bertambah.
Akankah pengembang atau DBA menjadi indeks penyesuaian kinerja? Jika Anda akan membiarkan orang membuat indeks, Anda dapat dengan mudah menggandakan (atau tiga kali lipat, atau empat kali lipat) ukuran data Anda tergantung pada seberapa berlebihan mereka.
Dan selama Anda mengajukan pertanyaan-pertanyaan ini, Anda juga harus bertanya apakah kinerja diharapkan tetap sama, menurunkan, atau menjadi lebih baik. Saya suka memetakan pertumbuhan yang diproyeksikan pada bagan garis, dan kemudian membandingkan investasi pelatihan perangkat keras dan staf dalam timeline yang sama.
Anda tidak dapat secara akurat memproyeksikan pertumbuhan di masa depan tanpa riwayat pertumbuhan sebelumnya. Namun Anda dapat menipu dan mendapatkan tren kasar menggunakan riwayat cadangan, seperti yang dirinci oleh Erin Stellato di Tren Basis Data Pertumbuhan Dari Cadangan .
Plot output dari kueri berikut di 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]);
Ada banyak cara bagaimana Anda dapat melakukan perencanaan kapasitas basis data.
msdb riwayat cadangan jika dipangkas secara teratur, Anda tidak akan memiliki banyak data yang tersisa untuk dianalisis
Seperti yang ditunjukkan oleh Mark, hal itu dapat dilakukan dengan menggunakan metode yang dijelaskan oleh Erin - tren pertumbuhan basis data dari cadangan.
Anda bahkan dapat menggunakan PIVOT untuk mengetahui pertumbuhan basis data selama 12 bulan dari riwayat cadangan seperti di bawah ini:
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;
Ada cara lain yang menurut Anda sangat berguna seperti yang dijelaskan dengan sangat baik oleh Chad Miller pada SSC - Database Space Capacity Planning . Dia juga fokus pada hal days remainingyang sangat berguna.
Ada metode lain yang melibatkan perhitungan matematis dan ini akan memberikan hasil yang akurat. Seperti yang telah ditunjukkan, cadangan sebaiknya mengacu pada pertumbuhan data karena Anda mengatakan Anda perlu menghitung dan memperkirakan ukuran basis data di bawah tautan Microsoft akan membantu Anda
Semoga kode ini Membantu:
Bekerja berdasarkan riwayat ukuran cadangan (dalam MB), memberikan bulan demi bulan MB minimum, rata-rata MB, maks MB, dan perbedaan dari bulan lainnya dalam MB.
Daftar semua basis data dengan cadangan kecuali untuk basis data sistem.
-- 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
Saya pikir posting Brent Ozar tepat. Saya sudah dalam proyek DB besar-besaran membengkak dan memiliki masalah yang sama persis Anda lakukan di sini, dan itu tidak sesederhana itu.
Karena lebih baik setidaknya melakukan sesuatu - bahkan jika tidak terlalu akurat -, saya akan menyiapkan tabel dan pekerjaan yang diperlukan (atau metode lain mana pun yang Anda inginkan, apa pun hanya dengan menanyakan ukuran dan menyimpannya di tempat yang dapat diandalkan) untuk dilacak baris dan ruang yang digunakan untuk DB dan semua tabelnya setiap minggu dan menggunakannya untuk memproyeksikan kurva pertumbuhan yang paling mungkin. Menggunakan riwayat cadangan juga merupakan ide bagus. Namun terlepas dari metode ini, Anda perlu waktu untuk mendapatkan data yang bahkan dapat diandalkan dari jauh.
Selain itu, itu sangat tergantung pada situasi Anda. Mungkin penggunaan% dari DB Anda sekarang hanya sebagian kecil dari apa yang akan terjadi dalam 6 bulan ke depan, misalnya ketika perangkat lunak Anda mendapatkan lebih banyak kekuatan, sehingga tidak mungkin untuk memprediksi pertumbuhan ledakan yang akan datang. Mungkin ada transfer data besar tahunan yang akan menggandakan ukuran DB, tetapi Anda hanya akan mengetahui massa itu setelah fakta.
Tetapi seperti yang dikatakan, jika pertumbuhan adalah masalah, maka Anda benar-benar harus melakukan sesuatu untuk melacaknya. Hal terakhir yang Anda inginkan adalah menemukan diri Anda 6 bulan dari sekarang dengan DB dua kali lebih besar dari proyeksi seumur hidup aslinya, harus menjelaskan kepada pelanggan Anda bagaimana atau mengapa itu terjadi, belum lagi harus mulai menebak berapa banyak lagi akan tumbuh dalam 6 bulan ke depan. Ada juga beberapa manfaat yang sangat jelas dari mengetahui ke mana data baru telah pergi dan apa pertumbuhan relatif setiap tabel dalam jumlah waktu tertentu, karena dapat memberikan informasi berharga tentang tren yang berbeda, potensi masalah perangkat lunak, dll. Semua untuk usaha yang relatif kecil .