Alguns tiros no pé acabaram de ocorrer em um servidor de produção. Corrigi o problema, mas agora estou bastante confuso.
Há um subconjunto de procedimentos armazenados que preservam o estado em caso de falha. Ou seja, se o procedimento gerar um erro, ele pode ser confirmado de qualquer maneira com segurança. Isso é feito com save transaction.
Agora, meu entendimento inicial era que o nome do ponto de salvamento definido para a transação é local para o procedimento armazenado que o utiliza. E em um cenário aninhado, se o procedimento armazenado interno salvar com o mesmo nome, na verdade é um nome diferente e está tudo bem.
Para ter certeza de que esse meu entendimento estava correto, configurei um caso de teste:
create table dbo.[footest] (
v varchar(50) NULL
);
go
insert into dbo.footest(v) values ('Nothing'); go
create procedure dbo.[foo_test_tran_inner]
as
begin
set nocount on;
declare @foo int;
begin tran;
update dbo.footest set v = 'Inner, before savepoint';
save tran the_constant_name;
begin try
update dbo.footest
set v = 'Inner, after savepoint';
set @foo = 1/0;
end try
begin catch
rollback tran the_constant_name;
end catch;
commit tran;
set @foo = 1/0;
return 0;
end;
go
create procedure dbo.[foo_test_tran_outer]
as
begin
set nocount on;
begin tran;
update dbo.footest set v = 'Outer, before savepoint';
save tran the_constant_name;
begin try
update dbo.footest
set v = 'Outer, after savepoint';
exec dbo.foo_test_tran_inner;
end try
begin catch
rollback tran the_constant_name;
end catch;
commit tran;
return 0;
end;
go
begin tran;
exec dbo.foo_test_tran_outer;
commit tran;
select * from dbo.footest;
Isso produz "Outer, antes do ponto de salvamento". O que significa que os nomes dos pontos de salvamento eram locais para o procedimento e foram revertidos corretamente em um cenário aninhado.
Na produção, esses procedimentos armazenados de preservação de estado têm exatamente esse esquema. Há muito mais código neles, mas se você remover, deixando apenas saves, rollbacks e commits, será exatamente o que está mostrado acima.
Mas. Não funcionou na produção. Em vez disso, cada ponto de salvamento aninhado com o mesmo nome parecia substituir um ponto de salvamento anterior, feito a partir do procedimento de chamada. E quando o código externo após receber uma exceção executou um commit(acreditando que as reversões internas foram feitas corretamente), o banco de dados foi deixado em um estado meio parafusado. Se aplicado ao exemplo acima, isso significaria que o select retorna Inner, before savepoint.
Percorri todas as etapas do procedimento de produção com um depurador e confirmei que a execução passou corretamente por todos os esperados save tran a_namee rollback tran a_name.
Para corrigir o problema na produção, substituí isso:
save tran the_constant_name;
...
rollback tran the_constant_name;
com isso:
declare @savepoint varchar(32) = replace(newid(), '-', '');
save tran @savepoint;
...
rollback tran @savepoint;
e isso corrigiu imediatamente.
Então o que dá? O nome do ponto de salvamento é local para o procedimento armazenado ou não?
Se for, então por que o código de produção fez o que fez e foi corrigido com sucesso conforme mostrado?
Se não for, então por que o exemplo de teste acima faz o que faz?
Não, eles não são locais para um procedimento armazenado.
Se você executar o seguinte em um banco de dados com modelo de recuperação simples
Dá esses resultados
O
[Savepoint Name]registrado no log de transações não contém nenhum identificador exclusivo relacionado ao procedimento armazenado.Se você remover o
rollback tran the_constant_name;fromfoo_test_tran_inner, o resultado da seleção final mudará paraInner, before savepointmostrar que orollback tran the_constant_name;from executadofoo_test_tran_outerapenas reverte para o ponto de salvamento mais recente (desenrolado) desse nome e não leva em consideração o aninhamento do procedimento armazenado.