В рамках процесса закрытия розничной торговли существует транзакционная хранимая процедура, которая выбирает из каждой из 18 таблиц и вставляет их в отдельную базу данных для последующей обработки мэйнфрейма. Эта процедура демонстрирует некоторые странные временные характеристики, и я думаю, что это из-за фундаментального недопонимания того, как транзакции работают в SQL Server.
Я понимаю, что это не лучшая архитектура для этой проблемы, и разрабатывается новое решение, но пока мне нужно улучшить этот процесс.
Хранимая процедура выполняется на основе запроса пользователя и выглядит примерно так:
BEGIN TRANSACTION
INSERT INTO Table1
(Column1,
Column2,
Column3,
Column4,
Column5,
Column6,
Column7,
Column8)
SELECT
Column1,
Column2,
Column3,
Column4,
Column5,
Column6,
Column7,
Column8
FROM
OLTPTable T
INNER JOIN
LookupTable1 L
ON
T.Foreign = L.Key
INSERT INTO Table2
(Column1,
Column2,
Column3)
SELECT
Column1,
Column2,
Column3
FROM
OLTPTable2 T
INNER JOIN
LookupTable2 L
ON
T.Foreign = L.Key
INSERT INTO Table3
(Column1,
Column2,
Column3,
Column4,
Column5,
Column6)
SELECT
Column1,
Column2,
Column3,
Column4,
Column5,
Column6
FROM
OLTPTable3 T
INNER JOIN
LookupTable3 L
ON
T.Foreign = L.Key
-- Through Table 18 and OLTP Table 18
COMMIT TRANSACTION
Регистрация выглядит примерно так:
Table1 0.2 seconds 354 rows
Table2 7.4 seconds 35 rows
Table3 3.9 seconds 99 rows
Нет четкой корреляции между количеством строк или сложностью объединений и временем.
У меня вопрос - на такой длительной процедуре, каков эффект транзакции? Блокирует ли все таблицы в подселектах в начале? Один за раз? Ожидание, пока исходная таблица станет доступной для блокировки, что вызывает ожидания?