SQL Server Perf Baseline Reports – nächstes Issue und Fix

Hallo zusammen,

und weiter geht es mit dem Thema Performance Baseline Reports. Vor kurzem habe ich ja bereites über meine kleine „Odyssee“ geschrieben bzgl. der Laufzeitfehler und meine Fehlerbehebung.

Meine Lösung in der Prozedur spGetPerfCountersFromPowerShell die Kommas mit Punkten zu tauschen funktioniert soweit auch ganz gut und der entsprechende SQL Agent Job „DBA – PerfMon Counter Collection“ läuft in der Regel auch fehlerfrei.

ABER: manchmal halt leider doch noch nicht. Zwischendurch fällt der Job immer noch auf die Nase, dann aber mit dem Fehler

Cannot convert a char value to money. The char value has incorrect syntax.

Natürlich habe ich hier auch wieder ein wenig geknobelt. Dafür hab ich mir die  Variante der Prozedur wieder eingestellt, wo die Konvertierung zu varchar (20) erfolgt. Macht eigentlich keinen Sinn, da ja die Reports nachgelagert nicht zwingend funktionieren.  Aber wenn ich nun einen convert char to money Fehler habe, dann scheint ja auf einmal sich irgendein Buchstabe oder sonstiges Zeichen eingeschlichen zu haben.

Und dem ist auch wirklich so:

Die Abfrage der Performancecounter liefert hin und wieder so kleine Werte zurück, dass das Windows System dann einfach eine Zahl mit einem negativen Exponenten zurückgibt. Dadurch, dass wir nun einen Buchstaben in unseren Datensatz drin haben können wir nicht zum Datentyp Money konvertieren.

Jetzt hatte ich mir überlegt, ob man sich das noch irgendwie schön rechnen soll. Der Wert 8,9999918995165E-05 zum Beispiel ist ja  8,9999918995165 / 100000. Das ergibt die wahnsinnig hohe Zahl von 0,000089999918995165. Wenn man das jetzt zum Datentyp Money konvertiert, welcher nur 4 Dezimalstellen hat, dann landen wir bei 0,0001 (bei dem Datentypen erfolgt eine Rundung). Da hab ich mir überlegt, ob es wirklich Sinn macht so einen Wert wegzuschreiben oder dann nicht einfach zu sagen der Wert ist 0.

Welchen Aufwand man betreiben muss, um den passenden Zahlenwert zur Laufzeit zu bekommen hab ich mal kurz nachgestellt:

  DECLARE @wert VARCHAR (50)
  SET @wert = '8,9999918995165E-05'

  SELECT @wert AS Ausganswert, LEFT(@wert,5)   AS Zusammenstauchen, 
  REPLACE (LEFT(@wert,5),',','.')  AS KommaRaus, 
  CAST(REPLACE (LEFT(@wert,5),',','.')  AS DECIMAL(5,4)) AS MachmalDezimal,
  CAST(REPLACE (LEFT(@wert,5),',','.')  AS DECIMAL(5,4)) / 100000 AS Exponentwegrechnen, 
  CONVERT (money,CAST(REPLACE (LEFT(@wert,5),',','.')  AS DECIMAL(5,4)) / 100000) AS Zielwert

(Vielleicht gibt es hier ja auch einen eleganteren Weg und ich war hier betriebsblind.)

Daher mein pragmatischer Ansatz in der entsprechenden Prozedur:

CASE
 WHEN [ct2].[output] LIKE '%E-%'
 THEN '0'
 ELSE CONVERT(MONEY, REPLACE([ct2].[output], ',', '.'))
 END AS [CounterValue]

Dies ist ggf. ein klein wenig geschummelt, aber den Reports macht es an der Stelle nichts aus, wenn ein Wert 0,0001 oder 0 ist.

Wer meine neue Variante ausprobieren möchte, der wird auf Github fündig. https://github.com/DiHo78/tigertoolbox/tree/DiHo78-TT-SQLPerformanceBaseline-ProcedureFix?files=1

Ich würde mich über Tester freuen.