HA201 – SAP HANA 2.0 SPS06 – High Availability and Disaster Tolerance Administration — Lesson 1: High-Availability Architecture and Recovery Objectives

Learning Objectives

• Explain how High-Availability Architecture and Recovery Objectives supports resilient HANA continuity.
• Complete the workflow and produce a reviewable HANA availability architecture decision record.
• Evaluate the condition where the selected topology cannot satisfy the approved recovery point objective and select a supported response.

Detailed Topics

• Host and service redundancy: business purpose, responsible roles, and SAP objects that establish the operating scope.
• Storage and network considerations: organizational assignments, master records, and dependencies required before processing begins.
• Recovery time and point objectives: navigation, field control, and status logic used to create a reliable starting point.
• Availability topology selection: approval and evidence checkpoints that confirm the foundation is ready for use.

Instructor Demonstration

The guided walkthrough links Host and service redundancy, Storage and network considerations, Recovery time and point objectives, Availability topology selection to business outcomes and control evidence. Learners see how the process should appear in SAP, what belongs in HANA availability architecture decision record, and how the team should respond when the selected topology cannot satisfy the approved recovery point objective.

Hands-On Exercise

Complete a controlled activity covering Host and service redundancy, Storage and network considerations, Recovery time and point objectives, Availability topology selection and preserve the final result in HANA availability architecture decision record.

1. Review prerequisites, process boundaries, master data, authorization, and acceptance criteria.
2. Complete the configured or transactional activity and preserve the resulting document and status trail.
3. Compare the normal result with the controlled exception and identify the most defensible root cause.
4. Record the selected response, validation result, residual risk, responsible owner, and review trigger.

Scenario Analysis

• Which SAP object, rule, master record, or process step most strongly influences the observed result?
• What evidence distinguishes a configuration problem from data, authorization, integration, or timing causes?
• How should the HANA availability architecture decision record be approved, retained, monitored, and updated after handover?

Troubleshooting Guidance

Start at the earliest point where expected SAP behavior differs from the observed result. Review process sequence, master data, organizational assignments, configuration, authorization, integration, and timing separately. Treat “the selected topology cannot satisfy the approved recovery point objective” as a testable hypothesis until settings, documents, logs, reports, and retest outcomes confirm the cause.

Validation Checklist

• Required structures, master data, roles, settings, and dependencies for High-Availability Architecture and Recovery Objectives are present.
• The HANA availability architecture decision record connects each conclusion to objective, reviewable SAP evidence.
• Normal processing, the stated exception, integration behavior, and access boundaries were tested.
• Corrections, retest criteria, ownership, documentation, monitoring, and operational handover are complete.

Lesson Outcome

Learners can apply High-Availability Architecture and Recovery Objectives, explain the resulting SAP behavior, and defend the outcome through HANA availability architecture decision record.