Tại sao chúng ta có lệnh SHRINKDATABASE trong SQL Server

Tôi đã đọc trên internet nơi Finest Developer nói rằng nên tránh thu nhỏ vì nó gây ra sự gia tăng phân mảnh và giảm hiệu suất.

Tôi muốn biết từ các bạn đã bao giờ sử dụng lệnh thu nhỏ cơ sở dữ liệu nếu có thì trong các kịch bản thực tế chúng ta nên sử dụng chúng.

Đầu tiên và trước hết cho phép phân biệt giữa nhu cầu SHRINK và tác dụng phụ không mong muốn được biết đến : có thể tăng sự phân mảnh. Sau này là một tác dụng phụ thực hiện . Trong thực tế là hoàn toàn có thể thiết kế một thu nhỏ sẽ làm giảm sự phân mảnh (nghĩa là có tác dụng tương tự như REORGANIZE) với chi phí thời gian chạy dài hơn đáng kể.

Nhu cầu thu nhỏ là một điều hoàn toàn hợp lệ: giảm kích thước của cơ sở dữ liệu đã phát triển vì bất kỳ lý do gì. Có giảm kích thước sau khi xóa dữ liệu một lần lớn hay không, đảo ngược hiệu quả của hoạt động một lần gây tăng trưởng kích thước không mong muốn (ví dụ: nhập xấu), di chuyển sang mô hình dữ liệu được cải thiện (và nhỏ hơn nhiều), làm sạch bỏ qua một số quản lý DBA tồi trước đây, tất cả đều là lý do hoàn toàn hợp lệ để thu hẹp cơ sở dữ liệu. Tất nhiên, chi phí thu nhỏ (tăng phân mảnh) phải được xem xét. Nhưng hãy xem xét một trường hợp khi DB có thiết kế kém 200Gb bị giảm xuống chỉ còn 20gb dữ liệu. Thu nhỏ nó đến kích thước 50Gb và xây dựng lại các chỉ mục có ý nghĩa hoàn hảo. Nói cách khác , khả năng thu hẹp cơ sở dữ liệu là cần thiết .

Những gì được tán thành là lạm dụng thu nhỏ:

• thu hẹp theo lịch trình thường xuyên
• thu nhỏ thủ công vì lý do vô căn cứ ('Tôi cần giải phóng một số dung lượng đĩa cho ...'), khi thường cơ sở dữ liệu thực sự cần kích thước đó và sẽ phát triển trở lại qua đêm
• thu nhỏ cho sản lượng nhỏ (ví dụ: giảm 200Gb xuống 5Gb)

Đối với thu nhỏ LOG, vấn đề thậm chí còn trực tiếp hơn: LOG có thể phát triển ngay cả trên một hệ thống được duy trì tốt. Các ví dụ rõ ràng: sao chép giao dịch hoặc triển khai phản chiếu DB gặp vấn đề với DB phân phối hoặc đối tác nhân bản. Cho đến khi vấn đề được giải quyết, nhật ký phải được nhà xuất bản (đối với TX) hoặc chính (đối với DBM) giữ lại. Khi vấn đề cuối cùng được giải quyết và nhật ký được ghim sẽ bị xóa, bạn sẽ kết thúc với một nhật ký lớn không cần thiết. Điều này có thể và nên được thu nhỏ lại kích thước hoạt động. Thu nhỏ nhật ký bằng cách nào đó được xem là VooDoo ('Tôi đã thử và không làm gì cả!', 'Hmm, tôi đã thử và nó hoạt động ngay bây giờ') nhưng thật dễ dàng khi bạn hiểu rằng để thu nhỏ đuôi của nhật ký đăng nhập phải miễn phí trong đó ngụ ý rằng, truy cập bằng trực giác, phải tạo thêm nhật ký (và giải phóng) trước khi tệp có thể được thu nhỏ. Tất cả được giải thích trong Cách sử dụng câu lệnh DBCC SHRINKFILE để thu nhỏ tệp nhật ký giao dịch trong SQL Server 2005

Hầu như không bao giờ.

Các trường hợp sử dụng hợp lệ? Vài ví dụ:

• Để sửa một tệp nhật ký cồng kềnh
  Nói mô hình phục hồi đã ĐẦY ĐỦ và không có bản sao lưu nhật ký nào được thực hiện.
• Máy phát triển để tiết kiệm không gian: những máy này sẽ không có tải sản xuất
• Chỉ đọc cơ sở dữ liệu

Nhưng điều tra của bạn là chính xác: bất kỳ loại thu nhỏ nào không nên là một hoạt động thường xuyên, theo lịch trình

Khi bạn cần thu nhỏ, bạn sẽ sử dụng SHRINKFILE thay vì được nhắm mục tiêu nhiều hơn