Seminar SAP HANA – Multitenant Database Containers und Tenant-Administration

Mehrmandantenbetrieb trennt Datenbanken und Workloads innerhalb eines Systems, erzeugt jedoch eigene Anforderungen an Ports, Ressourcen, Administration, Backup, Monitoring und Lifecycle. Die Schulung baut eine kontrollierte Tenant-Struktur auf und übt den vollständigen Lebenszyklus von Anlage bis Wiederherstellung.

Inhaltsverzeichnis

• Zielsetzung
• Zielgruppe
• Voraussetzungen
• Seminarinhalte
• Praxisübungen
• Methodik

Zielsetzung

• Systemdatenbank und Tenant-Datenbanken sicher voneinander abgrenzen
• Tenants anlegen, konfigurieren, starten, stoppen, verschieben und überwachen
• Ressourcen, Benutzer, Netzwerk, Backup und Zuständigkeiten je Tenant steuern
• Lifecycle- und Störungsszenarien mit klarer System- und Tenant-Perspektive bearbeiten

Zielgruppe

SAP-HANA-Administratoren, SAP-Basis-Teams, Plattformarchitekten, Hosting- und Betriebsverantwortliche sowie technische Consultants.

Voraussetzungen

Grundkenntnisse der SAP-HANA-Administration, Benutzer- und Berechtigungskonzepte sowie Backup/Recovery. Administrativer Laborzugriff ist erforderlich.

Seminarinhalte

1. Schritt 1: MDC-Architektur und Verantwortungen verstehen

   Systemdatenbank, Tenant-Datenbanken, gemeinsame Dienste, eigene Persistenz, administrative Benutzer und Werkzeugkontexte werden in einem Betriebsmodell dargestellt.

2. Schritt 2: Tenant-Design planen

   Anwendungszuordnung, Namensstandard, Portbereiche, Ressourcen, Verfügbarkeit, Backup, Wartungsfenster und Verantwortliche werden für mehrere Tenants festgelegt.

3. Schritt 3: Tenant-Datenbank anlegen

   Name, Systembenutzer, Speicher, Startzustand und technische Parameter werden kontrolliert konfiguriert. Erreichbarkeit und Katalogstatus werden unmittelbar geprüft.

4. Schritt 4: Verbindungen und Netzwerkzugriff steuern

   SQL-Ports, Hostnamen, Zertifikate, Client-Verbindungen und erlaubte Netze werden je Tenant nachvollziehbar eingerichtet.

5. Schritt 5: Benutzer und Rollen je Tenant verwalten

   Systemweite und tenantlokale Zuständigkeiten werden getrennt. Notfallzugang, technische Benutzer und Berechtigungsdelegation werden nach dem Minimalprinzip umgesetzt.

6. Schritt 6: Ressourcen und Workloads begrenzen

   Memory Allocation, Statement-Grenzen, Workload Classes und Prioritäten werden eingeordnet. Auswirkungen eines Tenant-Workloads auf andere Datenbanken werden gemessen.

7. Schritt 7: Start, Stopp und Wartung durchführen

   Geplanter Stop, Startreihenfolge, Abhängigkeiten, Wartungsfenster und Anwendungsprüfung werden mit einem Runbook ausgeführt.

8. Schritt 8: Backup und Recovery je Tenant organisieren

   Sicherungszeitplan, Katalog, Logkette, Recovery-Ziel und Zuständigkeit werden tenantbezogen festgelegt. Eine Wiederherstellung wird vorbereitet oder im Labor durchgeführt.

9. Schritt 9: Tenant überwachen und diagnostizieren

   Status, Dienste, Speicher, Sessions, Alerts, teure Statements und Backups werden im richtigen Datenbankkontext geprüft. Kontextfehler in Werkzeugen werden vermieden.

10. Schritt 10: Tenant verschieben oder kopieren

    Voraussetzungen, Zielsystem, Downtime, Datenübertragung, Identität, Netzwerk und Abnahme werden für Move- oder Copy-Szenarien geplant.

11. Schritt 11: Lifecycle und Systemänderungen koordinieren

    Systemweite Updates, tenantbezogene Tests, Startreihenfolge, Rückfall und Kommunikation werden in eine mandantenfähige Change-Planung überführt.

12. Schritt 12: Betriebsmodell abnehmen

    Mandanteninventar, Zugriffe, Ressourcen, Sicherung, Monitoring, Wartung und Eskalation werden anhand einer Checkliste verifiziert.

Praxisübungen

• Entwurf einer MDC-Landschaft mit drei unterschiedlichen Workload-Profilen
• Anlage und sichere Erreichbarkeit einer Tenant-Datenbank
• Ressourcenbegrenzung mit Belastungs- und Isolationstest
• Tenantbezogene Backup-, Wartungs- und Monitoring-Checkliste

Methodik

Die Übungen wechseln bewusst zwischen Systemdatenbank und Tenant-Kontext. Jeder administrative Schritt enthält eine Kontextprüfung, damit Fehlkonfigurationen durch Arbeiten in der falschen Datenbank vermieden werden.