Existe-t-il une différence de performances dans la validation et l'annulation d'une transaction en lecture seule?

J'ouvre une transaction (lecture répétable) ( BEGIN TRAN) pour effectuer certains travaux sur certains enregistrements. La première chose que je fais est de vérifier si les données que je dois modifier se trouvent dans la base de données. Dans certains cas, il y en aura, puis je procéderai à mes modifications. Mais dans certains cas, il n'y aura rien à faire. Dans ce cas, je ou COMMIT TRANou ROLLBACK TRANet reviens de la procédure stockée. Pour le moment, aucune modification n'a encore été apportée aux données, de sorte que l'effet de la validation et de la restauration est le même.

Y a-t-il une considération à prendre en compte pour choisir entre la validation et la restauration? Y a-t-il un coût de performance différent? Autres considérations?

Après avoir exécuté cela via une session de débogage (pour rafraîchir ma mémoire défaillante):

• La restauration fait plus de vérifications qu'une validation, mais elle ne devrait pas entraîner de travail supplémentaire ou avoir un effet notable sur les performances dans la situation que vous décrivez.
• La transaction de lecture-écriture ne commence vraiment que si et jusqu'à ce qu'une modification des données soit effectuée.

Vous pouvez voir une grande partie de cela en utilisant des DMV, par exemple:

-- Temporary procedure to show the state of the transaction
CREATE PROCEDURE #TranState
    @Comment varchar(100)
AS
BEGIN
    SELECT 
        @Comment AS Comment,
        DTCT.transaction_id,
        database_name =
            CASE DTDT.database_id
                WHEN 32767 THEN N'resource'
                ELSE DB_NAME(DTDT.database_id)
            END,
        tran_begin_time = DTDT.database_transaction_begin_time,
        tran_type =
            CASE DTDT.database_transaction_type
                WHEN 1 THEN 'read/write'
                WHEN 2 THEN 'read only'
                WHEN 3 THEN 'system'
            END,
        tran_state =
            CASE DTDT.database_transaction_state
                WHEN 1 THEN 'The transaction has not been initialized.'
                WHEN 3 THEN 'The transaction has been initialized but has not generated any log records.'
                WHEN 4 THEN 'The transaction has generated log records.'
                WHEN 5 THEN ' The transaction has been prepared.'
                WHEN 10 THEN 'The transaction has been committed.'
                WHEN 11 THEN 'The transaction has been rolled back.'
                WHEN 12 THEN 'The transaction is being committed. In this state the log record is being generated, but it has not been materialized or persisted.'
            END
    FROM sys.dm_tran_current_transaction AS DTCT
    JOIN sys.dm_tran_database_transactions AS DTDT
        ON DTDT.transaction_id = DTCT.transaction_id;
END;

Test sur AdventureWorks:

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

BEGIN TRANSACTION;

EXECUTE dbo.#TranState @Comment = 'After Begin Tran';

SELECT TOP (1)
    P.Name
FROM Production.Product AS P
ORDER BY 
    P.Name;

EXECUTE dbo.#TranState @Comment = 'After Select';

UPDATE Production.Product
SET Name = N'New Blade'
WHERE Name = N'Blade';

EXECUTE dbo.#TranState @Comment = 'After Update';

-- Or Commit
ROLLBACK TRANSACTION;

EXECUTE dbo.#TranState @Comment = 'After Tran';

Production:

D'un point de vue purement pratique (comme Aaron l'a noté dans un commentaire), il est probablement plus sûr d'émettre une restauration pour garantir qu'aucune modification n'est apportée, au cas où le code serait modifié à l'avenir. Donc, c'est une question d'intention: pas de changement = restauration.

Au passage, REPEATABLE READc'est un niveau d'isolement inhabituel à choisir; cela ne fonctionne pas toujours comme les gens s'y attendraient intuitivement . Selon vos besoins, vous pourriez trouver l' SNAPSHOTisolement mieux adapté.