Lors d'une transaction entre bases de données, dans quel (s) journal (s) de transactions les informations sont-elles stockées?

Étant donné l'extrait de code suivant:

-- error checking omitted for brevity
begin tran

exec database1..my_stored_procedure
exec database2..my_other_stored_procedure

if (@@error <> 0)
  rollback

commit

Dans quel (s) journal (s) de transactions de la base de données les informations transactionnelles seront-elles insérées?

Je m'attendrais à ce que les deux journaux obtiennent toutes les données, car cela n'aurait aucun sens si vous tentiez de relire database1le journal des transactions et cela n'affectait que cette base de données. Je m'attendrais également à ce que vous ne puissiez pas relire database1le journal des transactions sur un serveur où il database2n'était pas présent, et vice versa.

.. mais je suis ouvert aux corrections!

Le journal des transactions n'enregistre pas les instructions SQL en cours d'exécution, comme vous pouvez vous y attendre. Au lieu de cela, il enregistre les modifications des données brutes dans chaque base de données, indépendamment.

Il est possible qu'un proc stocké à partir d'une base de données fonctionne entièrement dans le journal des transactions d'une autre base de données.

... database1..my_stored_procedure AS 
BEGIN
INSERT INTO database2..table1 (col1) values (1);
  ^^ changes written to database2's tlog
INSERT INTO database2..table2 (col1) values (2);
  ^^ changes written to database2's tlog
END
^^ when this transaction is committed, COMMIT is recorded in database2's tlog

Ou pour qu'il apporte des modifications aux deux.

... database2..my_other_stored_procedure AS 
BEGIN
INSERT INTO database1..table1 (col1) values (1);
  ^^ changes written to database1's tlog
INSERT INTO database2..table1 (col1) values (2);
  ^^ changes written to database2's tlog
END
^^ when this transaction is committed, COMMIT is recorded in BOTH database1's and database2's tlog

Ce qui est enregistré dans le journal des transactions, ce sont les modifications réelles des données , et non les instructions SQL qui les ont provoquées. Les entrées de chaque fichier journal des transactions sont entièrement indépendantes, sauf dans la mesure où le COMMIT est écrit dans les deux fichiers journaux en même temps, une fois la transaction validée.

La même logique s'applique si vous avez une transaction plus importante exécutant un certain nombre de procédures stockées sur plusieurs bases de données. Une fois que vous avez COMMITÉ votre transaction, le COMMIT sera enregistré dans le journal de chaque base de données ayant participé à la transaction.

Il est parfaitement possible de restaurer une sauvegarde de database2 et de relire ses journaux de transactions sur un serveur qui n'a pas database1.

Ce comportement permet une certaine flexibilité dans la façon dont les procédures et les vues sont présentées dans SQL Server. De nombreux administrateurs de base de données conservent leurs procédures stockées - en particulier celles de maintenance - dans une base de données (par exemple Admin) complètement séparée des bases de données d'application / utilisateur, et écrivent les résultats de l'opération de maintenance dans cette base de données. Heureusement, il est possible de restaurer l'une des bases de données utilisateur sur un serveur de développement sans avoir à copier Adminégalement.