Nhận MS SQL Server để giải phóng không gian đĩa

Một bảng cơ sở dữ liệu được quản lý kém đã phát triển rất lớn. 48 + hợp đồng biểu diễn mồ côi. Tôi đang cố gắng dọn dẹp nó và đưa ổ cứng đầy nguy hiểm của tôi trở lại trạng thái bình thường. Tôi sẽ xóa khoảng 400 triệu hồ sơ từ bảng này. Đây là chạy khi tôi gõ. Tôi nhận thấy rằng tôi không thấy bất kỳ sự sụt giảm nào trong không gian ổ cứng của mình nhưng tôi đang thấy sự sụt giảm bộ nhớ trong các truy vấn bảng hệ thống, tôi đang chạy để lấy kích thước bảng. Cơ sở dữ liệu đang sử dụng "Mô hình khôi phục đơn giản".

Có nhiều câu hỏi tương tự như vậy với các câu trả lời nói rằng bạn cần thu nhỏ cơ sở dữ liệu. Nhưng họ tiếp tục giải thích điều này tệ / đáng sợ như thế nào vì dữ liệu bị phân mảnh, v.v.

1. Vì cơ sở dữ liệu không nên có kích thước này. Nó vẫn còn xấu cho tôi để thu nhỏ nó?
2. Đây là một cơ sở dữ liệu sản xuất. Nếu tôi thu nhỏ nó sẽ gây ra thời gian chết hoặc khóa cơ sở dữ liệu?
3. Trong SQL Server Management Studio, bạn có hai tùy chọn cho thu nhỏ, cơ sở dữ liệu hoặc tệp. Với tình hình của tôi, đâu sẽ là lựa chọn tốt nhất?
4. Có quy định nào về tỷ lệ phần trăm không gian trống mà DB nên có không?

Ngay cả việc đọc mô tả thẻ thu nhỏ cũng khiến tôi không muốn làm điều đó. Có cách nào khác không?

Tôi sẽ xóa khoảng 400 triệu hồ sơ từ bảng này.

Hy vọng rằng, bạn đang thực hiện nó trong khối - để tránh nhật ký giao dịch đầy hơi.

nhận thấy rằng tôi không thấy bất kỳ sự sụt giảm nào trong không gian ổ cứng của tôi

Bạn sẽ không, vì bạn phải thu nhỏ rõ ràng tệp cơ sở dữ liệu để giải phóng không gian. Chỉ cần xóa các bản ghi, máy chủ SQL sẽ không giải phóng không gian trở lại HĐH .

1. Vì cơ sở dữ liệu không nên có kích thước này. Nó vẫn còn xấu cho tôi để thu nhỏ nó?

Nó thường là một thực tiễn xấu vì cơ sở dữ liệu nên được chỉ định đúng. Nếu bạn chắc chắn 100% rằng cơ sở dữ liệu của bạn sẽ KHÔNG trở lại kích thước này, bạn có thể thu nhỏ cơ sở dữ liệu (trong kịch bản của bạn) .

2. Đây là một cơ sở dữ liệu sản xuất. Nếu tôi thu nhỏ nó sẽ gây ra thời gian chết hoặc khóa cơ sở dữ liệu?

Thu hẹp cơ sở dữ liệu là một IO rất chuyên sâu. Nên thu nhỏ sử dụng DBCC SHRINKFILEtrong cửa sổ bảo trì hoặc khi có hoạt động tối thiểu.

3. Trong studio quản lý, bạn có hai tùy chọn, Cơ sở dữ liệu hoặc Tệp. Với tình hình của tôi, đâu sẽ là lựa chọn tốt nhất?

Bạn nên sử dụng TSQL để thu nhỏ. (vì bạn đã hỏi, thu hẹp FILE là cách để đi thay vì cơ sở dữ liệu). Bạn có thể sử dụng cơ sở dữ liệu thu nhỏ trong khối - tập lệnh tsql để thực hiện thu nhỏ trong khối.

Hãy nhớ rằng khi bạn thu nhỏ, bạn đang phân mảnh các chỉ mục của mình.

4. Có quy định nào về tỷ lệ phần trăm không gian trống mà DB nên có không?

Bạn có thể tham khảo Ước tính yêu cầu dung lượng đĩa cho cơ sở dữ liệu . Không có quy tắc sửa chữa, bạn phải tính đến việc cơ sở dữ liệu của bạn dự kiến ​​sẽ phát triển như thế nào. Bạn cũng phải tính đến, tự động phát triển cơ sở dữ liệu của bạn .

Tài liệu tham khảo: Tại sao Nhật ký giao dịch tiếp tục phát triển hoặc hết dung lượng?

bạn có lý do chính đáng để lo ngại vì DB co lại trong SQL Server thường "hút". Paul Randal, người đứng đầu Công cụ lưu trữ trong SQL 2005 đã nêu, ShrinkDB được viết rất kém. Nó sẽ tìm không gian trống bằng cách lấy dữ liệu ở cuối và đặt nó vào đầu và tiếp tục làm điều này cho đến khi nó có không gian trống ở 'cuối' của các tệp DB. Tại thời điểm này, nó có thể giải phóng không gian từ SQL Server và trả lại cho HĐH. Bạn đang đảo ngược hiệu quả các tệp cơ sở dữ liệu của mình, do đó bạn sẽ thường thấy sự phân mảnh lớn. Bạn có thể đọc về quan điểm của anh ấy trên bài đăng trên blog này hoặc trên Video MCM Internals này

Như với tất cả mọi thứ, bạn thực sự phải kiểm tra những điều này trong môi trường của bạn đầu tiên. Một cách tốt hơn để làm điều đó là di chuyển dữ liệu đến một nhóm khác. Bạn có thể thực hiện xây dựng lại chỉ mục trực tuyến với chỉ mục được nhóm và sau đó reindex trong nhóm mới. Sau đó, bạn có thể thả cái cũ và giải phóng không gian và gần như không có sự phân mảnh. Lưu ý rằng điều này sẽ mất thêm khoảng 120% không gian trong khi nó đang hoạt động. Vấn đề với điều này là bạn cần thêm không gian trống mà có vẻ như bạn không có. Đây là một tính năng doanh nghiệp.

Nếu không gian trống ở mức cao như vậy, thì bạn có thể phải cắn viên đạn và từ từ thu nhỏ DB một đoạn nhỏ tại một thời điểm để tránh các quá trình chạy dài. Lưu ý rằng dữ liệu của bạn sẽ bị phân mảnh nhiều và bạn sẽ muốn giới thiệu lại mọi thứ một lần nữa. Lưu ý rằng sau khi giới thiệu lại mọi thứ, bạn sẽ tăng thêm không gian đã sử dụng một chút và quay lại để có thêm không gian trống. Xem lời khuyên của Brent tại đây .

Theo như bao nhiêu không gian trống là tốt cho bạn, là vấn đề bạn có thể chi trả bao nhiêu cho các hoạt động phân mảnh và tăng trưởng tệp. Khi bật IFI, tốc độ tăng trưởng tệp gần như ngay lập tức nhưng bạn vẫn bị phân mảnh. Một nguyên tắc nhỏ là phân bổ nhiều không gian như bạn nghĩ bạn sẽ cần, hoặc theo dõi sự tăng trưởng và điều chỉnh theo từng đợt nếu bạn phải. Điều này giữ cho sự phân mảnh vật lý xuống.

Ngoài ra tăng trưởng tập tin đăng nhập là rất quan trọng hơn nhiều. Các tệp nhật ký bổ sung có thể gây ra sự phân mảnh VLF. Điều này làm cho khôi phục của bạn chậm hơn rất nhiều và có thể ảnh hưởng đến điểm kiểm tra / cắt ngắn. Đây là một số rủi ro hiệu suất bạn có với một bản ghi phân mảnh. Làm một DBCC LOGINFO();trên mỗi cơ sở dữ liệu. Cố gắng giữ số lượng khoảng 50ish mỗi Kim Tripp, nhưng nếu bạn thấy hàng trăm, bạn có vấn đề phân mảnh, điều đó có nghĩa là các tệp nhật ký của bạn phải phát triển để hỗ trợ các hoạt động. Một cách tốt để xem tệp nhật ký của bạn nên là gì theo Paul Randal là chỉ để nó phát triển trong một tuần và reindex. Đó có thể là một điểm tốt, có lẽ bạn có thể ném thêm một chút không gian trống vào đó chỉ trong trường hợp. Đảm bảo nhật ký của bạn không bị phân mảnh với DBCC LOGINFO (); một lần nữa và nếu có, điều đó có nghĩa là họ đã trưởng thành hơn rất nhiều. Thu nhỏ và mở rộng lại tệp nhật ký bằng cách sử dụngphương pháp này .

Bạn có thể thu nhỏ nó đủ để đảm bảo máy chủ của bạn sẽ không bị sập trong khoảng thời gian bạn cần để đánh giá nhu cầu lưu trữ của mình và lên kế hoạch cho các dịch vụ phần cứng / lưu trữ phù hợp (xem câu hỏi 4). Không, nó sẽ không khóa nó. Xem các hạn chế . Thu nhỏ cơ sở dữ liệu vì nó giữ cho mọi thứ đơn giản.

Tôi đề nghị ký hợp đồng chuyên môn để tiến hành nghiên cứu và viết lên kế hoạch.