Vấn đề đọc dữ liệu từ thứ cấp khi sắp xếp lại chỉ mục cụm


7

Chúng tôi có AOAG trong SQL Server 2014 SP2 CU5 (3 nút). Có một cơ sở dữ liệu với mức cô lập Ảnh chụp nhanh đã cam kết BẬT . Chúng tôi có một bảng lớn nén. Một số truy vấn lớn hơn của chúng tôi trên bảng này được thực hiện vào phụ.

Sau đó, có một công việc ban đêm trên nút chính để sắp xếp lại các chỉ mục trên một số bảng. Khi nó chạm vào chỉ mục được nhóm của bảng đã đề cập, chúng tôi gặp lỗi sau:

Giao dịch bị hủy bỏ khi truy cập hàng được phiên bản trong bảng 'xxxx' trong cơ sở dữ liệu 'yyyy'. Hàng phiên bản được yêu cầu không được tìm thấy vì truy cập thứ cấp có thể đọc được không được phép cho hoạt động đã cố gắng tạo phiên bản.

Tại một số điểm, các truy vấn lớn đang thực hiện việc đọc với gợi ý READUNCOMMITTED. Tôi nghĩ rằng đó là nguyên nhân của lỗi này vì vậy tôi đã loại bỏ chúng. Nhưng lỗi vẫn còn đó.

Có ý kiến ​​gì không?

Thiết lập hiện tại:

  • 02 phụ là trên chế độ đồng bộ
  • 03 phụ trên chế độ không đồng bộ

Thiết lập hiện tại AOAG

Bảng chi tiết

  • Số lượng hàng: 122.567.668
  • TotalSpaceMB: 18.460
  • Được sử dụngSpaceMB: 18.238

Định nghĩa:

CREATE TABLE [dbo].[big_table](
[ID] [int] NOT NULL IDENTITY(1, 1),
1 [int] NULL,
2 [datetime] NULL,
3 [int] NULL,
4 [int] NULL CONSTRAINT [DF_ccc_bUnits] DEFAULT ((0)),
5 [money] NULL,
6 [money] NULL,
7 [int] NULL,
8 [int] NULL CONSTRAINT [DF_ccc_MinDays] DEFAULT ((0)),
9 [int] NULL,
10 [int] NULL,
11 [float] NULL,
12 [money] NULL,
13 [int] NULL,
14 [int] NULL,
15 [nvarchar] (200) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
16 [money] NULL,
17 [money] NULL,
18 [int] NULL,
19 [int] NULL,
20 [money] NULL,
21 [money] NULL,
22 [money] NULL,
23 [money] NULL,
24 [money] NULL,
25 [datetime] NOT NULL CONSTRAINT [DFcccadded] DEFAULT (getdate()),
26 [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
27 [money] NOT NULL CONSTRAINT [DFcccBrf] DEFAULT ((0)),
29 [money] NOT NULL CONSTRAINT [DFcccHB] DEFAULT ((0)),
30 [money] NOT NULL CONSTRAINT [DFcccFB] DEFAULT ((0)),
31 [money] NOT NULL CONSTRAINT [DFcccAllBoards] DEFAULT ((0)),
32 [money] NOT NULL CONSTRAINT [DFcccChildBrf] DEFAULT ((0)),
33 [money] NOT NULL CONSTRAINT [DFcccChildHB] DEFAULT ((0)),
34 [money] NOT NULL CONSTRAINT [DFcccChildFB] DEFAULT ((0)),
35 [money] NOT NULL CONSTRAINT [DFcccChildAllBoards] DEFAULT ((0)),
36 [int] NULL CONSTRAINT [DFcccShow_1] DEFAULT ((0)),
37 [timestamp] NOT NULL,
38 [money] NULL,
39 [money] NULL,
40 [money] NULL,
41 [money] NULL,
42 [money] NULL,
43 [money] NULL,
44 [money] NULL,
45 [money] NULL,
46 [int] NOT NULL CONSTRAINT [DFcccReleaseHour] DEFAULT ((0)),
47 [int] NULL,
48 [int] NULL,
49 [money] NULL,
50 [money] NULL,
51 [float] NULL
) ON [PRIMARY]
WITH (DATA_COMPRESSION = PAGE)
GO
CREATE UNIQUE CLUSTERED INDEX [IXccc] ON [dbo].[big_table] (1, 2) WITH (FILLFACTOR=90, DATA_COMPRESSION = PAGE) ON [PRIMARY]
GO
ALTER TABLE [dbo].[big_table] ADD CONSTRAINT [PKccc] PRIMARY KEY NONCLUSTERED ([ID]) WITH (DATA_COMPRESSION = PAGE) ON [secondary]
GO
CREATE UNIQUE NONCLUSTERED INDEX [IXcccstamp] ON [dbo].[big_table] (36) INCLUDE (1, 2) WITH (FILLFACTOR=100) ON [PRIMARY]
GO

bạn đã thử sắp xếp lại công việc ban đêm chưa? bao lâu thì bạn gặp lỗi này? và mức độ thường xuyên bạn cần phải sắp xếp lại khóa cụm trên bàn lớn của bạn? có vẻ như bảng của bạn có khóa phân cụm rộng hoặc khóa phân cụm không tăng .. Duy trì chỉ mục trong AG là một chút khó khăn, hãy cố gắng sắp xếp lại công việc chỉ mục của bạn để không chạy cùng lúc với các truy vấn của bạn.

1
Sử dụng phiên bản hàng dự kiến. Bảng này được truy cập cả ngày không ngừng, thời gian tốt nhất là sau nửa đêm, một cái gì đó chúng tôi đã làm. Đã lên lịch lại để tránh các công việc nặng nhọc khác, vẫn gặp vấn đề này, không phải lúc nào cũng vậy.
Yar Tư

đây là những gì tôi muốn giới thiệu: cô lập chỉ mục được nhóm khỏi công việc bảo trì chỉ mục của bạn. kiểm tra xem bạn có thể tách nó ra khỏi công việc chỉ mục không. hãy thử tự chạy nó trong thời gian thấp điểm .. xem cách nó hoạt động. btw, mất bao lâu để chạy công việc chỉ mục?, còn tại sao bạn cần phải lập chỉ mục lại?

Bất kỳ may mắn trên cô lập công việc chỉ số cụm? Sẽ rất hữu ích khi cung cấp chi tiết công việc chỉ mục (bạn đã chạy bảo trì chỉ mục như thế nào và mất bao lâu). có vẻ như vấn đề này không phổ biến và nó sẽ có lợi cho những người khác nếu bạn đã giải quyết vấn đề.

Cho đến nay chúng tôi đã có lỗi vài lần. Chúng tôi đang cố gắng cô lập công việc càng nhiều càng tốt để chúng tôi có thể chạy thử nghiệm kỹ lưỡng. Ngoài ra, chạy một số thử nghiệm khác để cải thiện / cập nhật các công việc bảo trì chỉ mục của chúng tôi và tránh việc làm thêm không thực sự cần thiết. Ngay sau khi tôi có kết quả để chia sẻ sẽ cập nhật câu hỏi hoặc thêm câu trả lời.
Yar Tư

Câu trả lời:


0

Vì vậy, sau khi hết các giải pháp khả thi, chúng tôi đã mở một trường hợp hỗ trợ cho Microsoft. Họ yêu cầu chạy một công cụ để thu thập một số thông tin trong khi quá trình đang chạy và sau đó họ đã phân tích nó. Đây là câu trả lời của họ:

  • Bạn chọn lệnh đang chạy tốt nếu nó bắt đầu trước khi tổ chức lại công việc chỉ mục được bắt đầu
  • Chọn lệnh không thành công nếu nó bắt đầu sau khi tổ chức lại công việc được bắt đầu.
  • Tìm thấy hành vi trên là hành vi dự kiến ​​trong AG.
    • Mặc dù các hoạt động đọc không có khóa chia sẻ vì phiên bản hàng, các hoạt động này có khóa ổn định lược đồ (Sch-S), có thể chặn các hoạt động làm lại đang áp dụng thay đổi DDL. Các hoạt động DDL bao gồm các bảng ALTER / DROP và dạng xem nhưng không phải DROP hoặc ALTER của các thủ tục được lưu trữ.
    • Trong trường hợp của chúng tôi trong khi tổ chức lại chỉ mục đang chạy trên hoạt động làm lại chính cho cùng một hoạt động đang được thực hiện trên bản sao thứ cấp và đang có được Sch-M (khóa sửa đổi lược đồ), khi lệnh select đang cố truy cập vào cùng một bản sao thì không thể có được các khóa Sch-S (Ổn định Schema) vì nó đã bị chiếm bởi luồng làm lại có khóa Sch-M.
    • Trong trường hợp này, ứng dụng của bạn đang tạo ra các lỗi bao gồm cả lỗi hết thời gian.
  • Để tránh loại tình huống này, nên lập lịch tổ chức lại nhiệm vụ chỉ mục trong giờ làm việc

Chúng tôi không có "giờ làm việc", chúng tôi chạy 24/7/365. Không phải là một câu trả lời dứt khoát, nhưng ít nhất chúng ta biết nguyên nhân sâu xa của vấn đề này. Vì vậy, cách tiếp cận sẽ là tạm thời thay đổi chuỗi kết nối để tác vụ bị lỗi sẽ đọc từ nút AG chính thay vì nút AG thứ cấp vào ngày reindex chạy.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.