Digicomp sqlday admin

767 Aufrufe

Veröffentlicht am

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
767
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
254
Aktionen
Geteilt
0
Downloads
2
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Digicomp sqlday admin

  1. 1. 1 DigiComp Academy AG SQLDAY 31.05.2012 Grundprinzipien der SQL Server Administration
  2. 2. 2 Alexander Jahn MS SQL Server Trainer und Consultant seit 1996 IT – Seminare und Projekte von KMU bis Konzern
  3. 3. 3 Zeitlicher Rahmen 10:00 Uhr – 10:45 Uhr
  4. 4. 4 Grundprinzipien der Microsoft SQL Server Administration
  5. 5. 5 Datenbanksicherung DB Konsistenzprüfung DB Statistiken Indexwartung Zugriffssicherheit
  6. 6. 6 Wer sichert ist feige  ! Spass !
  7. 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. 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. 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. 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. 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. 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. 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. 14 Noch Fragen zum Thema Datenbanksicherung ?
  15. 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. 16 Datenbankkonsistenzprüfung (Was passiert) DBCC  CHECKCATALOG   Überprü(  die  Katalogkonsistenz  innerhalb  der  angegebenen   Datenbank.  Die  Datenbank  muss  online  sein..  
  17. 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. 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. 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. 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. 21 Noch Fragen zum Thema Statistiken ?
  22. 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. 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. 24 Noch Fragen zum Thema Indizes ?
  25. 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. 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. 27 Noch Fragen zum Thema Wartungspläne?
  28. 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. 29 Login Sicherheit Weitere  Sicherheitsüberlegungen     n  Anwendungsrollen ? n  Verschlüsselung n  Zertifikate n  Firewall – Einstellungen n  …
  30. 30. 30 Noch Fragen zum Thema Sicherheit ?
  31. 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. 32 Sonst noch irgendwelche Fragen ?
  33. 33. 33 Danke für Ihre Aufmerksamkeit !

×