it-swarm.com.de

Was kann dazu führen, dass eine Spiegelungssitzung eine Zeitüberschreitung und dann ein Failover aufweist?

Wir haben zwei Produktions-SQL Server, auf denen SQL Server 2005 SP4 mit kumulativem Update 3 ausgeführt wird. Beide Server werden auf identischen physischen Computern ausgeführt. Dell PowerEdge R815 mit 4 x 12 Core-CPUs und 512 GB (ja GB) RAM mit 10 GB iSCSI SAN verbundene Laufwerke für alle SQL-Datenbanken und -Protokolle. Betriebssystem ist Microsoft Windows Server 2008 R2 Enterprise Edition mit Alle SPs und Windows-Updates. Das Betriebssystemlaufwerk ist ein RAID 5-Array mit 3 x 72 GB, 2,5 "15 KB SAS-Laufwerke. SAN ist ein Dell EqualLogic 6510 mit 48 x) 10K SAS 3,5 "-Laufwerke, in RAID 50 konfiguriert, in verschiedene LUNs für die beiden SQL-Server aufgeteilt und auch für einen Exchange-Computer und mehrere VMWare-Server freigegeben.

Wir haben über 20 Datenbanken, von denen 11 mit hoher Verfügbarkeit über einen Zeugenserver gespiegelt werden. Der Zeugenserver ist ein Computer mit geringerer Leistung, auf dem eine SQL Server-Instanz ausgeführt wird, die nur zur Bereitstellung von Zeugendiensten verwendet wird. Die größte gespiegelte Datenbank hat 450 GB und generiert etwa 100-300 Iops. Der Database Mirroring Monitor meldet eine aktuelle Sendegeschwindigkeit von 100 KB bis 10 MB pro Sekunde und einen Overhead für das Festschreiben von Spiegeln von (normalerweise) 0 Millisekunden. Der Spiegelserver hat kein Problem damit, mit dem Prinzipal Schritt zu halten.

Wir erleben ständig Spiegelungs-Failover. Manchmal wird eine einzelne Datenbank ausgefallen, manchmal werden fast alle Datenbanken gleichzeitig ausgefallen. Zum Beispiel hatten wir letzte Nacht ein Failover von 10 von 11 Datenbanken. Die verbleibende Datenbank blieb zugänglich, bis ich ein manuelles Failover durchführte.

Ich habe mehrere Schritte zur Fehlerbehebung durchgeführt, um das Problem zu identifizieren, konnte das Problem jedoch bisher nicht beheben:

1) Das Gerät wurde mit einem 4-Port-Gigabit-Netzwerkadapter von Broadcom BCM5709C NetXtreme II geliefert, den wir ursprünglich als primäre Netzwerkverbindung verwendet haben. Wir haben seitdem einen Intel (R) PRO/1000 PT Dual-Port-Serveradapter auf beiden Computern installiert, um das Problem NIC) zu beseitigen.

2) Alle Datenbanken verfügen über eine automatische vollständige Sicherung pro Nacht sowie eine Protokollsicherung für Datenbanken, die an der Spiegelung beteiligt sind. Die Verwendung von Protokolldateien wird überwacht und wird selten über 15% verwendet. Die Protokolldatei für die Hauptdatenbank ist 125 GB groß und besteht aus 159 virtuellen Protokolldateien mit einer Größe von 511 MB bis 1 GB. TempDB ist eine eigene LUN und besteht aus 24 x 2 GB großen Dateien.

3) Das SQL Server-Protokoll beim Zeugen zeigt keine anderen Fehler als: Die Spiegelungsverbindung zu "TCP: //SQL02.DOMAIN.INET: 5022" hat nach 30 Sekunden ohne Antwort eine Zeitüberschreitung für die Datenbank "Daten". Überprüfen Sie die Dienst- und Netzwerkverbindungen.

Das SQL Server-Protokoll auf dem primären und dem sekundären Server zeigt Meldungen zur Spiegelung an:

Die Spiegelungsverbindung zu "TCP: //SQL01.DOMAIN.INET: 5022" hat nach 30 Sekunden ohne Antwort eine Zeitüberschreitung für die Datenbank "Daten". Überprüfen Sie die Dienst- und Netzwerkverbindungen.

Die gespiegelte Datenbank "Data" ändert aufgrund der Rollensynchronisation die Rollen von "PRINCIPAL" in "MIRROR". (Die Synchronisation wird hier absichtlich falsch geschrieben, da genau so die tatsächliche Nachricht angezeigt wird.)

Die gespiegelte Datenbank "Data" ändert aufgrund eines Failovers die Rollen von "PRINCIPAL" in "MIRROR".

Die gespiegelte Datenbank "Daten" ändert aufgrund des Failovers vom Partner die Rollen von "SPIEGEL" in "PRINZIP".

Die SQL Server-Dienste werden weiterhin ausgeführt und die Netzwerkverbindungen scheinen weiterhin aktiv zu sein. Wir haben durchweg zwischen 500 und 2500 Sitzungen mit jedem Server verbunden (hauptsächlich Roboteranwendungen, die eine Verbindung zu Service Broker-Warteschlangen in einer einzelnen Datenbank herstellen).

4) TCP Chimney und RSS usw. sind mit der NET SH-Syntax deaktiviert.

5) Ich habe den SQL Server 2005 Best Practices Analyzer auf beiden Computern ausgeführt und finde nichts anderes als den gelegentlichen Fehler 833 des Anwendungsereignisprotokolls, von dem keiner mit den Failover-Ereignissen übereinstimmt:

In SQL Server sind 1 E/A-Anforderungen aufgetreten, deren Ausführung in der Datei [F:\Data.MDF] in der Datenbank [Data] (9) länger als 15 Sekunden dauert. Das Handle der Betriebssystemdatei lautet 0x00000000000010A0. Der Offset der letzten langen E/A beträgt: 0x000007d4b10000).

6) Gelegentlich wird angezeigt, dass der Client eine Sitzung mit SPID XXX, die für das Verbindungspooling zurückgesetzt wurde, nicht wiederverwenden konnte. Dieser Fehler wurde möglicherweise durch einen fehlgeschlagenen früheren Vorgang verursacht. Überprüfen Sie die Fehlerprotokolle unmittelbar vor dieser Fehlermeldung auf fehlgeschlagene Vorgänge . " von beiden Servern generiert. Es scheint keine "früheren" Meldungen zu geben, die auf ein Problem hinweisen.

7) Gelegentlich schreibt Datenbankmail einen Fehler in das Anwendungsereignisprotokoll:

Ausnahmetyp: Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException Meldung: Bei der Verbindung ist ein Fehler aufgetreten. Grund: Zeitüberschreitung abgelaufen. Die Zeitspanne, die vor Abschluss des Vorgangs verstrichen ist oder der Server nicht reagiert. Verbindungsparameter: Servername: MGSQL02, Datenbankname: msdb Daten: System.Collections.ListDictionaryInternal TargetSite: Void OpenConnection (Microsoft.SqlServer.Management.Common.SqlConnectionInfo) HelpLink: NULL Quelle: DatabaseMailEngine

StackTrace-Informationen unter Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.ConnectionManager.OpenConnection (SqlConnectionInfo ci) unter Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.DataAccessAdapter.OpenConnectionName, String-Name ) unter Microsoft.SqlServer.Management.SqlIMail.IMailProcess.QueueItemProcesser.ProcessQueueItems (String dbName, String dbServerName, Int32 LifetimeMinimumSec, LogLevel loggingLevel)

Ich glaube, dass die Timeouts das Failover verursachen. Was könnte diese Zeitüberschreitungen verursachen? Wenn ein tatsächliches Netzwerkproblem wie ein fehlerhaftes Kabel oder ein fehlerhafter Switch aufgetreten ist, kann dies natürlich zu Paketverlust und damit zu einer Zeitüberschreitung führen. Welche anderen Faktoren können jedoch zu Zeitüberschreitungen führen? Blockierung? Wenn MSDB oder eine andere Systemdatenbank ein E/A-Zeitlimit hatte, könnte dies das Spiegelungsfailover verursachen?

Vielen Dank für jeden Rat!

MSDN hat das im Folgenden über den Timeout-Mechanismus selbst zu sagen :

Der Spiegelungs-Timeout-Mechanismus

Da weiche Fehler von einer Serverinstanz nicht direkt erkannt werden können, kann ein weicher Fehler möglicherweise dazu führen, dass eine Serverinstanz unbegrenzt wartet. Um dies zu verhindern, implementiert die Datenbankspiegelung einen eigenen Timeout-Mechanismus, der darauf basiert, dass jede Serverinstanz in einer Spiegelungssitzung in einem festgelegten Intervall einen Ping für jede offene Verbindung sendet.

Um eine Verbindung offen zu halten, muss eine Serverinstanz innerhalb des festgelegten Zeitlimits einen Ping für diese Verbindung erhalten, zuzüglich der Zeit, die erforderlich ist, um einen weiteren Ping zu senden. Wenn während des Timeout-Zeitraums ein Ping empfangen wird, ist die Verbindung noch offen und die Serverinstanzen kommunizieren darüber. Beim Empfang eines Pings setzt eine Serverinstanz ihren Timeout-Zähler für diese Verbindung zurück.

Wenn während des Timeout-Zeitraums kein Ping für eine Verbindung empfangen wird, betrachtet eine Serverinstanz die Verbindung als abgelaufen. Die Serverinstanz schließt die Zeitüberschreitungsverbindung und behandelt das Zeitüberschreitungsereignis entsprechend dem Status und dem Betriebsmodus der Sitzung.

netsh interface tcp show global zeigt an:

Receive-Side Scaling State          : disabled
Chimney Offload State               : disabled
NetDMA State                        : enabled
Direct Cache Acess (DCA)            : disabled
Receive Window Auto-Tuning Level    : disabled
Add-On Congestion Control Provider  : ctcp
ECN Capability                      : disabled
RFC 1323 Timestamps                 : disabled

netsh interface ipv4 show dynamicportrange tcp

Protocol tcp Dynamic Port Range

Start Port      : 1025
Number of Ports : 64510

SELECT name, value_in_use FROM sys.configurations

 Ad-hoc-verteilte Abfragen 0 
 Affinitäts-E/A-Maske 0 
 Affinitätsmaske 0 
 Affinität64 E/A-Maske 0 
 Affinität64-Maske 0 
 Agent-XPs 1 
 Ermöglichen Aktualisierungen 0 
 Ehrfurcht aktiviert 0 
 Blockierte Prozessschwelle 5 
 C2-Überwachungsmodus 0 
 Clr aktiviert 1 
 Einhaltung gemeinsamer Kriterien aktiviert 0 
 Kostenschwelle für Parallelität 4 
 Cross-DB-Besitzverkettung 0 
 Cursorschwelle -1 
 Datenbank-Mail-XPs 1 
 Standard-Volltextsprache 1033 
 Standardsprache 0 
 Standard-Trace aktiviert 1 
 Ergebnisse von Triggern nicht zulassen 0 
 Füllfaktor (%) 0 
 ft Crawling-Bandbreite (max) 100 
 ft Crawl-Bandbreite (min) 0 
 ft Benachrichtigungsbandbreite (max) 100 
 ft Benachrichtigungsbandbreite (min) 0 
 index create memory (KB) 0 
 zweifelsfreie xact-Auflösung 0 
 leichtes Pooling 0 
 sperrt 0 
 maximaler Parallelitätsgrad 6 
 Maximaler Volltext-Crawling-Bereich 4 
 Maximaler Serverspeicher (MB) 393216 
 Maximale Textrepl-Größe (B) 65536 
 Max. Arbeitsthreads 0 
 Medienaufbewahrung 0 
 Min. Speicher pro Abfrage (KB) 2048 
 Min Serverspeicher (MB) 52427 
 verschachtelte Trigger 1 
 Netzwerkpaketgröße (B) 1400 
 Ole-Automatisierungsverfahren 1 
 offene Objekte 0 
 PH-Zeitüberschreitung (s) 60 
 Vorberechnungsrang 0 
 Prioritätserhöhung 0 
 Kostenlimit für Abfrage-Governor 0 
 Wartezeit (en) für Abfrage -1 
 Wiederherstellungsintervall (. min) 0 
 Fernzugriff 1 
 Remote-Administratorverbindungen 0 
 Zeitlimit (e) für Remote-Anmeldung 20 
 Zeitlimit für Remote-Prozess 0 
 Zeitlimit (e) für Remote-Abfragen 600 
 Replikations-XPs 0 
 Nach Startvorgängen suchen 0 
 Server-Trigger-Rekursion 1 
 Arbeitssatzgröße einstellen 0 
 Erweiterte Optionen anzeigen 1 
 SMO- und DMO-XPs 1 
 SQL Mail XPs 0 
 Transformieren von Rauschwörtern 0 
 Zweistelliger Jahresgrenzwert 2049 
 Benutzerverbindungen 0 
 Benutzeroptionen 4216 
 Web Assistant Proce dures 0 
 xp_cmdshell 1 

Vor einiger Zeit habe ich das mirroring_connection_timeout Wert für alle gespiegelten Datenbanken bis 30 Sekunden, um zu versuchen, das Problem zu beheben; Dies hat lediglich die Zeitspanne zwischen Failover-Ereignissen verlängert. Mit dem mirroring_connection_timeout Einstellung auf die Standardeinstellung von 10 Sekunden eingestellt, sehen wir eine Menge mehr Failover.

In einem Kommentar wurde ich gebeten, sicherzustellen, dass IPSec deaktiviert ist. Daher veröffentliche ich den Inhalt mehrerer netsh -Befehle, die die IPSec-Konfiguration des Betriebssystems anzeigen:

 
 C: \> netsh ipsec dynamic show all 
 Keine aktuell zugewiesene Richtlinie 
 Mainmode-Richtlinien nicht verfügbar. 
 Quickmode-Richtlinien nicht verfügbar. 
 Generische Mainmode-Filter nicht verfügbar. 
 Spezifische Mainmode-Filter nicht verfügbar. 
 Generische Quickmode-Filter nicht verfügbar. 
 Spezifische Quickmode-Filter nicht verfügbar. 
 IPSec-MainMode-Sicherheit Zuordnungen nicht verfügbar. 
 IPSec-QuickMode-Sicherheitszuordnungen nicht verfügbar. 
 
 IPSec-Konfigurationsparameter 
 ---------------- -------------- 
 StrongCRLCheck: 1 
 IPsecexempt: 3 
 
 IPSec-Statistik 
 --- ------------- 
 Active Assoc: 0 
 Offload SAs: 0 
 Pending Key: 0 
 Key Adds: 0 
 Schlüssel löscht: 0 
 ReKeys: 0 
 Aktive Tunnel: 0 
 Bad SPI Pkts : 0 
 Pkts nicht entschlüsselt: 0 
 Pkts nicht authentifiziert: 0 
 Pkts mit Wiederholungserkennung: 0 
 Vertrauliche gesendete Bytes: 0 
 Vertrauliche Bytes Empfangen: 0 
 Gesendete authentifizierte Bytes: 0 
 Empfangene authentifizierte Bytes: 0 
 Gesendete Transportbytes: 0 
 Empfangene Transportbytes: 0 
 Gesendete Bytes In Tunneln: 0 
 In Tunneln empfangene Bytes: 0 
 Gesendete abgeladene Bytes: 0 
 Empfangene abgeladene Bytes: 0 
 
 C: \> netsh ipsec static show all 
 ERR IPsec [05072]: Keine Richtlinien im Richtlinienspeicher 
 




UPDATE: 2012-12-20

Wir haben unsere Produktionssysteme jetzt auf SQL Server 2012 verschoben. Wir führen dies seit dem Morgen des 17. Dezember aus - bisher keine Failover. Ein paar Tage liegen jedoch genau innerhalb dessen, was wir mit den 2005-basierten Systemen gesehen haben.

Um die Leistung unserer neuen Systeme zu dokumentieren, habe ich mir sys.dm_os_wait_stats vorsichtiger; und bemerkte DBMIRROR_DBM_EVENT, ein undokumentierter Wartetyp. Graham Kent von Microsoft hat einen interessanten Artikel zur Fehlerbehebung bei unerwarteten Failovers und diesem Wartetyp. Ich werde seine Ergebnisse hier zusammenfassen:

Der Kunde hatte eine riesige Blockierungskette, die auf einer Datenbank mit hohem Volumen aufgebaut war OLTP Datenbank, in der alle Kopfblocker auf DBMIRROR_DBM_EVENT warteten. Hier ist die Abfolge der Ereignisse, die ich durchlaufen habe:

  1. Überprüfen Sie die Blockierungskette selbst - wir helfen hier, da wir nur sehen können, dass wir auf DBMIRROR_DBM_EVENT warten

  2. Überprüfen Sie die Quelle auf den undokumentierten Wartetyp. Natürlich können Sie dies nicht außerhalb von MS tun, aber ich kann sagen, dass dieser Wartetyp zum Zeitpunkt des Schreibens die Wartezeit darstellt, die verwendet wird, wenn der Principal darauf wartet, dass der Spiegel eine LSN härtet, was bedeutet, dass die Transaktion, zu der er gehört, nicht festgeschrieben werden kann . Dies weist sofort ganz spezifisch auf das Problem hin, dass der Principal keine Transaktionen festschreiben kann, während er auf den Spiegel wartet. Jetzt müssen wir untersuchen, warum der Spiegel keine Transaktionen festlegt oder warum der Principal nicht weiß, ob dies der Fall ist.

  3. Überprüfen Sie die msdb-Systemtabellen

(a) Sehen Sie in der Tabelle [backupset] nach, ob die Größe der zum Zeitpunkt des Problems erstellten Protokolle erheblich höher als normal ist. Wenn sie außergewöhnlich groß waren, konnte es sein, dass der Spiegel mit Transaktionen überflutet war und einfach nicht mit dem Volumen mithalten konnte. Aus diesem Grund werden Sie in Online-Büchern manchmal aufgefordert, die Spiegelung zu deaktivieren, wenn Sie einen außergewöhnlich großen protokollierten Vorgang ausführen müssen, z. B. eine Indexwiederherstellung. (Referenz dafür, warum dies so ist http://technet.Microsoft.com/en-us/library/cc917681.aspx ). Hier habe ich die folgende TSQL verwendet

SELECT backup_set_id,backup_start_date,database_name,has_bulk_logged_data,backup_size / 1000
FROM [backupset]
where backup_start_date between '2011-01-05 14:00:00' and '2011-01-05 19:30:00'
go

select round((AVG(backup_size)/1000),0)
FROM [backupset]
where database_name = 'mydatabase'

(b) Zweitens habe ich mir die Daten in den Tabellen [dbm_monitor_data] angesehen. Der Schlüssel hier ist, den Zeitrahmen zu lokalisieren, in dem wir ein Problem hatten, und dann zu prüfen, ob wir signifikante Änderungen in einer der folgenden Situationen festgestellt haben:

log_flush_rate
send_queue_size
send_rate
redo_queue_size
redo_rate

Dies sind alles Indikatoren, die Teil (a) insofern ähnlich sind, als sie möglicherweise eine Komponente oder ein Stück Architektur zeigen, die nicht reagiert haben. Wenn beispielsweise die send_queue plötzlich zu wachsen beginnt, die re_do-Warteschlange jedoch nicht wächst, bedeutet dies, dass der Principal die Protokolldatensätze nicht an den Spiegel senden kann, sodass Sie möglicherweise die Konnektivität oder die Service Broker-Warteschlangen überprüfen möchten Umgang mit den tatsächlichen Übertragungen.

In diesem speziellen Szenario haben wir festgestellt, dass alle Zähler seltsame Werte zu haben schienen, da Protokollsicherungen normaler Größe durchgeführt wurden, aber keine Statusänderungen, 0 Sendewarteschlangen, 0 Wiederherstellungswarteschlangen, eine flache Sendegeschwindigkeit und eine flache Wiederherstellungsrate. Dies ist sehr seltsam, da dies impliziert, dass der DBM-Monitor während des Problemzeitraums keine Werte von irgendwoher aufzeichnen konnte.

  1. Überprüfen Sie die SQL Server-Fehlerprotokolle. In diesem Fall gab es keinerlei Fehler oder Informationsmeldungen. In anderen Szenarien wie diesem werden jedoch häufig Fehler im Bereich 1400 gemeldet. Beispiele hierfür finden Sie an anderen Stellen in meinen anderen Spiegelungsblogs, z dieses Beispiel für Fehler 1413

  2. Überprüfen Sie die Standard-Trace-Dateien. In diesem Szenario wurden mir die Standard-Traces nicht bereitgestellt. Sie sind jedoch fantastische Quellen für DBM-Probleminformationen, da sie Statusänderungsereignisse auf allen Partnern aufzeichnen. Dies wird hier dokumentiert:

Ereignisklasse zur Änderung des Status der Datenbankspiegelung

Auf diese Weise erhalten Sie häufig ein umfassendes Bild von Szenarien, z. B. wenn die Netzwerkverbindung zwischen einem oder allen Partnern fehlgeschlagen ist und der Status der Partnerschaft danach erreicht wurde.

SCHLUSSFOLGERUNGEN:

In diesem speziellen Szenario fehlen mir derzeit zwei wichtige Datenpunkte, aber abgesehen davon kann ich immer noch eine vernünftige Hypothese zu den oben genannten Informationen aufstellen. Wir können mit Sicherheit sagen, dass die Blockierung durch die Tatsache verursacht wurde, dass DBM aktiviert wurde, da die Blocker alle auf den Wartetyp DBMIRROR_DBM_EVENT warten. Da wir wissen, dass wir den Spiegel nicht mit einem großen protokollierten Vorgang überflutet haben und diese Bereitstellung normalerweise in diesem Modus problemlos ausgeführt wird, können wir ungewöhnlich große Vorgänge ausschließen. Dies bedeutet, dass wir zu diesem Zeitpunkt zwei potenzielle Kandidaten haben:

  1. Hardwareprobleme bei der Konnektivität zwischen einigen oder allen Partnern.

  2. CPU-Erschöpfung auf dem Spiegelserver - einfach nicht in der Lage, mit Redos Schritt zu halten - Die CPU-Erschöpfung kann selbst von einem Prozess außerhalb von SQL Server oder außerhalb dieser Spiegelpartnerschaft herrühren.

  3. Ein Problem mit dem Spiegelungscode selbst (wir benötigen jedoch einige Speicherabbilder, um dies zu bestätigen).

Aus Erfahrung würde ich 1 oder 2 vermuten, aber ich bin auch immer offen für 3, wir versuchen jetzt, mehr Daten zu sammeln, um dieses Problem genauer zu untersuchen.

22
Max Vernon

Es hört sich so an, als würden Ihnen möglicherweise die TCP - Ports auf dem SQL Server ausgehen. Wie viele Verbindungen sehen Sie gleichzeitig zum Server?

Solche Timeouts würden das Problem definitiv verursachen.

6
mrdenny

Kannst du dich überprüfen sys.dm_os_schedulers ? Insbesondere tut work_queue_count weicht für eine signifikante Zeit von 0 ab? Dies würde Arbeiterhunger anzeigen und viele Ihrer Symptome erklären.

2
Remus Rusanu