SQL-Datenbankwartung

Diese Informationen sollen nur als Leitfaden dienen. Es wird empfohlen, standardmäßige Best Practices der Branche zu befolgen und Empfehlungen von einem erfahrenen Datenbankadministrator einzuholen. Diese Informationen sollten unter Berücksichtigung der allgemeinen Auswirkungen auf die Gesamtumgebung verwendet werden.

Die folgenden Datenbanken müssen gewartet werden:

  • InteractDB

  • InteractCacheDB

  • IadaDB

  • AuthenticationServerDB

  • HubDB

  • AuditDB

  • NotificationCenterDB

  • LicenceManagerDB

  • FileServiceDB

  • EmailServiceDB

  • BluePrismDecisionDB

  • ImsDB

  • FileServiceDB

    • CacheDB wurde ab Hub 4.4 durch FileServiceDB ersetzt.

Allgemeine Empfehlungen für die Datenbankwartung

Folgendes wird empfohlen:

  • Legen Sie das automatische Wachstum für alle Datenbanken korrekt fest. Empfohlene Werte sind 1024 MB für die Datendatei und 2048 MB für das Transaktionslog.
  • Aktualisieren Sie den Wert für das automatische Wachstum, wenn die Größe der Datenbank zunimmt, um die Häufigkeit von Ereignissen mit automatischem Wachstum zu minimieren.

    • Verwenden Sie kein Dateiwachstum in %, sondern legen Sie ein Wachstum um eine feste Anzahl von Megabytes fest.

  • Beseitigen Sie übermäßige Transaktionslog-Dateifragmentierung. Weitere Informationen finden Sie in der Microsoft-Onlinehilfe.
  • Aktivieren Sie die sofortige Dateiinitialisierung. Weitere Informationen finden Sie in der Microsoft-Onlinehilfe.
  • Deaktivieren Sie die automatische Verkleinerung, legen Sie die Seitenüberprüfung für alle Datenbanken auf Prüfsumme fest und aktivieren Sie AUTO_CREATE_STATISTICS und AUTO_UPDATE_STATISTICS. Richten Sie einen regelmäßigen Prozess zur Aktualisierung der Statistiken ein.

    • Zu diesem Zweck können Sie für jede der von Hub und Interact installierten Datenbanken die folgende T-SQL festlegen:

    ALTER DATABASE [Datenbankname] SET AUTO_CLOSE OFF;

    ALTER DATABASE [Datenbankname] SET AUTO_SHRINK OFF;

    ALTER DATABASE [Datenbankname] SET AUTO_UPDATE_STATISTICS ON;

    ALTER DATABASE [Datenbankname] SET AUTO_CREATE_STATISTICS ON;

    ALTER DATABASE [Datenbankname] SET PAGE_VERIFY CHECKSUM;

  • Richten Sie einen regelmäßigen Prozess zum Ausführen von DBCC CHECKDB ein – Es wird empfohlen, dass ein SQL-Agentenauftrag mindestens einmal pro Tag ausgeführt wird, wenn eine geringe oder keine Systemauslastung vorliegt. Die Ergebnisse sollten auf eine Beschädigung hin überprüft werden. Es könnte nützlich sein, SQL-Agentenalarme zu erstellen, um eine Operatorgruppe über die folgenden Fehler zu benachrichtigen:

    • 823 – Hard I/O Corruption

      • (Schwere I/O-Beschädigung)

    • 824 – Soft I/O Corruption

      • (Leichte I/O-Beschädigung)

    • 825 – Read/Retry Corruption

      • (Lese-/Wiederholungsbeschädigung)

    • 9100 – Index Corruption

      • (Indexbeschädigung)

    • Severity 19-25 Errors

    (Fehler mit Schweregrad 19–25)

  • Optimize for ad-hoc workloads = ON (Optimierung für Ad-hoc-Workloads = EIN)

  • Backup compression default = ON (Standardmäßige Backup-Komprimierung = EIN)

  • Backup checksum default = ON (Standardmäßige Backup-Prüfsumme = EIN)

  • Cost threshold for parallelism (Kostenschwelle für Parallelität) – 50 ist ein guter Ausgangspunkt.

  • Max degree of parallelism (Max. Grad der Parallelität) – Hängt von der NUMA-Konfiguration vom SQL Server ab, aber nicht mehr als die Anzahl der Kerne für einen einzigen NUMA-Knoten.

  • Set auto close = ON (Automatisch schließen = EIN)

  • Min Server Memory (Min. Serverspeicher) – Unterschiedlich pro SQL Server, sollte aber festgelegt werden.

  • Max Server Memory (Max. Serverspeicher) – Unterschiedlich pro SQL Server, sollte aber festgelegt werden.

Empfehlungen zur Datenträgerverwendung

Es wird empfohlen, separate Laufwerke für Daten- und Transaktionslogdateien, temporäre Datenbanken und Backups zu verwenden.

Wartungsplan erstellen

Stellen Sie sicher, dass ein Wartungsplan besteht, um regelmäßige Backups durchzuführen. Verwenden Sie den bevorzugten Wartungsplan Ihres Unternehmens zum Sichern von SQL-Datenbanken. Wenn Ihr Unternehmen keinen Wartungsplan hat, wird empfohlen, dass Sie sich über die Best Practices der Branche informieren und einen Wartungsplan auswählen, der die Anforderungen Ihres Unternehmens erfüllt.

Backups erstellen

Backups sollten basierend auf den Recovery Point (RPO) und Recovery Time Objectives (RTO) Ihres Unternehmens geplant werden.

  • RPO – Der Zeitpunkt, für den Sie Ihre Daten nach einem Ausfall wiederherstellen können. Dies entscheidet darüber, wie viele Daten verloren gehen.
  • RTO – Die Dauer der Wiederherstellung Ihrer Daten nach einem Ausfall. Dies entscheidet über den Zeitraum, während dem die Plattform nicht verfügbar ist.

Beim Erstellen eines Backup- und Wiederherstellungsplans für Blue Prism Datenbanken ist es wichtig, die folgenden Punkte zu berücksichtigen und zu implementieren:

  • Definieren Sie RPO und RTO.
  • Verwenden Sie das Wiederherstellungsmodell FULL (Vollständig), um vollständige, differenzielle und Transaktionslog-Backups gemäß Ihrer RPO- und RTO-Konfiguration zu ermöglichen.
  • Verwenden Sie die Optionen WITH CHECKSUM (Mit Prüfsumme) und VERIFYONLY (Nur prüfen) bei allen Backups, um zu überprüfen, ob die Backups in Ordnung sind und bei Bedarf wiederhergestellt werden können.
  • Verwenden Sie die Option WITH COMPRESSION (Mit Komprimierung), um Speicherplatz zu sparen und die Zeit zu reduzieren, die zum Sichern der Datenbanken und optional zum Wiederherstellen benötigt wird.
  • Dokumentieren Sie den Backup- und Wiederherstellungsprozess.
  • Überprüfen Sie, ob Ihre Backups zuverlässig sind, indem Sie regelmäßig testen, ob sie eine Wiederherstellung ermöglichen.

Wie oft Sie diese Backups durchführen sollten, hängt von der Größe Ihres Unternehmens und der Menge und dem Wert der gefährdeten Daten ab.

Es wird empfohlen, dass vollständige Backups während absoluter Ausfallzeiten durchgeführt werden. Inkrementelle Backups können durchgeführt werden, ohne Dienste zu unterbrechen, mit dem Risiko, dass einige Daten verloren gehen.

Indexfragmentierung beheben

Die Datenbank-Indexfragmentierung verschlechtert mit der Zeit die Abfrage-Performance. Um dies zu verhindern, sollten Indizes so häufig neu erstellt werden, wie es die Datenbankausfallzeit zulässt. Auch die Neuerstellung von Indizes nach Backups und/oder Löschungen von großen Datenmengen wird empfohlen. Es wird auch empfohlen, dass Sie Indizes neu erstellen, bevor Sie ein vollständiges Datenbankbackup erstellen, um die Indexfragmentierung im Falle der Wiederherstellung eines vollständigen Backups zu minimieren.

Empfohlene Schwellenwerte für die Neuerstellung/Reorganisation der Indexwartung sind: < 30 % Reorganisation und > 30 % Neuerstellung.

Die Neuerstellung von Datenbankindizes kann so geplant werden, dass sie als Auftrag im Datenbankserver ausgeführt und/oder dem Datenbankwartungsplan hinzugefügt wird. Es wird empfohlen, dass Sie diese Prozesse während Zeiten niedriger Systemaktivität ausführen und dass sie so geplant werden, dass eine Überschneidung mit Backups und der DBCC CHECKDB-Wartung vermieden wird.