Какой метод борьбы с тупиками транзакций предпочтительнее?

Question

Итак, я финансовый аналитик, который много использует SQL (только для чтения, а не для записи в БД), и только недавно я начал обращать внимание на проблему взаимоблокировок. Я никогда не знал, что запускать отчеты SQL из действующей производственной базы данных до недавнего времени было плохой практикой. Судя по моим исследованиям, создание отчетов для хранилища данных является идеальным вариантом, и я предлагаю нашей компании изучить его. В настоящее время мне действительно нужно разрешать проблему взаимоблокировки, которую мы получаем примерно один или два раза в неделю, что вызывает серьезные проблемы для наших пользователей ERP в офисе, а сотрудники регистрируют свое время на производственном этаже.

Я запускаю тонну отчетов в MS Query внутри Excel, и я заметил, что в 99% случаев возникает проблема, убивая все процессы Microsoft Office в мониторе активности, чтобы устранить эту проблему. Вот скриншот того, как это выглядит:

Я не знаю, как правильно читать этот материал, но я предполагаю, что в приведенном выше примере,это процесс с типом ожидания LCK_M_S, который вызвал тупик. Кроме того, я только что прочитал комментарий от разработчика Excel, в котором говорится:

В Excel (и других однопользовательских инструментах среды) нет действительно хорошего способа определения границ транзакции. Во многих случаях исключительная блокировка поддерживается с первого открытия таблицы в течение всего времени жизни этого сеанса, т.е. до тех пор, пока Excel не будет закрыт

Это выглядит довольно плохо, потому что это будет означать, что если я этого не сделаюУничтожить процессы Microsoft Office вручную. Единственный другой способ устранить тупик - это закрыть все файлы в компании, в которых есть запросы, что, очевидно, не является идеальным решением. У меня также есть много запросов в файлах Power BI, которые отображаются как «Mashup Engine» в мониторе активности, и я никогда не видел никаких проблем с этим, и я понятия не имею, почему. Я мог бы предположить, что потенциал тупика все еще существует

В любом случае, надеюсь, что этого достаточно, чтобы можно было рекомендовать потенциальные решения помимо хранилища данных. Вот несколько предложенных решений, которые я видел предложенные на основе моих исследований:

УСТАНОВИТЬ ЧАСТЬ ИЗОЛЯЦИИ СДЕЛКИ СЧИТАЕТСЯ НЕКОММИТИРОВАННОЙ

Я вижу, что основной проблемой в этом является грязное чтениеи другие подобные проблемы, которые могут привести к возвращению неточных данных. Дело в том, что мы довольно маленькая компания, и наша ERP не обрабатывает множество транзакций каждую минуту, как крупная корпорация. Я попытался запустить часть своего кода с этим оператором, и до сих пор большинство запросов, которые я выполнял, были идентичны запросам без этого оператора. Я думаю, что это хорошее решение, но, возможно, что-то мне не хватает.

SET DEADLOCK_PRIORITY LOW

Так что это, очевидно, не предотвращает взаимоблокировки, нопо крайней мере, позволяет выбрать жертву тупика. Когда один из моих Excel-запросов запрашивает взаимные блокировки, скажем, кто-то создает заказ на покупку в нашей системе ERP, я предполагаю, что всякий раз, когда транзакция ERP выбирается в качестве жертвы тупика, именно тогда части нашего ERP начинают зависать. Если бы я установил для каждого запроса Excel низкий приоритет взаимоблокировки, чтобы он всегда выбирался в качестве жертвы взаимоблокировки, было бы это хорошим решением, чтобы наша ERP никогда не зависала из-за тупика, вызванного запросом Excel? Этот метод гарантирует точные данные, но поскольку взаимные блокировки все равно будут возникать, не уверен, что он идеален.

УСТАНОВИТЕ УРОВЕНЬ ИЗОЛЯЦИИ СДЕЛКИ и УСТАНОВИТЕ READ_COMMITTED_SNAPSHOT ВКЛ.

Честно говоря, эти двадо сих пор чертовски запутанны, но подумали, что стоит упомянуть, если кто-то сочтет, что это лучшее решение для моего дела

Наконец, я включу пример запроса, который, как я знаю, часто конфликтует с нашим отделом закупок, если это помогает. Этот отчет используется нашим менеджером цепочки поставок и часто находится на его рабочем столе через Excel с частотой обновления 120 минут:

SELECT DISTINCT
    pr.PONum,
    CASE
        WHEN pr.JobNo LIKE '%E%' THEN SUBSTRING(pr.JobNo, 1, CHARINDEX('E', pr.JobNo)-1) 
        ELSE SUBSTRING(pr.JobNo, 1, CHARINDEX('-', pr.JobNo)-1)
        END AS [Order #],
    pd.Status, 
    p.VendCode,
    pr.PartNo, 
    CAST(pd.PartDesc AS NVARCHAR(MAX)) AS [PartDesc], 
    pd.QtyOrd, 
    pd.QtyRec, 
    pd.QtyCancel, 
    pd.QtyReject,
    CAST(p.DateEnt AS DATETIME) AS [DateEntered],
    CAST(p.DateReq AS DATETIME) AS [Original Due Date],
    CAST(pd.DueDate AS DATETIME) AS [DueDate],
    CAST(pd.DateFinished AS DATETIME) AS [DateFinished]
FROM POReleases pr
    JOIN PODet pd ON pr.PONum = pd.PONum AND pr.PartNo = pd.PartNo
    JOIN PO p ON pr.PONum = p.PONum AND CAST(p.DateEnt AS DATETIME) >= '20190101'
WHERE (pd.JobNo LIKE '%-%'
    OR pd.JobNo = '<Multiple>')
    AND pr.JobNo NOT LIKE '%Stock%'
ORDER BY 3 DESC, 1 DESC