Использование SQL Server 2016+ и VB.Net
В настоящее время я вижу проблему, в которой есть пробелы в моих журналах. Эти журналы создаются путем ручной вставки информации в таблицу журналов для отслеживания таких вещей, как создание сеансов, добавление элементов в корзины, изменения настроек и т. Д.
Я могу сказать, что есть пробелы, так как у нас есть поле идентичности и пропущены строки. Я могу смоделировать это с помощью следующего скрипта.
DROP TABLE IF EXISTS #TempLog;
CREATE TABLE #TempLog (ID INT IDENTITY(1, 1)
, TimeStamp DATETIME
DEFAULT GETDATE()
, LogMessage NVARCHAR(MAX));
INSERT INTO #TempLog (LogMessage)
VALUES ('Message 1')
, ('Message 2');
BEGIN TRAN;
INSERT INTO #TempLog (LogMessage)
VALUES ('Message 3')
, ('Message 4');
ROLLBACK TRAN;
INSERT INTO #TempLog (LogMessage)
VALUES ('Message 5')
, ('Message 6');
SELECT * FROM #TempLog
DROP TABLE IF EXISTS #TempLog;
выход
ID TimeStamp LogMessage
----------- ----------------------- -----------------
1 2019-05-10 09:13:47.647 Message 1
2 2019-05-10 09:13:47.647 Message 2
5 2019-05-10 09:13:47.647 Message 5
6 2019-05-10 09:13:47.647 Message 6
Из этого вы можете сказать, что если журналы создаются внутри транзакции и эта транзакция откатывается, значение идентификатора не сбрасывается.
Когда я выполняю настройки сеансов напрямую через SSMS, они всегда создаются правильно и без каких-либо пробелов в журналах. Когда мы вызываем настройки сеанса через наш пакет «среднего уровня» (VB.NET с веб-интерфейсом), он обычно работает нормально, но иногда занимает гораздо больше времени (15-20 секунд вместо <2 секунд), и я вижу много пробелы в логах. </p>
Обратите внимание, что это та же самая хранимая процедура, с той лишь разницей, что она вызывается из. В этом процессе нет транзакций, и они используются очень экономно, обычно только через процессы администрирования, в которых реализованы значительные изменения. В этих случаях журналы создаются вне транзакции.
Мне интересно, переносит ли .NET вызовы внутри собственной версии транзакции, вызывая эти откаты? Здесь может быть какая-то другая причина, загрузка сервера и т. Д., Однако, не видя, что в журналах, я ничего не могу отследить. Разработчики посоветовали мне, что они «ничего не делают в транзакциях» и они «не вызывают этого».
Может ли это быть вызвано тайм-аутом из-за нагрузки? Будет ли отмененный звонок сделать это? К сожалению, моя .NET экспозиция ограничена, и теперь я немного растерялся. Поскольку это временная ошибка, пошаговое выполнение кода оказалось неэффективным.
Я мог бы продублировать все создание журналов, чтобы отправить их в журналы SQL Server через ошибку повышения, но я бы предпочел не заполнять журналы информационными сообщениями, а оставить их для фактических ошибок.
заранее большое спасибо.