Kiểm tra tình trạng máy chủ SQL Proactive, Phần 1:Dung lượng đĩa

Khi năm 2014 kết thúc, tôi sẽ bắt đầu một loạt bài đăng về kiểm tra tình trạng SQL Server chủ động, dựa trên bài viết tôi đã viết lại vào đầu năm nay - Các vấn đề về hiệu suất:Cuộc gặp gỡ đầu tiên. Trong bài đăng đó, tôi đã thảo luận về những gì tôi tìm kiếm đầu tiên khi khắc phục sự cố hiệu suất trong một môi trường không quen thuộc. Trong loạt bài đăng này, tôi muốn nói về những gì tôi tìm kiếm khi nhận phòng với khách hàng lâu năm của mình. Chúng tôi cung cấp dịch vụ DBA Từ xa và một trong những nhiệm vụ thường xuyên của chúng tôi là kiểm tra sức khỏe “nhỏ” hàng tháng về môi trường của chúng. Chúng tôi có giám sát tại chỗ và thông thường, tôi đang làm việc trong các dự án, vì vậy tôi thường xuyên ở trong môi trường. Nhưng như một bước bổ sung để đảm bảo rằng chúng tôi không bỏ sót bất kỳ thứ gì, mỗi tháng một lần, chúng tôi xem xét cùng một dữ liệu mà chúng tôi thu thập trong kiểm tra sức khỏe tiêu chuẩn của mình và tìm kiếm bất kỳ điều gì khác thường. Đó có thể là nhiều thứ, phải không? Đúng! Vì vậy, hãy bắt đầu với không gian.

Chà, không gian? Có, không gian. Đừng lo lắng, tôi sẽ chuyển sang các chủ đề khác. ☺

Những gì cần kiểm tra

Tại sao tôi lại bắt đầu với khoảng trắng? Bởi vì đó là thứ mà tôi thường thấy bị bỏ quên và nếu bạn hết dung lượng đĩa cho các tệp cơ sở dữ liệu của mình, bạn sẽ trở nên cực kỳ hạn chế trong những gì bạn có thể làm trong cơ sở dữ liệu của mình. Cần thêm dữ liệu nhưng không thể phát triển tệp vì đĩa đã đầy? Xin lỗi, bây giờ người dùng không thể thêm dữ liệu. Không sao lưu nhật ký vì một số lý do, vì vậy nhật ký giao dịch đầy ổ đĩa? Xin lỗi, bây giờ bạn không thể sửa đổi bất kỳ dữ liệu nào. Không gian là rất quan trọng. Chúng tôi có các công việc theo dõi dung lượng trống trên đĩa và trong các tệp, nhưng tôi vẫn xác minh những điều sau cho mỗi lần kiểm tra và so sánh các giá trị với những giá trị từ tháng trước:

Kích thước của mỗi tệp nhật ký
Kích thước của mỗi tệp dữ liệu
Dung lượng trống trong mỗi tệp dữ liệu
Dung lượng trống trên mỗi ổ với các tệp cơ sở dữ liệu
Dung lượng trống trên mỗi ổ với các tệp sao lưu

Tăng trưởng tệp nhật ký

Phần lớn các vấn đề tôi gặp liên quan đến dung lượng ổ đĩa là do sự tăng trưởng của tệp nhật ký. Sự tăng trưởng thường xảy ra vì một trong hai lý do:

Cơ sở dữ liệu đang được khôi phục ĐẦY ĐỦ và các bản sao lưu nhật ký giao dịch sẽ không được thực hiện vì một số lý do
Ai đó chạy một giao dịch đơn lẻ, rất lớn, sử dụng tất cả không gian nhật ký hiện có, buộc tệp phải phát triển

Tôi cũng đã thấy tệp nhật ký phát triển như một phần của quá trình duy trì chỉ mục. Đối với các bản xây dựng lại, mọi phân bổ đều được ghi nhật ký và đối với các chỉ mục lớn, có thể tạo ra một lượng nhật ký đáng kể. Ngay cả với các bản sao lưu nhật ký giao dịch thông thường, nhật ký vẫn có thể phát triển nhanh hơn các bản sao lưu có thể xảy ra. Để quản lý nhật ký, bạn cần điều chỉnh tần suất sao lưu hoặc sửa đổi phương pháp duy trì chỉ mục của mình.

Bạn cần xác định lý do tại sao tệp nhật ký lại lớn lên, điều này có thể phức tạp trừ khi bạn đang theo dõi nó. Tôi có một công việc chạy hàng giờ để xem nhanh kích thước và việc sử dụng tệp nhật ký:

USE [Baselines];
GO
 
IF (NOT EXISTS (SELECT * 
                 FROM INFORMATION_SCHEMA.TABLES 
                 WHERE TABLE_SCHEMA = 'dbo' 
                 AND  TABLE_NAME = 'SQLskills_TrackLogSpace'))
 
BEGIN
	CREATE TABLE [dbo].[SQLskills_TrackLogSpace](
		[DatabaseName] [VARCHAR](250) NULL,
		[LogSizeMB] [DECIMAL](38, 0) NULL,
		[LogSpaceUsed] [DECIMAL](38, 0) NULL,
		[LogStatus] [TINYINT] NULL,
		[CaptureDate] [DATETIME2](7) NULL
	) ON [PRIMARY];
 
	ALTER TABLE [dbo].[SQLskills_TrackLogSpace] ADD  DEFAULT (SYSDATETIME()) FOR [CaptureDate];
 
END
 
CREATE TABLE #LogSpace_Temp (
	DatabaseName VARCHAR(100),
	LogSizeMB DECIMAL(10,2),
	LogSpaceUsed DECIMAL(10,2),
	LogStatus VARCHAR(1)
	);
 
INSERT INTO #LogSpace_Temp EXEC('dbcc sqlperf(logspace)');
 
INSERT INTO Baselines.dbo.SQLskills_TrackLogSpace 
	(DatabaseName, LogSizeMB, LogSpaceUsed, LogStatus)
	SELECT DatabaseName, LogSizeMB, LogSpaceUsed, LogStatus
	FROM #LogSpace_Temp;
 
DROP TABLE #LogSpace_Temp;

Tôi sử dụng thông tin này để xác định thời điểm tệp nhật ký bắt đầu phát triển và tôi bắt đầu xem qua nhật ký và lịch sử công việc để xem tôi có thể tìm thấy thông tin bổ sung nào. Quá trình phát triển nhật ký phải ở trạng thái tĩnh - nhật ký phải có kích thước phù hợp và được quản lý thông qua các bản sao lưu (nếu đang chạy trong phục hồi ĐẦY ĐỦ) và nếu tệp cần lớn hơn, tôi cần hiểu lý do và định lại kích thước cho phù hợp.

Nếu bạn đang giải quyết vấn đề này và bạn đã không chủ động theo dõi các sự kiện tăng trưởng tệp, bạn vẫn có thể tìm ra điều gì đã xảy ra. Các sự kiện tăng trưởng tự động được SQL Server ghi lại; Aaron Bertrand của SQL Sentry đã viết blog về điều này vào năm 2007, nơi anh ấy chỉ cách khám phá thời điểm những sự kiện này xảy ra (miễn là chúng gần đây đủ để vẫn tồn tại trong dấu vết mặc định).

Kích thước và Dung lượng trống trong Tệp Dữ liệu

Bạn có thể đã nghe nói rằng các tệp dữ liệu của bạn nên được định kích thước trước để chúng không phải tự động phát triển. Nếu làm theo hướng dẫn này, có thể bạn chưa gặp phải trường hợp tệp dữ liệu phát triển bất ngờ. Nhưng nếu bạn không quản lý các tệp dữ liệu của mình, thì bạn có thể có sự tăng trưởng diễn ra thường xuyên - cho dù bạn có nhận ra điều đó hay không (đặc biệt là với cài đặt tăng trưởng mặc định là 10% và 1 MB).

Có một mẹo để định cỡ trước các tệp dữ liệu - bạn không muốn kích thước cơ sở dữ liệu quá lớn, vì hãy nhớ rằng, nếu bạn khôi phục, chẳng hạn như môi trường nhà phát triển hoặc QA, các tệp có kích thước giống nhau, ngay cả khi chúng ' lại không đầy đủ dữ liệu. Nhưng bạn vẫn muốn quản lý tăng trưởng theo cách thủ công. Tôi thấy rằng các DBA gặp khó khăn nhất với cơ sở dữ liệu mới. Người dùng doanh nghiệp không có ý tưởng về tốc độ tăng trưởng và bao nhiêu dữ liệu đang được thêm vào, và cơ sở dữ liệu đó là một thứ hơi lỏng lẻo trong môi trường của bạn. Bạn cần phải chú ý đến các tệp này cho đến khi bạn nắm được kích thước và mức tăng trưởng dự kiến. Tôi sử dụng truy vấn cung cấp thông tin về kích thước và dung lượng trống:

SELECT 
    [file_id] AS [File ID],
    [type] AS [File Type],
    substring([physical_name],1,1) AS [Drive],
    [name] AS [Logical Name],
    [physical_name] AS [Physical Name],
    CAST([size] as DECIMAL(38,0))/128. AS [File Size MB], 
    CAST(FILEPROPERTY([name],'SpaceUsed') AS DECIMAL(38,0))/128. AS [Space Used MB], 
    (CAST([size] AS DECIMAL(38,0))/128) - (CAST(FILEPROPERTY([name],'SpaceUsed') AS DECIMAL(38,0))/128.) AS [Free Space],
    [max_size] AS [Max Size],
    [is_percent_growth] AS [Percent Growth Enabled],
    [growth] AS [Growth Rate],
    SYSDATETIME() AS [Current Date]
FROM sys.database_files;

Hàng tháng, tôi kiểm tra kích thước của các tệp dữ liệu và dung lượng được sử dụng, sau đó quyết định xem có cần tăng kích thước hay không. Tôi cũng theo dõi dấu vết mặc định cho các sự kiện tăng trưởng, vì điều này cho tôi biết chính xác thời điểm tăng trưởng xảy ra. Ngoại trừ cơ sở dữ liệu mới, tôi luôn có thể đi trước tốc độ phát triển tệp tự động và xử lý nó theo cách thủ công. Ok, hầu như luôn luôn. Ngay trước kỳ nghỉ lễ năm ngoái, tôi đã được bộ phận CNTT của khách hàng thông báo về dung lượng trống trên ổ đĩa thấp (hãy giữ suy nghĩ đó cho phần tiếp theo). Giờ đây, thông báo dựa trên ngưỡng miễn phí dưới 20%. Ổ đĩa này hơn 1TB, vì vậy có khoảng 150 GB trống khi tôi kiểm tra ổ đĩa. Đó vẫn chưa phải là trường hợp khẩn cấp, nhưng tôi cần hiểu không gian đã biến mất.

Khi kiểm tra các tệp cơ sở dữ liệu cho một cơ sở dữ liệu, tôi có thể thấy rằng chúng đã đầy - và tháng trước mỗi tệp có hơn 50GB trống. Sau đó, tôi tìm hiểu kích thước bảng và nhận thấy rằng trong một bảng, hơn 270 triệu hàng đã được thêm vào trong 16 ngày qua - tổng cộng hơn 100GB dữ liệu. Hóa ra đã có một sự sửa đổi mã và mã mới đang ghi lại nhiều thông tin hơn dự định. Chúng tôi nhanh chóng thiết lập công việc để xóa các hàng và khôi phục dung lượng trống trong tệp (và họ đã sửa mã). Tuy nhiên, tôi không thể khôi phục dung lượng đĩa - tôi sẽ phải thu nhỏ tệp và đó không phải là một tùy chọn. Sau đó, tôi phải xác định dung lượng còn lại trên đĩa và quyết định xem đó có phải là dung lượng mà tôi cảm thấy thoải mái hay không. Mức độ thoải mái của tôi phụ thuộc vào việc biết lượng dữ liệu được thêm vào mỗi tháng - tỷ lệ tăng trưởng điển hình. Và tôi chỉ biết có bao nhiêu dữ liệu đang được thêm vào vì tôi theo dõi việc sử dụng tệp và có thể ước tính lượng dung lượng cần thiết cho tháng này, cho năm nay và trong hai năm tới.

Dung lượng ổ

Tôi đã đề cập trước đó rằng chúng ta có công việc để theo dõi dung lượng trống trên đĩa. Điều này dựa trên một tỷ lệ phần trăm, không phải một số tiền cố định. Nguyên tắc chung của tôi là gửi thông báo khi có ít hơn 10% ổ đĩa trống, nhưng đối với một số ổ đĩa, bạn có thể cần đặt mức đó cao hơn. Ví dụ, với ổ 1 TB, tôi nhận được thông báo khi có dưới 100GB trống. Với ổ 100GB, tôi nhận được thông báo khi chỉ còn dưới 10GB trống. Với một ổ 20GB ... tốt, bạn thấy tôi sẽ đi đến đâu với cái này. Ngưỡng đó cần thông báo cho bạn trước khi có sự cố. Nếu tôi chỉ có 10GB trống trên ổ lưu trữ tệp nhật ký, tôi có thể không có đủ thời gian để phản ứng trước khi nó xuất hiện như một vấn đề đối với người dùng - tùy thuộc vào tần suất tôi kiểm tra dung lượng trống và vấn đề là gì. là.

Rất dễ dàng sử dụng xp_fixeddrives để kiểm tra dung lượng trống, nhưng tôi không khuyến khích điều này vì nó không có tài liệu và việc sử dụng các thủ tục được lưu trữ mở rộng nói chung đã không còn được dùng nữa. Nó cũng không báo cáo tổng kích thước của từng ổ đĩa và có thể không báo cáo về tất cả các loại ổ đĩa mà cơ sở dữ liệu của bạn có thể đang sử dụng. Miễn là bạn đang chạy SQL Server 2008R2 SP1 trở lên, bạn có thể sử dụng sys.dm_os_volume_stats thuận tiện hơn nhiều để lấy thông tin bạn cần, ít nhất là về các ổ chứa tệp cơ sở dữ liệu:

SELECT DISTINCT
  vs.volume_mount_point AS [Drive],
  vs.logical_volume_name AS [Drive Name],
  vs.total_bytes/1024/1024 AS [Drive Size MB],
  vs.available_bytes/1024/1024 AS [Drive Free Space MB]
FROM sys.master_files AS f
CROSS APPLY sys.dm_os_volume_stats(f.database_id, f.file_id) AS vs
ORDER BY vs.volume_mount_point;

Tôi thường gặp sự cố với dung lượng ổ đĩa trên ổ đĩa lưu trữ tempdb. Tôi đã mất số lần tôi có khách hàng với tốc độ tăng trưởng không giải thích được. Đôi khi nó chỉ là một vài GB; gần đây nhất là 200GB. Tempdb là một con quái vật khôn lanh - không có công thức nào để tuân theo khi định kích thước và quá thường xuyên, nó được đặt trên một ổ đĩa có ít dung lượng trống không thể xử lý sự kiện điên rồ do nhà phát triển tân binh hoặc DBA gây ra. Định kích thước tệp dữ liệu tempdb yêu cầu bạn chạy khối lượng công việc của mình trong một chu kỳ kinh doanh "bình thường" để xác định mức độ sử dụng tempdb và sau đó định kích thước cho phù hợp.

Gần đây, tôi đã nghe một gợi ý về một cách để tránh hết dung lượng trên ổ đĩa:tạo cơ sở dữ liệu không có dữ liệu và định kích thước tệp để chúng tiêu tốn bao nhiêu dung lượng mà bạn muốn “dành riêng”. Sau đó, nếu bạn gặp sự cố, chỉ cần thả cơ sở dữ liệu và viola, bạn sẽ có lại dung lượng trống. Cá nhân tôi nghĩ điều này tạo ra tất cả các loại vấn đề khác và tôi không khuyến khích nó. Nhưng nếu bạn có quản trị viên bộ nhớ không muốn thấy hàng trăm GB không sử dụng trên ổ đĩa, thì đây sẽ là một cách để làm cho ổ đĩa "trông đầy". Nó gợi nhớ cho tôi điều gì đó mà tôi đã nghe một người bạn tốt của tôi nói:“Nếu tôi không thể làm việc với bạn, tôi sẽ làm việc xung quanh bạn.”

Bản sao lưu

Một trong những nhiệm vụ chính của DBA là bảo vệ dữ liệu. Sao lưu là một phương pháp được sử dụng để bảo vệ nó và do đó, các ổ lưu trữ các bản sao lưu đó là một phần không thể thiếu trong cuộc sống của DBA. Có lẽ bạn đang giữ một hoặc nhiều bản sao lưu trực tuyến, để khôi phục ngay lập tức nếu cần. Sách chạy SLA và DR của bạn giúp chỉ ra số lượng bản sao lưu trực tuyến và bạn phải đảm bảo rằng bạn có sẵn dung lượng đó. Tôi ủng hộ rằng bạn cũng không xóa các bản sao lưu cũ cho đến khi bản sao lưu hiện tại hoàn tất thành công. Quá dễ dàng để rơi vào bẫy của việc xóa các bản sao lưu cũ, sau đó chạy bản sao lưu hiện tại. Nhưng điều gì sẽ xảy ra nếu bản sao lưu hiện tại không thành công? Và, điều gì sẽ xảy ra nếu bạn đang sử dụng tính năng nén? Chờ một chút… các bản sao lưu nén nhỏ hơn phải không? Cuối cùng thì chúng nhỏ hơn. Nhưng bạn có biết kích thước tệp .bak thường bắt đầu lớn hơn kích thước cuối không? Bạn có thể sử dụng cờ theo dõi 3042 để thay đổi hành vi này, nhưng bạn nên nghĩ rằng với các bản sao lưu, bạn cần nhiều dung lượng. Nếu bản sao lưu của bạn là 100GB và bạn đang trực tuyến trong 3 ngày, bạn cần 300GB cho 3 ngày sao lưu và sau đó có thể là một lượng lớn (kích thước cơ sở dữ liệu hiện tại gấp 2 lần) miễn phí cho lần sao lưu tiếp theo. Có, điều này có nghĩa là tại bất kỳ thời điểm nào bạn sẽ có nhiều hơn 100GB trống trên ổ đĩa này. Vậy là được rồi. Tốt hơn là việc xóa thành công và công việc sao lưu không thành công và ba ngày sau bạn phát hiện ra rằng bạn không có bản sao lưu nào cả (tôi đã từng xảy ra điều đó với một khách hàng tại công việc trước đây của tôi).

Hầu hết các cơ sở dữ liệu ngày càng lớn hơn theo thời gian, có nghĩa là các bản sao lưu cũng lớn hơn. Đừng quên thường xuyên kiểm tra kích thước của các tệp sao lưu và phân bổ thêm dung lượng nếu cần - có chính sách “200 GB miễn phí” cho cơ sở dữ liệu đã tăng lên 350 GB sẽ không hữu ích lắm. Nếu các yêu cầu về không gian thay đổi, hãy nhớ thay đổi mọi cảnh báo liên quan.

Sử dụng Cố vấn Hiệu suất

Có một số truy vấn có trong bài đăng này mà bạn có thể sử dụng để giám sát không gian, nếu bạn cần thực hiện quy trình của riêng mình. Nhưng nếu bạn tình cờ có SQL Sentry Performance Advisor trong môi trường của mình, điều này sẽ dễ dàng hơn nhiều với Điều kiện tùy chỉnh. Có một số điều kiện cổ phiếu được bao gồm theo mặc định, nhưng bạn cũng có thể tạo điều kiện của riêng mình.

Trong máy khách SQL Sentry, mở Bộ điều hướng, bấm chuột phải vào Nhóm được chia sẻ (Toàn cầu) và chọn Thêm điều kiện tùy chỉnh → SQL Sentry. Cung cấp tên và mô tả cho điều kiện, sau đó thêm so sánh số và thay đổi loại thành Truy vấn kho lưu trữ. Nhập truy vấn:

SELECT MIN(FreeSpace*100.0/Size)
  FROM SQLSentry.dbo.PerformanceAnalysisDeviceLogicalDisk;

Thay đổi Bằng thành Nhỏ hơn và đặt Giá trị rõ ràng là 10. Cuối cùng, thay đổi Tần suất đánh giá mặc định thành tần suất ít thường xuyên hơn 10 giây một lần. Một lần một ngày hoặc một lần mỗi 12 giờ có lẽ là một giá trị tốt - bạn không cần phải kiểm tra dung lượng trống thường xuyên hơn một lần mỗi ngày, nhưng bạn có thể kiểm tra nó thường xuyên nếu bạn muốn. Ảnh chụp màn hình bên dưới hiển thị cấu hình cuối cùng:

Khi bạn nhấp vào lưu cho điều kiện, bạn sẽ được hỏi xem bạn có muốn chỉ định các hành động cho điều kiện tùy chỉnh hay không. Tùy chọn Gửi đến các kênh cảnh báo được chọn theo mặc định, nhưng bạn có thể muốn thực hiện các tác vụ khác, chẳng hạn như Thực thi công việc - giả sử, để sao chép các bản sao lưu cũ sang một vị trí khác (nếu đó là ổ đĩa có dung lượng thấp).

Như tôi đã đề cập trước đây, mặc định 10% dung lượng trống cho tất cả các ổ đĩa có thể không phù hợp với mọi ổ đĩa trong môi trường của bạn. Bạn có thể tùy chỉnh truy vấn cho các phiên bản và ổ đĩa khác nhau, ví dụ:

SELECT Alert = MAX(CASE 
  WHEN Name = N'C:' AND [FreeSpace%] < 10 THEN 1
  WHEN Name = N'S:' AND [FreeSpace%] < 25 THEN 1
  WHEN Name = N'T:' AND [FreeSpace%] < 20 THEN 1
  ELSE 0 END)
FROM 
(
  SELECT 
	d.Name, 
	d.FreeSpace * 100.0/d.Size AS [FreeSpace%]
  FROM SQLSentry.dbo.PerformanceAnalysisDeviceLogicalDisk AS d
  INNER JOIN SQLSentry.dbo.EventSourceConnection AS c
  ON d.DeviceID = c.DeviceID
  WHERE c.ObjectName = N'HANK\SQL2012' -- replace with your server/instance
) AS s;

Bạn có thể thay đổi và mở rộng truy vấn này khi cần thiết cho môi trường của mình, sau đó thay đổi so sánh trong điều kiện cho phù hợp (về cơ bản đánh giá thành true nếu kết quả là 1):

Nếu bạn muốn thấy Cố vấn hiệu suất hoạt động, vui lòng tải xuống bản dùng thử.

Lưu ý rằng đối với cả hai điều kiện này, bạn sẽ chỉ được thông báo một lần, ngay cả khi nhiều ổ đĩa giảm xuống dưới ngưỡng của bạn. Trong các môi trường phức tạp, bạn có thể muốn hướng tới một số lượng lớn các điều kiện cụ thể hơn để cung cấp cảnh báo linh hoạt và tùy chỉnh hơn, thay vì ít điều kiện "bắt tất cả" hơn.

Tóm tắt

Có nhiều thành phần quan trọng trong môi trường SQL Server và không gian đĩa cần được chủ động giám sát và duy trì. Chỉ với một chút kế hoạch, điều này rất đơn giản để thực hiện, và nó giúp giảm bớt nhiều điều chưa biết và giải quyết vấn đề mang tính phản ứng. Cho dù bạn sử dụng tập lệnh của riêng mình hay công cụ của bên thứ ba, việc đảm bảo có nhiều dung lượng trống cho các tệp cơ sở dữ liệu và bản sao lưu là một vấn đề có thể dễ dàng giải quyết và rất đáng để nỗ lực.