1. 1
DigiComp Academy AG
SQLDAY 31.05.2012
Grundprinzipien der SQL Server
Administration

2. 2
Alexander Jahn
MS SQL Server Trainer und
Consultant seit 1996
IT – Seminare und Projekte
von KMU bis Konzern

3. 3
Zeitlicher Rahmen
10:00 Uhr – 10:45 Uhr

4. 4
Grundprinzipien der Microsoft
SQL Server Administration

5. 5
Datenbanksicherung
DB Konsistenzprüfung
DB Statistiken
Indexwartung
Zugriffssicherheit

6. 6
Wer sichert ist feige  !
Spass !

7. 7
Wer nicht sichert ?
KrollOntrack Datenwiederherstellung
freut sich auf Sie 
Wiederherstellung der Daten einer 500 GB
Festplatte ca. 5000 Euro
RAID um ein Vielfaches teurer

8. 8
Welche Risiken gibt es einen Datenverlust zu erlangen?
n Anwenderfehler n Ersetzen oder Ausbilden
n Hardwareausfall n Spiegelung + Sicherung
n Diebstahl n Spiegelung + Sicherung
n Naturkatastrophen n Spiegelung + Sicherung
n Replikation wäre eine Alternative

9. 9
Welche Datenbanken müssen gesichert werden ?
Das Sichern meiner Benutzerdatenbanken wird schon reichen !!
Nein ! Das ist nicht ausreichend !
n Master – Datenbank n Logins
n Info zu Benutzerdatenbanken
n MS SQL Server Konfiguration
n MSDB – Datenbank n Jobs, Alerts, Operators, Jobhistory
n Model – Datenbank n Vorlage (Muss jedoch immer
gesichert werden. Eindeutige SID)
n Tempdb n Nein !
n ReportServer - Datenbank n Ja ! Reports

10. 10
Welche Sicherungsmethoden stehen zur Verfügung ?
n Full – Backup (Nicht unbedingt jeden Tag)
Bitte nicht nur durchführen (+Log Backup) (eventuell DB – Option „SIMPLE“)
n Differential Backup (Zusätzlich oder im Wechsel mit Fullbackup)
n Log – Backup (häufig bis sehr häufig aber mind. 1 x pro Tag)
n File or Filegroup Backup
n Wozu die Option „with copy_only“ ?

11. 11
Wie häufig soll gesichert werden ?
• Wie viele Daten dürfen max. verloren gehen ?
• 1 Monat -> Sicherung
• 1 Woche -> Sicherung
• 1 Tag -> Sicherung
• 1 Stunde -> Sicherung
• Einige Minuten -> Sicherung
• <= 1 Minute
• -> Sicherung ist nicht mehr ausreichend
• Hochverfügbarkeit, Replikation, Log Shipping oder
noch besser
• ALWAYS ON ! (Ich sehe Sie in meiner Session !) 

12. 12
Was ist noch zu beachten ?
Immer eine Sicherungsstrategie !
n Was soll gesichert werden ?
p Alles bis auf Tempdb !!
n Wann soll gesichert werden ?
p (Morgens halb Zehn in Deutschland ϑ)
p Zeitfenster (meistens Nachts !)
n Wohin soll gesichert werden ?
p SAN, Band..
n Wie oft soll gesichert werden ?
p Individuell
n Wer ist zuständig für die Sicherung ?
p Bitte nicht nur 1 Person. Jeder braucht mal Urlaub !

13. 13
Wofür kann eine Datenbanksicherung noch verwendet
werden ?
n Kopie zum Testen
n Zur Vorbereitung einer Migration
n Für regelmäßige Auswertungen (Reports)
n Zur Fehlersuche durch die Administratoren oder den Hersteller der Client -
Anwendung

14. 14
Noch Fragen zum Thema
Datenbanksicherung ?

15. 15
Datenbankkonsistenzprüfung
Was passiert hier ?
n DBCC CHECKDB
p Führt die folgenden Anweisung nacheinander aus
p DBCC CHECKCATALOG
p DBCC CHECKALLOC
p DBCC CHECKTABLE (Für jede Tabelle in der Datenbank)

16. 16
Datenbankkonsistenzprüfung (Was passiert)
DBCC
CHECKCATALOG
Überprü(
die
Katalogkonsistenz
innerhalb
der
angegebenen
Datenbank.
Die
Datenbank
muss
online
sein..

17. 17
Datenbankkonsistenzprüfung (Was passiert)
DBCC
CHECKALLOC
Überprü(
die
Konsistenz
von
Strukturen
der
Speicherplatzzuordnung
für
eine
bes>mmte
Datenbank.
n REPAIR_ALLOW_DATA_LOSS Versucht, die gefundenen Fehler zu
beheben. Diese Reparaturen können zu Datenverlusten führen.
REPAIR_ALLOW_DATA_LOSS ist die einzige Option, die die Reparatur von
Zuordnungsfehlern ermöglicht.
n TABLOCK Bewirkt, dass der DBCC-Befehl eine exklusive Datenbanksperre
erhält.

18. 18
Datenbankkonsistenzprüfung (Was passiert)
DBCC
CHECKTABLE
Überprü(
die
Integrität
aller
Seiten
und
Strukturen,
aus
denen
die
Tabelle
oder
indizierte
Sicht
besteht
p REPAIR_ALLOW_DATA_LOSS Versucht, alle gemeldeten Fehler zu
beheben.Diese Reparaturen können zu Datenverlusten führen.
p REPAIR_FAST Die Syntax wird nur aus Gründen der Abwärtskompatibilität
bereitgestellt .Es werden keine Reparaturaktionen ausgeführt.
p REPAIR_REBUILD Führt Reparaturen aus, bei denen kein Datenverlust
möglich ist.Dazu können schnelle Reparaturen gehören, wie z. B. das
Reparieren fehlender Zeilen in nicht gruppierten Indizes, als auch
zeitaufwändigere Reparaturen, wie das Neuerstellen von Indizes.
REPAIR_REBUILD behebt keine Fehler, die FILESTREAM-Daten betreffen

19. 19
Datenbankkonsistenzprüfung
Wann
und
wie
o6
soll
das
erfolgen
p Individuell
p Wenn Fehler auftreten
p Bitte
Beachten Sie , dass der Vorgang sehr lange dauern kann !
p DBCC CHECKDB sollte für jede Benutzer(Datenbank ) getestet
werden
p Eventuell in einen Wartungsplan einbauen

20. 20
Statistiken
Was
ist
das
denn
?
p Gibt
dem Abfrageoptimierer Information über die Dichte und
Verteilung der Daten innerhalb einer Spalte in einer Tabelle
p Statistiken werden automatisch aktualisiert (nach 20% veränderten
Daten)
p Statistiken können zusätzlich manuell aktualisiert werden
p Auto Update Statistics kann ausgeschaltet werden
Durch das Update von Statistiken wird sichergestellt, dass Abfragen
anhand aktueller Statistiken neu kompiliert werden. Dies führt jedoch
dazu, dass Abfragen neu kompiliert werden
Kann in einen Wartungsplan eingebaut werden

21. 21
Noch Fragen zum Thema Statistiken ?

22. 22
Indizes
Was
ist
das
denn
?
n Wer das nicht weiß, der hat noch nie ein Buch gelesen
n Cluster und NonClustered Indexes, Fulltext - Indexes

23. 23
Indizes
Wieso
denn
eine
Wartung
für
Indizes?
n Wird irgendwann fragmentiert sein
n Sollte defragmentiert werden
p Bei einer Fragmentierung < 30 % „Alter Index … reorganize
p Bei einer Fragmentierung > 30 % „Alter Index…. Rebuild
n Einen vernünftigen „Fillfactor“ angeben, um das erneute
Fragmentieren hinauszuzögern
n Kann in einen Wartungsplan eingebaut werden !

24. 24
Noch Fragen zum Thema Indizes ?

25. 25
Wartungspläne
Wann
soll
ich
einen
Wartungsplan
verwenden
n Bei einer relativ kleinen Anzahl von Servern und einer relativ großen
Anzahl von Datenbanken

26. 26
Wartungspläne
Welche
Aufgaben
sollen
im
Wartungsplan
mit
aufgenommen
werden
?
n Datenbankkonsistenzüberprüfung (aber nicht jeden Tag)
n Datenbanksicherung (Full und Log – Backup)
p (Falls
etwas schief läuft beim Index – Task)
n Index – Neuerstellung
n Datenbanksicherung
n Update Statistics (eventuell)
n WartungsCleanup Task (um alte Sicherungsfiles zu löschen)

27. 27
Noch Fragen zum Thema Wartungspläne?

28. 28
Login Sicherheit
Wie
ist
diese
festzulegen
?
n Legen Sie den Authentifizierungsmodus fest (Mixed oder Windows)
n Erstellen Sie die nötigen Admin - Logins
n Erstellen Sie die nötigen Anwender – Logins
n Weisen Sie bestimmten Anwendern zusätzliche Rechte zu
p (entweder
direkt oder über Gruppenzugehörigkeiten)
p Erstellen Sie eventuell eigene Server – Rollen (Ja ! Das geht jetzt)
n Erstellen Sie in den Datenbanken die nötigen Database – User und
eventuell Datenbankgruppen
n Weisen Sie den Datenbank Benutzern oder Gruppen in den
Datenbanken Benutzerberechtigungen (Select, Insert, Update, Delete
zu)

29. 29
Login Sicherheit
Weitere
Sicherheitsüberlegungen
n Anwendungsrollen ?
n Verschlüsselung
n Zertifikate
n Firewall – Einstellungen
n …

30. 30
Noch Fragen zum Thema Sicherheit ?

31. 31
Was gilt es sonst noch zu beachten
n Trennen Sie Datenbankdateien von den Log - Dateien
n Legen Sie die Datenbank Tempdb auf ein separates Laufwerk
n Bei mehreren Prozessoren mehrere TempDB – Data Files
n Legen Sie Richtlinien fest: Kennwörter, Objektnamen
n Achten Sie darauf das der Owner der Datenbank der „SA“ ist
n Bei einer großen Anzahl an Servern und mehreren Instanzen
wenn möglich gleiche Instanznamen verwenden.
Verwenden Sie die gleichen Ports (1433, 52388…)

32. 32
Sonst noch irgendwelche Fragen ?

33. 33
Danke für Ihre Aufmerksamkeit !