Jadi saya punya proses Sisipkan Massal sederhana untuk mengambil data dari tabel pementasan kami dan memindahkannya ke datamart kami.
Prosesnya adalah tugas aliran data sederhana dengan pengaturan default untuk "Baris per batch" dan opsinya adalah "tablock" dan "no check constraint".
Meja cukup besar. 587.162.986 dengan ukuran data 201GB dan ruang indeks 49GB. Indeks berkerumun untuk tabel adalah.
CREATE CLUSTERED INDEX ImageData ON dbo.ImageData
(
DOC_ID ASC,
ACCT_NUM ASC,
MasterID ASC
)
Dan Kunci Utama adalah:
ALTER TABLE dbo.ImageData
ADD CONSTRAINT ImageData
PRIMARY KEY NONCLUSTERED
(
ImageID ASC,
DT_CRTE_DOC ASC
)
Sekarang kami mengalami masalah di mana BULK INSERT
via SSIS berjalan sangat lambat. 1 jam untuk memasukkan sejuta baris. Permintaan yang mengisi tabel sudah diurutkan dan permintaan untuk mengisi membutuhkan waktu kurang dari satu menit untuk berjalan.
Ketika proses ini berjalan saya bisa melihat permintaan menunggu pada masukkan BULK yang memakan waktu antara 5 hingga 20 detik dan menunjukkan jenis menunggu PAGEIOLATCH_EX
. Prosesnya hanya mampu INSERT
sekitar seribu baris sekaligus.
Kemarin saat menguji proses ini terhadap lingkungan UAT saya, saya mengalami masalah yang sama. Saya sedang menjalankan proses beberapa kali dan mencoba untuk menentukan apa penyebab utama dari penyisipan yang lambat ini. Kemudian tiba-tiba mulai berjalan dalam waktu kurang dari 5 menit. Jadi saya menjalankannya beberapa kali lagi dengan hasil yang sama. Juga jumlah sisipan massal yang menunggu 5 detik atau lebih besar dari ratusan turun menjadi sekitar 4.
Sekarang ini membingungkan karena tidak seperti kami memiliki beberapa penurunan besar dalam aktivitas.
CPU selama durasinya rendah.
Saat-saat ketika lebih lambat tampaknya lebih sedikit menunggu pada disk.
Disk latensi sebenarnya meningkat selama kerangka waktu proses berjalan di bawah 5 menit.
Dan The IO jauh lebih rendah pada saat proses ini berjalan buruk.
Saya sudah memeriksa dan tidak ada pertumbuhan file karena file hanya 70% penuh. File log masih memiliki 50% lagi. DB dalam mode Pemulihan Sederhana. DB hanya memiliki satu grup file tetapi tersebar di 4 file.
Jadi apa yang saya bertanya-tanya A: mengapa saya melihat waktu tunggu yang begitu besar pada sisipan massal tersebut. B: Sihir macam apa yang terjadi yang membuatnya berjalan lebih cepat?
Catatan samping. Ini berjalan seperti omong kosong lagi hari ini.
PEMBARUAN saat ini dipartisi. Namun itu dilakukan dalam metode yang paling konyol.
CREATE PARTITION SCHEME [ps_Image] AS PARTITION [pf_Image]
TO ([FG_Image], [FG_Image], [FG_Image], [FG_Image])
CREATE PARTITION FUNCTION [pf_Image](datetime) AS
RANGE RIGHT FOR VALUES (
N'2011-12-01T00:00:00.000'
, N'2013-04-01T00:00:00.000'
, N'2013-07-01T00:00:00.000'
);
Ini pada dasarnya meninggalkan semua data di partisi ke-4. Namun karena itu semua akan ke grup file yang sama. Data saat ini dibagi secara merata di seluruh file-file itu.
UPDATE 2 Ini adalah keseluruhan menunggu saat proses berjalan buruk.
Ini adalah menunggu selama periode yang saya dapat menjalankan proses berjalan dengan baik.
Subsistem penyimpanan adalah RAID yang terpasang secara lokal, tidak ada SAN yang terlibat. Log berada di drive yang berbeda. Raid Controller adalah PERC H800 dengan ukuran cache 1 GB. (Untuk UAT) Prod adalah PERC (810).
Kami menggunakan pemulihan sederhana tanpa cadangan. Ini dipulihkan dari salinan produksi setiap malam.
Kami juga telah menetapkan IsSorted property = TRUE
SSIS karena data sudah diurutkan.
PAGEIOLATCH_EX
dan ASYNC_IO_COMPLETION
menunjukkan sedang mengambil data dari disk ke dalam memori. Ini bisa menjadi indikator masalah dengan subsistem disk, atau mungkin pertengkaran memori. Berapa banyak memori yang tersedia SQL Server?
ASYNC_NETWORK_IO
berarti SQL Server sedang menunggu pengiriman baris ke klien di suatu tempat. Saya kira itu menunjukkan aktivitas SSIS mengkonsumsi baris dari tabel pementasan.