Tôi có một truy vấn SQL Server 2008 đang làm việc trên hàng triệu bản ghi. Truy vấn là w / in a Proc được điều hành hàng đêm bởi một công việc. Truy vấn có thể mất cả ngày để chạy khi tôi đặt nó lần đầu tiên trên máy chủ, nhưng trong vòng một tuần, nó sẽ giảm xuống dưới một giờ - mà không có sự can thiệp nào từ tôi. Nó CỐ ĐỊNH bằng cách nào đó.
Truy vấn chạy trong tempdb và trước khi tự khắc phục, khi tôi kiểm tra số liệu thống kê hiệu suất trên đó, tôi tìm thấy như sau: CXPACKET: 20.700 giây hoặc 66% thời gian chờ.
PAGEIOLATCH: _SH 2.500 hoặc 8% thời gian chờ.
LOGBUFFER: 1500 giây hoặc 5% thời gian chờ IO_COMPLETION: 1500 giây hoặc 5% thời gian chờ
Tôi đã cố gắng điều chỉnh các chỉ mục, v.v. và các số liệu thống kê ở trên có phần cải thiện so với lần chạy đầu tiên của tôi khi CXPACKET là 77% thời gian chờ đợi. Tôi đọc các mẹo chụp ảnh rắc rối nói rằng tôi nên chia tempdb của mình thành một tệp cho mỗi CPU. Tôi có hệ thống W2K8 32 bit cpu kép và vì vậy tôi chia tempdb thành 2 tệp và tăng đáng kể kích thước của mỗi tệp lên 150 GB mỗi lần tự động 10%, nhưng chúng không tăng nên tôi nghĩ kích thước là đủ.
Khi tôi nhìn vào máy chủ trong khi truy vấn đang chạy, tôi có thể thấy rằng CPU KHÔNG được ghim và đang lơ lửng khoảng <10% công suất. Những gì đã được ghim là DISK IO. Máy có một đĩa đơn.
Nếu không có gì khó chịu, đây là hai truy vấn gây rắc rối (truy vấn đầu tiên được sử dụng là truy vấn con của phần sau - xem giải thích bên dưới):
insert into #ttcbm(tradeId1, tradeId2)
select distinct tp.tradeid tradeId1, tp1.tradeid tradeId2
from #tradeP tp
join #tradeP tp1
on tp.cmbId = tp1.cmbId
and tp.qs_plyrid = tp1.qs_plyrid
and tp.tradeId > tp1.tradeId
OPTION (MAXDOP 1)
insert into #mergeT(tradeId1, tradeId2)
select distinct tp.tradeid tradeId1, tp1.tradeid tradeId2
from #tradep tp
join #tradep tp1
on tp.cmbId = tp1.cmbId
and tp.tradeid > tp1.tradeId
left join #ttcbm x
on tp.tradeId = x.tradeId1
and tp1.tradeId = x.tradeId2
where 1 = 1
and x.tradeId1 is null
and x.tradeId2 is null
OPTION (MAXDOP 1);Tôi đã thêm MAXDOP 1 cho mỗi mẹo khắc phục sự cố mà tôi đọc được nói rằng CXPACKET là do song song và có lẽ nó đã giúp tôi giảm bớt sự chờ đợi của mình một chút, nhưng không giống như sự cải thiện xảy ra khi truy vấn tự khắc phục, tức là từ 24 giờ để kẻo hơn 1 giờ
bảng #ttcbm có PK là Tradeid1, Tradeid2 và #tradep có pk là (cmbId, qs_plyrid, Tradeid) và cả hai bảng đều có số lượng bản ghi theo thứ tự từ 100K đến 500k. #ttcbm từng là truy vấn con của truy vấn 'chèn vào #mergeT' sau, nhưng tôi đã tách nó ra khi tôi đọc rằng tách ra các truy vấn phức tạp có thể cải thiện hiệu suất khi xảy ra sự cố song song.
dual cpu 32 bit W2K8thời gian nâng cấp lên 64Bit. Ngoài ra, bạn đã bật / chuyển 3GB cùng với AWE chưa?