Tôi không giỏi SQL, nhưng tôi có một cơ sở dữ liệu để duy trì.
Gần như không còn chỗ cho nó, vì vậy tôi đã quyết định xóa tất cả dữ liệu, giả sử, năm 2008. Sau khi thực hiện truy vấn xóa (đã xóa khoảng 10 000 000 hàng) và xóa nhật ký giao dịch tôi đã phát hiện ra rằng hành động không có ảnh hưởng đến kích thước cơ sở dữ liệu. Có điều gì khác tôi phải làm không?
Câu trả lời:
Trong khi thu hẹp là nguy hiểm thực sự vì những lý do được đề cập ở đây. Có một phương tiện hạnh phúc giữa câu trả lời của Jimbo và câu trả lời của John ... Bạn nên luôn luôn nghiêm túc xem xét liệu bạn có muốn thu nhỏ cơ sở dữ liệu của mình hay không.
Trong một thế giới lý tưởng - bạn sẽ tạo DB của mình với nhiều không gian trống để phát triển. Tôi gọi đây là "Đúng kích cỡ" cơ sở dữ liệu của bạn. Bạn sẽ cho phép không gian trống này ở đó và không cố gắng trả lại và giữ cho tổng kích thước của bạn đúng với kích thước bạn đã sử dụng .. Tại sao? Bởi vì cơ sở dữ liệu của bạn cuối cùng sẽ phát triển trở lại .. Sau đó, bạn sẽ thu nhỏ lại .. Và bạn sẽ bị mắc kẹt trong mô hình thu nhỏ vô dụng khủng khiếp này theo sau sự tăng trưởng - và toàn bộ thời gian, như một số người đã chỉ ra, bạn sẽ tăng phân mảnh chỉ số của bạn.
Tôi đã viết blog về điều này khi tôi khuyên mọi người " Đừng chạm vào nút thu nhỏ đó! " Nhưng đôi khi ... Đôi khi bạn cần phải làm vậy. Nếu bạn có một cơ sở dữ liệu lớn, chỉ cần giải phóng không gian đáng kể và không mong đợi phát triển trở lại vào đó - thì bạn có thể cân nhắc thu hẹp như một hoạt động một lần miễn là bạn có thể xử lý phân mảnh chỉ mục của mình sau khi xây dựng lại họ Hoạt động thu nhỏ có thể tốn thời gian, vì vậy bạn muốn lập kế hoạch cho thời gian mà bạn có thể trả giá của hoạt động thu hẹp đó. Cách tiếp cận tạo DB trống và sao chép dữ liệu vào nó hoạt động - nhưng điều đó có thể trở nên rất khó khăn với cơ sở dữ liệu lớn hơn và nhiều dữ liệu.
Nếu bạn có kế hoạch thêm không gian đó trở lại DB thông qua mô hình sử dụng và tăng trưởng bình thường vào tương lai, thì bạn có thể chỉ muốn để lại không gian ở đó.
Cũng thế
Bạn nói bạn "xóa" nhật ký giao dịch của bạn. Tôi tò mò muốn biết bạn đã làm điều này như thế nào nhưng khi bạn đọc bài đăng tôi đã chia sẻ và những người khác trong loạt bài, bạn sẽ thấy một số mẹo về quản lý nhật ký giao dịch. Nhưng tóm lại - nếu bạn đang ở chế độ Full Recovery, bạn nên thực hiện sao lưu nhật ký thường xuyên để giữ cho nhật ký sử dụng lại chính nó. Mặt khác - không có bản sao lưu nhật ký trong khi ở Chế độ đầy đủ - tệp nhật ký tiếp tục phát triển và tăng trưởng và luôn lưu những gì bạn đã làm vì bạn đã nói với SQL rằng bạn không chỉ muốn duy trì nhật ký đó để phục hồi sự cố mà muốn giữ sao lưu thủ công của nó để phát lại các giao dịch / hoàn tác giao dịch để phục hồi đến một thời điểm cụ thể cho mục đích khôi phục ... Nếu bạn đơn giản và thấy nhật ký phát triển quá mức,BEGIN TRAN ... do work.... COMMIT TRANhoặc cho dù bạn vừa đưa ra một DELETEtuyên bố lớn và xóa toàn bộ mớ dữ liệu trong một giao dịch ngầm.)
Tôi cũng giả định rằng bạn đang tìm kiếm không gian trống này trên hệ thống tệp của bạn. Nếu bạn đang tìm kiếm nó trong SQL và trong tệp lớn mà bạn có - có thể là bạn đang chờ quá trình dọn dẹp ma hoàn tất nếu tìm kiếm ngay sau thao tác của bạn. Paul Randal viết blog về Ghost Cleanup .
Xóa các hàng trong cơ sở dữ liệu sẽ không làm giảm kích thước tệp cơ sở dữ liệu thực tế.
Bạn cần nén cơ sở dữ liệu sau khi xóa hàng.
SQL Server 2005 DBCC SHRINKDATABASE (Transact-SQL)
Sau khi chạy nó, bạn sẽ muốn xây dựng lại các chỉ mục. Thu hẹp thường gây ra sự phân mảnh chỉ mục và đó có thể là một chi phí hiệu suất đáng kể.
Tôi cũng khuyên bạn nên sau khi thu nhỏ, bạn hãy phát triển lại các tệp để bạn có không gian trống. Theo cách đó, khi các hàng mới xuất hiện, chúng không kích hoạt tự động phát triển. Autogrowth có chi phí hiệu năng và là điều bạn muốn tránh (thông qua kích thước cơ sở dữ liệu phù hợp) bất cứ khi nào có thể.
ĐỪNG CHIA SẺ CƠ SỞ DỮ LIỆU CỦA BẠN!
"Tại sao điều này xảy ra? Một thao tác thu nhỏ tệp dữ liệu hoạt động trên một tệp duy nhất tại một thời điểm và sử dụng bitmap GAM (xem Inside The Storage Engine: GAM, SGAM, PFS và các bản đồ phân bổ khác) để tìm trang cao nhất được phân bổ trong Sau đó, nó di chuyển nó càng xa về phía trước của tập tin càng tốt, v.v. Trong trường hợp trên, nó đã đảo ngược hoàn toàn thứ tự của chỉ mục cụm, đưa nó từ phân mảnh hoàn hảo sang phân mảnh hoàn hảo. "
http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx
"Hãy nhìn vào sự mỉa mai của cơ sở dữ liệu Thu hẹp. Một người thu nhỏ cơ sở dữ liệu để có được không gian (nghĩ rằng nó sẽ giúp hiệu suất), dẫn đến tăng phân mảnh (giảm hiệu suất). Để giảm phân mảnh, một chỉ số xây dựng lại, dẫn đến kích thước cơ sở dữ liệu để tăng cách nhiều hơn kích thước ban đầu của cơ sở dữ liệu (trước khi thu hẹp). Chà, bằng cách thu nhỏ, người ta không đạt được những gì anh ta đang tìm kiếm thông thường. "
Khi bạn xóa dữ liệu, SQL Server dành không gian của nó để sử dụng sau này để chèn dữ liệu mới. Bạn cần thu nhỏ cơ sở dữ liệu. Bạn có thể tìm thêm thông tin ở đây .
Tôi tìm thấy điều này bởi vì tôi vừa xóa một loạt các bảng sao lưu vì cơ sở dữ liệu của tôi đã "tối đa hóa". Tôi cứ nhìn vào tài sản "Kích cỡ", nghĩ tại sao cái này không nhỏ đi? . Sau khi đọc nó, không, tôi không muốn thu nhỏ cơ sở dữ liệu. Những gì tôi muốn làm là "đòi lại" không gian cho rác tôi vừa xóa. Những gì tôi cần phải nhìn vào là "Không gian có sẵn". Tôi nghĩ có lẽ đó cũng là điều mà người khác có thể cần phải nhìn vào đó.
Đáng lưu ý là nếu bảng có các chỉ mục trên đó, sự phân mảnh có thể tồn tại sau khi xóa các luồng dữ liệu lớn. Tôi đã có một bảng ngày hôm nay có ~ 70 triệu bản ghi trong đó chiếm khoảng 13 GB. Tôi đã xóa nó xuống 1639 bản ghi (phần còn lại được tạo bởi một lỗi duy nhất) nhưng bảng vẫn chiếm khoảng 4,5 GB. Sau khi tôi xây dựng lại tất cả các chỉ mục trên bàn, nó chỉ mất 85 trang (680kb). Sau đó, tôi đã sử dụng co rút tăng dần để lấy lại khoảng trống (và sửa lỗi trên hệ thống để tránh lặp lại).