Performancedaten

Forum
1

Hallo,

gibt es eine Möglichkeit über eine Schnittstelle aktuelle Performance-Daten von Combit abzugreien? Also zB. Angemeldete Benutzer, welcher Benutzer welche CPU und DB Last verursacht. Oder sagen wir mal langsam aufbauende Sichten, etc…?

Gruß.

2

Wie machen dies bei uns intern über entsprechende SQL Server Tools. Die Zuordnung von SQL-Session zu cRM-Loginname (also: „Wer ist das denn?“) sollte hier irgendwo im Forum zu finden sein oder in einem der vielen Solution-Trigger Quellcodes. Das ist irgendeine processes Sicht, deren genauer Name mir jetzt auswendig nicht einfällt. Sonst nochmal melden. :blush:

3

Bei einem zentralen DB Benutzer aus dem Client heraus könnte in SQL Triggern SYSTEM_USER funktionieren, bin aber nicht ganz sicher.

4

Eigentlich sollte kein Benutzer auf der DB dauerhaft Last verursachen, das wäre dann vermutlich eher unperformantes SQL, also ein Trigger der Laufzeit verursacht. Da könnte eine Suche allgemein nach slow querys funktionieren:
sql server - How to find slowest queries - Stack Overflow

5 
-- Ermitteln des Namens des cRM-Benutzers / der cRM-Benutzerin, der/die diese Abfrage ausführt
SELECT @LoginName = Substring("program_name", 0, PATINDEX('%@%', "program_name")) FROM sys.dm_exec_sessions WHERE "session_id" = @@SPID AND PATINDEX('%@%', "program_name") != 0

-- Fragezeichen setzen, wenn der LoginName nicht gesetzt werden kann (z. B. wenn Änderungen in der Tabelle NICHT über den cRM ausgeführt werden)
IF @LoginName = '' OR @LoginName IS NULL
	SET @LoginName = '?'
6

Es muss nicht immer an der Query selbst liegen, sondern an den von der Query erfragten Daten oder „die Serverumstände“. Hier ein paar Beispiele aus dem Nähkästchen, was alles „Last“ auf dem Server auslösen kann, auch wenn die Abfrage selbst eigentlich „unschuldig“ ist.

  • Fehlende Wartungspläne, die das Transaktionsprotokoll einpflegen würden, wodurch dieses wächst und wächst und wächst
  • Fehlende Indizes auf wichtige Felder
  • Falsch konfigurierte Memoryeinstellungen am Server, wodurch dieser anfangen muss, auf die Festplatte zu swappen
  • In der SQL-Tabelle angelegte „berechnete Felder“, was überhaupt nicht mit steigender Datensatzanzahl skaliert, schlimmstenfalls wird danach sortiert oder gefiltert
  • Datenbanksichten, die aufwändige on-the-fly Aggregationen/Berechnungen machen, schlimmstenfalls noch über einen externen „Linked Server“
  • Volltextsuche in allen Zeichenfeldern unbedarfter Benutzer:innen in Millionen von Datensätzen (Grenzfall bzgl. der Einleitung, da ist tatsächlich die Abfrage selbst „Schuld“, aber weder combit CRM noch der SQL Server können da halt dann zaubern :smiley: )

…und manches mehr.

Aber ein Blick in die Server-Metriken sollte einen da eigentlich ganz gut auf die richtige Spur bringen. :nerd_face: