Der Resource Governor wurde in SQL Server 2008 eingeführt und ist eine Funktion in SQL Server, die es ermöglicht, den Ressourcenverbrauch des Systems mit Hilfe einer benutzerdefinierten Logik zu steuern.

Insbesondere im Hinblick auf die durch den SharePoint – Suchdienst beanspruchten Ressourcen (CPU / RAM) erweist sich dieses als äußerst nützlich und sollte auf Ebene des SQL Servers konfiguriert werden.

Nomenklaturen in diesem Zusammenhang:

Ressourcenpools

Ressourcenpools stellen die physischen Ressourcen des Servers dar, d.h. CPU und Speicher. Jede Ressource hat einen Mindestwert und einen Höchstwert. Der Mindestwert ist der Wert, den der Ressourcen-Governor dem Ressourcen-Pool garantiert (d.h. diese Ressourcen werden nicht mit anderen Ressourcen-Pools geteilt) und der Höchstwert ist der Maximalwert (der mit anderen Pools geteilt werden kann). Standardmäßig erstellt SQL Server zwei Ressourcenpools: den internen und den Standardpool. Der interne Pool ist der, den SQL Server selbst verwendet. Ressourcenpools können mit T-SQL oder mit dem SQL Server Management Studio erstellt werden.

Workload Groups

Jeder Ressourcenpool kann eine oder mehrere Workload-Gruppen haben, und die Workload-Gruppen sind der Ort, an den die Sitzungen gesendet werden (durch den Classifier, siehe unten). Jeder Workload-Gruppe kann eine Reihe von Richtlinien zugewiesen werden und sie kann zur Überwachung verwendet werden. Workload-Gruppen können von einem Ressourcenpool in einen anderen verschoben werden. Workload-Gruppen können mit T-SQL oder mit dem SQL Server Management Studio erstellt werden.

Klassifizierung

Die Klassifizierung von Anfragen/Sitzungen wird von der Klassifizierungsfunktion vorgenommen. Die Klassifizierungsfunktion (es kann nur eine geben) verarbeitet die Klassifizierung eingehender Anfragen und sendet sie an eine Workload-Gruppe unter Verwendung Ihrer eigenen Logik. Die Klassifizierungsfunktion kann nur mit T-SQL erstellt werden!

Am Beispiel des Suchdienstes und der damit im Zusammenhang stehenden Suchdatenbanken (SQL) stellt sich das Ganze nun wie folgt dar:

USE master

GO CREATE RESOURCE POOL SharePoint_Search_DB_Pool WITH ( MAX_CPU_PERCENT = 10, MIN_CPU_PERCENT = 0 )

GO CREATE RESOURCE POOL SharePoint_Search_DB_Pool_OffHours WITH ( MAX_CPU_PERCENT = 80, MIN_CPU_PERCENT = 0 )

GO

Hier setzen wir einen Maximalwert von 10 % der CPU Leistung und einen Maximalwert von 80%.

Aber warum 2 Pools?

Ganz einfach: Wir möchten hier unterscheiden können und je nach Uhrzeit (kommt gleich) verschiedene Maximalwerte garantieren.

Workload Groups

CREATE WORKLOAD GROUP SharePoint_Search_DB_Group WITH ( IMPORTANCE = MEDIUM ) USING SharePoint_Search_DB_Pool GO

CREATE WORKLOAD GROUP SharePoint_Search_DB_Group_OffHours WITH ( IMPORTANCE = LOW ) USING SharePoint_Search_DB_Pool_OffHours GO

Um die Konfiguration bis zu diesem Punkt zu aktivieren, setzen wir folgenden T-SQL ab:

ALTER RESOURCE GOVERNOR RECONFIGURE GO

Klassifizierung

CREATE FUNCTION fn_SharePointSearchClassifier()
RETURNS sysname
WITH SCHEMABINDING
AS
BEGIN
	DECLARE @time time
	DECLARE @start time
	DECLARE @end time
	
	SET @time = CONVERT(time, GETDATE())
	SET @start = CONVERT(time, '22:00')
	SET @end = CONVERT(time, '05:00')
	IF PATINDEX('%search%',ORIGINAL_DB_NAME()) > 0 
	BEGIN 
		IF @time > @start AND @time < @end 
		BEGIN
			RETURN N'SharePoint_Search_DB_Group_OffHours'
		END
		RETURN N'SharePoint_Search_DB_Group'
	END
	RETURN N'default'
END
GO

Das sieht schon etwas komplexer aus. Was passiert genau. Da der Classifier unterscheiden soll, zu welchen Uhrzeiten Anfragen an welche Workload gruppe gesendet werden sollen, geben wir die entsprechenden Uhrzeit an, zu welchen jeglicher Verkehr die Search Datenbanken betreffend an die “OffHour” Gruppe gesendet werden sollen. Die OffHour Gruppe gehört zum Pool SharePoint_Search_DB_Group_OffHours und stellt 80% der CPU Leistung bereit. 😉

Das ist die Zeit, in der in der Regel keine oder aber zumindest wenig Anfragen durch User oder die Dienstanwendung gesendet werden. Über die PATIndex Abfrage filtern wir Anfragen explizit für alle Datenbanken raus, die SEARCH im Namen tragen. Alle anderen Datenbankanfragen (Userdatenbanken) gehen an den Standardpool!

Je nach Anforderung kann jedoch die Classifier Definition im Detail angepasst werden.

Ob der Einsatz des Resource Governors sinnvoll ist, entscheidet letzten Endes die verwendete Anwendung und die damit einhergehende Datenhaltung und Abfragelogik. Durch eine falsche Konfiguration kann man das Ganze natürlich auch ins Gegenteil umkehren und die Abfrageperformance des SQL Servers in die Knie zwingen. Hier ist also Vorsicht und vor allem eine vorhergehende Analyse der eingesetzten Anwendung erforderlich.