Использование явного коммита в транзакции

Есть ли разница в добавлении explicit commit в мой transaction, чем автоматический фиксация.Использование явного коммита в транзакции

CREATE TABLE #test (test_col INT)

С явным COMMIT

INSERT #test 
VALUES (11) 

BEGIN TRY 
    BEGIN TRAN DELETE_TRAN 

    DELETE FROM #test 

    COMMIT TRAN DELETE_TRAN 
END TRY 

BEGIN CATCH 
    ROLLBACK TRAN DELETE_TRAN 

    SELECT ERRORMESSAGE = Error_message() 
END CATCH 

SELECT * 
FROM #test

без явного COMMIT

INSERT #test 
VALUES (11) 

BEGIN TRY 
    BEGIN TRAN DELETE_TRAN 

    DELETE FROM #test 
END TRY 

BEGIN CATCH 
    ROLLBACK TRAN DELETE_TRAN 

    SELECT ERRORMESSAGE = Error_message() 
END CATCH 

SELECT * 
FROM #test

Здесь и делает то же самое. Может ли кто-нибудь сказать, есть ли какая-то разница или преимущество друг над другом.

источник

2016-02-23 ask_Overflow

Хороший вопрос. Это может быть лучше подходит для [Stack DBA] (http://dba.stackexchange.com/). –

@ destination-data - Должен ли я опубликовать тот же вопрос на вышеупомянутом сайте? –

Нет, мне сказали, что я сделал это! По-видимому, это плохая форма. Если вы хотите, вы можете поставить этот вопрос, как вне темы - неправильный сайт. Моды затем переместят его. –

-1

неявной Commit медленнее, чем Явная Commit, мы можем включить или выключить неявное зависит от нашего требования, для получения более подробной информации вы можете увидеть по этой ссылке: SQL Server – performance and other stories

источник

2016-02-23 11:05:10

Есть ли какие-либо функциональные различия? –

Есть ли какой-либо способ, которым приведенный выше запрос (** Без явного COMMIT **) вызывает такую ошибку, как это: «Текущая транзакция не может быть зафиксирована и не может поддерживать операции, которые записываются в файл журнала. Отмените транзакцию. '. Я получил эту ошибку при выполнении одной процедуры, которая никогда не выдавала никаких ошибок, подобных этой за последние 1 год –

@ask_Overflow, а затем добавляет фиксацию. Я бы предположил, что патч базы данных был применен, и поэтому вы никогда не получали ошибку раньше. Тем не менее, практикой POOR является открытие транзакции без явного закрытия ее как с помощью фиксации, так и с возможным откатом. – HLGEM

Основное функциональное различие, которое я мог видеть, было бы что используя явный COMMIT в вашем первом примере, вы убедитесь, что таблица (временная таблица в этом случае) разблокирована для оператора SELECT в конце. Если во втором примере SELECT будет заблокирован для других пользователей, если только они не выполняют грязные чтения (например, WITH (NOLOCK) и т. Д.) До тех пор, пока не будет задействован неявный COMMIT.

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

Это также хорошая стандартная практика, чтобы явно закрыть любой TRAN, открытый в SQL, чтобы вы не полагались на вызывающего абонента, чтобы попытаться выполнить COMMIT TRAN. Имейте в виду, что если соединение с SQL закрыто, и TRAN не имеет COMMIT, тогда TRAN автоматически получает ROLLBACK.

источник

2016-02-23 14:30:00 TomS

Точно искал этот ответ. Спасибо тонну –

В моем первоначальном сценарии это была не временная таблица –

Использование явного коммита в транзакции

ответ

Смежные вопросы