Konfigurieren und Problembehandlung den SubscriptionStreams-Parameter von der Verteilungs-Agent in SQL Server 2005

Bei der Transaktionsreplikation in Microsoft SQL Server 2005 können Sie den SubscriptionStreams -Parameter, um mehrere Verbindungen zu ermöglichen, die der Verteilungs-Agent, verwendet um Batches von Änderungen in Parallel zu den Abonnenten anwenden. Zur gleichen Zeit können der Verteilungs-Agent weiterhin viele Transaktions-dieselben Merkmale wie beibehalten, wenn der Verteilungs-Agent eine einzelne Verbindung, verwendet um die Änderungen zu übernehmen.

Hinweis: In den folgenden Abschnitten bezieht sich auf eine Verbindung, die der Verteilungs-Agent zu der Instanz von SQL Server auf dem Abonnenten öffnet eine Sitzung.

Dieser Artikel beschreibt die folgenden Themen:

• Behebung des Problems beim der Verteilungs-Agent wechselt in den um nur eine Sitzung zu verwenden.
• Zum Ermitteln von eines effizienten Wert für die SubscriptionStreams -Parameter.

Das Verhalten des Verteilungs-Agenten nach dem Angeben des SubscriptionStreams-Parameters

Der Verteilungs-Agent verwaltet die Anzahl der Sitzungen, die Sie in der SubscriptionStreams -Parameter angeben. Der Verteilungs-Agent verwendet diese Sitzungen, um Änderungen auf dem Abonnenten anzuwenden.

Nachdem Sie den SubscriptionStreams -Parameter angeben und der Verteilungs-Agent für einige Zeit ausgeführt wird, kann jedoch Wechseln von der Verteilungs-Agent nur eine Sitzung verwenden, um Änderungen auf dem Abonnenten anzuwenden.

Gründe für den Verteilungs-Agent zum wechseln, nur eine Sitzung zu verwenden

Der Verteilungs-Agent können wechseln, gibt viele Gründe, um nur eine Sitzung zu verwenden. Im folgenden sind die häufigsten Gründe:

• Wenn der Verteilungs-Agent Änderungen übernommen wird, löst eine der Sessions einen Fehler.
  
  Der Verteilungs-Agent fügt z. B. eine Zeile in einer untergeordneten Tabelle mithilfe einer Sitzung ein. Wenn dies auftritt, bevor der Verteilungs-Agent die entsprechende Zeile in der übergeordneten Tabelle, einfügt mithilfe einer anderen Sitzung, löst eine foreign Key-Einschränkungsverletzung einer Fehlermeldung.
• Blockieren Monitorthread erkennt blockieren. Blockieren kann einer der folgenden Gründe auftreten:
  • Der Verteilungs-Agent führt eine INSERT -Operation und eine UPDATE -Operation für eine Tabelle auf dem Abonnenten mithilfe von verschiedene Sitzungen. Wenn die Tabelle einen eindeutigen nicht gruppierten Index enthält, kann zwischen zwei Sitzungen sperren auftreten, wenn der Verteilungs-Agent die Indexschlüssel der Tabelle aktualisiert.
  • Der Verteilungs-Agent führt auf dem Abonnenten DML-Anweisungen auf mehrere Tabellen aus. Wenn eine indizierte Sicht auf diese Tabellen definiert ist, kann zwischen zwei Sitzungen sperren auftreten, wenn die indizierte Sicht, die gemeinsam genutzte Indexschlüssel aktualisiert.
  • Der Verteilungs-Agent wird eine DML-Anweisung für eine Tabelle auf dem Abonnenten mithilfe einer Sitzung ausgeführt. DML-Trigger sind auf dieser Tabelle definiert. DML-Trigger führen DML-Anweisungen auf einer anderen Tabelle, das mithilfe einer anderen Sitzung aktualisiert wird. In dieser Situation kann zwischen zwei Sitzungen sperren auftreten.

Wir empfehlen dringend, dass die folgenden Datenbankobjekte nicht an die Abonnentendatenbank zu verwenden:

• Foreign Key-Einschränkungen
• Eindeutige nicht gruppierte Indizes
• Indizierte Sichten
• DML-Trigger, die zwischen Sitzungen blockieren verursachen können

Wie Sie feststellen, ob der Verteilungs-Agent gewechselt hat, wenn Sie nur eine Sitzung verwenden

Verwenden Sie hierzu eine der folgenden Methoden.

Hinweis: Obwohl Sie bestätigen können, dass der Verteilungs-Agent nicht mit einer Sitzung, mit Methode 1 gewechselt hat, müssen Sie Methode 2 oder Methode 3 verwenden, um zu bestätigen, dass der Verteilungs-Agent gewechselt hat, um eine Sitzung zu verwenden.

Methode 1

Abfrage der sys.dm_exec_sessions (Dynamic Management View, DMV) für die Verbindungssitzungen auf die Abonnementdatenbank. Wenn Sie nur eine Verbindungssitzung sehen, der Verteilungs-Agent möglicherweise gewechselt haben, eine Sitzung verwenden. Wenn Sie mehr als eine Verbindungssitzung sehen, wird der Verteilungs-Agent die angegebene Anzahl von Sitzungen weiterhin verwendet.

Um zu bestätigen, dass der Verteilungs-Agent gewechselt hat, um eine Sitzung zu verwenden, verwenden Sie Methode 2 oder Methode 3.

Methode 2

Abfrage der Spalte Kommentare der Msdistribution_history Tabelle in der Verteilungsdatenbank. Wenn das Ergebnis der Abfrage den folgenden Eintrag enthält, gewechselt der Verteilungs-Agent hat um eine Sitzung zu verwenden:

Methode 3

Überprüfen Sie die Ausgabedatei des Verteilungs-Agents. Der Verteilungs-Agent hat nur eine Sitzung verwenden, wenn die Ausgabedatei den gleichen Fehlermeldung als Method 2 enthält gewechselt.

Die folgende Ausgabedatei ist ein Beispiel:

Behandlung von einen Verteilungs-Agenten, die Sie nur eine Sitzung wechselt

1. Führen Sie SQL Server Profiler auf den Abonnenten der Blockierte Prozess Bericht Ereignis und das Exception -Ereignis aufzeichnen. Diese Ereignisse aufzeichnen blockieren und Fehlern, die auftreten, wenn der Verteilungs-Agent Änderungen anwendet.
   
   Hinweis: Das Exception -Ereignis kann durch eine beliebige Art von Fehler verursacht werden, die das Problem zugeordnet werden kann. Beispielsweise kann der Fehler durch eine foreign Key-Einschränkungsverletzung verursacht werden.
2. Verwenden Sie eine der Methoden im Abschnitt "So zu bestimmen, ob der Verteilungs-Agent gewechselt hat, nur eine Sitzung verwenden" der Verteilungs-Agent überwachen.
3. Wenn der Verteilungs-Agent gewechselt hat, um eine Sitzung zu verwenden, beenden Sie die Ablaufverfolgung.
4. Erhalten Sie aus der Ausgabedatei des Verteilungs-Agenten oder von der Start_time Spalte der Tabelle Msdistribution_history den Zeitstempel des folgenden Eintrags:
   Der Prozess konnte nicht abgeschlossen letzte Batch in Multi-streaming-Modus, wurde in den einzelnen Verbindungsmodus zurückgesetzt und wird den Vorgang wiederholen.
5. Öffnen Sie die (TRC)-Ablaufverfolgungsdatei vom Abonnenten. Suchen einer Blockierungsskript oder eine Ausnahme-Ereignis, deren Zeitstempel ist identisch oder sehr nah an den Zeitstempel, den in Schritt 4 abgerufen.
6. Wenn Ausnahme feststellen, überprüfen Sie die Details der Ausnahme, um die Ursache zu bestimmen. Beispielsweise kann die Ausnahme durch eine foreign Key-Einschränkungsverletzung verursacht werden. Wenn dies der Fall ist, empfehlen wir, die foreign Key-Einschränkung zu, in der Abonnentendatenbank entfernen.
   
   Wenn Sie eine Blockierungsskript feststellen, ist das Problem durch das Blockieren verursacht. The following is a sample blocking script:

   <blocked-process-report monitorLoop="41589">
    <blocked-process>
     <process id="process3a6d438" taskpriority="0" logused="24592" waitresource="KEY: 6:72057594375700480 (0100e420fa5a)" waittime="9937" ownerId="568644832" transactionname="user_transaction" lasttranstarted="2008-05-05T04:55:04.430" XDES="0xa5619e370" lockMode="X" schedulerid="11" kpid="6104" status="suspended" spid="58" sbid="0" ecid="0" priority="0" transcount="2" lastbatchstarted="2008-05-05T04:55:04.553" lastbatchcompleted="2008-05-05T04:55:04.430" clientapp=<DistributionAgentProgram> hostname=<servername> hostpid="3980" loginname=<SQLAgentAcct>  isolationlevel="read committed (2)" xactid="568644832" currentdb="6" lockTimeout="4294967295" clientoption1="671090784" clientoption2="128056">
      <executionStack>
       <frame line="5" stmtstart="642" stmtend="1600" sqlhandle="0x0300060057a14477a8c6dd00609a00000100000000000000"/>
      </executionStack>
      <inputbuf>
   Proc [Database Id = 6 Object Id = 2000986455]   </inputbuf>
     </process>
    </blocked-process>
    <blocking-process>
     <process status="sleeping" spid="68" sbid="0" ecid="0" priority="0" transcount="1" lastbatchstarted="2008-05-05T04:55:04.570" lastbatchcompleted="2008-05-05T04:55:05.103" clientapp=<DistributionAgentProgram> hostname=<servername> hostpid="3980" loginname=<SQLAgentAcct> isolationlevel="read committed (2)" xactid="568644998" currentdb="6" lockTimeout="4294967295" clientoption1="671090784" clientoption2="128056">
      <executionStack/>
      <inputbuf>
   Proc [Database Id = 6 Object Id = 1172459501]   </inputbuf>
     </process>
    </blocking-process>
   </blocked-process-report>
   

   das Blockierungsskript einer blockierten Sitzung und eine Blockierung Sitzung aufgezeichnet. Blockierte Sitzung beginnt das <blocked-process>-Tag. Blockierende Sitzung beginnt das <blocking-process>-Tag.
7. Suchen Sie die Objekt-ID des Prozedur -Objekts, in der Sitzung gesperrt und in der Sitzung blockieren.
   
   Im Skript blockieren Beispiel ist die Objekt-ID des Objekts Prozeduren in der gesperrten Sitzung 2000986455. Die Objekt-ID des Objekts Prozeduren in der blockierenden Sitzung ist 1172459501.
8. Fragen Sie in der Abonnementdatenbank sys.objects Anzeigen indem Sie die Object_id-Spalte gleich dem Objekt-IDs sein, die Sie in Schritt 7 erhalten haben ab. Wenn Sie dies tun, können Sie die Objektnamen ermitteln.
   
   Führen Sie z. B. die folgende Abfrage im Kontext der Abonnementdatenbank:

   USE <SubDBName>
   GO
   SELECT name FROM sys.objects
   WHERE object_id = 1172459501 OR object_id = 2000986455
   

   Notizen
   • Die <SubDBName> Platzhalter stellt den Namen der Abonnementdatenbank dar.
   • Diese Objekte sind in der Regel Prozeduren, die in der Replikation verwendet werden.
9. Bestimmen Sie den Index oder der indizierten Sicht, die Blockierung verursacht. Gehen Sie hierzu folgendermaßen vor:
   1. Suchen Sie in das Blockierungsskript den Wert der Eigenschaft "waitresource" .
      
      Im Beispiel blockieren Skript ist der Wert der Eigenschaft "waitresource" 72057594375700480.
   2. Abfrage der sys.partitions-Ansicht erhalten die Objekt-ID und die Index-ID durch die Angabe der PARTITION_ID Spalte gleich dem Wert der Eigenschaft "waitresource" bestehen, die in Schritt 9a abgerufen.
      
      Führen Sie z. B. die folgende Abfrage:

      SELECT object_id, index_id FROM SYS.PARTITIONS WHERE PARTITION_ID=72057594375700480

   3. In der Abonnementdatenbank Abfragen der sys.indexes-Ansicht, um bestimmen den Index mithilfe von die Objekt-ID und Index-ID, die in Schritt 9 b abgerufen.
      
      Führen Sie z. B. die folgende Abfrage: Namen

      USE <SubDBName>
      GO
      SELECT name, type_desc, is_unique FROM sys.indexes
      WHERE object_id = <objID> and index_id = <idxID>
      

      Hinweis der <objID> Platzhalter steht für die OBJEKTKENNUNG, die in Schritt 9 b abgerufen. Die <idxID> Platzhalter stellt die Index-ID, die in Schritt 9 b abgerufen.
10. Wenn eine indizierte Sicht Blockierung verursacht wird, empfehlen wir, dass Sie die indizierte Sicht ablegen. Wenn blockieren durch einen eindeutigen nicht gruppierten Index verursacht wird, empfehlen wir, dass Sie den Index löschen können, und dann einen nicht eindeutigen Index erstellen.

Beschreibung des blockierenden Monitorthread

Der Verteilungs-Agent verwaltet einen blockieren Monitorthread, der erkennt, zwischen den Sitzungen blockiert. Wenn blockieren Monitorthread zwischen den Sitzungen blockieren erkennt, wechselt der Verteilungs-Agent eine Sitzung mit den aktuellen Batch von Befehlen erneut anwenden, die der Verteilungs-Agent nicht zuvor angewendet werden konnte.

Weitere Informationen über den blockierenden Monitorthread finden Sie im folgenden Artikel der Microsoft Knowledge Base:

Wie wird der Verteilungs-Agent mehrere Sitzungen fortgesetzt

Bevor der Verteilungs-Agent mehrere Sitzungen fortgesetzt werden kann, muss der Verteilungs-Agent führen Sie die Sp_MSget_repl_commands gespeicherte Prozedur mit die Verteilungsdatenbank für die Befehle, die nicht auf dem Abonnenten angewendet wurden. Der Verteilungs-Agent müssen Sie dann diese Befehle auf dem Abonnenten anwenden, bevor der Verteilungs-Agent mehrere Sitzungen fortgesetzt werden kann. In einer Replikationsumgebung lose kann nicht der Verteilungs-Agent mehrere Sitzungen fortgesetzt, da der Verteilungs-Agent viele Befehle auf dem Abonnenten anwenden müssen, bevor der Verteilungs-Agent mehrere Sitzungen fortgesetzt werden kann.

Um den gesamten Prozess zu überwachen, untersuchen Sie die Ausgabedatei des Verteilungs-Agents.

Weitere Informationen, wie Sie den SubscriptionStreams-Parameter, um Datenträger-Subsystem Durchsatz verbessert finden Sie im folgenden Artikel der Microsoft Knowledge Base: