Asynchrone Déclenche dans SQL Server 2005/2008

Vous ne pouvez pas faire le déclencheur s'exécute de façon asynchrone, mais vous pourriez avoir le déclencheur synchrone envoyez un message à un SQL Service Broker file d'attente. La file d'attente peut alors être traité de manière asynchrone par une procédure stockée.

SQL Server 2014 introduit une fonction très intéressante appelée Retard De La Durabilité. Si vous pouvez tolérer de perdre quelques lignes dans le cas d'un événement catastrophique, comme un crash du serveur, vous pourriez vraiment augmenter votre performance dans schenarios comme la vôtre.

Retard de la durabilité des transactions s'effectue à l'aide de journaux
les écritures sur le disque. Journal des transactions les registres sont conservés dans une mémoire tampon et
écrits sur le disque lorsque le tampon se remplit ou un tampon de rinçage événement prend
place. Retard de la durabilité des transactions permet de réduire le temps de latence et
conflit au sein du système

La base de données contenant la table doit d'abord être modifiée pour permettre retard de la durabilité.

ALTER DATABASE dbname SET DELAYED_DURABILITY = ALLOWED

Alors vous pouvez contrôler la durabilité par transaction.

begin tran

insert into ChangeTrackingTable select * from inserted

commit with(DELAYED_DURABILITY=ON)

La transaction sera engagé comme durable si la transaction est de la croix-base de données, donc cela ne fonctionnera que si votre table d'audit est situé dans la même base de données que le déclencheur.

Il est également possible de modifier la base de données forcé au lieu de permis. Cela provoque toutes les transactions dans la base de données risque d'être retardé durable.

ALTER DATABASE dbname SET DELAYED_DURABILITY = FORCED

Pour cause de retard de durabilité, il n'y a pas de différence entre un inattendu
l'arrêt et attendue d'un arrêt/redémarrage de SQL Server. Comme
les événements catastrophiques, vous devez planifier pour la perte de données. Dans un projet
arrêt/redémarrage de certaines transactions qui n'ont pas été écrites sur le disque
peut tout d'abord être enregistré sur le disque, mais vous ne devriez pas compter sur elle. Plan
si un arrêt/redémarrage, planifiée ou non, perd la
des données de la même comme un événement catastrophique.

Cette étrange défaut, nous l'espérons être résolu dans une version ultérieure, mais jusqu'alors, il peut être sage de faire en sorte d'exécuter automatiquement le " sp_flush_log procédure lorsque SQL server est le redémarrage ou l'arrêt.

Il y a un conflit entre le "fait son travail très bien" et "inacceptable", évidemment.

Il me semble que vous êtes en train d'utiliser des déclencheurs de la même manière que vous utiliseriez des événements dans un OO procédure de demande, ce qui à mon humble avis n'a pas de carte.

J'appellerais un des déclencheurs de la logique qui prend 30 secondes - non, plus que 0,1 seconde - comme disfunctional. Je pense que vous avez vraiment besoin de refonte de votre fonctionnalité et de le faire d'une autre manière. Je dirais "si vous voulez vous rendre asynchrone", mais je ne pense pas que cette conception a de sens que dans n'importe quelle forme.

Autant que "asynchrone déclencheurs", la base fondamentale des conflits, c'est que vous pourriez ne jamais inclure une telle chose entre BEGIN TRAN et COMMIT TRAN états parce que vous avez perdu la trace de savoir si elle a réussi ou non.

Pour effectuer le traitement asynchrone, vous pouvez utiliser le Service de Courtier, mais ce n'est pas la seule option, vous pouvez également utiliser des objets CLR.

Ce qui suit est un exemple d'une procédure stockée (AsyncProcedure) que des appels asynchrones d'une autre procédure (SyncProcedure):

using System;
using System.Data;
using System.Data.SqlClient;
using System.Data.SqlTypes;
using Microsoft.SqlServer.Server;
using System.Runtime.Remoting.Messaging;
using System.Diagnostics;
public delegate void AsyncMethodCaller(string data, string server, string dbName);
public partial class StoredProcedures
{
[Microsoft.SqlServer.Server.SqlProcedure]
public static void AsyncProcedure(SqlXml data)
{
AsyncMethodCaller methodCaller = new AsyncMethodCaller(ExecuteAsync);
string server = null;
string dbName = null;
using (SqlConnection cn = new SqlConnection("context connection=true"))
using (SqlCommand cmd = new SqlCommand("SELECT @@SERVERNAME AS [Server], DB_NAME() AS DbName", cn))
{
cn.Open();
using (SqlDataReader reader = cmd.ExecuteReader())
{
reader.Read();
server = reader.GetString(0);
dbName = reader.GetString(1);
}
}
methodCaller.BeginInvoke(data.Value, server, dbName, new AsyncCallback(Callback), null);
//methodCaller.BeginInvoke(data.Value, server, dbName, null, null);
}
private static void ExecuteAsync(string data, string server, string dbName)
{
string connectionString = string.Format("Data Source={0};Initial Catalog={1};Integrated Security=SSPI", server, dbName);
using (SqlConnection cn = new SqlConnection(connectionString))
using (SqlCommand cmd = new SqlCommand("SyncProcedure", cn))
{
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.Add("@data", SqlDbType.Xml).Value = data;
cn.Open();
cmd.ExecuteNonQuery();
}
}
private static void Callback(IAsyncResult ar)
{
AsyncResult result = (AsyncResult)ar;
AsyncMethodCaller caller = (AsyncMethodCaller)result.AsyncDelegate;
try
{
caller.EndInvoke(ar);
}
catch (Exception ex)
{
// handle the exception
//Debug.WriteLine(ex.ToString());
}
}
}

Il utilise asynchrone délégués pour appeler SyncProcedure:

CREATE PROCEDURE SyncProcedure(@data xml)
AS
INSERT INTO T(Data) VALUES (@data)

Exemple de l'appel AsyncProcedure:

EXEC dbo.AsyncProcedure N'<doc><id>1</id></doc>'

Malheureusement, le montage nécessite l'autorisation UNSAFE.

Je soupçonne que votre déclencheur de ces csv générique/texte de générer des déclencheurs conçu pour enregistrer toutes les modifications de la table en un seul endroit. Bon en théorie (peut-être...), mais difficile à tenir et à utiliser dans la pratique.

Si vous pouviez exécuter de manière asynchrone (ce qui serait encore besoin de stocker des données quelque part pour l'enregistrement de nouveau plus tard), alors vous n'êtes pas d'audit et de n'avoir de l'histoire à utiliser.

Vous pourriez peut-être regarder le déclenchement du plan d'exécution et de voir ce bit est de prendre le plus de temps?

Pouvez-vous modifier le mode de vérification, de dire, de par table? Vous pourriez diviser le journal actuel des données dans les tableaux correspondants.