COMPAREX AG
Nintex Workflow History Clean Up mit Performance Rückgewinnung (Teil 2): Step-by-Step-Anleitung

Nintex Workflow History Clean Up mit Performance Rückgewinnung (Teil 2): Step-by-Step-Anleitung

Aufgrund von zunehmenden Datenbankgrößen kann die Performance von Nintex Workflow für SharePoint abnehmen. Im ersten Blogbeitrag zu dem Thema haben wir bereits Ursachen und Tools zur Bereinigung vorgestellt. In diesem Beitrag möchten wir den Aktionsplan zur Bereinigung und Performance-Optimierung von Nintex Workflow genau vorstellen.

Ein Blogbeitrag von Daniel Mönch, Senior Consultant SharePoint und Office 365 Competence Team


Wiederholend aus dem ersten Blogbeitrag der notwendige Aktionsplan nochmals im Überblick:

  • Stellen Sie sicher, dass Sie über ein vollständiges Backup der SharePoint Farm verfügen, bevor Sie die nachfolgenden Maßnahmen durchführen (Sicherheitsnetz)
  • Reduzierung und/oder Abschaltung von Nintex Workflow Verbose Logging (Global)
  • Bereinigung der Nintex Datenbank-Tabelle „dbo.workflowlog“ (in allen Nintex Workflow-Datenbanken)
  • Re-Indexierung und Defragmentierung der Nintex Datenbank (Fragmentierungs-Schwellwert 30%, alle Nintex Datenbanken)
  • Bereinigung von SharePoint Workflow History Listen (alle SharePoint Listen des Typs “Workflow History”)
  • Bereinigung der Nintex Datenbank Tabelle „dbo.workflowprogress“ (in allen Nintex Workflow Datenbanken)

Nintex Workflow Optimierung - Schritt 1 (Verbose Logging)

Nintex Workflow Verbose Logging häuft sehr viele Daten an. Um dem zukünftig vorzubeugen, reduzieren wir zunächst die Aufbewahrungszeit dieser Log-Daten auf nur noch x Tage. Hierbei steht das x für einen Wert in Tagen, die Sie für angebracht halten, diese Detaildaten aufzubewahren. In den meisten Fällen wird dieses Logging während der Entwicklung von Nintex Workflows zum Debugging durch den Entwickler selbst genutzt. Ein straffer Wert hierfür sind bspw. 2 Tage.

Zum Festlegen dieses Aufbewahrungszeitraums von Verbose Logs wechseln Sie bitte in die SharePoint Zentraladministration > Nintex Workflow > Global Settings. Dort befindet sich die Option „Allow verbose workflow logging“, die Sie (wie in der Abbildung beispielhaft für 2 Tage gezeigt) konfigurieren:

Abb. 1: Beispielhafte Einstellung Nintex Workflow, Quelle: COMPAREXAbb. 1: Beispielhafte Einstellung Nintex Workflow, Quelle: COMPAREX

Um Verbose Logging komplett zu unterbinden, setzen Sie die Option „Allow verbose workflow logging“ einfach auf „No“.

Speichern Sie Ihre Konfiguration abschließend mittels des OK-Buttons. Danach muss ein IISRESET auf allen WFE Servern der SharePoint Farm ausgeführt werden!

Nintex Workflow Optimierung - Schritt 2 (Tabelle dbo.workflowlog)

Die Bereinigung der Nintex Datenbanktabelle „dbo.workflowlog“ erfolgt mittels SQL Query.

Öffnen Sie das SQL Management Studio (als Farmadmin) und verbinden sich zur SQL Instanz Ihrer SharePoint Farm.

Setzen Sie folgende SQL-Query für jede Ihrer Nintex Workflow Datenbanken ab. Ersetzen Sie vorher den Platzhalter <Datenbank> durch den Namen der Datenbank und den Platzhalter <INT> durch die Anzahl der Tage (empfohlen ist der Wert 0), für die Sie die Log-Daten behalten wollen:


USE [<Datenbank>]
GO

DECLARE @return_value int
EXEC @return_value=[dbo].[PurgeVerboseLogs]
$DAYSTOKEEP=<INT>
SELECT 'Return Value'=@return_value"
GO

Quelle: Nintex 

Nintex Workflow Optimierung - Schritt 3 (Defragmentierung)

Die Defragmentierung nutzt eine herstellereigene SQL Prozedur. Die Defragmentierung und Re-Indexierung der Nintex Datenbank erfolgt mittels SQL Query.

Öffnen Sie das SQL Management Studio (als Farmadmin) und verbinden sich zur SQL Instanz Ihrer SharePoint Farm.

Setzen Sie folgende SQL Query für jede Ihrer Nintex Workflow Datenbanken ab. Ersetzen Sie vorher den Platzhalter <Datenbank> durch den Namen der Datenbank:

USE <Datenbank>
SET NOCOUNT ON
DECLARE @objectid int
DECLARE @indexid int
DECLARE @partitioncount bigint
DECLARE @schemaname sysname
DECLARE @objectname sysname
DECLARE @indexname sysname
DECLARE @partitionnum bigint
DECLARE @partitions bigint
DECLARE @frag float
DECLARE @command varchar(8000)
-- ensure the temporary table does not exist
IF EXISTS (SELECT name FROM sys.objects WHERE name = 'work_to_do')
    DROP TABLE work_to_do
-- conditionally select from the function, converting object and index IDs to names.
SELECT
    object_id AS objectid,
    index_id AS indexid,
    partition_number AS partitionnum,
    avg_fragmentation_in_percent AS frag
INTO work_to_do
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, 'LIMITED')
WHERE avg_fragmentation_in_percent > 10.0 AND index_id > 0
-- Declare the cursor for the list of partitions to be processed.
DECLARE partitions CURSOR FOR SELECT * FROM work_to_do
-- Open the cursor.
OPEN partitions
-- Loop through the partitions.
FETCH NEXT
   FROM partitions
   INTO @objectid, @indexid, @partitionnum, @frag
WHILE @@FETCH_STATUS = 0
    BEGIN
        SELECT @objectname = o.name, @schemaname = s.name
        FROM sys.objects AS o
        JOIN sys.schemas as s ON s.schema_id = o.schema_id
        WHERE o.object_id = @objectid
 
        SELECT @indexname = name
        FROM sys.indexes
        WHERE  object_id = @objectid AND index_id = @indexid
 
        SELECT @partitioncount = count (*)
        FROM sys.partitions
        WHERE object_id = @objectid AND index_id = @indexid
-- 30 is an arbitrary decision point at which to switch between reorganizing and rebuilding
IF @frag < 30.0
    BEGIN
    SELECT @command = 'ALTER INDEX ' + @indexname + ' ON ' + @schemaname + '.' + @objectname + ' REORGANIZE'
    IF @partitioncount > 1
        SELECT @command = @command + ' PARTITION=' + CONVERT (CHAR, @partitionnum)
    EXEC (@command)
    END
 
IF @frag >= 30.0
    BEGIN
    SELECT @command = 'ALTER INDEX ' + @indexname +' ON ' + @schemaname + '.' + @objectname + ' REBUILD'
    IF @partitioncount > 1
        SELECT @command = @command + ' PARTITION=' + CONVERT (CHAR, @partitionnum)
    EXEC (@command)
    END
PRINT 'Executed ' + @command
FETCH NEXT FROM partitions INTO @objectid, @indexid, @partitionnum, @frag
END
-- Close and deallocate the cursor.
CLOSE partitions
DEALLOCATE partitions
-- drop the temporary table
IF EXISTS (SELECT name FROM sys.objects WHERE name = 'work_to_do')
    DROP TABLE work_to_do

Quelle: Nintex Support 2018

Nintex Workflow Optimierung - Schritt 4 (SP Workflow History Listen)

Die Bereinigung der SharePoint Listen von Typ „Workflow History“ erfolgt optimalerweise mittels eines Power Shell Scripts, das auf einem Web-Frontend-Server der SharePoint Farm vom Farmadministrator ausgeführt wird.

Das Power Shell Skript wird in diesem Artikel nicht abgebildet, sondern vielmehr die notwendigen Aktionsschritte stichpunktartig aufgeführt. Bei diesem Schritt geht es darum, alle Elemente in Workflow History Listen des SharePoints, die älter als x Tage sind, zu entfernen. Der Wert x steht hier bspw. für 365, also 365 Tage (1 Jahr), der auch gleichzeitig die Empfehlung darstellt. Bei Entfernung mit diesem Wert x werden alle Workflow History Elemente, die älter sind als 1 Jahr, aus den Workflow History Listen des SharePoint entfernt. Also auch diejenigen Elemente, deren Workflows bereits länger als ein Jahr laufen und immer noch aktiv sind. Dies schadet einem solchen Workflow jedoch nicht, lediglich die Logeinträge, die er hinterlassen hat und die älter sind als x Tage, entschwinden aus der Historie.

Bitte merken Sie sich diesen x-Wert, da er in Schritt 5 erneut benötigt wird.

Welche Aktionen muss das Power Shell Skript ausführen?

  • Für jede Websitesammlung (ausgenommen der ZA und den MySites) alle Websitesammlungen ermitteln
  • Für jede ermittelte Websitesammlung jedes Web ermitteln
  • Für jedes ermittelte Web jede Liste vom Typ „Workflow History“ ermitteln
  • Für jede ermittelte Liste vom Typ „Workflow History“ jedes Element ermitteln (Achtung! Setzen Sie zum Einsammeln der Elemente eine Query ein, die die Elemente in Batches zu bspw. 1.000 Elementen pro Batch liefert. Sie werden scheitern, wenn Sie versuchen alle Elemente auf einmal einzulesen und Sie mehrere 100K Elemente in der Liste haben.)
  • Für jedes ermittelte Element das letzte Änderungsdatum ermitteln und falls dieses Datum älter ist als x-Wert (in Tagen) das Element löschen

Bitte berücksichtigen Sie, dass dieses Power Shell Skript voraussichtlich nicht mehr als 0,75 Millionen Elemente pro Tag löschen wird. Starten Sie dieses Skript solange neu bis Sie eine Verarbeitungszeit von unter einem Tag erreichen und führen Sie erst danach Schritt 5 durch.

Nintex Workflow Optimierung - Schritt 5 (Tabelle dbo.workflowprogress)

Die Bereinigung der Nintex Datenbank-Tabelle „dbo.workflowprogress“ erfolgt mittels SQL Query.

Öffnen Sie das SQL Management Studio (als Farmadmin) und verbinden sich zur SQL Instanz Ihrer SharePoint Farm.

Setzen Sie folgende SQL Query für jede Ihrer Nintex Workflow Datenbanken ab. Ersetzen Sie vorher den Platzhalter <Datenbank> durch den Namen der Datenbank und den Platzhalter <Datum> durch das Datum, das der Anzahl der Tage x (aus Schritt 4) entspricht. In Schritt 4 war x der Wert 365, so dass Sie das Datum von heute minus 365 Tage für den Platzhalter <Datum> einsetzen. Der Platzhalter <Datum> ist bspw. für das Datum des 03.10.2017 als 2017-10-03 einzusetzen.

USE [<Datenbank>]
GO

DECLARE @return_value int
EXEC @return_value=[dbo].[PurgeWorkflowData]
@state=4, 
@lastActivityDate='<Datum>'
SELECT 'Return Value'=@return_value
GO


Benutzen Sie die gleiche Query erneut, jedoch ändern Sie die Zeile @state=4, in @state=8, um.

Benutzen Sie die gleiche Query erneut, jedoch ändern Sie die Zeile @state=4,
in @state=64, um.

Die einzelnen @state Werte stehen dabei für

   4 … Workflows im Status „Abgeschlossen“
   8 … Workflows im Status „Abgebrochen“
 64 … Workflows im Status „Fehler“

Quelle: Nintex

Vollautomatsche Bereinigung (set and forget)

Die Schritte 1 bis 5 zeigen die durchzuführenden Aktivitäten zur Bereinigung historischer Nintex Workflow Daten alle einzeln auf. Diese Schritte sind zunächst durchzuführen, wirken aber nur bis zum Zeitpunkt der Durchführung. Danach geht die Datenansammlung in Ihrem System aber weiter. Um zu einer Konfiguration der dauerhaften Optimierung und dem dauerhaften Performance-Erhalt zu gelangen, empfiehlt sich folgendes ergänzende Vorgehen:

Schritt 1 bleibt wie gehabt. Stellen Sie das Verbose Logging wunschgemäß ein und belassen Sie es wie eingestellt.

Für die Schritte 2 bis 5 erstellen Sie jeweils ein Power Shell Skript, das jeden Tag per geplantem Task im Task Scheduler startet und die erforderlichen Aktionen innerhalb des gleichen Tages umsetzt.

Unter Berücksichtigung der täglichen Office-Zeiten, in denen die SQL Querys nicht abgesetzt werden sollten, empfiehlt sich folgender Zeitplan:

06:00 Uhr: PS Skript für Schritt 4 (keine Belastung im Betrieb, nur Voraussetzung für Schritt 5)
18:00 Uhr: PS Skript für Schritt 2
20:00 Uhr: PS Skript für Schritt 3
22:00 Uhr: PS Skript für Schritt 5 (muss vor 24 Uhr enden, da sonst keine x-Wert Gleichheit)

Bitte berücksichtigen Sie, dass alle Skripte am gleichen Kalendertag laufen sollten, Sie also die Tagesgrenze von 24 Uhr nicht überschreiten. Die Skripte der Schritte 4 und 5 müssen zwingend am gleichen Tag laufen und auch enden. Hintergrund ist der als x in Tagen Wert in beiden Schritten gleichwertig anzuwendende Wert (vgl. Beschreibung der Schritte 4 und 5). Anderenfalls entstehen Datensatzlooks, die Sie nicht mehr entfernen können (nicht mehr löschbare Datensätze). Berücksichtigen Sie ebenfalls für den Zeitplan bedarfsgerecht Ihre aktuellen Backup-Zeiten von SharePoint und SQL Server.

Ihr nächster Schritt

Sie wünschen eine persönliche Beratung und weitere Informationen über das COMPAREX SharePoint Portfolio? Kontaktieren Sie uns und wir zeigen Ihnen, wie SharePoint in Ihrem Unternehmen erfolgreich eingesetzt werden kann.

Jetzt Kontakt aufnehmen


Aktuell und kostenlos: Nutzen Sie die Erfahrung unserer Consultants

SharePoint-Veranstaltungs- und Webinar-Termine:

28.05.2019 | 10:00 - 11:00 Uhr

kostenfreies Webinar

Mehr Informationen »

Migration von Microsoft SharePoint nach Office 365

Unsere Webinare richten sich in erster Linie an Endkunden. Um an dem Webinar teilzunehmen, benötigen Sie lediglich einen Laptop oder PC, einen Internetzugang und ein Headset oder Telefon. Die Übertragung des Webinars passiert über Ihren Webbrowser.

Diesen Artikel teilen

Artikel vom:
13.12.2018

geschrieben von:

TAGS:
Nintex Workflow, SharePoint

Thema:

Kommentieren sie diesen Artikel...

© COMPAREX AG
Zurück nach oben