Xây dựng lại chỉ mục, DB bây giờ kích thước gấp 10 lần

Tôi có cơ sở dữ liệu SQL Server (2008 R2 SP1) khoảng 15 hợp đồng biểu diễn. Hóa ra bảo trì đã không chạy trong một thời gian, vì vậy tôi đã tạo một kế hoạch bảo trì để xây dựng lại tất cả các chỉ mục, chúng rất phân mảnh.

Công việc đã hoàn thành và sự phân mảnh đã biến mất, nhưng bây giờ cơ sở dữ liệu là hơn 120 hợp đồng biểu diễn! Tôi hiểu rằng nó sẽ sử dụng thêm không gian để thực hiện tất cả các công việc xây dựng lại, nhưng bây giờ công việc đã hoàn thành, tôi nghĩ tất cả không gian đó sẽ là không gian trống, nhưng không gian trống chỉ hiển thị là 3 hợp đồng, vì vậy 117 hợp đồng đang được sử dụng mặc dù công việc xây dựng lại chỉ số đã kết thúc.

Tôi rất bối rối và có thể sử dụng một số hướng dẫn, tôi có thể đưa db trở lại kích thước hợp lý, chúng tôi không có dung lượng đĩa cho việc này.

Cảm ơn trước!

Đây là kết quả của cả hai truy vấn được đăng:

log_Vuse_wait_desc KHÔNG CÓ

name    TotalSpaceInMB  UsedSpaceInMB   FreeSpaceInMB
LIVE_Data   152             123             28
LIVE_Log    18939           89              18849
LIVE_1_Data 114977          111289          3688

Tệp thứ 3 là tệp .ndf, là tệp chỉ hiển thị 3688 trong không gian chưa sử dụng, nhưng 111289 được sử dụng cho khoảng 15 hợp đồng dữ liệu.

Trong khi đó tôi chỉ cần tìm ra điều này, ợ toàn bộ não. Tôi đã chỉ ra những gì tôi nghĩ là hệ số lấp đầy 90 trong công việc xây dựng lại, nhưng nó được gọi là "thay đổi tỷ lệ phần trăm không gian trống thành" vì vậy bằng cách sử dụng giá trị 90 trong đó, tôi thực sự đã sử dụng hệ số lấp đầy là 10 !! DOH. Không có gì ngạc nhiên khi nó phát triển gấp 10 lần. Tôi sẽ xây dựng lại với hệ số điền chính xác sau đó thu nhỏ lại. Cảm ơn tất cả mọi người cho đầu vào mặc dù.

Việc xây dựng lại các chỉ mục gây ra không gian chùng thêm trong DB. Đây là sản phẩm phụ tự nhiên của quá trình reindexing - máy chủ đang xây dựng một phiên bản mới, liên tục của chỉ mục bên cạnh phiên bản hiện tại, sau đó bỏ phiên bản hiện tại khi hoàn tất.

Co lại sau khi reindexing là vô nghĩa!

Bạn sẽ chỉ phân đoạn lại chỉ số! Thu hẹp sẽ loại bỏ không gian chùng bằng cách phân bổ lại dữ liệu trong DB.

Đây là một bài viết hay của Paul Randal, người khi làm việc tại Microsoft chịu trách nhiệm về DBCCmã bao gồm thu nhỏ, về lý do tại sao bạn không nên thu nhỏ.

Bạn nên sử dụng tùy chọn xây dựng lại SORT_IN_TEMPDB=ON.

Trong trường hợp của bạn, (các) tệp dữ liệu thực tế, nơi đặt các bảng trong câu hỏi, đã được sử dụng để sắp xếp các chỉ mục. Phần lớn dung lượng 120 GB đó vẫn chưa được sử dụng và sẽ được lấp đầy với dữ liệu trang khi cần.

Bạn có thể thấy trạng thái không gian sử dụng / không gian trống với truy vấn này (lấy từ đây ):

use [YourDatabaseNameHere]
go

select
    name,
    cast((size/128.0) as int) as TotalSpaceInMB,
    cast((cast(fileproperty(name, 'SpaceUsed') as int)/128.0) as int) as UsedSpaceInMB,
    cast((size/128.0 - cast(fileproperty(name, 'SpaceUsed') AS int)/128.0) as int) as FreeSpaceInMB
from
    sys.database_files

Để thu nhỏ một tệp cơ sở dữ liệu cụ thể (dữ liệu hoặc nhật ký), bạn có thể xem một số thông tin ở đây . Một cảnh báo trước đó, việc giải phóng không gian chưa sử dụng đang mất khá nhiều thời gian cho hơn 100 cơ sở dữ liệu Gb (cũng phụ thuộc vào tốc độ lưu trữ), vì vậy hãy để nó chạy.

Không có bất kỳ chi tiết nào khác, tôi nghi ngờ bạn cần thực hiện sao lưu nhật ký giao dịch trước khi bạn có thể lấy lại không gian của nó.

Xem những gì select name, log_reuse_wait_desc from sys.databasesnói với bạn. Nếu cột log_Vuse_wait_desc nói LOG_BACKUPthì nó không thể lấy lại dung lượng cho đến khi bạn thực hiện sao lưu nhật ký tran.