MS-SQL Baseline - Versionsgeschichte

David: /* SQL Performance Counters */

2015-06-22T08:29:16Z

‎SQL Performance Counters

David: /* Performance Monitor */

2015-06-22T08:27:34Z

‎Performance Monitor

David am 22. Juni 2015 um 08:10 Uhr

2015-06-22T08:10:22Z

David: /* Probleme */

2015-06-18T10:31:33Z

‎Probleme

David: /* Performance Baseline ? */

2015-06-18T10:31:09Z

‎Performance Baseline ?

David: /* Ablauf */

2015-06-18T10:26:49Z

‎Ablauf

David: /* Performance Baseline ? */

2015-06-18T10:25:44Z

‎Performance Baseline ?

David: Die Seite wurde neu angelegt: „= Performance Baseline ? = Eine Performance Baseline ist nix anderes als eine Aufzeichnung von verschiedenen Countern/Parametern über einen definierten Zeitr…“

2015-06-18T10:23:36Z

Die Seite wurde neu angelegt: „= Performance Baseline ? = Eine Performance Baseline ist nix anderes als eine Aufzeichnung von verschiedenen Countern/Parametern über einen definierten Zeitr…“

Neue Seite

= Performance Baseline ? =

Eine Performance Baseline ist nix anderes als eine Aufzeichnung von verschiedenen Countern/Parametern über einen definierten Zeitraum, z.B. eine Stunde. Die Baseline sollte in regelmäßigen Abständen erneut aufgezeichnet werden, damit diese mit der Ursprünglichen Baseline verglichen werden kann.

Durch diesen Vergleich können Problemstellen leichter identifiziert werden bzw. Leistungsprobleme des SQL Server mit Fakten belegt werden und erleichtert die Fehlersuche deutlich.

= Ablauf =

Es gibt verschiedene fertige Tools. Eine Suche bei google mit "Microsoft SQL Performance Baseline" gibt schon einige nützliche Treffer. Am einfachsten und mit Windows Bordmitteln lässt sich eine grundlegende Performance Basline mittels dem "Performance Monitor" erstellen.

Kostenpflichte Tools aber auch frei erhältiche T-SQL Scripte können zusätzlich die DMV's auswerten, mit denen eine weitaus genauere Erfassung aller Werte ermöglicht wird.

== Probleme ==

Eine Baseline Erfassung, abhängig welche Werte genau erfasst werden, erzeugt eine zusätzliche Last auf dem SQL Server. D.h. wenn der Server schon starke Leistungsprobleme hat, sollte von einer komplette Performance Baseline abgesehen werden und eher manuell die einzelnen problematischen Stellen eingekreist werden. Hier kann es hilfreich sein, wenn historische Baselines zur Verfügung stehen. Damit kann ggf. ein Trend erkannt werden, um bei der manuellen Suche nicht die sprichwörtliche "Nadel im Heuhaufen" zu suchen, sondern die Ursache schneller zu lokalisieren.

← Nächstältere Version		Version vom 22. Juni 2015, 08:29 Uhr
Zeile 131:		Zeile 131:

	== SQL Performance Counters ==		== SQL Performance Counters ==
		+
		+	Hier fehlen noch Counter, falls AlwaysOn oder Replikation aktiv ist.

	=== SQLAgent:Jobs(*) ===		=== SQLAgent:Jobs(*) ===

@@ Zeile 19: / Zeile 19: @@
 Folgende Parameter sind unter anderem für eine grundlegende Performance Baseline mittels Performance Monitor interessant.
-== OS ==
+== OS  Performance Counters ==
 === IPv4 ===
 * Fragment Re-assembly Failures
@@ Zeile 129: / Zeile 129: @@
 * Segments Sent/sec
 * Segments/sec

← Nächstältere Version		Version vom 22. Juni 2015, 08:10 Uhr
Zeile 14:		Zeile 14:

	Eine Baseline Erfassung, abhängig welche Werte genau erfasst werden, erzeugt eine zusätzliche Last auf dem [[SQL Server]]. D.h. wenn der Server schon starke Leistungsprobleme hat, sollte von einer komplette Performance Baseline abgesehen werden und eher manuell die einzelnen problematischen Stellen eingekreist werden. Hier kann es hilfreich sein, wenn historische Baselines zur Verfügung stehen. Damit kann ggf. ein Trend erkannt werden, um bei der manuellen Suche nicht die sprichwörtliche "Nadel im Heuhaufen" zu suchen, sondern die Ursache schneller zu lokalisieren.		Eine Baseline Erfassung, abhängig welche Werte genau erfasst werden, erzeugt eine zusätzliche Last auf dem [[SQL Server]]. D.h. wenn der Server schon starke Leistungsprobleme hat, sollte von einer komplette Performance Baseline abgesehen werden und eher manuell die einzelnen problematischen Stellen eingekreist werden. Hier kann es hilfreich sein, wenn historische Baselines zur Verfügung stehen. Damit kann ggf. ein Trend erkannt werden, um bei der manuellen Suche nicht die sprichwörtliche "Nadel im Heuhaufen" zu suchen, sondern die Ursache schneller zu lokalisieren.
		+
		+	= Performance Monitor =
		+
		+	Folgende Parameter sind unter anderem für eine grundlegende Performance Baseline mittels Performance Monitor interessant.
		+
		+	== OS ==
		+	=== IPv4 ===
		+	* Fragment Re-assembly Failures
		+	* Fragmentation Failures
		+	* Fragmented Datagrams/sec
		+	* Fragments Created/sec
		+	* Fragments Re-assembled/sec
		+	* Fragments Received/sec
		+
		+	=== IPv6 ===
		+	* Fragment Re-assembly Failures
		+	* Fragmentation Failures
		+	* Fragmented Datagrams/sec
		+	* Fragments Created/sec
		+	* Fragments Re-assembled/sec
		+	* Fragments Received/sec
		+
		+	=== LogicalDisk(XZ:) ===
		+
		+	Hier sollte jede LogicalDisk überwacht werden, wo der die SQL Server Instanz Daten speichert.
		+
		+	* Avg. Disk Bytes/Read
		+	* Avg. Disk Bytes/Transfer
		+	* Avg. Disk Bytes/Write
		+	* Avg. Disk sec/Read
		+	* Avg. Disk sec/Transfer
		+	* Avg. Disk sec/Write
		+	* Disk Bytes/sec
		+	* Disk Read Bytes/sec
		+	* Disk Reads/sec
		+	* Disk Transfers/sec
		+	* Disk Write Bytes/sec
		+	* Disk Writes/sec
		+	* Free Megabytes
		+
		+	=== Memory ===
		+	* Available MBytes
		+	* Cache Faults/sec
		+	* Page Faults/sec
		+	* Page Reads/sec
		+	* Page Writes/sec
		+	* Pages Input/sec
		+	* Pages Output/sec
		+	* Pages/sec
		+
		+	=== Network Interface ===
		+
		+	Bitte nur die spezifischen Adapter, über welche mit dem SQL kommuniziert wird.
		+
		+	* Bytes Received/sec
		+	* Bytes Sent/sec
		+	* Bytes Total/sec
		+	* Packets Outbound Discarded
		+	* Packets Outbound Errors
		+	* Packets Received Discarded
		+	* Packets Received Errors
		+	* Packets Received Non-Unicast/sec
		+	* Packets Received Unicast/sec
		+	* Packets Received Unknown
		+	* Packets Received/sec
		+	* Packets Sent Non-Unicast/sec
		+	* Packets Sent Unicast/sec
		+	* Packets Sent/sec
		+	* Packets/sec
		+
		+	=== Process(sqlservr) ===
		+
		+	Der Prozess der zu untersuchenden [[SQL Server]] Instanz.
		+
		+	* % Privileged Time
		+	* % Processor Time
		+
		+	=== Processor (_Total\|0..n) ===
		+
		+	Die Werte für jede Core einzeln und als Totale erfassen
		+
		+	* % Interrupt Time
		+	* % Privileged Time
		+	* % Processor Time
		+
		+	=== Processor Information(_Total\|0..n) ===
		+
		+	Die Werte für jede Core einzeln und als Totale erfassen
		+
		+	* % of Maximum Frequency
		+	* Processor Frequency
		+
		+	=== TCPv4 ===
		+
		+	* Connection Failures
		+	* Connections Active
		+	* Connections Established
		+	* Connections Passive
		+	* Connections Reset
		+	* Segments Received/sec
		+	* Segments Retransmitted/sec
		+	* Segments Sent/sec
		+	* Segments/sec
		+
		+	=== TCPv6 ===
		+
		+	* Connection Failures
		+	* Connections Active
		+	* Connections Established
		+	* Connections Passive
		+	* Connections Reset
		+	* Segments Received/sec
		+	* Segments Retransmitted/sec
		+	* Segments Sent/sec
		+	* Segments/sec

← Nächstältere Version		Version vom 18. Juni 2015, 10:31 Uhr
Zeile 13:		Zeile 13:
	== Probleme ==		== Probleme ==

−	Eine Baseline Erfassung, abhängig welche Werte genau erfasst werden, erzeugt eine zusätzliche Last auf dem SQL Server. D.h. wenn der Server schon starke Leistungsprobleme hat, sollte von einer komplette Performance Baseline abgesehen werden und eher manuell die einzelnen problematischen Stellen eingekreist werden. Hier kann es hilfreich sein, wenn historische Baselines zur Verfügung stehen. Damit kann ggf. ein Trend erkannt werden, um bei der manuellen Suche nicht die sprichwörtliche "Nadel im Heuhaufen" zu suchen, sondern die Ursache schneller zu lokalisieren.	+	Eine Baseline Erfassung, abhängig welche Werte genau erfasst werden, erzeugt eine zusätzliche Last auf dem [[SQL Server]]. D.h. wenn der Server schon starke Leistungsprobleme hat, sollte von einer komplette Performance Baseline abgesehen werden und eher manuell die einzelnen problematischen Stellen eingekreist werden. Hier kann es hilfreich sein, wenn historische Baselines zur Verfügung stehen. Damit kann ggf. ein Trend erkannt werden, um bei der manuellen Suche nicht die sprichwörtliche "Nadel im Heuhaufen" zu suchen, sondern die Ursache schneller zu lokalisieren.

@@ Zeile 3: / Zeile 3: @@
 Eine Performance Baseline ist nix anderes als eine Aufzeichnung von verschiedenen Countern/Parametern über einen definierten Zeitraum, z.B. eine Stunde. Die Baseline sollte in regelmäßigen Abständen erneut aufgezeichnet werden, damit diese mit der ursprünglichen Baseline verglichen werden kann.
-Durch diesen Vergleich können Problemstellen leichter identifiziert werden bzw. Leistungsprobleme des SQL Server mit Fakten belegt werden und erleichtert die Fehlersuche deutlich.
+Durch diesen Vergleich können Problemstellen leichter identifiziert werden bzw. Leistungsprobleme des [[SQL Server]] mit Fakten belegt werden und erleichtert die Fehlersuche deutlich.
 = Ablauf =

@@ Zeile 7: / Zeile 7: @@
 = Ablauf =
-Es gibt verschiedene fertige Tools. Eine Suche bei google mit "Microsoft SQL Performance Baseline" gibt schon einige nützliche Treffer. Am einfachsten und mit Windows Bordmitteln lässt sich eine grundlegende Performance Basline mittels dem "Performance Monitor" erstellen.
+Es gibt verschiedene kommerzielle und freie Tools. Eine Suche bei google mit "Microsoft SQL Performance Baseline" gibt schon einige nützliche Treffer. Am einfachsten und mit Windows Bordmitteln lässt sich eine grundlegende Performance Basline mittels dem "Performance Monitor" erstellen.
 Kostenpflichte Tools aber auch frei erhältiche T-SQL Scripte können zusätzlich die DMV's auswerten, mit denen eine weitaus genauere Erfassung aller Werte ermöglicht wird.

@@ Zeile 1: / Zeile 1: @@
 = Performance Baseline ? =
-Eine Performance Baseline ist nix anderes als eine Aufzeichnung von verschiedenen Countern/Parametern über einen definierten Zeitraum, z.B. eine Stunde. Die Baseline sollte in regelmäßigen Abständen erneut aufgezeichnet werden, damit diese mit der Ursprünglichen Baseline verglichen werden kann.
+Eine Performance Baseline ist nix anderes als eine Aufzeichnung von verschiedenen Countern/Parametern über einen definierten Zeitraum, z.B. eine Stunde. Die Baseline sollte in regelmäßigen Abständen erneut aufgezeichnet werden, damit diese mit der ursprünglichen Baseline verglichen werden kann.
 Durch diesen Vergleich können Problemstellen leichter identifiziert werden bzw. Leistungsprobleme des SQL Server mit Fakten belegt werden und erleichtert die Fehlersuche deutlich.