Thu nhỏ cơ sở dữ liệu dưới kích thước ban đầu của nó

Tôi đã có cơ sở dữ liệu SQL server 2005 dev là bản sao 30 GB trực tiếp. Chúng tôi đã xóa một số dữ liệu không cần thiết trong dev, điều này mang lại không gian tệp dữ liệu được sử dụng xuống còn 20GB. Vì vậy, chúng tôi có khoảng 33% không sử dụng.

Tôi cần phải lấy lại không gian, điều này sẽ cho phép chúng tôi có một DB dev thứ hai trên máy chủ (dựa trên phiên bản cắt giảm); tuy nhiên, tôi không thể lấy lại không gian, tôi đã làm như sau:

• Kích thước ban đầu của tệp SMS2_Datalà 30 GB.

  DBCC SHRINKFILE (N'SMS2_Data' , 0, TRUNCATEONLY)

  theo dõi bởi

  DBCC SHRINKFILE (N'SMS2_Data' , 19500)

Không có niềm vui. Tôi đã thử tạo một bản sao lưu, tạo một DB mới với kích thước ban đầu thấp sau đó khôi phục, không có gì vui vì kích thước ban đầu bị ghi đè. Cũng đã thử:

ALTER DATABASE SMS2HazSub MODIFY FILE (NAME = 'SMS2_Data', SIZE = 20000) 

Điều này sai lầm, nói:

SỬA ĐỔI FILE thất bại. Kích thước được chỉ định nhỏ hơn kích thước hiện tại.

Tôi đã thử 20800 và sau đó tiếp tục tăng đến 29000 (29 GB) và nó vẫn không cho phép tôi thay đổi.

Đã thực hiện thu nhỏ sau đó thay đổi chế độ phục hồi từ FULLsang SIMPLEvà quay lại. Không có niềm vui.

Tôi nghĩ rằng đó là để làm với một số TEXTlĩnh vực. Chúng tôi có khoảng 6 trên toàn hệ thống. Vì vậy, như một bài kiểm tra, tôi đã bỏ tất cả chúng và sau đó thu nhỏ tệp và vẫn không thay đổi.

Tùy chọn duy nhất còn lại là nhập lại dữ liệu sang DB khác. Điều này là không thực tế, vì nó sẽ phải được thực hiện trên DB trực tiếp, mang quá nhiều rủi ro. Chúng tôi thường xuyên lấy một bản sao của DB trực tiếp và ghi đè lên dev / test. Chúng tôi có khoảng 500 bảng. Tôi muốn một cách làm điều đó sẽ không có rủi ro xuất dữ liệu sang DB mới.

Tôi đã thử di chuyển dữ liệu sang một tệp khác và nó đã sao chép tất cả trừ 5% dữ liệu. Đây là những gì dẫn tôi thử và thả tất cả các cột văn bản.

Máy chủ ở chế độ tương thích 90, nhưng là SP2. Bây giờ tôi đã thực hiện 3 lần sau: reindex tất cả các bảng, sao lưu cơ sở dữ liệu, thu nhỏ tệp, thu nhỏ cơ sở dữ liệu. Vẫn không có niềm vui.

EXECUTE sp_spaceused trả về:

database_name   database_size   unallocated space
SMS2Tests       31453.94 MB     13903.16 MB

reserved     data         index_size   unused
16545568 KB  10602264 KB  4254360 KB   1688944 KB

Như một số người đã đề cập, bạn có thể tạo cơ sở dữ liệu mới và "sao chép" nội dung từ cơ sở dữ liệu cũ. Đây sẽ là lựa chọn tốt nhất cho bạn. Tuy nhiên tôi đã nhận thấy rằng bạn muốn làm điều đó khá thường xuyên. Vì vậy, lựa chọn tốt nhất của bạn là Redgate Data So sánh và Redgate So sánh . Cả hai đều là một phần của gói Redgate SqlToolbelt .

Vì vậy, những gì bạn làm:

1. Tạo một DB trống với kích thước ban đầu nhỏ.
2. Sử dụng Redgate So sánh để sao chép cấu trúc db, các chức năng, vv từ db cũ
3. Sử dụng Redgate Data So sánh để sao chép dữ liệu từ cơ sở dữ liệu cũ sang cơ sở dữ liệu mới
4. Bạn làm việc trên cơ sở dữ liệu dev và bất cứ lúc nào bạn cũng chỉ thực hiện So sánh dữ liệu và cập nhật Dev DB thường xuyên hoặc nếu bạn thực hiện bất kỳ thay đổi nào đối với db, bạn có thể triển khai các thay đổi đó bằng So sánh Redgate và sau đó thực hiện So sánh dữ liệu Redgate.

Điều tốt với So sánh dữ liệu là sau khi bạn sao chép 30gb dữ liệu đó (bạn chỉ có thể thực hiện bắt đầu với một số bảng) sau một thời gian, nó chỉ cần 'biên dịch lại' một số thay đổi chứ không phải toàn bộ 30gb dữ liệu. Điều đó có nghĩa là nó sẽ tác động ít hơn nhiều đến cả hai cơ sở dữ liệu sau đó bằng cách sao chép nó bình thường.

Một vài khả năng ở đây.

Trước hết, bạn có dùng SQL 2005 SP3 trở lên không? Một số đã báo cáo các sự cố SHRINKFILE trên các phiên bản trước (xem http://www.sqlservercentral.com/Forums/Topic981292-146-6.aspx#bm985164 )

Thứ hai, bạn có thể xác minh rằng cơ sở dữ liệu được đặt thành tương thích chế độ 90 chứ không phải chế độ 80 không? Đây rõ ràng là một vấn đề với SQL 2000, nhưng hạn chế đã được gỡ bỏ trong SQL 2005. Nếu cơ sở dữ liệu của bạn vẫn được đặt ở chế độ tương thích 80, đây vẫn có thể là một vấn đề.

Thứ ba, đây có thể là một vấn đề với dữ liệu LOB (văn bản, ntext, varchar (max)). Xem bài viết xuất sắc của Paul Randall tại đây

Tôi giả định rằng bạn hiểu những gì SHRINKing thực sự làm và nó có thể ảnh hưởng tiêu cực đến hiệu suất của bạn:

• SHRINK hoạt động bằng cách di chuyển mù quáng các trang từ cuối tệp đến đầu
• Như vậy, nó có thể tạo ra các chỉ mục phân đoạn khủng khiếp, có thể gây ra các vấn đề hiệu suất đáng kể
• Bởi vì nó là một hoạt động chuyên sâu dữ liệu, thu nhỏ có thể mất thời gian đáng kể

Tôi thường khuyên bạn nên theo dõi thu nhỏ với một reindex đầy đủ (sẽ lấy lại một số không gian vừa được giải phóng), nhưng có vẻ như bạn thậm chí không thể đến điểm đó.

Nếu bạn nhìn vào SPID thu nhỏ của mình trong màn hình hoạt động, nó có vẻ như đang làm gì không? (Bộ đếm IO và CPU thay đổi) Hoặc nó bị chặn? Điều khác duy nhất tôi có thể nghĩ là nếu có hoạt động khác trên cơ sở dữ liệu, chặn thu hẹp. Hãy chắc chắn rằng không có các spids hoạt động khác đang sử dụng cơ sở dữ liệu tại thời điểm đó.

Chuyển sang chế độ khôi phục đơn giản trong quá trình này cũng là một ý tưởng tốt, để giữ cho nhật ký không tăng quá nhiều.

SHRINKDATABASE sẽ chỉ thu nhỏ cơ sở dữ liệu (tốt nhất) thành MinSize của nó, vì vậy điều đó sẽ không giúp bạn.

Khi bạn thử, bạn thu nhỏ FILE thông qua giao diện người dùng SSMS bằng cách sử dụng mặc định, nó sử dụng 'DBCC SHRINKFILE (N'MyDB', 0, TRUNCATEONLY) '. Lệnh đó sẽ chỉ thu nhỏ tệp (tốt nhất) đến mức được phân bổ cuối cùng.

Nếu bạn muốn thu nhỏ tệp bên dưới MinSize, chỉ cần thay đổi tham số trên DBCC SHRINKFILEtừ 0 thành kích thước mà bạn muốn cố gắng thu nhỏ tệp thành MB. Một số khác không sẽ báo cho SHRINKFILE thu nhỏ tệp về kích thước đó nếu có thể. Vì vậy, DBCC SHRINKFILE('MyDB', 300, TRUNCATEONLY)sẽ thu nhỏ tệp thành 300MB nếu cơ sở dữ liệu có không gian.

Bạn có thể thấy MinSize bằng cách chạy này:

DBCC TRACEON(3604)
go
DBCC PAGE('MyDB', 1, 0, 3) with tableresults
go

Kích thước tối thiểu tính bằng MB được tính theo cách này: (Kích thước tối thiểu * 8) / 1024

Nếu bạn thực sự muốn làm điều này:

• thiết lập chế độ phục hồi thành đơn giản
• coi chừng: DBCC SHRINKDATABASE (MyDatabase, TRUNCATEONLY);

Nếu bạn có 20003 (mb) dữ liệu thực tế trong cơ sở dữ liệu thì "SIZE = 20000" sẽ quá nhỏ. Hãy thử với 21000 hoặc 25000, xem điều đó có hiệu quả không. (Và nhớ, 1 GB = 1024 MB.)

Thử

DBCC SHRINKDATABASE (N'SMS2_Data' , 0)

Tôi đã sử dụng điều này trên cơ sở dữ liệu SQL 2005 tôi có ở đây và không gian được phân bổ cho tệp dữ liệu đã tăng từ 10,2 GB đến 3 GB.

Fyi, đây là một quá trình dài và mất hơn 19 phút cho cơ sở dữ liệu của tôi.

Tôi giả sử rằng bạn có một tệp cơ sở dữ liệu duy nhất có tên logic SMS2_Data. Bạn cũng có một hoặc nhiều tệp nhật ký giao dịch trong cơ sở dữ liệu.

Bạn có một thách thức không thể sửa được trên bản sao cơ sở dữ liệu hiện tại. Thông tin quan trọng mà bạn nêu là 'kích thước ban đầu của tệp cơ sở dữ liệu là 30 GB'. Thật không may, tập tin này không thể thu nhỏ hơn kích thước ban đầu của nó.

Như bạn đã có kinh nghiệm, SHRINKDB và SHRINKFILE không cung cấp cho bạn những gì bạn muốn. Các lệnh này tuân theo quy tắc không thể thu nhỏ hơn quy tắc kích thước ban đầu. Vì vậy, bạn chỉ có thể thu nhỏ cơ sở dữ liệu về kích thước ban đầu và không nhỏ hơn.

Sao lưu cơ sở dữ liệu và khôi phục lại cơ sở dữ liệu nhỏ hơn hiện có cũng không hoạt động. Khi bạn thực hiện khôi phục cơ sở dữ liệu, các tệp cơ sở dữ liệu sẽ được khôi phục về kích thước tệp như trong quá trình sao lưu. Và, mô hình phục hồi (đơn giản, đầy đủ, v.v.) không liên quan đến vấn đề này.

Và, một điểm xấu cuối cùng. Bạn có thể xem xét thêm các tệp cơ sở dữ liệu nhỏ hơn khác vào cơ sở dữ liệu, chuyển tất cả dữ liệu ra khỏi tệp 30 GB và sau đó loại bỏ nó. Thật không may, điều này sẽ không hoạt động vì bạn không thể xóa tệp ban đầu khỏi cơ sở dữ liệu.

Vì vậy, giải pháp tốt nhất là sao chép dữ liệu sang cơ sở dữ liệu khác. Bạn có một vài lựa chọn ở đây và có thể bạn đã biết về chúng. Bước đầu tiên là tạo một cơ sở dữ liệu mới với kích thước nhỏ hơn kích thước dữ liệu. Sau đó, bạn có thể mở rộng kích thước cơ sở dữ liệu đến kích thước yêu cầu.

Bạn có thể coi SSIS là một cách để chuyển dữ liệu từ cơ sở dữ liệu này sang cơ sở dữ liệu khác. Bạn sẽ tìm thấy một nhiệm vụ cơ sở dữ liệu sao chép sẽ giúp bạn ra ngoài. Bạn có thể sử dụng các bước sau:

1. Tạo cơ sở dữ liệu mới với kích thước nhỏ hơn cơ sở dữ liệu nguồn
2. Thiết lập gói SSIS với tác vụ cơ sở dữ liệu chuyển. Đặt tác vụ để sử dụng chuyển trực tuyến.
3. Chạy gói SSIS.
4. Gói SSIS có thể thay đổi kích thước cơ sở dữ liệu để phù hợp với kích thước cơ sở dữ liệu nguồn. Thu nhỏ cơ sở dữ liệu này, vì nó có kích thước tệp gốc nhỏ hơn.

Xem thêm thông tin về nhiệm vụ cơ sở dữ liệu chuyển SSIS .

Một số không gian không sử dụng trong cơ sở dữ liệu là bình thường.
Nếu bạn có nhiều bản ghi lớn (giả sử, chuỗi dài), có thể có nhiều không gian chưa sử dụng trong các trang dữ liệu (vì một bản ghi thường không được phân chia giữa các trang).
Một điều nữa là hệ số lấp đầy - ban đầu, các chỉ mục được nhóm không được tạo đầy đủ 100% để tránh chia tách trang (một thao tác đắt tiền) trong các lần chèn tiếp theo.
Nếu nhiều dữ liệu bị xóa khỏi cơ sở dữ liệu, không gian bị chiếm dụng trước đó bởi các dữ liệu này sẽ không tự động được lấy lại - nó sẽ được phân bổ vào bảng.

Hãy thử gọi DBCC DBREINDEX (table_name, '', 100)trên mỗi bảng trong cơ sở dữ liệu của bạn - nó sẽ xây dựng lại tất cả các chỉ mục với hệ số lấp đầy 100%, vì vậy dữ liệu được đặt càng gọn càng tốt. Sau đó thử thu nhỏ lại cơ sở dữ liệu.

Tôi đã phát hiện ra rằng việc thu hẹp cơ sở dữ liệu SQL Server có thể gây rắc rối. Cảm giác như bạn đã phải thực hiện một bài hát và điệu nhảy.

Đây là quá trình tôi thường trải qua:

Sao lưu cơ sở dữ liệu Shrink Sao lưu riêng biệt Nhật ký và tệp cơ sở dữ liệu. Sao lưu Lặp lại cho đến khi cuối cùng nó co lại.

Tôi đã phải thực hiện quá trình này một vài lần đến ba lần để cuối cùng nó hoạt động. Chúng tôi đã có một cơ sở dữ liệu có kích thước hơn 68 GB, với khoảng trống 98% chưa sử dụng. Đã đi qua thói quen hát và nhảy này nhiều lần, nhưng cuối cùng nó đã giảm xuống dưới 1GB.

Tôi đã cố gắng giảm kích thước ban đầu của tệp mdf xuống 29 000 MB trước, sau đó xuống 28, 000 để phát hiện lần truy cập gần.

Thật không hợp lý khi hy vọng giảm 30% kích thước tệp cơ sở dữ liệu bằng cách xóa 30% dữ liệu.

Bạn có thể ước tính bao nhiêu không gian chưa sử dụng trong cơ sở dữ liệu của bạn bằng cách

execute sp_spaceused

trong ngữ cảnh cơ sở dữ liệu của bạn (sử dụng yourdatabaename;)
Bạn có thể đăng kết quả thực hiện của nó không?

Cập nhật:
Tôi đã đăng câu hỏi liên quan của mình lên đó:

• nén, chống phân mảnh, lấy lại không gian, cơ sở dữ liệu thu nhỏ so với thu nhỏ