Wir haben zwei SQL Server für die Produktion, auf denen SQL Server 2005 SP4 mit kumulativem Update 3 ausgeführt wird. Beide Server werden auf physischen Computern ausgeführt, die identisch sind. DELL PowerEdge R815 mit 4 x 12-Kern-CPUs und 512 GB (yes GB) RAM mit 10 GB iSCSI SAN-Laufwerken für alle SQL-Datenbanken und -Protokolle. Betriebssystem ist Microsoft Windows Server 2008 R2 Enterprise Edition mit allen SPs und Windows-Updates. Das Betriebssystem-Laufwerk ist ein RAID 5-Array mit 3 x 72 GB 2,5-Zoll-SAS-Laufwerken (15 KB). Das SAN ist ein Dell EqualLogic 6510 mit 48 x 10 KB SAS 3,5-Zoll-Laufwerken, das in RAID 50 konfiguriert und in verschiedene LUNs für die beiden SQL-Server aufgeteilt und gemeinsam genutzt wird mit einem Exchange-Computer und mehreren VMWare-Servern.
Wir haben über 20 Datenbanken, von denen 11 mithilfe eines Zeugenservers mit hoher Verfügbarkeit gespiegelt werden. Der Zeugenserver ist ein Computer mit geringerer Leistung, auf dem eine SQL Server-Instanz ausgeführt wird, die ausschließlich für die Bereitstellung von Zeugendiensten verwendet wird. Die größte gespiegelte Datenbank ist 450 GB groß und generiert etwa 100-300 Iops. Der Datenbankspiegelungsmonitor meldet eine aktuelle Sendegeschwindigkeit von 100 KB bis 10 MB pro Sekunde und einen Mirror-Commit-Overhead von (normalerweise) 0 Millisekunden. Der Spiegelserver hat kein Problem damit, mit dem Prinzipal Schritt zu halten.
Es kommt regelmäßig zu Spiegelungsfailovers. Manchmal wird ein Failover für eine einzelne Datenbank ausgeführt, manchmal werden fast alle Datenbanken gleichzeitig ausgeführt. In der letzten Nacht hatten wir beispielsweise 10 von 11 Datenbank-Failovers. Die verbleibende Datenbank blieb zugänglich, bis ich ein manuelles Failover durchführte.
Ich habe mehrere Schritte zur Fehlerbehebung durchlaufen, um das Problem zu identifizieren, konnte das Problem jedoch bisher nicht beheben:
1) Das Gerät wurde mit einem Broadcom BCM5709C NetXtreme II 4-Port-Gigabit-Netzwerkadapter geliefert, den wir ursprünglich als primäre Netzwerkverbindung verwendeten. Wir haben seitdem auf beiden Computern einen Intel (R) PRO / 1000 PT-Dual-Port-Serveradapter installiert, um die NIC als Problem zu beseitigen.
2) Alle Datenbanken verfügen über eine automatische vollständige nächtliche Sicherung sowie eine Protokollsicherung für die an der Spiegelung beteiligten Datenbanken. Die Verwendung von Protokolldateien wird überwacht und selten zu mehr als 15% genutzt. Die Protokolldatei für die Hauptdatenbank hat eine Größe von 125 GB und besteht aus 159 virtuellen Protokolldateien mit einer Größe von 511 MB bis 1 GB. TempDB ist auf einer eigenen LUN und besteht aus 24 x 2 GB großen Dateien.
3) Das SQL Server-Protokoll für den Zeugen zeigt keine anderen Fehler als: Die Spiegelungsverbindung zu "TCP: //SQL02.DOMAIN.INET: 5022" ist nach 30 Sekunden ohne Antwort für die Datenbank "Data" abgelaufen. Überprüfen Sie die Dienst- und Netzwerkverbindungen.
Das SQL Server-Protokoll auf dem primären und dem sekundären Server zeigt Meldungen im Zusammenhang mit der Spiegelung an:
Die Spiegelungsverbindung zu "TCP: //SQL01.DOMAIN.INET: 5022" ist für die Datenbank "Data" nach 30 Sekunden ohne Antwort abgelaufen. Überprüfen Sie die Dienst- und Netzwerkverbindungen.
Die gespiegelte Datenbank "Data" wechselt aufgrund der Rollensynchronisierung die Rollen von "PRINCIPAL" zu "MIRROR". (Die Synchronisierung ist hier absichtlich falsch geschrieben, da genau so die eigentliche Nachricht angezeigt wird.)
Die gespiegelte Datenbank "Data" wechselt aufgrund eines Failovers die Rollen von "PRINCIPAL" zu "MIRROR".
Die gespiegelte Datenbank "Data" wechselt aufgrund eines Failovers vom Partner die Rollen von "MIRROR" zu "PRINCIPAL".
Die SQL Server-Dienste werden weiterhin ausgeführt und die Netzwerkverbindungen scheinen aufrecht zu erhalten. 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 mithilfe 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 Anwendungsereignisprotokollfehler 833, von dem keiner mit den Failover-Ereignissen übereinstimmt:
SQL Server hat festgestellt, dass 1 E / A-Anforderungen länger als 15 Sekunden in der Datei [F: \ Data.MDF] in der Datenbank [Data] (9) ausgeführt wurden. Das OS-Dateihandle lautet 0x00000000000010A0. Der Offset der letzten langen E / A lautet: 0x000007d4b10000).
6) Gelegentlich wird angezeigt: "Der Client konnte eine Sitzung mit SPID XXX, die für das Verbindungspooling zurückgesetzt wurde, nicht wiederverwenden. Dieser Fehler wurde möglicherweise durch einen früheren fehlgeschlagenen 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 Datenbank-Mail einen Fehler in das Anwendungsereignisprotokoll:
Ausnahmetyp: Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException Meldung: Bei der Verbindung ist ein Fehler aufgetreten. Grund: Timeout abgelaufen. Das Zeitlimit, das verstrichen ist, bevor der Vorgang abgeschlossen wurde 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.OpenConnection (String dbServerName, String dbConnection, String ) unter Microsoft.SqlServer.Management.SqlIMail.IMailProcess.QueueItemProcesser.ProcessQueueItems (String dbName, String dbServerName, Int32 lifetimeMinimumSec, LogLevel loggingLevel)
Ich glaube, die Timeouts verursachen das Failover. Was könnte diese Zeitüberschreitungen verursachen? Wenn ein tatsächliches Netzwerkproblem wie ein fehlerhaftes Kabel oder ein fehlerhafter Switch vorliegt, kann dies 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 aufweist, kann dies zu einem Spiegelungsfailover führen?
Danke für jeden Rat!
MSDN hat Folgendes zum Timeout-Mechanismus selbst zu sagen :
Der Mirroring-Timeout-Mechanismus
Da Softwarefehler von einer Serverinstanz nicht direkt erkannt werden, kann ein Softwarefehler möglicherweise dazu führen, dass eine Serverinstanz auf unbestimmte Zeit wartet. Um dies zu verhindern, implementiert die Datenbankspiegelung einen eigenen Timeout-Mechanismus, der auf jeder Serverinstanz in einer Spiegelungssitzung basiert und bei jeder offenen Verbindung in einem festen Intervall einen Ping sendet.
Um eine Verbindung offen zu halten, muss eine Serverinstanz in der festgelegten Zeitspanne einen Ping für diese Verbindung erhalten, zuzüglich der Zeit, die zum Senden eines weiteren Pings erforderlich ist. Das Empfangen eines Pings während des Zeitlimits zeigt an, dass die Verbindung noch offen ist und dass die Serverinstanzen über sie kommunizieren. Beim Empfang eines Pings setzt eine Serverinstanz ihren Timeout-Zähler für diese Verbindung zurück.
Wenn während des Zeitlimits für eine Verbindung kein Ping empfangen wird, wird die Verbindung von einer Serverinstanz als Zeitlimitüberschreitung eingestuft. Die Serverinstanz beendet 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
affinity64 E / A-Maske 0
affinity64 mask 0
Agent XPs 1
Aktualisierungen zulassen 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 Eigentumsverkettung 0
Cursor-Schwelle -1
Datenbank Mail XPs 1
Standardvolltextsprache 1033
Standardsprache 0
Standardablaufverfolgung aktiviert 1
Ergebnisse von Triggern 0 nicht zulassen
Füllfaktor (%) 0
Durchforstungsbandbreite (max.) 100 ft
ft Crawling-Bandbreite (min) 0
ft Benachrichtigungsbandbreite (max) 100
ft Benachrichtigungsbandbreite (min) 0
Indexerstellungsspeicher (KB) 0
zweifelhafte xact auflösung 0
Leichtes Pooling 0
sperrt 0
Maximaler Parallelitätsgrad 6
Maximaler Volltext-Crawling-Bereich 4
Maximaler Serverspeicher (MB) 393216
max text repl size (B) 65536
max worker threads 0
Medienspeicherung 0
Mindestspeicher pro Abfrage (KB) 2048
Min. Serverspeicher (MB) 52427
verschachtelte Trigger 1
Netzwerkpaketgröße (B) 1400
Ole Automatisierungsverfahren 1
offene Objekte 0
PH-Timeout (s) 60
Rang 0 vorberechnen
Prioritätserhöhung 0
Kostenlimit für Query Governor 0
Abfrage Wartezeit (n) -1
Erholungsintervall (min) 0
Fernzugriff 1
Remote-Admin-Verbindungen 0
Remote Login Timeout (s) 20
remote proc trans 0
Zeitlimit für Remoteabfrage (n) 600
Replikations-XPs 0
Nach Startprozedur 0 suchen
Server-Trigger-Rekursion 1
set working set size 0
Erweiterte Optionen anzeigen 1
SMO und DMO XPs 1
SQL Mail XPs 0
Rauschwörter transformieren 0
zweistellige Jahresgrenze 2049
Benutzerverbindungen 0
Benutzeroptionen 4216
Web Assistant-Verfahren 0
xp_cmdshell 1
Vor einiger Zeit habe ich den mirroring_connection_timeoutWert für alle gespiegelten Datenbanken manuell auf 30 Sekunden geändert , um das Problem zu beheben. Dies hat lediglich die Zeitspanne zwischen Failover-Ereignissen verlängert. Bei einer mirroring_connection_timeoutStandardeinstellung von 10 Sekunden sehen wir viel mehr Failovers.
In einem Kommentar wurde ich aufgefordert, sicherzustellen, dass IPSec deaktiviert ist. Daher veröffentliche ich den Inhalt mehrerer netshBefehle, mit denen die IPSec-Konfiguration des Betriebssystems angezeigt wird:
C: \> netsh ipsec dynamic alle anzeigen Keine aktuell zugewiesene Richtlinie Mainmode Policies nicht verfügbar. QuickMode-Richtlinien nicht verfügbar. Generische Hauptmodusfilter nicht verfügbar. Bestimmte Hauptmodusfilter nicht verfügbar. Generische Quickmode-Filter nicht verfügbar. Bestimmte Quickmode-Filter nicht verfügbar. IPsec-MainMode-Sicherheitszuordnungen nicht verfügbar. IPsec-QuickMode-Sicherheitszuordnungen nicht verfügbar. IPsec-Konfigurationsparameter ------------------------------ StrongCRLCheck: 1 IPsecexempt: 3 IPsec-Statistiken ---------------- Aktive Zuordnung: 0 SAs entladen: 0 Ausstehender Schlüssel: 0 Schlüssel fügt hinzu: 0 Schlüssel löschen: 0 ReKeys: 0 Aktive Tunnel: 0 Fehlerhafte SPI-Pkts: 0 Pkts nicht entschlüsselt: 0 Pkts nicht authentifiziert: 0 Pkts mit Wiederholungserkennung: 0 Vertrauliche gesendete Bytes: 0 Vertrauliche empfangene Bytes: 0 Authentifizierte gesendete Bytes: 0 Authentifizierte empfangene Bytes: 0 Transport Bytes Sent: 0 Empfangene Transportbytes: 0 In Tunneln gesendete Bytes: 0 In Tunneln empfangene Bytes: 0 Abgeladene gesendete Bytes: 0 Entladene empfangene Bytes: 0 C: \> netsh ipsec static alle anzeigen ERR IPsec: Keine Richtlinien im Richtlinienspeicher
UPDATE: 2012-12-20
Wir haben jetzt unsere Produktionssysteme auf SQL Server 2012 umgestellt. Wir führen dies seit dem Morgen des 17. Dezember aus - bisher keine Failover. Ein paar Tage liegen jedoch weit hinter dem, was wir mit den 2005-basierten Systemen gesehen haben.
Um die Leistung unserer neuen Systeme zu dokumentieren, habe ich mir diese sys.dm_os_wait_statsgenauer angesehen. und bemerkt DBMIRROR_DBM_EVENT, dass es sich um einen undokumentierten Wartetyp handelt. Graham Kent von Microsoft hat einen interessanten Artikel zur Fehlerbehebung bei unerwarteten Failovers und diesem Wartetyp. Ich werde seine Ergebnisse hier zusammenfassen:
Der Kunde erlebte eine riesige Blockierungskette, die auf einer hochvolumigen OLTP-Datenbank aufbaute, in der alle Headblocker auf DBMIRROR_DBM_EVENT warteten. Hier ist die Abfolge der Ereignisse, die ich durchlaufen habe:
Überprüfen Sie die Blockierungskette selbst. Hier können Sie nur sehen, dass wir auf DBMIRROR_DBM_EVENT warten
Ü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 unmittelbar auf das Problem hin, dass der Principal keine Transaktionen festschreiben kann, während er auf dem Spiegel wartet. Jetzt müssen wir untersuchen, warum der Spiegel keine Transaktionen festlegt oder warum der Principal nicht weiß, ob dies der Fall ist.
Ü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ß sind, kann es sein, dass der Spiegel mit Transaktionen überflutet ist und einfach nicht mit dem Volumen mithalten kann. Aus diesem Grund werden Sie in der Onlinedokumentation manchmal aufgefordert, die Spiegelung zu deaktivieren, wenn Sie einen außergewöhnlich großen protokollierten Vorgang ausführen müssen, z. B. eine Indexwiederherstellung. (Informationen dazu finden Sie unter http://technet.microsoft.com/en-us/library/cc917681.aspx ). Hier habe ich die folgenden 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 ermitteln, 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_rateDies sind alles Indikatoren, die Teil (a) ähneln, da sie möglicherweise eine Komponente oder ein Stück Architektur anzeigen, die bzw. das nicht reagiert hat. Wenn beispielsweise die Warteschlange send_queue plötzlich wächst, die Warteschlange re_do jedoch nicht wächst, kann der Principal die Protokolldatensätze nicht an den Spiegel senden, sodass Sie sich möglicherweise die Konnektivität oder die Warteschlangen des Service Brokers ansehen möchten Umgang mit den tatsächlichen Übertragungen.
In diesem speziellen Szenario stellten wir fest, dass alle Leistungsindikatoren seltsame Werte zu haben schienen, da Protokollsicherungen mit normaler Größe durchgeführt wurden, aber keine Statusänderungen, keine Sendewarteschlange, keine Wiederholungswarteschlange, eine flache Sendegeschwindigkeit und eine flache Wiederholrate. Dies ist sehr merkwürdig, da der DBM-Monitor während des gesamten Problemzeitraums keine Werte von irgendwoher aufzeichnen konnte.
Ü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 von 1400 gemeldet. Beispiele hierfür finden Sie an anderen Stellen in meinen anderen Spiegelungsblogs, z Dieses Fehler 1413 Beispiel
Überprüfen Sie die Standardablaufverfolgungsdateien. In diesem Szenario wurden die Standardablaufverfolgungsdateien nicht bereitgestellt. Sie sind jedoch fantastische Quellen für DBM-Probleminformationen, da sie Statusänderungsereignisse für alle Partner aufzeichnen. Dies ist hier dokumentiert:
Ereignisklasse "Statusänderung der Datenbankspiegelung"
Auf diese Weise erhalten Sie häufig ein gutes Bild von Szenarien, beispielsweise wenn die Netzwerkverbindung zwischen einem oder allen Partnern fehlgeschlagen ist und anschließend der Status der Partnerschaft angezeigt wird.
SCHLUSSFOLGERUNGEN:
In diesem speziellen Szenario fehlen mir derzeit zwei wichtige Datenpunkte, aber abgesehen davon kann ich zu den obigen Informationen immer noch eine vernünftige Hypothese aufstellen. Wir können mit Sicherheit sagen, dass die Blockierung durch die Tatsache verursacht wurde, dass der DBM aktiviert wurde, da alle Blocker auf den Wartetyp DBMIRROR_DBM_EVENT warten. Da wir wissen, dass wir den Spiegel nicht mit einem großen protokollierten Vorgang geflutet haben und diese Bereitstellung in diesem Modus normalerweise problemlos ausgeführt wird, können wir ungewöhnlich große Vorgänge ausschließen. Dies bedeutet, dass wir derzeit zwei potenzielle Kandidaten haben:
Hardwareprobleme bei der Konnektivität zwischen einigen oder allen Partnern.
CPU-Erschöpfung auf dem Spiegelserver - kann einfach nicht mit Wiederholungen Schritt halten - Die CPU-Erschöpfung kann selbst von einem Prozess außerhalb von SQL Server oder außerhalb dieser Spiegelpartnerschaft herrühren.
Ein Problem mit dem Spiegelungscode selbst (wir würden allerdings einige Speicherabbilder benötigen, um dies zu bestätigen).
Basierend auf der Erfahrung, die ich mit 1 oder 2 bezweifle, aber ich bin auch immer offen für 3, versuchen wir jetzt, mehr Daten zu sammeln, um dieses Problem genauer zu betrachten.