OSMC 2008 | Monitoring Microsoft SQL Server by Michael Streb

http://www.netways.de
NETWAYS GmbH | Deutschherrnstr. 47a | 90429 Nürnberg | www.netways.de | info@netways.de
Monitoring Microsoft SQL Server
Michael Streb
NETWAYS GmbH

Einführung
  Welche Software kommt zum Einsatz
  SQL Server
 Microsoft Windows 2003 Server x64
 Microsoft SQL Server 2008 x64 Standart
 NSClient++ 0.3.3 aus MSI Paket
  NAGIOS Server
 Debian Etch 4.0
 NAGIOS 3.0.3
 Nagios-Plugins 1.4.12
 Verschiedene SQL Plugins

Grundlagen
  Welche Parameter sollten überwacht werden und wie ?
  Betriebssystem und Hardware
 Systemüberwachung mittels NSClient
 System Performancecounter
 Herstellertools für Hardware
  SQL Server
 Dienste
 SQL spezifische Performancecounter
 Datenbankabfragen (Queries / Stored Procedures)
  Netzwerk
 Latenz
 Auslastung der Netzwerkinterfaces

Grundlagen
  Wie sind die Messwerte zu betrachten ?
  Einzelne Parameter sind nur bedingt aussagekräftig
  Zusammenhang verschiedener Parameter finden
 Durch zeitgleiche Alarmierungsmeldungen
 grafische Darstellung der Messwerte über einen bestimmten Zeitraum
–  NagiosGrapher
–  PNP

Betriebssystem / CPU
  CPU Auslastung
  Gesamt genutzte Prozessorzeit in %
(über alle Prozessoren und Core`s)
 sollte unter 80% bleiben
  Privileged CPU Zeit
  Wieviel Prozessorzeit in % braucht das System selbst (z.B. für IO Operationen)
 < 15 % der gesamten CPU Auslastung ist ok

Betriebssystem / CPU
  Benutzer CPU Zeit
  Wieviel % der gesamten CPU Zeit wird für Benutzerprozesse verwendet
 <= 80% der gesamten benutzen CPU Zeit
  SQLServer CPU Zeit
  Wieviel % der gesamten CPU Zeit wird für den SQL Serverprozess verwendet
 <= 80% der gesamten benutzten CPU Zeit
  Prozessor Queue
  Wie viele Threads warten auf Abarbeitung
 <= 4 pro CPU ist sehr gut
 <= 8 pro CPU ist gut
 <= 20 pro CPU ist ok
 >20 pro CPU suboptimal

Zusammenfassung CPU
  CPU Auslastung
  < 80 % optimal
  Prozessor Queue
  < 4 pro CPU optimal
  < 8 pro CPU gut
  > 20 pro CPU problematisch
  Privileged CPU Zeit
  <= 15% der gesamten CPU Auslastung
  Benutzer CPU Zeit
  SQL Server CPU Zeit

Betriebssystem / Speicher
  Verfügbarer Speicher
  Freier Arbeitsspeicher für neue Prozesse
 > 100MB mimimum
  Seiteneingaben / s
  Wieviele Speicherseiten (Pages) werden pro Sekunde in den Speicher geladen
 < 10 pro Sekunde optimal
  Seiten / s
  Wieviele Pages werden pro Sekunde gesamt gelesen und geschrieben
 grobe Werte für den Optimalzustand
–  < 100 auf langsamen Festplattensystemen
–  < 600 auf schnelleren Festplattensystemen

Betriebssystem / Speicher
  SQL MemoryManager: Grants pending
  Auf Speicher wartende Prozesse
 Je näher der Wert an 0 ist desto besser
  Pagefile Benutzung
 < 70% durchaus normal und nicht bedenklich

Betriebssystem / IO
  Direct Attached Storage (DAS) Parameter
  Festplattenplatz prüfen
 Wie viel Festplattenplatz ist noch frei
–  sehr grob 10% der Laufwerksgröße
  Mittlere Sek./Lesevorgänge
 Wie lange dauert der lesende Festplattenzugriff
–  < 8ms optimal
–  > 20ms problematisch

Betriebssystem / IO
  Mittlere Sek./Schreibvorgänge
 Wie lange dauert der schreibende Festplattenzugriff
 Writecache nur mit Battery Backup Unit (BBU)
-> Geschwindigkeitssteigerung
–  mit Write Cache (nur mit BBU)
»  < 1 ms optimal
»  < 4 ms gut
»  > 4 ms schlecht
–  ohne Write Cache
»  < 8 ms optimal
»  < 20 ms gut
»  > 20 ms schlecht

Betriebssystem / IO
  Durchschnittl. Warteschlangenlänge des Datenträgers
 Wie lange warten Anfragen an den Datenträger bis sie verarbeitet werden
–  > 30 weist auf mögliche Probleme hin
 Durch Read-Ahead nicht genau prognostizierbar
–  Performancetests um den genauen Wert zu ermitteln
  RAID Controller / BBU
 Herstellertools
–  DELL OpenManage
–  HP SIM
–  FSC Serverview
–  IBM Director
–  3ware tw_cli
–  Areca cli32
–  ...

Betriebssystem / IO
  SAN Parameter
  Herstellertools nutzen
 auf Clientseite nur bedingt aussagekräftig
  kein Allheilmittel für IO Performanceprobleme

Zusammenfassung IO
  DAS Parameter
  Freie Kapazität
 sehr grob > 10%
  Mittlere Sek. / Lesevorgänge
 < 8 optimal
 > 20 schlecht
  Mittlere Sek. / Schreibzugriffe
 Cached: < 1 ms optimal, > 4 ms schlecht
 Non-cached: < 8 ms optimal, > 20 ms schlecht
  Durchschnittl. Warteschlangenlänge des Datenträgers
 Kein allgemeingültiger Wert
–  > 30 weist auf mögliche Probleme hin
  BBU des RAID Controllers prüfen
  SAN Parameter
  Herstellertools nutzen

Betriebssystem / Dienste
  SQL Server Dienste
  SQL Server selbst
 MSSQLSERVER
  evtl. Analyse Service für SQL Server

Software / SQL Server
  Verbindung zum MSSQL aufnehmen um Abfragen mit NAGIOS Plugins
auszuführen
  meist Perl Plugins
 DBD::Sybase
–  keine Konfiguration notwendig
–  benötigte Pakete
»  libdbd-sybase-perl
 TDS und ODBC
–  Konfiguration notwendig
–  benötigte Pakete
»  libdbd-odbc-perl
»  unixodbc
»  Tdsodbc
  MS SQL spezifische Performancecounter

Software / Konfiguration ODBC
  /etc/odbcinst.ini
  Welche Datenbanktreiber stehen zur Verfügung
[FreeTDS]
Description=MSSQL DB
Driver=/usr/lib/odbc/libtdsodbc.so
UsageCount=1

Software / Konfiguration ODBC
  /etc/odbc.ini
  Konfiguration der DSN
[MSSQLServer]
Driver=FreeTDS
Description=MSSQL Nagios
Trace=Yes
TraceFile=/tmp/sql.log
ForceTrace=yes
Server=192.168.242.131
Port=1433
Database=master

Software / Welche Plugins gibt es
  check_mssql_monitor
  Perl
  DBD::Sybase
  Nagios::Plugins
  benutzt sp_monitor
  check_mssql_sproc.pl
  Perl
  DBD::ODBC
  führt eine beliebige Stored Procedure aus
  check_sql
  Perl
  DBD::Sybase
  führt einen beliebigen SQL Query oder eine SP aus

Software / Plugins / check_mssql_monitor
  check_mssql_monitor
  Anpassungen zur Version auf NagiosExchange.org
 Keine
  Kommandozeilenaufruf
  ./check_mssql_monitor -H 192.168.242.131 -U sa -P '$Mssql2008' -w 10 -c 20
  Ausgabe des Plugins
  Output:
  CHECK_MSSQL_MONITOR OK - SQL Server responded in 0.023985 seconds
  Perfdata:
  time=0.023985s;10;20 cpu=10%;; io=20%;; idle=50%;;

Software / Plugins / check_mssql_sproc.pl
  check_mssql_sproc.pl
< $conn{"dsn"} = "dbi:ODBC:Driver={SQL Server};SERVER=" . $conn{"server"};
> $conn{"dsn"} = "dbi:ODBC:" . $conn{"server"};
  ./check_mssql_sproc.pl -H MSSQLServer -u sa -P '$Mssql2008' -d testdb -p
sp_product_price_lower_30 -w 10 -c 20
  MSSQLServer ist die DSN aus odbc.ini _kein_ Hostname oder IP Adresse
  Output:
  CRITICAL: SQL Query returned 56612 for stored procedure 'sp_product_price_lower_30'. The critical
threshold is 20.
  Perfdata:
  keine

Software / Plugins / check_sql
  check_sql
< my $cs = "DBI:$driver:" . ($database ? "database=$database;" : '') . "server=$hostname" . ($port ? ";port=$port" : '');
> my $cs = "DBI:$driver:" . ($database ? "database=$database;" : '') . "host=$hostname" . ($port ? ";port=$port" : '');
  ./check_sql -H 192.168.242.131 -d Sybase -U sa -P '$Mssql2008' -D testdb -q
'sp_product_price_lower_30' -s -l 'Row count‘
  Output:
  CHECK_SQL OK - SQL Server Row count: 75274 (0.043734 seconds).
  Perfdata:
  time=0.043734s;;

Software / SQL Server / Performancecounter
  SQLServer:Access Methods
  Forwarded Records
 Einträge einer Tabelle die zur Laufzeit vergrößert wurden und nun mittels
Zeiger an eine andere Stelle verweisen
–  unter 10 pro 100 Batch requests / s optimal
 nur bei Heap Tabellen interessant
  Index Searches / sec
 Wie viele Suchen werden über Indexes abgearbeitet
–  Je mehr indizierte Suchen desto besser
  Full Scans / sec
 Wie viele Suchen erfordern einen Fullscan der Tabellen
–  So gering wie möglich halten, evtl. Indexes anpassen
  Page Splits
 Speicherseiten die verschoben werden müssen
–  < 20 per 100 Batch requests / s

  SQLServer:Buffer Manager
  Buffer Cache Hit Ratio
 Wie viele Anfragen werden aus dem Buffer Cache beantwortet
–  > 90% optimal
  Free List Stalls / sec
 Aus Speichergründen abgewiesene Anfragen an den Buffer
–  < 2 Sekunden optimal
–  Indikator für zu wenig Speicher
  Page Life Expectancy
 Wie lange bleiben bereits vorhandene Pages im Speicher bestehen
–  > 300 Sekunden optimal
»  Werte darunter deuten auf Speichermangel hin

  Page Reads / Writes per sec
 Von SQL aus verursachte Speicher Lese/Schreibzugriffe
–  < 90 Zugriffe optimal
  Lazy Writes / sec
 Wie oft müssen benutzte Pages aus dem Speicher auf die Festplatte
geschrieben(ausgelagert) werden
–  < 20 ist optimal
–  > 20 weist auf einen Speichermangel hin

Zusammenfassung SQL Performancecounter
  SQLServer:Access Methods
  Forwarded Records
  unter 10 pro 100 Batch requests / s
  Index Searches / sec
  Full Scans / sec
  Page Splits
  < 20 per 100 Batch requests / s
  Buffer Cache Hit Ratio
  > 90% optimal
  Free List Stalls / sec
  < 2 Sekunden optimal
  Page Life Expectancy
  > 300 Sekunden optimal
  Page Reads / Writes per sec
  Lazy Writes / sec

Netzwerk
  Netzwerkauslastung
  Prüfung durch:
 Performancecounter
 SNMP Abfrage auf den Windows Host
 SNMP Abfrage(n) auf den/die entsprechenden Switches
  Latenz
  Prüfung vom NAGIOS Server aus per PING
  Prüfung von den SQL Client Systemen per PING

Demo

Fragen ?

Vielen Dank für Ihre Aufmerksamkeit.

OSMC 2008 | Monitoring Microsoft SQL Server by Michael Streb

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (17)

Ähnlich wie OSMC 2008 | Monitoring Microsoft SQL Server by Michael Streb

Ähnlich wie OSMC 2008 | Monitoring Microsoft SQL Server by Michael Streb (20)

OSMC 2008 | Monitoring Microsoft SQL Server by Michael Streb