Khi nào thì thu nhỏ Cơ sở dữ liệu?

Tôi biết thu nhỏ là ma quỷ: Nó đảo ngược trật tự trang và chịu trách nhiệm cho bệnh ung thư da, phân mảnh dữ liệu và nóng lên toàn cầu. Danh sách này tiếp tục ... Điều đó có nghĩa là tôi có cơ sở dữ liệu 100 GB và tôi xóa 50 GB dữ liệu - không phải trên một bảng, mà là cắt xén chung dữ liệu cũ ở mức độ rộng của cơ sở dữ liệu, chiếm 90% bảng - điều này có tạo thành trường hợp sử dụng thích hợp để thu hẹp cơ sở dữ liệu không?

Nếu không, các bước thích hợp cần thực hiện để dọn dẹp nhà cửa sau khi loại bỏ phần trăm dữ liệu cao như vậy khỏi cơ sở dữ liệu là gì? Tôi có thể nghĩ về hai: Chỉ số xây dựng lại và Chỉ số cập nhật. Còn gì nữa không

Một tổ chức lại và thu nhỏ không bao giờ được khuyến khích thực sự.

Nếu bạn có thể lấy các ứng dụng mà cơ sở dữ liệu đang phục vụ ngoại tuyến, bạn có thể tăng tốc quá trình và giảm phân mảnh chỉ mục bằng cách xóa tất cả các chỉ mục và các ràng buộc khóa chính / ngoại khóa trước khi thu hẹp (điều này có nghĩa là sẽ có ít dữ liệu được di chuyển xung quanh vì chỉ có các trang dữ liệu sẽ được xáo trộn không phải là các trang chỉ mục hiện không tồn tại, tăng tốc quá trình) sau đó tạo lại tất cả các chỉ mục và khóa.

Tái tạo các chỉ mục sau khi thu nhỏ có nghĩa là chúng không bị phân mảnh đáng kể và việc chúng bị mất trong quá trình thu nhỏ có nghĩa là xây dựng lại chúng sẽ không để lại nhiều "lỗ hổng" nhỏ trong phân bổ trang trong các tệp có thể mời phân mảnh sau này.

Một tùy chọn khác nếu bạn có thể ngoại tuyến các ứng dụng là di chuyển tất cả dữ liệu sang cơ sở dữ liệu mới có cùng cấu trúc. Nếu quá trình xây dựng của bạn là vững chắc, bạn sẽ có thể xây dựng DB trống đó một cách nhanh chóng, nếu không tạo một DB từ DB hiện tại (khôi phục bản sao lưu của cái hiện tại, cắt / xóa tất cả nội dung trong các bảng và thực hiện thu nhỏ toàn bộ).

Bạn vẫn có thể muốn thả tất cả các chỉ mục vào đích và tạo lại chúng sau đó vì điều này có thể hiệu quả hơn rất nhiều khi thay đổi nhiều dữ liệu được lập chỉ mục (trong trường hợp này là 100%). Để tăng tốc quá trình sao chép, hãy đưa (các) cơ sở dữ liệu của cơ sở dữ liệu đích vào các ổ đĩa vật lý khác nhau vào nguồn (trừ khi bạn đang sử dụng SSD trong trường hợp bạn không cần quan tâm đến việc giảm chuyển động của đầu), bạn có thể di chuyển chúng đến vị trí nguồn khi bạn hoàn thành.

Ngoài ra, nếu tạo đích là mới (thay vì xóa một bản sao của nguồn), hãy tạo điểm đến với kích thước ban đầu sẽ chứa tất cả dữ liệu hiện tại cộng với một số tháng tăng trưởng - điều đó sẽ khiến dữ liệu sao chép nhanh hơn một chút nó sẽ không được phân bổ không gian mới mỗi lần trong suốt quá trình.

Điều này có thể tốt hơn so với sử dụng thu nhỏ vì di chuyển dữ liệu sang cơ sở dữ liệu mới sao chép hành động dự định của hoạt động thu nhỏ, nhưng có khả năng bị phân mảnh ít hơn (đó là hậu quả không lường trước của việc sắp xếp lại và thu nhỏ). Thu nhỏ chỉ đơn giản là lấy các khối từ gần cuối tệp và đặt chúng vào không gian đầu tiên gần đầu, không cần nỗ lực để giữ các dữ liệu liên quan với nhau.

Tôi nghi ngờ kết quả sẽ là không gian hiệu quả hơn vì có thể sẽ có ít trang được sử dụng một phần sau đó. Thu nhỏ sẽ chỉ di chuyển các trang được sử dụng một phần xung quanh, di chuyển dữ liệu có nhiều khả năng dẫn đến các trang đầy đủ đặc biệt là nếu bạn chèn vào đích theo thứ tự của khóa / chỉ mục được nhóm của bảng (trong đó một bảng có một) và tạo các chỉ mục khác sau khi dữ liệu đã di chuyển tất cả.

Tất nhiên, nếu bạn hoàn toàn không thể đưa các ứng dụng ngoại tuyến, chỉ cần thực hiện thu nhỏ là lựa chọn duy nhất của bạn, vì vậy nếu bạn thực sự cần phải lấy lại không gian thì hãy thực hiện điều đó. Tùy thuộc vào dữ liệu của bạn, các mẫu truy cập, kích thước tập làm việc chung, máy chủ có bao nhiêu RAM, v.v., sự phân mảnh bên trong có thể không đáng kể đến cuối cùng.

Đối với hoạt động sao chép, SSIS hoặc T-SQL cơ sở cũng sẽ hoạt động tốt (tùy chọn SSIS có thể kém hiệu quả hơn, nhưng có khả năng dễ dàng hơn để duy trì sau này). Nếu bạn tạo các mối quan hệ FK ở cuối cùng với các chỉ mục, bạn có thể thực hiện một "đơn giản cho mỗi bảng, sao chép" trong cả hai trường hợp. Tất nhiên đối với một lần, thu nhỏ + sắp xếp lại có lẽ cũng tốt nhưng tôi chỉ muốn làm mọi người sợ không bao giờ xem xét thu nhỏ thường xuyên! (Tôi đã biết mọi người lên lịch cho họ hàng ngày).

Là cơ sở dữ liệu sẽ phát triển trở lại? Nếu vậy thì nỗ lực bạn sẽ bỏ ra cho các hoạt động thu nhỏ sẽ là một sự lãng phí, bởi vì khi bạn đã giảm kích thước tệp và sau đó bạn thêm nhiều dữ liệu, tệp sẽ phải phát triển lại và giao dịch phải chờ sự tăng trưởng đó xảy ra. Nếu bạn có cài đặt tăng trưởng tự động tối ưu phụ và / hoặc lái xe chậm, hoạt động tăng trưởng này sẽ khá đau đớn.

Nếu bạn thu hẹp cơ sở dữ liệu, bạn sẽ sử dụng không gian đĩa được giải phóng để làm gì? Một lần nữa, nếu bạn sẽ giữ không gian trống trong trường hợp cơ sở dữ liệu này phát triển trở lại, thì bạn chỉ cần quay bánh xe của mình.

Những gì bạn có thể cân nhắc làm, bây giờ bạn đã có tất cả dung lượng trống này trong tệp, đang xây dựng lại các chỉ mục của bạn để chúng được tối ưu hóa tốt hơn (và sẽ bớt đau đớn hơn khi bạn có không gian trống để làm điều đó - nghĩ về việc cố gắng thay đổi một chiếc áo len trong tủ quần áo nhỏ so với phòng ngủ lớn).

Vì vậy, trừ khi đây là một hoạt động dọn dẹp lớn và bạn thực sự sẽ không tiếp tục sử dụng cùng một mức dữ liệu, tôi sẽ để nguyên như vậy và tập trung vào các lĩnh vực tối ưu hóa khác.

Nếu bạn sắp hết dung lượng và dữ liệu của bạn không được coi là lớn như vậy thì hãy thu nhỏ lại, nhưng xây dựng lại các chỉ số của bạn sau khi có các yếu tố điền thích hợp cho phép tăng trưởng điển hình.

Nếu mục tiêu cuối cùng của bạn thực sự là giảm kích thước sao lưu, hãy đảm bảo bạn thực hiện chiến lược sao lưu toàn diện để xóa nhật ký giao dịch và khi bạn sao lưu db, hãy sử dụng các tùy chọn nén.

• Tạo một bản sao lưu cơ sở dữ liệu đầy đủ (SQL Server)
• Sao lưu nhật ký giao dịch (SQL Server)

Tôi sẽ không đề xuất tăng trưởng tự động 5GB trừ khi bạn thường sẽ tăng 5GB thường xuyên. Bạn có thể có vấn đề hiệu suất không liên tục khác. Trước tiên, kích thước dữ liệu của bạn phải được đặt thành những gì bạn nghĩ là bắt buộc, giả sử, một năm và Tăng trưởng tự động phải được đặt thành kích thước mà bạn đã kiểm tra không ảnh hưởng đến hiệu suất hoạt động. Xem Đừng chạm vào nút thu nhỏ cơ sở dữ liệu trong máy chủ SQL! bởi Mike Walsh.

Xây dựng lại các chỉ mục trước khi thu hẹp làm cho các chỉ mục được đặt ra xấu. Nó không tốt để xây dựng lại sau đó thu nhỏ. Thu hẹp làm cho các chỉ mục bị xáo trộn để phục hồi không gian - vì vậy việc xây dựng lại trước đó sau đó thu hẹp là vô nghĩa. Xem Khi nào nên sử dụng Auto Shrink của Thomas LaRock.

Tôi không biết liệu điều này có hoạt động tốt hơn so với giới thiệu lại sau khi thu nhỏ hay không, nhưng một lựa chọn khác là tạo một tệp dữ liệu mới có kích thước phù hợp và di chuyển tất cả dữ liệu sang đó. Trong trường hợp đó tôi sẽ thực hiện reindex trước để bạn biết kích thước dữ liệu thực tế là gì. Một lưu ý là nếu đây là tệp đầu tiên trong tệp dữ liệu chính thì tôi không nghĩ bạn có thể làm trống nó. Bạn sẽ có thể thu nhỏ nó sau đó di chuyển dữ liệu trở lại sau đó và điều đó sẽ tránh đảo ngược trang. Tuy nhiên, nếu bạn đang tìm cách chuyển sang trạng thái rắn mà không nên tạo ra sự khác biệt lớn nào.

Trở lại với CÁCH này muộn. Tuy nhiên, chúng tôi đã cân nhắc và thử nghiệm việc sử dụng thu nhỏ trong môi trường thử nghiệm của chúng tôi trong một thời gian dài. Theo chủ đề, có những lúc thu nhỏ là một lựa chọn khả thi. Nhưng biết khi nào và làm thế nào để áp dụng nó, rất quan trọng để thực hiện đúng cả trong dài hạn và ngắn hạn.

Trong kịch bản của chúng tôi, gần đây chúng tôi đã thêm nhiều thay đổi vào DB lớn của chúng tôi bao gồm nén, phân vùng, lưu trữ và xóa dữ liệu cũ đơn giản. Do đó, phần được sử dụng của tệp dữ liệu chính của chúng tôi đã giảm xuống dưới một nửa so với trước đây. Nhưng những gì mang theo xung quanh tất cả hành lý đó? Đặc biệt là trái với một số bài viết trên web, kích thước của tệp dữ liệu của bạn TRỰC TIẾP ĐÚNG VỚI THỜI GIAN BACKUP / RESTORE. Đó là bởi vì không giống như nhiều bài báo giả định, các tình huống thực tế có nhiều dữ liệu trên bất kỳ trang nào hơn là những thứ bạn có thể xóa.

Hơn nữa, điều này mở ra một kịch bản tuyệt vời cho việc thu hẹp:

1. Tạo một tập lệnh sẽ tìm thấy tất cả các đối tượng và nhóm tệp của chúng trong cơ sở dữ liệu của bạn (nhiều ví dụ trực tuyến), sử dụng tập lệnh này để tạo các mệnh đề thả cũng như tạo định nghĩa cho mọi chỉ số và ràng buộc của bạn.
2. Tạo một tệp mới & filegroup và đặt mặc định đó.
3. Bỏ tất cả các chỉ số không bao gồm (lưu ý, một số chỉ mục có thể là các ràng buộc).
4. Tạo các chỉ mục được nhóm của bạn trên nhóm mới với DROP_EXISTING = ON (trong đó, btw, là một hoạt động cực kỳ nhanh, được ghi lại tối thiểu để bắt đầu so với nhiều lựa chọn thay thế).
5. Tái tạo các chỉ số không bao gồm của bạn.
6. Cuối cùng, CHIA SẺ tệp dữ liệu cũ của bạn (thường là CHÍNH).

Bằng cách này, dữ liệu duy nhất còn lại trong đó sẽ là các đối tượng, thống kê, quy trình và quy trình của DB. Việc thu nhỏ phải nhiều, NHIỀU nhanh hơn và không cần bảo trì chỉ mục thêm cho các đối tượng dữ liệu chính của bạn sẽ được tạo ra một cách gọn gàng theo thứ tự và rủi ro tối thiểu cho sự phân mảnh trong tương lai.