Base Monitoring

TSQLTuesdayT-SQL Tuesday #66: Base Monitoring

Cathrine Wilhemsen (b|t) is hosting the T-SQL Tuesday blog party of this month.

I will describe what’s my understanding of Base Monitoring for SQL Server.

Last Thursday 5/7/2015 I presented these thoughts at a PASS regional Chapter in Cologne/Germany.

„My“ Base Monitoring consists of monitoring all Events that come up from too few hard disk space, memory or CPU. It is also about monitoring of locking, blocking or deadlocks, long running queries/jobs and failure in logins.
I will also do additional tasks that didn’t belong to the monitoring itself but help in failure check and reorganization of indexes and so on (…)

All this was arranged and written down after an installation of a new SQL Server.
These are the steps I did:

1. create a DBA Database for several scripts and tables (see below)
2. install the main script from dbWarden for Monitoring
3. install Integrity check and Maintenance scripts from Ola Halengren into DBA Database
4. create GetErrorLogEvent Stored Procedures and Job for Mails out of the SQL Errorlog into DBA Database
5. create Jobs for recycling ErrorLogs
6. Performance Monitoring, Event Logs with an external Tool called Host Monitor

The dbWarden Script (2.) is a great ressource for real time monitoring blocking, deadlocks, long running querys, jobs and so on – best of all: it is free of charge (!). It also brings a detailed and configurable health report of the server that will be sent every morning.

The scripts from Ola Halengren (3) are well known in the SQL Server Community for bringing us perfect maintenance tasks for index and statistic updates with rebuild online/offline or reorganize where it is neccessary.
Additionally there is a script for integrity check – and backup of course. 🙂

The GetErrorLogEvent Script (4.) was originally written by Jonathan Kehayias and published on an MSDN Archive site. I didn’t found the site any more on MSDN so the script is attached together with the presentation (Sorry, only german these days) below.

For recycling the Error Log (5.) it is only neccessary to create a job with the two commands (exec dbo.sp_cycle_errorlog and exec dbo.sp_cycle_agent_errorlog).

The only tool that is not free of charge is the last one, called Host Monitor.
It is perfect for more monitoring especially for long term monitoring.

Ressources

dbWarden
Description: http://www.sqlservercentral.com/articles/Monitoring/98106/
Download, Wiki: http://sourceforge.net/projects/dbwarden/

Ola Halengren
https://ola.hallengren.com/

Hostmonitor (€)
http://www.ks-soft.net

GetErrorLogEvents and Basis Monitoring Presentation from the PASS Chapter in Cologne (German)
BaseMonitoring_20150507

Thanks for reading,
Volker

Optimierung Reporting Server MS SQL 2008 R2

Meldung der Report-Abteilung: täglich zwischen 9 und 9:20 Uhr ist der Reporting Server völlig ausgelastet, d.h. die Reaktionszeiten beim Erstellen und Bearbeiten von Reports sind inakzeptabel.

Meine Recherchen nach den Ursachen:

1. Ausgangssituation

  • Aus Performancegründen wurde vor 1 ½ Jahren ein neuer Reporting Server angeschafft.
  • Danach lief der Restore der Datenbanken (Befüllung des Reporting Server über Backup&Restore aus den Produktiv Datenbanken) über Nacht und ebenso sämtliche Abfragen deutlich schneller.
  • Ein Zwang zu weiterer Optimierung der Abfragen usw. war damit nicht mehr notwendig

2. Analyse

  • Datenbank und Tabellen sind für OLTP ausgelegt, d.h. Eingabe von Daten, Update usw.
  • Auf dem Reporting Server handelt es sich um OLAP, d.h. Analyse von Daten inkl. Aggregierung
    => andere Art der Abfrage => andere Art der Indizierung notwendig
  • Es laufen Reports gleichzeitig die auf die gleichen Daten zugreifen – mit der fehlenden Indizierung laufen diese Reports dann so lange, dass sie sich gegenseitig blockieren.
    => Ergebnis: ~ 400.000 Wartende Tasks, mäßige Prozessorauslastung, viele SperrenAktivitätsmonitor

3. Lösungsmöglichkeiten

  1. Anzahl der Reports verkleinern.
  2. Reports besser verteilen damit diese sich zeitlich nicht so sehr in die Quere kommen.
  3. Views (general_view usw.) materialisieren, d.h. in Tabellen umwandeln und darauf dann Indizes anwenden.
    Erklärung: Für die Abfrage über alle Datenbanken wurde ein View entworfen, der einen Union All über alle Datenbanken macht. Die Idee ist, das Ergebnis aus diesem View, der mittlerweile in fast allen Reports (~300 Stück) verwendet wird, in eine Tabelle zu speichern, damit bei jeder Abfrage nur noch die Tabelle verwendet wird und nicht mehr sämtliche Datenbanken. Passende Indizes gehören dann dazu.
  4. Vorhandene Indizes durch OLAP Indizes ersetzen.
  5. zusätzliche SQL Instanz vom Server verlagern -> zusätzlicher SQL Server 2008R2 notwendig.
  6. Replikation zur Verringerung der Wiederherstellungszeiten und für Intraday Reports.
    Erklärung: durch Backup und Restore als Aktualisierung des Reporting Servers ist der Server während der entsprechenden Restore-Zeit nicht für Reports verfügbar. Da wir an dieser Stelle aber abhängig vom Backup auf den Produktiv Servern sind, kann der Restore nicht früher laufen.
    Lösungsansatz: Backup und Restore durch Replikation ersetzen.
  7. größerer Server mit mehr Speicher – Investition ca. 20.000€

4. Umsetzung

Mittlerweile sind die Punkte 1-3 realisiert. Schon alleine durch konsequentes auseinanderziehen der Reports konnte die Verfügbarkeit des Servers zu den angegebenen Zeiten eindeutig verbessert werden.
Zuletzt wurde dann noch Punkt 3 umgesetzt. Vermutlich sollten noch weitere Indizes hinzugefügt werden um die Geschwindigkeit der Abfragen deutlich zu erhöhen, aber das ist so schon um längen besser als vorher.

Die weitern Punkte werden vermutlich nicht umgesetzt werden, da die ersten 3 Punkte schon eine deutliche Verbesserung gebracht haben. Zusätzlich ist das Thema DBA nicht mein einziges Thema und ich kann mich nicht so darauf konzentrieren, wie ich gerne würde.

Danke fürs Lesen,

Volker

 

 

In-Memory Techniken – Teil 2 – open HPI

Hallo,

im ersten Teil zu In-Memory Techniken habe ich meine erste Erfahrung mit dem Thema beschrieben.

Danach wollte ich mehr zu dem Thema wissen.

Nach etwas längerer Suche habe ich dann per Zufall einen Hinweis auf die Online Platform des Hasso Plattner Instituts in Potsdam gefunden.

Dort wird ein kostenloses 6-wöchiges Seminar angeboten was über „In-Memory Data Management – Implications on Enterprise Systems“ informiert. Zwar basiert das ganze auf der vom Hasso Plattner Institut mitentwickelten Open Source SanssouciDB bzw. der SAP HANA Appliance, vieles ist aber auch auf den MS SQL Server übertragbar. Auch in 2015 wird dieser Kurs wieder angeboten:
https://open.hpi.de/courses/imdb2015

Das Seminar wird mit wöchentlichen Selbsttests und einem Examen und Zeugnis abgeschlossen. Das ganze ist nicht so ganz einfach, aber durchaus nebenberuflich zu schaffen.

Ich kann das nur empfehlen!

Danke fürs Lesen
Volker

 

In-Memory Techniken – Teil 1

Hallo Leute,
wie in meiner „über mich“ Seite angekündigt werde ich mich dem Thema In-Memory Datenbanken des SQL Server 2014 widmen.

Die beeindruckende Beschleunigung, die ein Insert Statement durch In-Memory Techniken erfahren kann, habe ich zum ersten Mal nach dem Lesen eines Artikels von Pinal Dave ausprobiert. Das ist dieser Artikel:
http://blog.sqlauthority.com/2014/09/15/sql-server-beginning-in-memory-oltp-with-sample-example/

Da wir in der Firma noch „Lichtjahre“ von dem Einsatz des SQL Server 2014 entfernt sind, bzw. für diesen bisher keine Notwendigkeit besteht, musste ich mich zuerst mit einer Testversion des SQL 2014 zufrieden geben mit der ich testen konnte.
Das reichte auf einer virtuellen Maschine aus um den Effekt zu sehen.

Von dem Erfolg angetrieben habe ich dann natürlich sofort versucht vorhandene Datenbanken auf In-Memory umzubauen 🙂 . Das Umbauen der Datenbank war dabei nicht das Problem, allerdings der Switch von einzelnen, viel genutzen Tabellen war dann nicht mehr so einfach. Da so manche Details der Tabellen nicht in Einklang mit den Vorgaben der In-Memory Tabellen stand, musste ich dort einiges ändern.

Das betraf vor allem Indizes. Bei dem Umbau half mir der Migrationsassistent des SSMS. Ich hab dann einfach alle Indizes gelöscht die nicht den Vorstellungen des Assistenten entsprachen und dann die Tabellen zu In-Memory Tabellen umgebaut.

Die erhoffte Beschleunigung beim Zugriff mit unserer Anwendung blieb allerdings aus. 🙁

Im Nachhinein erklärte sich das ganze auch:
Memory-optimierte Tabellen sind nicht unbedingt für das reine Lesen optimiert, sondern für Schreiben/Updates, so wie es in dem kleinen Beispiel von Pinal ja auch umgesetzt ist.

Da ich aber nur Tabellen umgebaut hatte, die ausschließlich lesende Zugriffe zu verarbeiten hatten, stellte sich keine Beschleunigung ein.

Meine weiteren Erfahrungen folgen im nächsten Teil…

Danke fürs Lesen,
Volker

Rückblick auf Vorträge zum SQL Server Monitoring dbWarden

In 2013 habe ich in den Regionalgruppen Köln/Bonn/Düsseldorf sowie Ruhrgebiet einen Vortrag zu einem kostenlosen Monitoring Skript (dbWarden) halten können welches ich Euch nicht vorenthalten möchte.

Es handelt sich dabei um eine Kombination aus Skripten und Jobs zum SQL Server Monitoring – Warden = Wächter, Aufseher

Voraussetzungen:

  • SQL Server Agent, SQL 2005 ff.
  • „This script assumes you already have DBMail setup (with a Global Public profile available.)“

Beschreibung: http://www.sqlservercentral.com/articles/Monitoring/98106/

Forum: http://www.sqlservercentral.com/Forums/Topic1441532-3362-1.aspx

Download: http://sourceforge.net/projects/dbwarden/

Hier dann noch die Präsentation von dem Termin in Köln am 3.6.2013:
0306 dbWarden Volker Bachmann

Viele Grüße
Volker