SAP HANA Zero Downtime Patching: Unterschied zwischen den Versionen
| (3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 34: | Zeile 34: | ||
</pre> | </pre> | ||
===== 1.3 Patch anwenden ===== | ===== 1.3 Patch anwenden ===== | ||
Anwenden des Patches, siehe | Anwenden des Patches, siehe [[SAP HANA#SAP HANA Update|Update]] | ||
=====1.4 Secondary System starten ===== | =====1.4 Secondary System starten ===== | ||
| Zeile 44: | Zeile 44: | ||
<pre> | <pre> | ||
# Auf olga9196 | # Auf olga9196 | ||
hdbnsutil -sr_register --remoteHost=olga9195rep --remoteInstance=00 --replicationMode=sync --operationMode=logreplay --name=imsaimpdb2 | |||
# Alternative, volle Neuinitialisierung: | |||
hdbnsutil -sr_register --remoteHost=olga9195rep --remoteInstance=00 --replicationMode=sync --operationMode=logreplay --name=imsaimpdb2 --force_full_replica --online | |||
</pre> | </pre> | ||
===== 1.6 Replikation Status prüfen ===== | ===== 1.6 Replikation Status prüfen ===== | ||
<pre> | <pre> | ||
| Zeile 75: | Zeile 74: | ||
</pre> | </pre> | ||
===== 3.2 Patch anwenden ===== | ===== 3.2 Patch anwenden ===== | ||
Anwenden des Patches | Anwenden des Patches, siehe [[SAP HANA#SAP HANA Update|Update]] | ||
===== 3.3 Altes Primary starten ===== | ===== 3.3 Altes Primary starten ===== | ||
Aktuelle Version vom 4. Juli 2025, 18:00 Uhr
SAP HANA Zero Downtime Patching mit System Replication
Übersicht
Diese Anleitung beschreibt das Zero Downtime Patching von SAP HANA mit System Replication unter Verwendung von hdbnsutil. Das Verfahren ermöglicht das Patchen beider HANA-Systeme ohne Ausfallzeit.
Voraussetzungen
SAP HANA System Replication ist konfiguriert und läuft
Replication Mode: sync
Operation Mode: logreplay
Backup der Systeme ist vorhanden
Administrativer Zugang auf beide Hosts
Vorbereitungen
Status prüfen
Vor Beginn des Patching-Prozesses muss der aktuelle Status der System Replication überprüft werden:
# Auf Primary (olga9195) impadm@olga9195:/usr/sap/IMP/HDB00> hdbnsutil -sr_state # Auf Secondary (olga9196) impadm@olga9196:/usr/sap/IMP/HDB00> hdbnsutil -sr_state
Backup erstellen
Phase 1: Secondary System patchen
1.1 Secondary unregistrieren
# Auf olga9196 als impadm impadm@olga9196:/usr/sap/IMP/HDB00> hdbnsutil -sr_unregister --id=2
1.2 Secondary System stoppen
# Auf olga9196 impadm@olga9196:/usr/sap/IMP/HDB00> HDB stop
1.3 Patch anwenden
Anwenden des Patches, siehe Update
1.4 Secondary System starten
# Auf olga9196 impadm@olga9196:/usr/sap/IMP/HDB00> HDB start
1.5 Secondary wieder registrieren
# Auf olga9196 hdbnsutil -sr_register --remoteHost=olga9195rep --remoteInstance=00 --replicationMode=sync --operationMode=logreplay --name=imsaimpdb2 # Alternative, volle Neuinitialisierung: hdbnsutil -sr_register --remoteHost=olga9195rep --remoteInstance=00 --replicationMode=sync --operationMode=logreplay --name=imsaimpdb2 --force_full_replica --online
1.6 Replikation Status prüfen
# Auf beiden Hosts prüfen hdbnsutil -sr_state
Erwartetes Ergebnis: Secondary ist wieder als sync/logreplay registriert.
Phase 2: Takeover zu Secondary
2.1 Takeover durchführen
# Auf olga9196 (Secondary wird zum Primary) impadm@olga9196:/usr/sap/IMP/HDB00> hdbnsutil -sr_takeover
2.2 Status nach Takeover prüfen
# Auf olga9196 (neuer Primary) impadm@olga9196:/usr/sap/IMP/HDB00> hdbnsutil -sr_state
Erwartetes Ergebnis: olga9196 ist jetzt Primary (mode: primary).
Phase 3: Ursprüngliches Primary patchen
3.1 Altes Primary stoppen
# Auf olga9195 impadm@olga9195:/usr/sap/IMP/HDB00> HDB stop
3.2 Patch anwenden
Anwenden des Patches, siehe Update
3.3 Altes Primary starten
# Auf olga9195 impadm@olga9195:/usr/sap/IMP/HDB00> HDB start
3.4 Als neues Secondary registrieren
# Auf olga9195 (wird zum Secondary) impadm@olga9195:/usr/sap/IMP/HDB00> hdbnsutil -sr_register --remoteHost=olga9196rep \ --remoteInstance=00 \ --replicationMode=sync \ --operationMode=logreplay \ --name=imsaimpdb1
Phase 4: Zurück switchen (optional)
Falls das ursprüngliche Primary wieder zum Primary werden soll:
4.1 Switchover zurück
# Auf olga9195 (zurück zum Primary) impadm@olga9195:/usr/sap/IMP/HDB00> hdbnsutil -sr_takeover
4.2 Secondary neu registrieren
# Auf olga9196 (wieder Secondary) impadm@olga9196:/usr/sap/IMP/HDB00> hdbnsutil -sr_register --remoteHost=olga9195rep \ --remoteInstance=00 \ --replicationMode=sync \ --operationMode=logreplay \ --name=imsaimpdb2
Validierung
Finale Überprüfung
# Auf beiden Hosts den finalen Status prüfen hdbnsutil -sr_state hdbnsutil -sr_info # Detaillierte Informationen HDBSettings.sh systemReplicationStatus.py
Erwartete Ergebnisse
Troubleshooting
Häufige Probleme
- Replikation synchronisiert nicht
- Prüfen Sie die Netzwerkverbindung zwischen den Hosts und die Log-Verzeichnisse.
- Takeover schlägt fehl
- Überprüfen Sie, ob alle Services auf dem Secondary laufen:
HDB info - Secondary registriert sich nicht
- Kontrollieren Sie die Parameter (insbesondere remoteHost) und die Berechtigung des impadm-Users.
Log-Dateien
Wichtige Log-Dateien für die Diagnose:
# Nameserver Trace /usr/sap/IMP/HDB00/olga9195/trace/nameserver_*.trc # System Replication Log /usr/sap/IMP/HDB00/olga9195/trace/nameserver_history.trc
Wichtige Hinweise
Backup vor Start: Erstellen Sie immer ein vollständiges Backup vor dem Patching.
Patch-Kompatibilität: Stellen Sie sicher, dass beide Systeme mit derselben Patch-Version kompatibel sind.
Monitoring: Überwachen Sie kontinuierlich den Status mit hdbnsutil -sr_state.
Rollback-Plan: Halten Sie einen Rollback-Plan für den Fall von Problemen bereit.
Downtime: Obwohl "Zero Downtime", gibt es kurze Unterbrechungen während der Takeover-Vorgänge.
Weiterführende Informationen
SAP Note 1999880 - FAQ: SAP HANA System Replication SAP Note 2013111 - FAQ: SAP HANA Database Upgrade SAP HANA Administration Guide - System Replication