Фиксирование только Определенных изменений, внесенных внутри ТРАНЗАКЦИИ, которые могут быть ОТКАТАНЫ

Question

Это существенная правка по сравнению с исходным вопросом, делающая его более кратким и охватывающая вопросы, поднятые существующими ответами...

Возможно ли внести множественные изменения в несколько таблиц внутри одной транзакции и откатить только некоторые из изменений?

В приведенном ниже TSQL я бы НЕ хотел, чтобы какие-либо изменения, внесенные "myLogSP", когда-либо были откатаны.Но все изменения, внесенные различными MYBUSINESSSP, должны быть откатаны при необходимости.

BEGIN TRANSACTION  

    EXEC myLogSP

    EXEC @err = myBusinessSPa
    IF (@err <> 0) BEGIN ROLLBACK TRANSACTION RETURN -1 END

    EXEC myLogSP

    EXEC @err = myBusinessSPb
    IF (@err <> 0) BEGIN ROLLBACK TRANSACTION RETURN -1 END

    EXEC myLogSP

    EXEC @err = myBusinessSPc
    IF (@err <> 0) BEGIN ROLLBACK TRANSACTION RETURN -1 END

    EXEC myLogSP

COMMIT TRANSACTION
RETURN 0

Порядок важен, myLogSPs должны выполняться между MYBUSINESSSP и после myLogSPs (myLogSPs отслеживают изменения, внесенные MYBUSINESSSP)

Также важно, чтобы все MYBUSINESSSP выполнялись внутри одной транзакции, чтобы поддерживать целостность базы данных и разрешать откат всех их изменений при необходимости.

Это как если бы я хотел, чтобы myLogSPs вели себя так, как будто они не являются частью транзакции.Это просто неудобный факт, что они случайно находятся внутри одного (в силу необходимости вызова между MYBUSINESSSP.)

Редактировать:

Окончательный ответ - "нет", единственный вариант - переработать код.Либо использовать табличные переменные для ведения журнала (поскольку переменные не откатываются), либо перепроектировать бизнес-логику так, чтобы она не требовала транзакций...

Answer 1

Использование SAVEPOINTs, например

BEGIN TRANSACTION  

    EXEC myLogSP

    SAVE TRANSACTION savepointA
    EXEC @err = myBusinessSPa
    IF (@err <> 0) BEGIN
        ROLLBACK TRANSACTION savepointA
        COMMIT
        RETURN -1
    END

    EXEC myLogSP

    SAVE TRANSACTION savepointB
    EXEC @err = myBusinessSPb
    IF (@err <> 0) BEGIN
        ROLLBACK TRANSACTION savepointB
        COMMIT
        RETURN -1
    END

    EXEC myLogSP

    SAVE TRANSACTION savepointC
    EXEC @err = myBusinessSPc
    IF (@err <> 0) BEGIN
        ROLLBACK TRANSACTION savepointC
        COMMIT
        RETURN -1
    END

    EXEC myLogSP

COMMIT TRANSACTION

---

Редактировать

Основываясь на предоставленной на данный момент информации (и моем понимании этого), похоже, что вам придется перепроектировать свои SPS ведения журнала, либо использовать переменные, либо использовать файлы, либо разрешить им запускаться "постфактум" следующим образом:

BEGIN TRANSACTION  

    SAVE TRANSACTION savepointA
    EXEC @err = myBusinessSPa
    IF (@err <> 0) BEGIN
        ROLLBACK TRANSACTION savepointA
        EXEC myLogSPA -- the call to myBusinessSPa was attempted/failed
        COMMIT
        RETURN -1
    END

    SAVE TRANSACTION savepointB
    EXEC @err = myBusinessSPb
    IF (@err <> 0) BEGIN
        ROLLBACK TRANSACTION savepointB
        EXEC myLogSPA -- the call to myBusinessSPa originally succeeded
        EXEC myLogSPB -- the call to myBusinessSPb was attempted/failed
        COMMIT
        RETURN -1
    END

    SAVE TRANSACTION savepointC
    EXEC @err = myBusinessSPc
    IF (@err <> 0) BEGIN
        ROLLBACK TRANSACTION savepointC
        EXEC myLogSPA -- the call to myBusinessSPa originally succeeded
        EXEC myLogSPB -- the call to myBusinessSPb originally succeeded
        EXEC myLogSPC -- the call to myBusinessSPc was attempted/failed
        COMMIT
        RETURN -1
    END

    EXEC myLogSPA -- the call to myBusinessSPa succeeded
    EXEC myLogSPB -- the call to myBusinessSPb succeeded
    EXEC myLogSPC -- the call to myBusinessSPc succeeded

COMMIT TRANSACTION

Answer 2

Вам нужно в основном выйти за пределы текущего контекста.Есть несколько способов сделать это.Один из них (который я никогда не пробовал) - вызвать среду CLR для выполнения вставки.

Возможно, однако, лучшим способом является использование того факта, что транзакция не влияет на переменные таблицы.Например:

CREATE TABLE dbo.Test_Transactions
(
     my_string VARCHAR(20) NOT NULL
)
GO

DECLARE
     @tbl TABLE (my_string VARCHAR(20) NOT NULL)

BEGIN TRANSACTION

INSERT INTO dbo.Test_Transactions (my_string) VALUES ('test point one')

INSERT INTO @tbl (my_string) VALUES ('test point two')

INSERT INTO dbo.Test_Transactions (my_string) VALUES ('test point three')

ROLLBACK TRANSACTION

INSERT INTO dbo.Test_Transactions (my_string) select my_string from @tbl

SELECT * FROM dbo.Test_Transactions
SELECT * FROM @tbl
GO

Answer 3

Нам повезло с помещением записей журнала в табличные переменные, а затем вставкой в реальные таблицы после фиксации или отката.

Хорошо, если вы не используете SQL Server 2008, то попробуйте этот метод.Это грязно и является обходным путем, но это должно сработать.Таблица #temp и переменная table должны быть настроены в соответствии со структурой того, что возвращается sp.

create table #templog (fie1d1 int, field2 varchar(10))

declare @templog table (fie1d1 int, field2 varchar(10))

BEGIN TRANSACTION      
insert into #templog
Exec my_proc

insert into @templog (fie1d1, field2)
select t.* from #templog t 
left join @templog t2 on t.fie1d1 = t2.fie1d1 where t2.fie1d1 is null

insert into templog
values (1, 'test')

rollback tran
select * from #templog
select * from templog
select * from @templog

Answer 4

Использование ТОЧКИ СОХРАНЕНИЯ и УРОВНИ ИЗОЛЯЦИИ ТРАНЗАКЦИЙ.

Answer 5

Не проще ли было бы перенести вставку журнала за пределы транзакции?

На самом деле у меня нет для вас ответа по поводу блокировки таблицы, я думаю, у вас уже есть ответ, там будет иметь быть блокировкой таблицы, поскольку столбец identity может откатиться назад.

Answer 6

переместите инструкцию BEGIN TRANSACTION на после первой вставки.

Answer 7

Возможно, вы могли бы поместить вставки / обновления бизнес-таблиц в их собственную атомарную транзакцию t1 и перенести каждую из этих транзакций в другую транзакцию t2, которая выполняет обновление таблицы журнала и t1 (обновления бизнес-таблицы) без каких-либо откатов.Например:

BEGIN TRANSACTION t2
     <insert to log>
     <execute stored procedure p1>
END TRANSACTION t2

CREATE PROCEDURE p1
AS
     BEGIN TRANSACTION t1
         <insert to business tables>
         <rollback t1 on error>
     END TRANSACTION t1

Я полагаю, что когда вы откатываете t1 в хранимой процедуре, это оставляет вызывающую транзакцию t2 незатронутой.