Tôi có một cơ sở dữ liệu rất lớn trong kho dữ liệu của chúng tôi, nơi chúng tôi đã triển khai phân vùng để quản lý bảo trì và sao lưu. Các bản ghi ở một độ tuổi nhất định cuối cùng được chuyển sang nhóm tệp chỉ đọc mỗi tháng một lần.
Đôi khi, quá trình ETL của chúng tôi cố gắng cập nhật các hồ sơ cũ hơn đã được di chuyển vào kho lưu trữ và chúng tôi hy vọng những điều này sẽ thất bại. Tuy nhiên, tôi có ít nhất hai ví dụ gần đây trong đó bản ghi trong kiểm tra được cập nhật ngay cả khi nó xuất hiện trong một phân vùng trên nhóm tệp chỉ đọc trong môi trường thử nghiệm của chúng tôi (truy vấn sys.partition_functionsvà sys.partition_range_values).
Một bản ghi giống hệt trong sản xuất gây ra sự thất bại dự kiến khi cố gắng cập nhật bản ghi. Hai lần chúng tôi đã bắt gặp điều này cho đến nay bản cập nhật thất bại trong sản xuất nhưng thành công trong thử nghiệm (không bao giờ có cách khác).
Sự thật môi trường có liên quan:
- Máy chủ SQL 2012 SP3 CU3 (bản dựng 11.0,6537.0)
- Kiểm tra là phiên bản dành cho nhà phát triển, sản xuất là doanh nghiệp
- Có thể cung cấp cho người khác theo yêu cầu: Nghiêm túc bị vấp ngã ngay bây giờ ...
CẬP NHẬT 2016-08-19
Có hồ sơ mới được cập nhật bằng cách nào đó qua đêm. Xác nhận nó nằm trong nhóm tập tin chỉ đọc. Tìm thấy rằng tôi có thể cập nhật các bản ghi được chèn cùng một lúc (nghĩa là cũng nằm trên cùng một phân vùng trên filegroup chỉ đọc). Tôi đã xác định một bản ghi trên cùng một phân vùng và đã có thể cập nhật bản ghi nhiều lần. Nỗ lực cập nhật hồ sơ cập nhật kết quả qua đêm trong thất bại dự kiến.
CẬP NHẬT 2016-08-11
Các cập nhật tiếp tục xảy ra trong quá trình xử lý hàng đêm trong thử nghiệm trên phân vùng chỉ đọc. Cố gắng cập nhật các hồ sơ tương tự từ quá trình không thành công. Cố gắng cập nhật các bản ghi tương tự trong khi đăng nhập là người dùng đã cập nhật nó trước đó không thành công. Tôi cũng không thể sao chép vấn đề bằng cách cập nhật một bản ghi tương tự chưa được xử lý bởi quy trình hàng đêm.
CẬP NHẬT 2016-08-04
Hôm nay phát hiện ra rằng nó không bị giới hạn trong một bảng duy nhất khi tôi phát hiện ra một sự xuất hiện khác của cùng một hành vi trên một bảng khác bằng cách sử dụng cùng một sơ đồ phân vùng.
CẬP NHẬT 2016-08-03
Chạy tập lệnh từ tập lệnh MSDN này xác nhận những gì tôi nhận được khi sử dụng chế độ xem trình trợ giúp phân vùng của Kendra Little ph.FilegroupDetailvà ph.ObjectDetailtừ bản demo này . Bản ghi trong câu hỏi nằm trong phân vùng số 2 (giá trị cột phân vùng cho bản ghi được đề cập là 2015 / 03-18)
Filegroup Low Boundary UpperBoundary
Archive (RO) NULL 1900-01-01
Archive (RO) 1900-01-01 2015-04-01
ActiveFG (RW) 2015-04-01 2015-07-01
ActiveFG (RW) 2015-07-01 2015-10-01
ActiveFG (RW) 2015-10-01 2015-01-01
ActiveFG (RW) 2016-01-01 2016-04-01
ActiveFG (RW) 2016-04-01 2016-07-01
ActiveFG (RW) 2016-07-01 2016-10-01
ActiveFG (RW) 2016-10-01 2017-01-01
ActiveFG (RW) 2017-01-01 2115-01-01
ActiveFG (RW) 2115-01-01 NULL
Mã để đặt bảng trên phân vùng (không có chỉ mục nào khác)
ALTER TABLE [dbo].[TABLE_NAME] ADD CONSTRAINT [pk_TABLE_NAME] PRIMARY KEY CLUSTERED
(
[ETL_VERS_START_DTM] ASC,
[ACCT_NO] ASC,
[ACCT_TYPE] ASC
) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON ps_SmallTablesDate(ETL_VERS_START_DTM)
Tuyên bố cập nhật sẽ thất bại (thông qua Informatica):
UPDATE TABLE_NAME SET ETL_JOB_SEQ_NUM = ?, ETL_IUD_CD = ?, ETL_UPD_DTM = ?, ETL_DEL_DTM = ? WHERE ETL_VERS_START_DTM = ? AND ACCT_NO = ? AND ACCT_TYPE = ?
ETL_VERS_START_DTM (ETL_VERS_START_DTM:Date:): "03/17/2015 23:30:02.140000000"
ETL_JOB_SEQ_NUM (ETL_JOB_SEQ_NUM:Int:): "1173651"
ETL_IUD_CD (ETL_IUD_CD:Char.1:): "D"
ETL_UPD_DTM (ETL_UPD_DTM:Date:): "08/02/2016 02:32:45.000000000"
ETL_DEL_DTM (ETL_DEL_DTM:Date:): "08/02/2016 00:10:03.567000000"
ACCT_NO (ACCT_NO:Char.12:): "1234567890"
ACCT_TYPE (ACCT_TYPE:Char.3:): "OLN"
CẬP NHẬT 2017 / 02-21
Vì vậy, sau tất cả thời gian này, chúng tôi đã phát hiện ra rằng bằng cách nào đó khi phân vùng hoạt động lâu đời nhất được sáp nhập vào kho lưu trữ, một phần hồ sơ không được chuyển trên đĩa từ nhóm tệp hoạt động sang nhóm tệp lưu trữ. Truy vấn sau đây cho thấy các bản ghi từ phân vùng 2 đã được ánh xạ tới ActiveFG trong khi kiểm tra sơ đồ phân vùng thực tế cho thấy rằng các bản ghi tương tự sẽ được sắp xếp vào nhóm tệp Lưu trữ theo chức năng phân vùng.
SELECT OBJECT_NAME(P.[object_id]) ,
P.index_id ,
P.partition_number ,
F.name ,
F.filegroup_guid
FROM sys.allocation_units AU
JOIN sys.partitions P ON P.partition_id = AU.container_id
JOIN sys.filegroups F ON F.data_space_id = AU.data_space_id
WHERE P.partition_number IN ( 1, 2, 3 )
AND P.[object_id] = OBJECT_ID('TABLE_NAME')
ORDER BY P.partition_number;
Tôi đã sao lưu tất cả các phân vùng trong cơ sở dữ liệu sử dụng thực tế và giữ một phiên bản của cơ sở dữ liệu đã bị hỏng để làm việc với vé Microsoft. Tôi cần phải điều chỉnh lại kế hoạch phân vùng với nhóm DW của chúng tôi nhưng tôi sẽ thừa nhận là một người nhưng lại ngại ngùng khi thử lại lần nữa.
Microsoft đã không thể sao chép hành vi này và vì vậy được thực hiện với vé tại thời điểm này. Họ dường như đã sẵn sàng để nhún vai và cho rằng nó không có mặt trong 2014/2016? Họ dường như không thể sao chép nó trong phòng thí nghiệm của họ mặc dù khả năng của tôi để nó tiếp tục tồn tại trong cơ sở dữ liệu ngay cả khi tôi khôi phục nó từ bản sao lưu trong hệ thống của mình.