Làm thế nào để ngăn chặn nhật ký giao dịch đầy đủ trong khi tổ chức lại chỉ mục?

Chúng tôi có nhiều máy trong đó chúng tôi đã phân bổ trước kích thước của nhật ký giao dịch là 50gb. Kích thước của bảng mà tôi đang cố gắng sắp xếp lại là 55 - 60 gb nhưng sẽ liên tục tăng. Lý do chính tôi muốn tổ chức lại là để lấy lại không gian và bất kỳ lợi ích hiệu suất nào vì đó là một phần thưởng bổ sung.

Mức độ phân mảnh của bảng là 30 - 35%. Trên một số máy này, tôi gặp lỗi "nhật ký giao dịch đầy đủ" và sắp xếp lại không thành công. Kích thước nhật ký giao dịch lên tới 48gb. Một cách tốt để chống lại điều này là gì? Chúng tôi không bật tự động tăng và tôi miễn cưỡng làm như vậy.

Tôi có thể tăng kích thước nhật ký lên giá trị lớn hơn nhưng khi kích thước bảng tăng trong tương lai, giá trị có thể không đủ. Ngoài ra, nó đánh bại mục đích của việc tổ chức lại để lấy lại không gian nếu tôi sẽ tăng kích thước nhật ký như nhau. Bất kỳ ý tưởng về làm thế nào tôi có thể chống lại điều này một cách hiệu quả? Sử dụng chế độ hàng loạt không phải là một lựa chọn vì mất dữ liệu là không thể chấp nhận được.

Thực hành tốt nhất là REORGANIZEdưới mức phân mảnh khoảng 30% và REBUILDtrên mức này. Đơn giản, REBUILDtạo một bản sao sạch, REORGANIZEthực hiện tại chỗ.

Kiểm tra những gì bạn thực sự đang làm: bạn không có kế hoạch bảo trì làm cả hai phải không?

Trên các bảng lớn hơn (bảng 50 GB đang đến đó) Tôi đã thấy REORGANIZEtiêu thụ tất cả không gian nhật ký giao dịch nếu bạn tuân theo quy tắc này. Không thường xuyên: chỉ có một hệ thống với một mẫu tải nhất định. Các REORGANIZEchỉ ran cho đến khi log mở rộng và tiêu thụ tất cả các không gian đĩa.

Chúng tôi chuyển sang REBUILDthay vì không có nhiều vấn đề, nhưng bỏ qua phân mảnh dưới 25%. Điều này làm việc tốt hơn cho chúng tôi: bạn sẽ phải xem nó có hiệu quả với bạn không.

REBUILDcó thể ảnh hưởng đến hiệu suất nhiều hơn REORGANIZEtrong sản xuất, nhưng điều này đôi khi có thể được giảm thiểu bằng ONLINEtùy chọn (Yêu cầu phải có Phiên bản doanh nghiệp).

REORGANIZE (như trong ALTER INDEX ... REORGANIZE) là một hoạt động rất nhanh (tốt, chủ yếu là ...), yêu cầu số lượng nhật ký nhỏ, có thể bị gián đoạn bất cứ lúc nào và tiếp tục lại sau đó, và hoạt động nội bộ trong các giao dịch hàng loạt nhỏ :

phân mảnh được thực hiện dưới dạng một loạt các giao dịch ngắn, do đó, một nhật ký lớn là không cần thiết nếu sao lưu nhật ký được thực hiện thường xuyên hoặc nếu cài đặt mô hình khôi phục là SIMPLE.

Bạn có chắc là bạn không nói về việc xây dựng lại ? Một chỉ mục REBUILD chậm, tốn kém, tiêu thụ một lượng nhật ký khổng lồ (nếu không ngoại tuyến và không thể đăng nhập tối thiểu , xây dựng lại trực tuyến không thể được ghi lại tối thiểu), là một giao dịch khổng lồ và không thể bị gián đoạn mà không mất tất cả công việc.

Dường như với tôi rằng bạn đang thực hiện việc xây dựng lại, đây là một hoạt động thực sự đặc biệt mà bạn không nên làm trừ khi bạn có lý do cực kỳ suy nghĩ. Bạn đang hy vọng loại không gian nào? Bất cứ điều gì DBCC CLEANTABLEsẽ không xử lý? Bạn đã kiểm tra cấu trúc vật lý của bảng chưa, nó có bị trôi khỏi cấu trúc logic không (xem các cột bảng SQL Server bên dưới mui xe để biết chi tiết)?

Nếu bạn thực sự phải xây dựng lại bảng thì tôi sợ bạn không còn cách nào khác ngoài việc cắn viên đạn và phân bổ nhật ký cần thiết. Đừng để nó tự động phát triển, nó sẽ chỉ làm chậm quá trình. Phát triển trước nó tới 2,5 lần kích thước của bảng.

Nếu bảng được phân vùng thì bạn có thể xây dựng lại ngoại tuyến (và sắp xếp lại) một phân vùng một lần. Xây dựng lại trực tuyến chỉ có thể được thực hiện ở toàn bộ cấp độ bảng.

Tôi đã có vấn đề này trước đây.

• Bạn có một cơ sở dữ liệu lớn và một ổ đĩa nhỏ. Bạn muốn tổ chức lại (vì nhiều lý do).
• Khi bạn thử điều này trên một bảng phân mảnh lớn, nhật ký sẽ điền cho đến khi ổ đĩa nhật ký đầy và sau đó lệnh hủy bỏ.
• Nếu ở chế độ đơn giản, các giao dịch khác có thể thất bại cho đến khi nhật ký bị xóa trong điểm kiểm tra tiếp theo và nếu ở chế độ đầy đủ, các giao dịch khác có thể thất bại cho đến lần sao lưu nhật ký tiếp theo. Mất điện!
• Nếu bạn ở chế độ đầy đủ, bạn tăng tần suất sao lưu nhật ký nhưng điều đó không giúp tránh được vấn đề vì việc sắp xếp lại được thực hiện trong một giao dịch ngầm, nhật ký sẽ không rõ ràng cho đến khi giao dịch kết thúc hoặc hủy bỏ hoặc bị dừng.
• Và bạn thực sự muốn tổ chức lại để chạy đến hoàn thành.

Đó là một chút phản trực giác bởi vì bạn biết nếu bạn hủy bỏ việc sắp xếp lại thì nó có thể tiếp tục từ nơi nó rời đi, chỉ là việc hủy bỏ thực hiện giao dịch thay vì quay trở lại.

Đây là những gì bạn làm. Nó hơi dài nhưng đơn giản.

• Phát triển trước tệp nhật ký của bạn đến kích thước tương đối lớn, nhưng không phải là tối đa. Về cơ bản, bạn muốn để lại đủ không gian để thực hiện công việc hữu ích, cộng với một số tăng trưởng nhỏ nếu chúng xảy ra, để các hoạt động bình thường sẽ không dừng lại.
• Tạo một công việc để chạy lại chỉ mục của bạn ('Sắp xếp lại').

• Tạo cảnh báo WMI tác nhân ('Sắp xếp lại van cứu trợ') trong điều kiện hiệu suất.

  • Đối tượng: SQLServer: Cơ sở dữ liệu
  • Số lượt truy cập: Phần trăm Nhật ký được sử dụng
  • Sơ thẩm: (tên cơ sở dữ liệu lớn của bạn)
  • Thông báo nếu bộ đếm tăng lên trên: 80
  • Trả lời: Thực thi công việc ('Kiểm tra lại tổ chức')

• Tạo một công việc ('Kiểm tra lại tổ chức')

  • Trong công việc, hãy kiểm tra msdb.dbo.sysjobactivity để xem công việc 'Sắp xếp lại' có đang chạy hay không. Và nếu đó là ...
  • Dừng công việc và thăm dò ý kiến ​​cho đến khi nó dừng lại. Điều này có thể mất một vài giây.
  • (Nếu bạn đang ở chế độ đầy đủ) Kích hoạt công việc sao lưu nhật ký của bạn và xác nhận khi nào nó kết thúc.
  • Kiểm tra kỹ sys.dm_os_performance_counters rằng bộ đếm không gian trống nhật ký của bạn đã giảm dưới ngưỡng của bạn.
  • Bắt đầu công việc 'Sắp xếp lại'.

• Kiểm tra tất cả điều này ở đâu đó, thậm chí là một hộp cát phát triển, để đảm bảo nó hoạt động đúng trước khi dán nó vào máy chủ sản xuất của bạn.

Những gì bạn sẽ thấy là công việc 'Sắp xếp lại' bắt đầu và bắt đầu điền vào nhật ký. Khi nhật ký đạt đến một phần trăm đầy đủ, nó sẽ kích hoạt cảnh báo WMI (trong khoảng 30 giây) để chạy công việc khác của bạn, thấy rằng công việc 'Sắp xếp lại' đang chạy và rất có thể có lỗi. Sau đó, nó dừng 'Sắp xếp lại', thực hiện sao lưu, xác nhận không gian trống nhật ký trở lại giá trị hợp lý, sau đó bắt đầu lại công việc 'Sắp xếp lại' của bạn, nơi sẽ tiếp tục ở nơi nó dừng lại.

Vì vậy, vì lý do bạn có thể thay đổi kích thước trước nhật ký của mình thành một con số hợp lý trong kịch bản này là để giảm số lượng tăng trưởng / kích hoạt / công việc / dừng / khởi động lại, để nó có thể hiệu quả hơn và cũng giữ đủ không gian cho tăng trưởng không thường xuyên mà không bắt kịp thời gian.

Đây là một loại kịch bản kỳ lạ. Tôi khá chắc chắn rằng tôi đã bực bội về điều này một vài năm trước và rõ ràng có những vấn đề cơ bản tiềm ẩn trong tay ở đây. Nhưng nếu bạn đối phó với hàng trăm máy chủ, một vài trường hợp như thế này sẽ mọc lên mà không thể xử lý bằng bất kỳ cách nào, vì bất kỳ lý do kinh doanh nào, ngoại trừ MacGyvering một giải pháp tạm thời hoàn thành công việc.

Miễn là nó an toàn, hợp lý, được kiểm tra và được ghi chép đầy đủ, sẽ không có vấn đề gì.

Đây là những gì tôi thường làm (tôi cũng có một vài bảng với mỗi bảng lớn hơn 80 GB) cho reorg chỉ mục (vì reorg chỉ mục có thể bị dừng bất cứ lúc nào mà không mất công việc reorg trước đó).

1. Trong quá trình reorg chỉ mục, tôi sẽ tăng sao lưu tlog từ tần số 30 phút thông thường của mình lên tần số 10 phút
2. Tôi có một phiên khác thực hiện kiểm tra không gian trống tlog cứ sau 1 phút và nếu không gian trống tlog dưới ngưỡng, tôi sẽ dừng phiên reorg chỉ mục và bắt đầu (hoặc chờ) sao lưu tlog. Sau đó khởi động lại chỉ số reorg.

Trong khung bảo trì chỉ mục của tôi, tôi phân loại các chỉ mục thành hai nhóm, một nhóm là để xây dựng lại chỉ mục và một nhóm khác để tái lập chỉ mục. Để xây dựng lại chỉ mục, tôi sẽ sử dụng một số cách tiếp cận khác vì tôi không muốn dừng phiên xây dựng lại chỉ mục (điều này sẽ gây ra sự phục hồi và mất tất cả các công việc trước đó). Trong quá trình xây dựng lại chỉ mục, nếu phiên giám sát của tôi thông báo kịch bản không gian trống của tệp tlog đã sử dụng, phiên giám sát sẽ tự động tăng trước tệp tlog và trong trường hợp xấu nhất (tức là đĩa đã đầy), phiên giám sát của tôi sẽ tạo một tệp nhật ký khác ( nhưng sau này tôi sẽ thả nó) vào một ổ đĩa khác (ổ đĩa sao lưu)

Tôi có cùng một vấn đề với tác giả câu hỏi và nhìn vào bình luận của anh ấy, tôi có thể nói rằng tôi đã có cùng một thiết lập. Trong khi tôi đang cố gắng thực hiện REORGANIZE, nhật ký sẽ phát triển đầy đủ, bất kể kích thước, thậm chí gấp nhiều lần kích thước của toàn bộ bảng.

Vấn đề là do nhân rộng giao dịch . Rõ ràng, nhật ký không thể được sao lưu cho đến khi REORGANIZEhoạt động kết thúc. Tôi đã đọc ở đâu đó rằng đó là một vấn đề được biết đến bởi Microsoft, nhưng tôi không chắc là ở đâu.

Khi tôi vô hiệu hóa sao chép giao dịch, sao lưu nhật ký hoạt động bình thường trở lại và thực hiện sao lưu nhật ký cứ sau 30 giây trong khi tổ chức lại hoạt động tốt với tôi.

Tôi giả sử bạn đang chạy một cái gì đó dọc theo dòng:

THAY ĐỔI INDEX VỀ SỬA CHỮA

Thật không may, không có cách nào để chạy một tổ chức một phần (ví dụ như cách bạn có thể thu nhỏ một phần tệp nhật ký). Những cách tôi có thể nghĩ xung quanh vấn đề này là:

1) đặt cơ sở dữ liệu về chế độ khôi phục đơn giản trong khi bạn chạy sắp xếp lại, nhưng bạn nói rằng không thể chấp nhận được

2) phân vùng chỉ mục - nếu có thể nghĩ ra cách phân vùng chỉ mục để có được các phân vùng có kích thước xấp xỉ bằng nhau, thì bạn sẽ có thể tổ chức lại (hoặc xây dựng lại với tùy chọn trực tuyến) mỗi phân vùng một cách độc lập và do đó hạn chế sự phát triển tệp nhật ký

Tôi chắc chắn rằng bạn đang làm điều này, nhưng nếu bạn không, bạn có thể muốn bắt đầu sao lưu tệp nhật ký trước và sau khi bạn thực hiện bất kỳ tối ưu hóa chỉ mục nào, điều này sẽ cho phép nó lấy lại không gian đã sử dụng.