У мене проблема з величезною кількістю ВСТУП, які блокують мої операції SELECT.
Схема
У мене така таблиця:
CREATE TABLE [InverterData](
[InverterID] [bigint] NOT NULL,
[TimeStamp] [datetime] NOT NULL,
[ValueA] [decimal](18, 2) NULL,
[ValueB] [decimal](18, 2) NULL
CONSTRAINT [PrimaryKey_e149e28f-5754-4229-be01-65fafeebce16] PRIMARY KEY CLUSTERED
(
[TimeStamp] DESC,
[InverterID] ASC
) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF
, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON
, ALLOW_PAGE_LOCKS = ON)
)У мене також є ця маленька помічна процедура, яка дозволяє мені вставити або оновити (оновити конфлікт) командою MERGE:
CREATE PROCEDURE [InsertOrUpdateInverterData]
@InverterID bigint, @TimeStamp datetime
, @ValueA decimal(18,2), @ValueB decimal(18,2)
AS
BEGIN
MERGE [InverterData] AS TARGET
USING (VALUES (@InverterID, @TimeStamp, @ValueA, @ValueB))
AS SOURCE ([InverterID], [TimeStamp], [ValueA], [ValueB])
ON TARGET.[InverterID] = @InverterID AND TARGET.[TimeStamp] = @TimeStamp
WHEN MATCHED THEN
UPDATE
SET [ValueA] = SOURCE.[ValueA], [ValueB] = SOURCE.[ValueB]
WHEN NOT MATCHED THEN
INSERT ([InverterID], [TimeStamp], [ValueA], [ValueB])
VALUES (SOURCE.[InverterID], SOURCE.[TimeStamp], SOURCE.[ValueA], SOURCE.[ValueB]);
ENDВикористання
Зараз я запускаю службові екземпляри на декількох серверах, які виконують масові оновлення, [InsertOrUpdateInverterData]швидко викликаючи процедуру.
Існує також веб-сайт, який робить SELECT запити на [InverterData]столі.
Проблема
Якщо я виконую запити SELECT у [InverterData]таблиці, вони надходять у різні часові періоди, залежно від використання INSERT моїх службових екземплярів. Якщо я призупиняю всі екземпляри служби, SELECT блискавично працює, якщо екземпляр виконує швидке вставлення, SELECTs стає дійсно повільним або навіть скасовується.
Спроби
Я зробив декілька SELECTs на [sys.dm_tran_locks]столі, щоб знайти процеси блокування, як це
SELECT
tl.request_session_id,
wt.blocking_session_id,
OBJECT_NAME(p.OBJECT_ID) BlockedObjectName,
h1.TEXT AS RequestingText,
h2.TEXT AS BlockingText,
tl.request_mode
FROM sys.dm_tran_locks AS tl
INNER JOIN sys.dm_os_waiting_tasks AS wt ON tl.lock_owner_address = wt.resource_address
INNER JOIN sys.partitions AS p ON p.hobt_id = tl.resource_associated_entity_id
INNER JOIN sys.dm_exec_connections ec1 ON ec1.session_id = tl.request_session_id
INNER JOIN sys.dm_exec_connections ec2 ON ec2.session_id = wt.blocking_session_id
CROSS APPLY sys.dm_exec_sql_text(ec1.most_recent_sql_handle) AS h1
CROSS APPLY sys.dm_exec_sql_text(ec2.most_recent_sql_handle) AS h2Це результат:
S = Спільний. Засідання сесії надає спільний доступ до ресурсу.
Питання
Чому SELECT блокуються [InsertOrUpdateInverterData]процедурою, яка використовує лише команди MERGE?
Чи потрібно використовувати якусь транзакцію з визначеним режимом ізоляції всередині [InsertOrUpdateInverterData]?
Оновлення 1 (пов'язане з питанням від @Paul)
База на внутрішній звіт на сервері MS-SQL про [InsertOrUpdateInverterData]наступну статистику:
- Середній час процесора: 0,12 мс
- Середні процеси зчитування: 5,76 / с
- Середній процес запису: 0,4 на секунду
Виходячи з цього, схоже, що команда MERGE в основному зайнята операціями читання, які заблокують таблицю! (?)
Оновлення 2 (пов'язане з питанням від @Paul)
[InverterData]Таблиця , як має наступні зберігання статистики:
- Простір даних: 26 901,86 Мб
- Кількість рядків: 131 827 749
- Розділено: правда
- Кількість розділів: 62
Ось ( найвищий ) повний набір результатів sp_WhoIsActive :
SELECT командування
- dd hh: mm: ss.mss: 00 00: 01: 01.930
- session_id: 73
- wait_info: (12629ms) LCK_M_S
- ЦП: 198
- blocking_session_id: 146
- читає: 99,368
- пише: 0
- статус: призупинено
- open_tran_count: 0
[InsertOrUpdateInverterData]Команда блокування
- dd hh: mm: ss.mss: 00 00: 00: 00.330
- session_id: 146
- wait_info: NULL
- ЦП: 3972
- blocking_session_id: NULL
- читає: 376,95
- пише: 126
- статус: сон
- open_tran_count: 1
([TimeStamp] DESC, [InverterID] ASC)виглядає як дивний вибір для кластерного індексу. Я маю на увазіDESCчастину.