Les Transactions à l'intérieur de la boucle à l'intérieur de la procédure stockée

EXEC procédure ne pas créer une transaction. Une épreuve très simple affichera ceci:

create procedure usp_foo
as
begin
  select @@trancount;
end
go

exec usp_foo;

@@Trancount à l'intérieur de usp_foo est 0, donc l'instruction EXEC ne pas démarrer une transaction implicite. Si vous avez un démarrage de la transaction lors de la saisie de UpdateRemoteServer cela signifie que quelqu'un a commencé l'opération, je ne peux pas dire qui.

Cela étant dit, l'utilisation de serveurs distants et de DTC pour mettre à jour des éléments va effectuer une assez mauvaise. Est l'autre serveur SQL Server 2005, au moins? Peut-être vous pouvez file d'attente de la demande de mise à jour et l'utilisation messagerie entre le local et le serveur distant et d'avoir le serveur distant effectuer les mises à jour basée sur les informations du message. Il serait effectuer beaucoup mieux parce que les deux serveurs ont uniquement pour traiter les transactions locales, et vous obtenez beaucoup mieux disponibilité en raison du couplage de la file d'attente de messagerie.

Mis à jour

Curseurs fait de ne pas commencer les opérations. La typique du curseur en fonction du traitement par lot est généralement basée sur les curseurs et des lots de mises à jour dans les opérations d'une certaine taille. Cette situation est assez courante pour une nuit d'emplois, car il permet de meilleures performances (vidage du journal de débit suite à l'accroissement de la taille des transactions) et de l'emploi peut être interrompu et repris w/o perdre everithing. Une version simplifiée d'un lot de boucle de traitement est généralement comme ceci:

create procedure usp_UpdateRemoteServer
as
begin
  declare @id int, @batch int;
  set nocount on;
  set @batch = 0;

  declare crsFoo cursor 
    forward_only static read_only 
    for 
    select object_id 
    from sys.objects;

  open crsFoo;

  begin transaction
  fetch next from crsFoo into @id ;
  while @@fetch_status = 0
  begin

    -- process here

    declare @transactionId int;
    SELECT @transactionId = transaction_id 
      FROM sys.dm_tran_current_transaction;
    print @transactionId;

    set @batch = @batch + 1
    if @batch > 10
    begin
      commit;
      print @@trancount;
      set @batch = 0;
      begin transaction;
    end
    fetch next from crsFoo into @id ;
  end
  commit;
  close crsFoo;

  deallocate crsFoo;
end
go

exec usp_UpdateRemoteServer;

J'ai oublié l'erreur de manipulation de la partie (commencer/commencer à attraper) et de la fantaisie @@fetch_status contrôles (curseurs statiques n'ont pas réellement besoin d'eux de toute façon). Cette démo montre le code que pendant l'exécution, il y a plusieurs différentes opérations de démarrage (différents Identifiants de transaction). De nombreuses fois des lots aussi déployer des transactions points de sauvegarde à chaque élément traitée de sorte qu'ils peuvent sauter en toute sécurité un élément qui provoque une exception, à l'aide d'un modèle similaire à celui de mon lien, mais cela ne s'applique pas aux transactions distribuées depuis les points d'enregistrement et de DTC ne se mélangent pas.

OriginalL'auteur Remus Rusanu

Ne JAMAIS traiter un élément à la fois dans une boucle lorsque vous faites le travail transactionnel. Vous pouvez faire une boucle à travers les documents des groupes de traitement, mais jamais, jamais, jamais faire un enregistrement à la fois. Ne basées sur des inserts au lieu et votre performance va changer à partir de quelques heures à quelques minutes ou même quelques secondes. Si vous utilisez un curseur à insérer, mettre à jour ou supprimer et ce n'est pas de la manipulation d'au moins 1000 rowa dans chaque état (pas un seul à la fois) que vous êtes de faire la mauvaise chose. Les curseurs sont une très mauvaise pratique pour telle chose.

OriginalL'auteur HLGEM