Vì vậy, tôi có một quy trình Chèn hàng loạt đơn giản để lấy dữ liệu từ bảng phân tầng của chúng tôi và chuyển nó vào bảng dữ liệu của chúng tôi.
Quá trình này là một tác vụ luồng dữ liệu đơn giản với các cài đặt mặc định cho "Hàng trên mỗi lô" và các tùy chọn là "khóa tab" và "không ràng buộc kiểm tra".
Cái bàn khá rộng. 587.162.986 với kích thước dữ liệu 201GB và 49GB không gian chỉ mục. Chỉ số cụm cho bảng là.
CREATE CLUSTERED INDEX ImageData ON dbo.ImageData
(
DOC_ID ASC,
ACCT_NUM ASC,
MasterID ASC
)Và khóa chính là:
ALTER TABLE dbo.ImageData
ADD CONSTRAINT ImageData
PRIMARY KEY NONCLUSTERED
(
ImageID ASC,
DT_CRTE_DOC ASC
)Bây giờ chúng tôi đã có một vấn đề trong đó BULK INSERTthông qua SSIS đang chạy rất chậm. 1 giờ để chèn một triệu hàng. Truy vấn điền vào bảng đã được sắp xếp và truy vấn để điền vào sẽ mất dưới một phút để chạy.
Khi quá trình đang chạy, tôi có thể thấy truy vấn đang chờ trên BULK insert, mất từ 5 đến 20 giây và hiển thị loại chờ PAGEIOLATCH_EX. Quá trình chỉ có thể INSERTkhoảng một nghìn hàng tại một thời điểm.
Hôm qua trong khi thử nghiệm quá trình này với môi trường UAT của tôi, tôi đã gặp vấn đề tương tự. Tôi đã chạy quá trình một vài lần và cố gắng xác định nguyên nhân gốc rễ của việc chèn chậm này là gì. Rồi đột nhiên nó bắt đầu chạy trong chưa đầy 5 phút. Vì vậy, tôi đã chạy nó một vài lần nữa với cùng một kết quả. Ngoài ra, số lượng chèn hàng loạt đang chờ trong 5 giây hoặc lớn hơn đã giảm từ hàng trăm xuống còn khoảng 4.
Bây giờ điều này thật khó hiểu bởi vì nó không giống như chúng ta đã có một số hoạt động giảm mạnh.
CPU trong suốt thời gian thấp.
Thời gian chậm hơn dường như có ít chờ đợi hơn trên đĩa.
Độ trễ của đĩa thực sự tăng trong khung thời gian mà quá trình đang chạy dưới 5 phút.
Và IO thấp hơn nhiều trong thời gian mà quá trình này hoạt động kém.
Tôi đã kiểm tra và không có sự tăng trưởng tập tin vì các tập tin chỉ đầy 70%. Tệp nhật ký vẫn còn 50%. DB ở chế độ Khôi phục đơn giản. DB chỉ có một nhóm tệp nhưng được trải rộng trên 4 tệp.
Vì vậy, những gì tôi đang tự hỏi A: tại sao tôi lại thấy thời gian chờ đợi lớn như vậy trên các chèn số lượng lớn đó. B: loại phép thuật nào đã xảy ra khiến nó chạy nhanh hơn?
Lưu ý bên. Nó chạy như tào lao ngày hôm nay.
CẬP NHẬT nó hiện đang được phân vùng. Tuy nhiên, nó được thực hiện theo một phương pháp tốt nhất là ngớ ngẩn.
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'
);Điều này về cơ bản để lại tất cả dữ liệu trong phân vùng thứ 4. Tuy nhiên vì tất cả sẽ đi đến cùng một nhóm tập tin. Dữ liệu hiện được phân chia khá đều trên các tệp đó.
CẬP NHẬT 2 Đây là những chờ đợi tổng thể khi quá trình hoạt động kém.
Đây là sự chờ đợi trong khoảng thời gian tôi có thể chạy quy trình đang chạy tốt.
Hệ thống con lưu trữ được gắn cục bộ RAID, không liên quan đến SAN. Các bản ghi là trên một ổ đĩa khác nhau. Bộ điều khiển Raid là PERC H800 với kích thước bộ đệm 1 GB. (Đối với UAT) Prod là PERC (810).
Chúng tôi đang sử dụng phục hồi đơn giản không có bản sao lưu. Nó được khôi phục từ một bản sao sản xuất hàng đêm.
Chúng tôi cũng đã thiết lập IsSorted property = TRUESSIS vì dữ liệu đã được sắp xếp.
PAGEIOLATCH_EXvà ASYNC_IO_COMPLETIONđang chỉ ra rằng mất một lúc để lấy dữ liệu từ đĩa vào bộ nhớ. Đây có thể là một chỉ báo của một vấn đề với hệ thống con đĩa, hoặc nó có thể là sự tranh chấp bộ nhớ. SQL Server có bao nhiêu bộ nhớ?
ASYNC_NETWORK_IOcó nghĩa là SQL Server đang chờ gửi hàng đến máy khách ở đâu đó. Tôi cho rằng điều đó đang hiển thị hoạt động của các hàng tiêu thụ SSIS từ bảng phân tầng.