ALTER INDEX ALL REBUILD có sử dụng nhiều không gian nhật ký giao dịch với mô hình khôi phục đơn giản hơn là xây dựng lại từng chỉ mục riêng lẻ không?

Hoạt động "ALTER INDEX ALL REBUILD" trên SQL Server 2012 không thành công do nhật ký giao dịch hết dung lượng. Các chỉ số chưa bao giờ được tổ chức lại hoặc xây dựng lại, vì vậy sự phân mảnh chiếm hơn 80% trên gần như tất cả chúng.

DB sử dụng mô hình phục hồi đơn giản. Tôi giả định rằng sau mỗi hoạt động chỉ mục được thực hiện bởi hình thức "TẤT CẢ" của lệnh, dữ liệu nhật ký giao dịch sẽ bị xóa trước khi xây dựng lại chỉ mục tiếp theo. Đó có phải là cách nó thực sự hoạt động hay chỉ mục được xây dựng lại được ghi lại như thể chúng là một phần của một giao dịch?

Nói cách khác, tôi có thể giảm tăng trưởng nhật ký giao dịch bằng cách viết một tập lệnh để thực hiện mỗi lần xây dựng lại không? Có bất kỳ yếu tố khác để xem xét?

Tôi giả định rằng sau mỗi hoạt động chỉ mục được thực hiện bởi hình thức "TẤT CẢ" của lệnh, dữ liệu nhật ký giao dịch sẽ bị xóa trước khi xây dựng lại chỉ mục tiếp theo. Đó có phải là cách nó thực sự hoạt động hay chỉ mục được xây dựng lại được ghi lại như thể chúng là một phần của một giao dịch?

1) Xóa nhật ký: mô hình khôi phục SIMPLE không xóa nhật ký sau mỗi giao dịch, nhưng tại các điểm kiểm tra. ( liên kết để biết thêm)

2a) REBUILD ALL: có, REBUILD ALL hoạt động như một giao dịch đơn lẻ. Chỉ mục được xây dựng lại bên trong có các giao dịch riêng của họ, nhưng hoạt động chung không hoàn toàn được cam kết cho đến khi kết thúc. Vì vậy, có, bạn có thể hạn chế tăng trưởng tệp nhật ký bằng cách xây dựng lại các chỉ mục riêng lẻ (và có thể ban hành các lệnh CHECKPOINT).

2b) Bằng chứng! Ở đây, có một kịch bản demo. (Được xây dựng vào năm 2016 dev) Trước tiên, hãy thiết lập db thử nghiệm, với bảng và chỉ mục:

USE master
GO

CREATE DATABASE Test_RebuildLog
GO

ALTER DATABASE Test_RebuildLog
SET RECOVERY SIMPLE
GO

USE Test_RebuildLog
GO

CREATE TABLE IndexTest
(ID int identity(1,1),
a char(1),
b char(1))

CREATE CLUSTERED INDEX CIX_IndexTest_ID ON IndexTest(ID)
CREATE INDEX IX_IndexTest_a ON IndexTest(a)
CREATE INDEX IX_IndexTest_b ON IndexTest(b)

INSERT IndexTest
(a,b)
VALUES ('a','b'),('z','y'),('s','r')

Bây giờ bạn có thể so sánh hoạt động nhật ký giữa REBUILD ALL và xây dựng lại riêng lẻ

CHECKPOINT
GO
ALTER INDEX ALL ON IndexTest REBUILD

SELECT *
FROM sys.fn_dblog(NULL,NULL)
WHERE Operation = 'LOP_COMMIT_XACT'
OR Operation = 'LOP_BEGIN_XACT'
GO

CHECKPOINT
GO
ALTER INDEX CIX_IndexTest_ID ON IndexTest REBUILD
ALTER INDEX IX_IndexTest_a ON IndexTest REBUILD
ALTER INDEX IX_IndexTest_b ON IndexTest REBUILD

SELECT *
FROM sys.fn_dblog(NULL,NULL)
WHERE Operation = 'LOP_COMMIT_XACT'
OR Operation = 'LOP_BEGIN_XACT'
GO

Lưu ý cách giao dịch mở đầu tiên (ID giao dịch 0000: 000002fa đối với tôi) không được cam kết cho đến khi kết thúc REBUILD ALL, nhưng đối với việc xây dựng lại theo chỉ mục, chúng được cam kết liên tiếp.

Như nó đứng, đây là giao dịch duy nhất.

Câu hỏi là tầm thường đối với việc xây dựng lại ngoại tuyến . Tất nhiên là một giao dịch duy nhất. Hãy tưởng tượng sự tàn phá sẽ xảy ra nếu hoạt động phân tách từng chỉ số thành giao dịch của chính nó, vì nó sẽ phải giải phóng các khóa khi cam kết và sau đó mua lại chúng. Trong khi khóa SCH-M quan trọng được phát hành, các chỉ mục có thể bị hủy và các chỉ mục mới có thể được tạo, câu lệnh sẽ xử lý các trường hợp như thế nào? Chưa kể rằng bảng có thể bị hủy và thậm chí được tạo lại giữa hai giao dịch! Bao gồm cả trường hợp khi bảng bị hủy và một bảng khác được tạo với cùng một id đối tượng (vâng, nó có thể xảy ra) ...

Điều gì xảy ra nếu bạn tăng câu hỏi để nói điều gì xảy ra nếu xây dựng lại chỉ mục là xây dựng lại trực tuyến ? Đó là một giao dịch đơn lẻ hay nhiều? Câu trả lời rất phức tạp, vì thực sự có một số giao dịch nội bộ liên quan . Tuy nhiên, điểm mấu chốt là có một giao dịch cung cấp tổng thể kéo dài toàn bộ hoạt động (câu lệnh ALTER) và điều này ghim vào vị trí đăng nhập (không thể cắt ngắn), do đó thao tác cần được lên kế hoạch phù hợp để cho phép dữ liệu ~ 1.6x kích thước cho chế độ phục hồi ĐẦY ĐỦ hoặc kích thước dữ liệu 0,2x cho chế độ BULK_LOGGED / SIMPLE. Xem giấy liên kết để biết thêm chi tiết.

Bạn có thể lập luận rằng tại sao bản dựng ngoại tuyến không sử dụng cùng một giao dịch nội bộ mà chế độ trực tuyến thực hiện và phân chia hoạt động? Các vấn đề tôi đã đề cập về việc bảng bị thay đổi / loại bỏ giữa các hoạt động chỉ mục riêng lẻ (ví dụ: bảng 'ổn định lược đồ') vẫn sẽ yêu cầu có một giao dịch bao gồm giữ SCH-S trên bảng trong toàn bộ thời gian của câu lệnh. Vì giao dịch này phải giữ SCH-S trong quá trình khôi phục, nó phải được ghi lại và do đó sẽ có một bản ghi nhật ký BEGIN XACT sẽ ghim nhật ký và ngăn cắt ngắn trong toàn bộ thời gian của câu lệnh. Tôi biết vấn đề cụ thể này đã được giải quyết trong khung thời gian SQL 2016-2017 (vì các vấn đề về kích thước nhật ký SQL Azure), nhưng tôi không chắc tiến trình nào đã được thực hiện . Có vẻ như là trong bản xem trước bây giờ:Khôi phục chỉ mục trực tuyến Rebuild nằm trong bản xem trước công khai cho SQL Server 2017 CTP 2.0 .

Vâng, tôi đã có vấn đề tương tự với một cái bàn rất lớn. Bất cứ khi nào tôi phát hành ALTER INDEX ALL, nhật ký giao dịch sẽ phát triển rất nhiều, nhưng nếu được phát hành riêng lẻ ALTER INDEX, việc sử dụng không gian nhật ký sẽ nhỏ hơn.

Phản hồi trước đó của Remus rằng lập chỉ mục trực tuyến yêu cầu 1,6 lần kích thước chỉ mục trong chế độ phục hồi ĐẦY ĐỦ là không chính xác. Tỷ lệ không gian ghi nhật ký giao dịch cần thiết để xây dựng lại một chỉ mục trực tuyến trong FULL có thể cao hơn nhiều và chúng tôi đã quan sát nhiều lần kích thước của chỉ mục, đặc biệt là khi chỉ mục được xây dựng lại được nén khi ghi nhật ký giao dịch không được nén. Điều này một mình sẽ làm rõ rằng việc ghi nhật ký giao dịch trong quá trình xây dựng lại trực tuyến trong FULL có thể ít nhất gấp vài lần kích thước của chỉ mục. Thêm vào chi phí bản ghi tlog không được Microsoft ghi lại đầy đủ nhưng thường được ước tính là 60 byte mỗi hàng và kích thước ghi nhật ký trong một chỉ mục trực tuyến được xây dựng lại dưới sự phục hồi hoàn toàn có thể gấp nhiều lần kích thước của chỉ mục được xây dựng lại, đặc biệt là nếu chỉ số được nén

Rdfozz đúng là cách tốt nhất để quyết định liệu chỉ số lớn nhất của bạn có thể được xây dựng lại dựa trên bộ nhớ hiện tại hay không. Chỉ cần chạy dm_exec_requeststrong khi hoạt động đang diễn ra (hoặc SQL Profiler) để xem liệu tất cả các chỉ mục đang được xây dựng lại. Tôi cũng sẽ xem xét thay đổi mô hình phục hồi để đăng nhập hàng loạt. Đây là những gì tôi làm và vẫn có bản sao lưu nhật ký giao dịch trong cửa sổ. Xem bài viết dưới đây https://technet.microsoft.com/en-us/l Library / ms191484 (v = sql.105) .aspx