Catatan SQL Server Diperbarui pada Read-Only Filegroup?

Saya memiliki basis data yang sangat besar di gudang data kami di mana kami telah mengimplementasikan partisi untuk mengelola pemeliharaan dan cadangan. Catatan usia tertentu pada akhirnya dimigrasikan ke grup file hanya baca sebulan sekali.

Terkadang proses ETL kami berupaya memperbarui catatan yang lebih lama yang telah dimigrasi ke arsip dan kami berharap ini gagal. Namun, saya memiliki setidaknya dua contoh terbaru di mana catatan dalam pengujian diperbarui bahkan ketika itu tampaknya berada di partisi pada grup file read-only di lingkungan pengujian kami (kueri sys.partition_functionsdan sys.partition_range_values).

Catatan identik dalam produksi menyebabkan kegagalan yang diharapkan ketika mencoba memperbarui catatan. Dua kali kami telah menangkap sejauh ini pembaruan gagal dalam produksi tetapi berhasil dalam pengujian (tidak pernah sebaliknya).

Fakta lingkungan yang relevan:

SQL Server 2012 SP3 CU3 (build 11.0.6537.0)
Tes adalah edisi pengembang, produksi adalah perusahaan
Dapat memberikan yang lain seperti yang diminta: Benar-benar bingung sekarang ...

UPDATE 2016-08-19

Apakah catatan baru diperbarui entah bagaimana dalam semalam. Mengonfirmasi itu pada grup file hanya baca. Ditemukan bahwa saya dapat memperbarui catatan yang disisipkan pada saat yang sama (yaitu juga pada partisi yang sama pada grup-baca read-only). Saya mengidentifikasi satu catatan pada partisi yang sama dan telah dapat memperbarui catatan beberapa kali. Upaya untuk memperbarui catatan yang diperbarui semalam menghasilkan kegagalan yang diharapkan.

UPDATE 2016-08-11

Pembaruan terus terjadi selama pemrosesan malam hari dalam pengujian pada partisi read-only. Mencoba memperbarui catatan yang sama dari proses gagal. Mencoba memperbarui catatan yang sama saat masuk sebagai pengguna yang memperbaruinya sebelumnya gagal. Saya juga tidak dapat menduplikasi masalah dengan memperbarui catatan serupa yang belum tersentuh oleh proses malam.

UPDATE 2016-08-04

Ditemukan hari ini bahwa itu tidak terbatas pada tabel tunggal itu ketika saya menemukan kejadian lain dari perilaku yang sama pada tabel yang berbeda menggunakan skema partisi yang sama.

UPDATE 2016-08-03

Menjalankan skrip dari skrip MSDN ini mengkonfirmasi apa yang saya dapatkan ketika menggunakan tampilan pembantu partisi Kendra Little ph.FilegroupDetaildan ph.ObjectDetaildari demo ini . Catatan yang dipertanyakan tinggal di partisi # 2 (nilai kolom partisi untuk catatan yang dimaksud adalah 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

Kode untuk meletakkan tabel di partisi (tidak ada indeks lain)

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)

Pernyataan pembaruan yang seharusnya gagal (via 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"

PEMBARUAN 2017-02-21

Jadi setelah sekian lama kami telah menemukan bahwa entah bagaimana ketika partisi aktif tertua digabungkan ke dalam arsip, bagian catatan tidak dipindahkan pada disk dari grup file aktif ke grup file arsip. Kueri berikut menunjukkan bahwa catatan dari partisi 2 dipetakan ke ActiveFG sementara memeriksa skema partisi yang sebenarnya menunjukkan bahwa catatan yang sama harus diurutkan ke dalam grup file Arsip oleh fungsi partisi.

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;

Saya mencadangkan semua partisi yang sebenarnya digunakan dalam database dan menyimpan versi yang rusak untuk bekerja dengan tiket Microsoft. Saya perlu merevisi rencana pemartisian dengan tim DW kami, tetapi saya akan mengaku sebagai orang yang malu untuk mencobanya lagi.

Microsoft tidak dapat menduplikasi perilaku ini dan begitu juga dengan tiket saat ini. Mereka tampaknya siap untuk mengabaikannya dan menganggap itu tidak ada di 2014/2016? Mereka tampaknya tidak dapat mereplikasi di lab mereka meskipun kemampuan saya untuk terus ada di database bahkan setelah saya mengembalikannya dari cadangan di sistem saya.

sql-server partitioning filegroups

— toosuto
sumber

Saya mencadangkan semua partisi pada basis data aktual yang digunakan dan menyimpan versi yang rusak untuk mengerjakan tiket MS. Saya perlu merevisi rencana pemartisian dengan tim DW kami tetapi saya akan mengaku sebagai orang yang malu untuk mencoba lagi ...

— toosuto

Saya memiliki sebuah pengakuan.

Suatu ketika, ketika saya masih muda, saya membangun proses ETL dimulai dengan mengubah grup baca-saja menjadi baca-tulis, melakukan pekerjaan ETL-nya, dan kemudian mengaturnya kembali menjadi hanya-baca.

Jadi kalau-kalau Anda memiliki rekan kerja yang kejam seperti saya (saya masih muda, saya butuh uang), Anda dapat mengujinya dengan:

Ubah nama grup-baca read-only - dengan cara itu, jika seseorang memiliki skrip hard-cod yang mengubah nama-filegroup dengan nama, skrip mereka akan gagal, dan Anda akan menangkap pelakunya. Atau, sedikit lebih sulit:
Gunakan Profiler atau Extended Events untuk melacak siapa saja yang melakukan DATABASE ALTER.

— Brent Ozar
sumber

Kami benar-benar memberikan naskah kepada tim DW untuk melakukan perubahan ini sehingga mereka tidak harus membangunkan kami di malam hari pada kesempatan yang jarang tetapi diharapkan pekerjaan mereka gagal. Kami juga memiliki pemicu audit tingkat server (pada DDL_SERVER_LEVEL_EVENTS) yang mengatur grup file baca / tulis hit properti. Ini mengirimkan skrip SQL, pengguna dan alamat IP untuk ditinjau oleh tim DBA.

— toosuto

Meskipun saya bisa kelihatannya mereka cukup licik untuk menggunakan skrip kami untuk mengubah pengaturan grup file sebelum proses ETL mereka, mereka secara teknis tidak cukup sadar untuk mencari dan menonaktifkan pemicu kami.

— toosuto