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 NULLKode 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.
sumber
Jawaban:
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.
sumber