Regelmäßige Wartungsarbeiten

Wie alle komplexen Systeme benötigt auch der SQL Server regelmäßige Wartungsarbeiten um effizient zu arbeiten.

Hier gibt es im Internet bereits viele Beispiele welche Wartungen man machen sollte. Die für mich beste Adresse für den SQL Server sind die Skripte von Ola Hallengren https://ola.hallengren.com/.

Auf seiner Seite findet man ein TSQL Skript welche alle sinnvollen Wartungen als SQL Server Agent Job erzeugt. Hat man das Skript auf seinem SQL Server ausgeführt findet man im SQL Server Agent die entsprechenden Jobs. Für diese Jobs ist aber noch kein Zeitplan hinterlegt. Diese muss man als DBA (Database Administrator) selber anlegen. Aber auch hier kann man sich die Arbeit über das PowerShell Modul dbatools https://dbatools.io/ erleichtern.

über das Cmdlet New-DBaAgentSchedule kann man leicht die entsprechenden Zeitpläne anlegen. Ich verwende für die Zeitpläne immer gleichen Namen wie auch der eigentliche Job hat. Aber da Namen ja Schall und Rauch und können beliebig verändert werden.

In folgenden habe ich mal ein Beispiel zusammengestellt wie man für die Hallengren Jobs entsprechende Zeitpläne erstellt und anschließend dem Agent Job zugewiesen. Ob die Zeitpläne für einen selber passen muss aber jeder für sich entscheiden und ggf. entsprechend anpassen.

#Wartungszeitpläne für Hallengren

#CommandLog Cleanup
New-DbaAgentSchedule -SqlInstance $Server -FrequencyType Weekly -FrequencyInterval Saturday -FrequencySubdayType Time  -FrequencyRelativeInterval First -FrequencyRecurrenceFactor 0 -StartTime 201000 -EndTime 234801 -Schedule "CommandLog Cleanup Samstag um 20:10 Uhr" -Force
Set-DbaAgentJob -SqlInstance $Server -Schedule "CommandLog Cleanup Samstag um 20:10 Uhr" -Job "CommandLog Cleanup"

#DatabaseIntegrityCheck - SYSTEM_DATABASES
New-DbaAgentSchedule -SqlInstance $Server -FrequencyType Weekly -FrequencyInterval Sunday -FrequencySubdayType Time  -FrequencyRelativeInterval First -FrequencyRecurrenceFactor 0 -StartTime 080000 -EndTime 234801 -Schedule "DatabaseIntegrityCheck - SYSTEM_DATABASES Sonntag um 8:10 Uhr" -Force
Set-DbaAgentJob -SqlInstance $Server -Schedule "DatabaseIntegrityCheck - SYSTEM_DATABASES Sonntag um 8:10 Uhr" -Job "DatabaseIntegrityCheck - SYSTEM_DATABASES"

#DatabaseIntegrityCheck - USER_DATABASES
New-DbaAgentSchedule -SqlInstance $Server -FrequencyType Weekly -FrequencyInterval Sunday -FrequencySubdayType Time  -FrequencyRelativeInterval First -FrequencyRecurrenceFactor 0 -StartTime 083000 -EndTime 234801 -Schedule "DatabaseIntegrityCheck - USER_DATABASES Sonntag um 8:30" -Force
Set-DbaAgentJob -SqlInstance $Server -Schedule "DatabaseIntegrityCheck - USER_DATABASES Sonntag um 8:30" -Job "DatabaseIntegrityCheck - USER_DATABASES"

#Output File Cleanup
New-DbaAgentSchedule -SqlInstance $Server -FrequencyType Weekly -FrequencyInterval Saturday -FrequencySubdayType Time  -FrequencyRelativeInterval First -FrequencyRecurrenceFactor 0 -StartTime 201000 -EndTime 234801 -Schedule "Output File Cleanup Samstag um 20:20" -Force
Set-DbaAgentJob -SqlInstance $Server -Schedule "Output File Cleanup Samstag um 20:20" -Job "Output File Cleanup"

#sp_delete_backuphistory
New-DbaAgentSchedule -SqlInstance $Server -FrequencyType Weekly -FrequencyInterval Saturday -FrequencySubdayType Time  -FrequencyRelativeInterval First -FrequencyRecurrenceFactor 0 -StartTime 203000 -EndTime 234801 -Schedule "sp_delete_backuphistory Samstag um 20:30 Uhr" -Force
Set-DbaAgentJob -SqlInstance $Server -Schedule "sp_delete_backuphistory Samstag um 20:30 Uhr" -Job "sp_delete_backuphistory"

#sp_purge_jobhistory
New-DbaAgentSchedule -SqlInstance $Server -FrequencyType Weekly -FrequencyInterval Saturday -FrequencySubdayType Time  -FrequencyRelativeInterval First -FrequencyRecurrenceFactor 0 -StartTime 204000 -EndTime 234801 -Schedule "sp_purge_jobhistory Samstag um 20:40 Uhr" -Force
Set-DbaAgentJob -SqlInstance $Server -Schedule "sp_purge_jobhistory Samstag um 20:40 Uhr" -Job "sp_purge_jobhistory"

 

Advertisements

Gespiegelte Sicherungsmediensätze

Der SQL Server bietet die Möglichkeit ein Backup gleichzeitig an zwei getrennten Orten zu erstellen. Laut Microsoft soll sich durch diese Möglichkeit die Zuverlässigkeit erhöhen während gleichzeitig die Auswirkungen von Funktionsstörungen verringert werden sollen.

Ein Backup mit einem gespiegelten Mediaset würde man über TSQL wie folgt erstellen

BACKUP DATABASE DemoDB
TO TAPE = '\\.\tape0' 
MIRROR TO TAPE = '\\.\tape1'
with format

Als Ziel kann man sowohl Festplatten oder Bandlaufwerke nutzen aber nicht beides gleichzeitig.

Die Verwendung dieses Features macht aber für Festplatten als Backup Ziel kaum Sinn und sollte nur für Bandsicherungen verwendet werden. Bei den Bandlaufwerken und Tapes muss man auf gleiche Modelle setzen da sonst das Backup mit dem Fehlercode 3212 fehlschlägt.

Zudem gibt es praktische Einschränkungen welche man bei der Verwendung der Funktion beachten sollte.

  • Die langsamste Komponente beider Sicherungsziele bestimmt die Backupleistung.
  • Ist ein Sicherungsziel nicht betriebsbereit oder fällt während der Sicherung aus scheitert das Backup komplett.

Zusammenfassend bietet das Feature nur Schutz gegen den Verlust oder Zerstörung eines Sicherungsbandes. Wer seine Backups auf eine Festplatte (lokal oder auf einem Fileserver) erstellt hat über die Powershell deutlich besserer Möglichkeiten auf Ausfälle zu reagieren und sollte die Gespiegelte Sicherungsmediensätze nicht nutzen.

Weitere Informationen findet man bei Microsoft unter

https://docs.microsoft.com/de-de/sql/relational-databases/backup-restore/mirrored-backup-media-sets-sql-server?view=sql-server-2014

MSSQL Server – Das Copy-Only Backup

Wer sich mit dem Thema Backup im Microsoft SQL Server beschäftigt ist mit ziemlicher Sicherheit schon über das Copy-Only Backup (zu Deutsch: Kopie Sicherung) gestoßen. Was dieser Backup Type bedeutet und wo man ihn einsetzten kann/sollte gehen die Meinungen auseinander. Aus diesem Grund möchte ich den technischen Hintergrund und die Unterschiede zwischen „Normalen“ Backups und den Copy-Only Backups vorstellen und anschließend zeigen wann man diese sinnvoll einsetzen kann. Weiterlesen

Backup und Restore Tests

Oder: Vertrauen ist gut, Kontrolle ist besser!

Welcher Windows Administrator kenn diese Situation nicht? Man ist zwar eigentlich kein Datenbankadministrator (DBA) aber zur der Anwendung gehört halt ein SQL Server und einen echten DBA gibt es halt nicht. Also muss man sehen, dass die Datenbank läuft. Genau so wichtig wie ein laufender Server ist gerade bei Datenbanken, dass man die Daten im Notfall auch wiederherstellen kann. Dabei muss man immer wieder feststellen, dass das Backup noch recht gut überwacht und kontrolliert wird aber die Wiederherstellung so gut wie nie getestet ist.

Es gilt der Spruch:

Was interessiert mich das erfolgreiche Backup, der erfolgreiche Restore ist mir viel wichtiger!

Weiterlesen

SQL Express – Sicherung mit der Powershell

11.11.2016 Anleitung für die Aufgabenplanung ergänzt

15.12.2017 Link zum Skript geändert

Die SQL Express Edition erfreut sich gerade für kleine Anwendungen großer Beliebtheit da sie keine Lizenzkosten verursacht. Diese Beliebtheit dürfte sogar noch steigen seit dem Microsoft mit dem Service Pack 1 für den SQL Server 2016 viele Funktionen der Standard und sogar Enterprise Edition nun auch in der Express Edition verfügbar macht.

Nun stehen hier auch viele der InMemory Features und Sicherheitsfunktionen wie AlwaysEncrypted auch in der Express Edition bereit. Weiterlesen