Chạy các lệnh DBCC Shrink là một vấn đề gây tranh cãi trong cộng đồng SQL Server. Trong bài viết này, chúng tôi sẽ xem xét chi tiết về lệnh này và cung cấp tổng quan ngắn gọn về việc sử dụng nó và cũng cảnh báo bạn về những rủi ro khi chạy lệnh này. Là DBA, một số cơ sở dữ liệu đã được chuyển giao cho các nhóm hoặc nhà cung cấp khác và không phải lúc nào chúng ta cũng có thể quản lý cơ sở dữ liệu mà chúng ta đã tạo. Với tư cách là DBA, bất cứ khi nào chúng ta tham gia vào quá trình di chuyển hoặc dự án mới, chúng ta cần đảm bảo rằng chúng ta lập kế hoạch cẩn thận để chuyển cơ sở dữ liệu sang sản xuất và sử dụng thường xuyên một cách suôn sẻ. Ở giai đoạn này, chúng ta cần tính đến kích thước của cơ sở dữ liệu. Bạn có thể tưởng tượng, bạn thiết lập một ứng dụng cơ sở dữ liệu mà không xem xét dự báo tăng trưởng trong năm đầu tiên hoặc lâu hơn. Còn bạn thì sao, bạn tạo cơ sở dữ liệu SQL Server với kích thước nhỏ đến mức nó cần phải phát triển hàng ngày, nâng cao dung lượng cảnh báo đĩa vào lúc nửa đêm? Nghe có vẻ ngớ ngẩn, nhưng trên thực tế, sự thật là điều này xảy ra và điều này đôi khi có thể không nằm trong tầm kiểm soát của bạn.
Một số điểm cần xem xét đối với DBA chủ động
Trước khi nhận hỗ trợ cơ sở dữ liệu sản xuất, hãy nhớ kiểm tra với người tiền nhiệm của bạn những dự báo nào về tốc độ tăng trưởng cơ sở dữ liệu. Kích thước ban đầu của cơ sở dữ liệu mà bạn sẽ quản lý có đủ kích thước không? Đừng lo lắng quá nếu kích thước hiện tại của cơ sở dữ liệu lớn hơn nhiều so với dữ liệu hiện có. Hãy nhớ rằng bạn không muốn những cuộc gọi về dung lượng đĩa đó vào lúc 3:00 sáng khi bạn có thể hoàn toàn tránh được nó bằng cách có một cơ sở dữ liệu có kích thước chính xác. Xu hướng chung của các nhà quản trị cơ sở dữ liệu trong toàn ngành là hy sinh mạng sống của họ vào đêm khuya cho những vấn đề trần tục mà lẽ ra ngay từ đầu đã không xảy ra. Ngoài ra, cùng với kích thước cơ sở dữ liệu, hãy ghi nhớ dung lượng đĩa của máy chủ. Bạn không muốn kích thước đĩa quá nhỏ so với những gì cơ sở dữ liệu có thể chứa. Đây là tất cả những thứ đơn giản có ích tại thời điểm lập kế hoạch. Tuy nhiên, như bạn biết, không phải lúc nào chuyên gia cơ sở dữ liệu cũng cài đặt hoặc cấu hình cơ sở dữ liệu ngay từ đầu. Điểm quan trọng cần lưu ý là nắm được những điều cơ bản ngay với cơ sở dữ liệu của bạn về định cỡ và bạn có thể không cần phải chạy lệnh này bao giờ. Tuy nhiên, như mọi khi, với tư cách là một DBA, đôi khi mọi thứ có thể không nằm trong tầm kiểm soát của bạn và trong thời gian này, bạn có thể sử dụng các lệnh tệp DBCC Shrink để sử dụng hiệu quả.
Khi nào tôi có thể sử dụng DBCC ShrinkFile?
Bạn vừa nhận được cảnh báo về dung lượng ổ đĩa ngay giữa giấc ngủ và bạn phải đáp ứng SLA nghiêm ngặt. Mức độ ưu tiên là P2 và SLA có thể vi phạm rất sớm. Và bạn nhận ra rằng việc mở rộng ổ đĩa sẽ không xảy ra sớm, tốt, trong trường hợp đó, hãy giữ các lệnh DBCC ShrinkFile của bạn luôn sẵn sàng để bạn có thể sử dụng chúng để lấy lại dung lượng. Như tên cho thấy, nó thu nhỏ tệp dữ liệu hoặc tệp nhật ký của cơ sở dữ liệu. Nhưng trước khi bạn bắt đầu chạy các lệnh DBCC ShrinkFile, hãy thử kiểm tra xem tại sao tệp cơ sở dữ liệu lại phát triển ngay từ đầu.
- Tệp có phát triển do một số giao dịch đang diễn ra trong thời gian dài không?
- Có loại chặn nào trên máy chủ không?
- Có bất kỳ bản phát hành ứng dụng lớn nào đang diễn ra mà bạn chưa được thông báo không? (Điều này xảy ra hầu hết thời gian)
- Có bất kỳ loại vấn đề sao chép hoặc sao chép cơ sở dữ liệu nào gây ra sự phát triển cơ sở dữ liệu không?
Điều quan trọng là phải nhận được câu trả lời cho những câu hỏi này càng nhanh càng tốt. Nói chung, có một câu trả lời cho tất cả những câu hỏi này và đó là một công cụ miễn phí tuyệt vời được gọi là sp_whoisactive. Không có từ nào để mô tả công dụng to lớn của công cụ này và tôi đã sử dụng nó nhiều lần để khắc phục nhiều vấn đề liên quan đến sản xuất. Bạn có thể tải xuống mã mới nhất từ liên kết này:http://whoisactive.com/. Nó dễ dàng và đơn giản để sử dụng và trả lại kết quả đầu ra trong thời gian ngắn. Nếu bạn là DBA dày dặn, bạn sẽ có cái này theo ý của mình.
DBCC ShrinkFile với các ví dụ
Cú pháp cho DBCC ShrinkFile rất đơn giản và dễ hiểu, hãy tham khảo ví dụ này bên dưới.
use YOURDATABASE go DBCC Shrinkfile(FileName,1024)
Ví dụ trên thu nhỏ FileName thuộc YOURDATABASE thành 1024 MB. Bạn có thể thực hiện thao tác tương tự bằng SQL Server Management Studio (SSMS). Nhấp chuột phải vào cơ sở dữ liệu, đi tới Công việc , chọn Thu hẹp rồi đến Tệp .
Sau khi bạn nhấp vào Tệp , bạn sẽ nhận được cửa sổ này.
Tại đây, bạn có tùy chọn để chọn loại tệp:Dữ liệu, Nhật ký hoặc Dữ liệu dòng lọc và thực hiện “Hành động thu nhỏ” theo yêu cầu. Việc sử dụng chính lệnh DBCC cho các mục đích thu nhỏ sẽ dễ dàng hơn.
Sử dụng DBCC ShrinkFile với các tùy chọn bổ sung
Bạn có thể chạy lệnh DBCC ShrinkFile với các tùy chọn bổ sung - tệp trống, ký hiệu hoặc cắt ngắn.
Emptyfile
Bạn có thể sử dụng lệnh voidfile như bên dưới.
use YOURDATABASE go dbcc shrinkfile(FileName,emptyfile)
Điều này sẽ giúp di chuyển dữ liệu sang các tệp khác trong cùng một nhóm tệp. Sau khi hoàn tất, bạn sẽ có thể xóa tệp cơ sở dữ liệu nếu nó không còn cần thiết. Tuy nhiên, có một số điều cần lưu ý với tùy chọn tệp trống này vì bạn sẽ không thể làm gì nhiều để làm trống nội dung của tệp dữ liệu chính có ID tệp 1. Để lấy số ID tệp, hãy chạy tập lệnh này.
select file_id, name,physical_name from sys.database_files
Ở đây, trong ví dụ này, tên tệp là “mo” và tệp_id là 1. Khi bạn thử làm trống tệp mo có tệp_id 1, bạn sẽ gặp phải thông báo lỗi này.
Điều này là do có thông tin hệ thống trong tệp gốc, không thể bị làm trống. Tuy nhiên, nếu bạn thử lệnh tương tự trên tệp dữ liệu khác “mo2data”, lệnh tệp trống sẽ thành công.
Notruncate
Như tên cho thấy, không có dung lượng được giải phóng trở lại hệ điều hành. Điều này giống như một hoạt động nội bộ trong tệp nơi các trang được phân phối lại trong chính tệp mà không thay đổi kích thước tổng thể của tệp cơ sở dữ liệu. Bởi vì điều này, có khả năng rất lớn cho sự phân mảnh được giới thiệu. Xem ví dụ bên dưới.
-- Example only Use YourDatabase go DBCC SHRINKFILE (filename,notruncate); GO
Chỉ cắt ngắn
Như tên cho thấy, dung lượng trống sẽ được giải phóng trở lại hệ điều hành từ cuối tệp. Đây là hoạt động an toàn nhất mà bạn có thể chạy bằng DBCC ShrinkFile. Xem ví dụ bên dưới.
-- Example only Use YourDatabase go DBCC SHRINKFILE (filename,truncateonly); GO
Phải làm gì khi DBCC ShrinkFile trên nhật ký giao dịch không hoạt động như mong đợi? Tham khảo phương pháp an toàn này để khắc phục sự cố
Đôi khi lệnh này có thể không hoạt động như mong đợi. Giả sử bạn gặp phải trường hợp bạn đang cố gắng thu nhỏ tệp nhật ký của cơ sở dữ liệu và nó dường như không hoạt động. Dưới đây là một số bước bạn có thể thực hiện để hiểu tại sao việc thu nhỏ không hoạt động như mong đợi. Bạn sẽ nhận thấy rằng tệp thu nhỏ sẽ hiển thị như đã thành công, tuy nhiên, không có sự giảm kích thước của tệp nhật ký. Trong trường hợp đó, hãy chạy lệnh này để kiểm tra một số điều về việc sử dụng tệp nhật ký.
select name,log_reuse_wait_desc,* from sys.databases
Từ ảnh chụp màn hình, bạn có thể thấy rằng cột log_reuse_wait_desc đang chờ sao lưu nhật ký.
Ở đây, bạn có thể thấy rằng việc sao lưu nhật ký cho cơ sở dữ liệu cần phải được thực hiện trước khi bạn thực sự có thể thu nhỏ tệp nhật ký. Nếu điều này nằm trên cơ sở dữ liệu sản xuất, hãy thử thực hiện sao lưu nhật ký trên một ổ đĩa khác có dung lượng trống. Để thực hiện sao lưu nhật ký, hãy sử dụng lệnh mẫu bên dưới.
backup log DBName to disk='C:\Program Files\Microsoft SQL Server\MSSQL15.A1\MSSQL\Backup\DBName.trn' with init,stats,compression
Sau khi bạn chạy lệnh sao lưu, hãy chạy lại lệnh dưới đây để xem trạng thái của cột log_reuse_wait_desc.
select name,log_reuse_wait_desc,* from sys.databases
Từ ảnh chụp màn hình, bạn có thể thấy rằng trạng thái của cột log_reuse_wait_desc đã thay đổi thành “Không có gì”.
Tại đây, bạn có thể thấy rằng trạng thái của cột “log_reuse_wait_desc” đã thay đổi thành “Không có gì”. Trong trường hợp của bạn, nó vẫn có thể hiển thị là “LOG_BACKUP”. Tiếp tục thực hiện sao lưu nhật ký cho cơ sở dữ liệu cho đến khi trạng thái chuyển thành “Không có gì”. Lý do bạn vẫn có thể thấy trạng thái “LOG_BACKUP” ngay cả sau khi thực hiện sao lưu nhật ký giao dịch là vì không có VLF nào có thể bị xóa sau khi bạn chạy sao lưu nhật ký giao dịch. VLF là viết tắt của các tệp nhật ký ảo và là một phần của kiến trúc nội bộ của nhật ký giao dịch. Các tệp nhật ký giao dịch được tạo thành từ các VLF này. Bạn có thể nhận thông tin về VLF bằng cách chạy lệnh này.
select * from sys.dm_db_log_info(5)
Ở đây 5 đại diện cho database_id. Ảnh chụp màn hình của đầu ra được hiển thị. Số hàng được trả về đại diện cho số lượng tệp nhật ký ảo (VLF) thực tế trong cơ sở dữ liệu. Bạn có thể kiểm tra cột “vlf_status” để kiểm tra trạng thái của tệp nhật ký ảo. Giá trị 2 có nghĩa là nó đang hoạt động. Với lệnh này, bạn có thể kiểm tra các cờ bên trong tệp nhật ký giao dịch để hiểu lý do tại sao nhật ký giao dịch không được giải phóng ngay cả sau khi thực hiện sao lưu nhật ký.
Trước đây, lệnh đã được sử dụng là DBCC LOGINFO cung cấp thông tin tương tự.
Phải làm gì khi DBCC ShrinkFile trên nhật ký giao dịch không hoạt động như mong đợi? Một cái gì đó bạn có thể thực hiện trên môi trường non-prod. Tuy nhiên, không được khuyến khích trên môi trường sản xuất
Bạn sẽ bắt gặp trên nhiều trang web mà mọi người khuyên nên thay đổi mô hình khôi phục thành một mô hình đơn giản và sau đó chạy một tệp thu nhỏ để giải phóng dung lượng trở lại Hệ điều hành. Hãy nhớ rằng việc thay đổi mô hình khôi phục thành một mô hình đơn giản sẽ ảnh hưởng đến quá trình khôi phục cơ sở dữ liệu của bạn vì bạn sẽ không thể khôi phục về một thời điểm cụ thể. Điều này một lần nữa phụ thuộc vào SLA doanh nghiệp của bạn. Bạn có thể thay đổi mô hình khôi phục bằng T-SQL (bên dưới) hoặc sử dụng GUI.
alter database DB_NAME set recovery simple
Sử dụng GUI, thay đổi mô hình khôi phục như được hiển thị. Nhấp chuột phải vào cơ sở dữ liệu, đi tới “Thuộc tính”, nhấp vào “Tùy chọn”. Trong “Tùy chọn”, hãy chọn “Mô hình khôi phục”.
Bạn sẽ nhận thấy rằng chỉ cần thay đổi mô hình khôi phục thành Đơn giản sẽ không giải phóng dung lượng trở lại Hệ điều hành. Bạn sẽ cần chạy lệnh DBCC ShrinkFile một cách rõ ràng để thu nhỏ tệp và lấy lại dung lượng. Xem kịch bản mẫu bên dưới. Lệnh này sẽ thu nhỏ FileName của bạn còn 1024 MB.
use YOURDATABASE go DBCC Shrinkfile(FileName,1024)
Tùy chọn cơ sở dữ liệu tự động thu nhỏ
Bạn sẽ nhận thấy rằng có một tùy chọn được gọi là “Tự động thu nhỏ” trong thuộc tính cơ sở dữ liệu. Chỉ cần bấm chuột phải vào cơ sở dữ liệu để xem thuộc tính cơ sở dữ liệu. Ở phần tùy chọn, bạn sẽ thấy tùy chọn này như hình. Từ cài đặt cơ sở dữ liệu mô hình, bạn có thể thấy rằng tùy chọn “Tự động thu nhỏ” bị tắt theo mặc định. Vì vậy, bất cứ khi nào bất kỳ cơ sở dữ liệu mới nào được tạo, tùy chọn này cũng ở trạng thái vô hiệu hóa. Có thể có một số trường hợp các chuyên gia cơ sở dữ liệu có thể vô tình để tùy chọn này được bật mà không nhận thức được hậu quả tiêu cực của việc bật tùy chọn này.
Chạy lệnh này để kiểm tra trạng thái của tùy chọn này đối với cơ sở dữ liệu trên máy chủ.
select name,is_auto_shrink_on,* from sys.databases
Bạn sẽ thấy kết quả này.
Nếu tình cờ, bạn thấy rằng nó đã được bật, bạn có thể tắt nó bằng cách sử dụng GUI hoặc bạn có thể chạy lệnh bên dưới đối với cơ sở dữ liệu.
ALTER DATABASE YOUR_DATABASE set AUTO_SHRINK OFF
Các đề xuất bảo trì khác
Hãy tham khảo một số mẹo bổ sung sau để tránh vấn đề tăng trưởng cơ sở dữ liệu, do đó bạn cần chạy các lệnh DBCC ShrinkFile.
- Đảm bảo mô hình khôi phục của cơ sở dữ liệu của bạn phù hợp với SLA kinh doanh. Nếu doanh nghiệp của bạn không yêu cầu khôi phục tại thời điểm cho cơ sở dữ liệu thử nghiệm, chỉ cần để chúng trong mô hình khôi phục Đơn giản. Tôi đã nhiều lần chứng kiến mô hình khôi phục của cơ sở dữ liệu đã hoàn tất khi mọi thứ đều ổn với việc khôi phục bằng cách sử dụng bản sao lưu đầy đủ mới nhất
- Đảm bảo giám sát thích hợp tại chỗ, đặc biệt là với sự phát triển của cơ sở dữ liệu. Bạn sẽ được cảnh báo khi việc sử dụng tệp nhật ký đạt 85%. Điều này sẽ giúp bạn có chút thời gian để giải quyết vấn đề về dung lượng
- Đảm bảo sao lưu nhật ký thường xuyên được thực hiện nếu cơ sở dữ liệu ở mô hình Khôi phục hoàn toàn và bạn sẽ được thông báo nếu bất kỳ quá trình sao lưu nhật ký nào không thành công
- Đảm bảo có đủ dung lượng trên các ổ cơ sở dữ liệu để tránh các vấn đề thiếu dung lượng
- Đối với cơ sở dữ liệu có thể được lưu trữ, hãy phát triển một số chiến lược lưu trữ để bạn có thể di chuyển dữ liệu cũ hơn sang cơ sở dữ liệu khác để tạo báo cáo và đặt cơ sở dữ liệu đó ở chế độ chỉ đọc. Điều này sẽ giúp bạn kiểm soát nhiều hơn về kích thước cơ sở dữ liệu
- Đảm bảo thường xuyên thực hiện kiểm tra tính toàn vẹn trên cơ sở dữ liệu của bạn bằng cách sử dụng DBCC CheckDB. Để biết thêm thông tin, hãy tham khảo bài viết này:https://codingsight.com/dbcc-checkdb-overview/
Kết luận
- Từ bài viết này, bạn đã hiểu rõ về cách sử dụng lệnh DBCC ShrinkFile
- Bạn đã biết về các rủi ro khi chạy các lệnh DBCC ShrinkFile
- Bạn đã biết các tùy chọn khác nhau mà chúng tôi có thể cung cấp bằng cách sử dụng các lệnh DBCC ShrinkFile
- Bạn đã thấy các tùy chọn mà chúng tôi có thể thử nếu nhật ký giao dịch không bị thu hẹp bằng cách sử dụng các lệnh DBCC ShrinkFile
- Bạn đã tìm hiểu về cài đặt tự động thu nhỏ mặc định trong thuộc tính cơ sở dữ liệu
- Bạn cũng đã học được các đề xuất bảo trì cơ sở dữ liệu khác để giữ cho cơ sở dữ liệu của bạn hoạt động tốt
- Cuối cùng, hãy đảm bảo bạn luôn sẵn sàng trong mọi trường hợp cho những ngày TẮT mà có thể không nằm trong tầm kiểm soát của bạn
