Gần đây tôi đã bắt đầu làm việc với SQL Server 2008 với tư cách là một thực tập sinh DBA. Tôi cần tính toán kích thước của cơ sở dữ liệu nhưng cũng ước tính mức tăng trưởng của nó trong những tháng gần đây và mức tăng trưởng dự đoán trong 12 tháng tới.
Tôi có thể sử dụng câu lệnh sp_spaceuse để tính kích thước thực tế nhưng làm cách nào để tính toán mọi thứ khác?
Câu trả lời:
Các câu trả lời khác là đúng về mặt kỹ thuật, nhưng không đúng trong thế giới thực. Đây là những gì bạn cần hỏi doanh nghiệp:
Tôi đang nhắm đến thời gian nào? Trong trường hợp của bạn, bạn đang tìm kiếm một số 12 tháng.
Trong thời gian đó, chúng tôi sẽ lưu trữ dữ liệu hay giữ tất cả dữ liệu? Ở một số doanh nghiệp, bạn được phép (hoặc bắt buộc) chỉ giữ một lượng dữ liệu nhất định, như 12 tháng qua. Trong trường hợp đó, bạn sẽ cần phải tìm ra sự tăng trưởng dữ liệu (mà các câu hỏi tiếp theo sẽ trả lời) nhưng sau đó quay trở lại 12 tháng qua. Bạn không thể chỉ nói: "Ngay bây giờ lượng dữ liệu đó là 100 GB", bởi vì nếu khối lượng dữ liệu của bạn tăng lên, thì 12 tháng qua cũng tăng theo. Lượng thời gian có thể không đổi, nhưng dữ liệu thì không.
Chúng tôi sẽ thêm người dùng bổ sung? Ví dụ: doanh nghiệp có thể đang phát triển sang các lãnh thổ mới hoặc có được khách hàng mới. Nếu họ nhân đôi cơ sở người dùng, thì trong một số trường hợp, dữ liệu cũng sẽ bắt đầu nhân đôi.
Chúng ta có mong đợi khối lượng kinh doanh tăng trưởng? Ví dụ: nếu bạn đang theo dõi doanh số bán hàng trên một trang web và bạn bắt đầu chạy quảng cáo Super Bowl hoặc World Cup, khối lượng dữ liệu của bạn có thể chạm vào đường cong tăng trưởng của khúc côn cầu.
Chúng tôi sẽ thêm chức năng bổ sung trong ứng dụng? Nếu ứng dụng đột nhiên bắt đầu lưu trữ hình ảnh, điều này sẽ ảnh hưởng đáng kể đến kích thước cơ sở dữ liệu.
Chúng tôi sẽ thêm dữ liệu từ một nguồn khác, hoặc đăng nhập dữ liệu mới? Nếu bạn bắt đầu ghi lại các lần nhấp vào trang web hoặc trong kho dữ liệu, thêm các nguồn bổ sung, thì khối lượng dữ liệu sẽ tăng lên.
Các nhà phát triển hoặc DBA sẽ là các chỉ số điều chỉnh hiệu suất? Nếu bạn sẽ cho phép mọi người tạo chỉ mục, bạn có thể dễ dàng nhân đôi (hoặc gấp ba hoặc gấp bốn lần) kích thước dữ liệu của mình tùy thuộc vào mức độ họ quá nhiệt tình.
Và miễn là bạn đang hỏi những câu hỏi này, bạn cũng nên hỏi xem hiệu suất có được giữ nguyên, giảm hoặc tốt hơn không. Tôi thích vạch ra sự tăng trưởng dự kiến trên biểu đồ đường, và sau đó so sánh các khoản đầu tư đào tạo phần cứng và nhân viên trên cùng dòng thời gian đó.
Bạn không thể dự đoán chính xác sự tăng trưởng trong tương lai mà không có lịch sử tăng trưởng trước đó. Tuy nhiên, bạn có thể gian lận và nhận được xu hướng thô bằng cách sử dụng lịch sử sao lưu, như chi tiết của Erin Stellato trong Xu hướng tăng trưởng cơ sở dữ liệu từ các bản sao lưu .
Vẽ sơ đồ đầu ra của truy vấn sau trong 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]);Có nhiều cách để bạn có thể lập kế hoạch dung lượng cơ sở dữ liệu.
Lịch sử sao lưu msdb nếu được cắt xén thường xuyên, bạn sẽ không còn nhiều dữ liệu để phân tích
Như Mark đã chỉ ra, nó có thể được thực hiện bằng phương pháp được mô tả bởi Erin - xu hướng tăng trưởng cơ sở dữ liệu từ bản sao lưu.
Bạn thậm chí có thể sử dụng PIVOT để tìm hiểu sự tăng trưởng cơ sở dữ liệu trong khoảng thời gian 12 tháng kể từ lịch sử sao lưu như sau:
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;Có một cách khác mà bạn sẽ thấy thực sự hữu ích như được mô tả xuất sắc bởi Chad Miller trên SSC - Lập kế hoạch dung lượng không gian cơ sở dữ liệu . Ông cũng tập trung vào days remainingđó là rất hữu ích.
Có một phương pháp khác liên quan đến các phép tính toán học và điều này sẽ cho kết quả chính xác. Vì các bản sao lưu đã được chỉ ra sẽ là tốt nhất để tham khảo tăng trưởng dữ liệu vì bạn nói rằng bạn cần tính toán và dự đoán kích thước của cơ sở dữ liệu bên dưới các liên kết của Microsoft sẽ giúp bạn
Ước tính kích thước của cơ sở dữ liệu
Hy vọng mã này sẽ giúp:
Hoạt động dựa trên lịch sử kích thước sao lưu (tính bằng MB), cung cấp từng tháng theo MB, avg MB, MB tối đa và chênh lệch so với tháng khác tính bằng MB.
Liệt kê tất cả các cơ sở dữ liệu có bản sao lưu ngoại trừ cơ sở dữ liệu hệ thống.
-- 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.YearMonthTôi nghĩ rằng bài viết của Brent Ozar là tại chỗ. Tôi đã tham gia vào một dự án DB ồ ạt và có cùng một vấn đề bạn làm ở đây, và nó không đơn giản như vậy.
Vì tốt nhất là nên làm một cái gì đó - ngay cả khi không thực sự chính xác -, tôi đã thiết lập các bảng cần thiết và một công việc (hoặc bất kỳ phương pháp nào bạn muốn, bất cứ điều gì chỉ cần truy vấn kích thước và lưu trữ ở đâu đó một cách đáng tin cậy) để theo dõi các hàng và không gian được sử dụng cho DB và tất cả các bảng của nó trên cơ sở hàng tuần và sử dụng điều đó để chiếu đường cong tăng trưởng có khả năng nhất. Sử dụng lịch sử sao lưu cũng là một ý tưởng tuyệt vời. Nhưng bất kể phương pháp nào, bạn cần thời gian để có được dữ liệu thậm chí từ xa đáng tin cậy.
Ngoài ra, nó thực sự phụ thuộc vào tình hình của bạn. Nó có thể là% sử dụng DB của bạn bây giờ chỉ là một phần nhỏ trong 6 tháng tới, ví dụ như khi phần mềm của bạn tăng thêm điểm, khiến cho không thể dự đoán được sự tăng trưởng bùng nổ sắp tới. Có thể có những lần chuyển dữ liệu khổng lồ hàng năm sẽ tăng gấp đôi kích thước của DB, nhưng bạn sẽ chỉ tìm hiểu về khối lượng đó sau khi thực tế.
Nhưng như đã nói, nếu tăng trưởng là một mối quan tâm, thì bạn hoàn toàn nên làm gì đó để theo dõi nó. Điều cuối cùng bạn muốn là tìm cho mình 6 tháng kể từ bây giờ với DB lớn gấp đôi so với dự đoán trọn đời ban đầu của nó, phải giải thích cho khách hàng của bạn về việc đó hoặc tại sao điều đó xảy ra, thậm chí không đề cập đến việc phải bắt đầu đoán xem nó sẽ tăng thêm bao nhiêu nữa trong 6 tháng tới. Ngoài ra còn có một số lợi ích rất rõ ràng khi biết dữ liệu mới đã đi đâu và mức tăng trưởng tương đối của mỗi bảng trong một khoảng thời gian nhất định, vì nó có thể cung cấp thông tin có giá trị về các xu hướng khác nhau, các vấn đề phần mềm tiềm năng, v.v. .