By me Installing and Administering SAP HANA.pdf

Installing and Administering SAP HANA Key features of S/4HANA application Suite From an IT value perspective, this means that SAP S/4HANA creates unique opportunities to simplify the landscape and reduce the total cost of ownership, with SAP HANA as the main driver. Enterprises can now significan...

Installing and Administering SAP HANA Key features of S/4HANA application Suite From an IT value perspective, this means that SAP S/4HANA creates unique opportunities to simplify the landscape and reduce the total cost of ownership, with SAP HANA as the main driver. Enterprises can now significantly reduce their data footprint and work with larger data sets in one system (for example, SAP ERP, SAP CRM, SAP SRM, SAP SCM, and SAP PLM in one system). This saves hardware costs, operational costs, and time. With one common source of live data on one system, enterprises no longer face discrepancies between different systems. Migration to SAP HANA Migrating your existing SAP system to the SAP HANA database involves switching the SAP system to a new database that runs on new host(s). A migration to SAP HANA can be performed in the following two ways: Heterogeneous system copy using Software Provisioning Manager (SWPM)  Database migration option (DMO) of the Software Update Manager (SUM) Initial situation You can use DMO in the following scenarios: Migration of existing SAP system from any supported database to SAP HANA database In-place migration option to avoid landscape changes (SID, host name, and so on), so you need an update of your SAP 7.x system Avoiding the usage of the classical migration procedure, because it is complex and requires several steps and tools The benefits when using are as follows: Migration steps are simplified System update and database migration are combined in one tool Business downtime is reduced Well-known tool SUM is used, with improved UI The database migration option (DMO) is not a new tool – it is just an option of using the Software Update Manager (SUM). SUM is the trusted tool for system maintenance, such as the following: Release updates and upgrades Enhancement package implementations Support Package Stacks (SPS) and Feature Package Stacks (FPS) for ABAP- based SAP systems The Migration Process Performing the migration in a combined procedure offers the following benefits: The combined procedure requires only one maintenance phase and not two. This reduces business downtime (TCO) and fewer regression tests are necessary. The original database is kept, and can be reactivated as a fallback. This reduces risk, no restore is required, and there is more time for testing before cutover. There are fewer prerequisites for the SAP and database start releases. This reduces effort (TCO), and there are no additional licenses for traditional database updates. In-place migration keeps the application server and system ID stable. This has a low impact on the system landscape because only the database server is new. For SAP BW, the database migration option can be applied when Post Copy Automation (PCA) is used. Illustrating the Need for In-Memory Technology SAP HANA In-Memory Technology In-Memory Computing The Past: Disk-Centric, Singular Processing Platforms The Present: Low Latency Computing Driven by In-Memory Technology Row Store Versus Column Store SAP HANA is an ACID-compliant, in-memory database. ACID is an acronym that means the database can support Atomicity, Consistency, Isolation, and Durability. This is a primary requirement of a database, which ensures that it is 100% reliable for mission-critical applications. The database must guarantee data accuracy and integrity even when there are lots of simultaneous updates across multiple tables. The traditional database systems (without in-memory technology) focus on one workload: OLTP or OLAP. With SAP HANA, this has changed because it handles transactional and analytical workloads very well. The SAP HANA database stores the data in a columnar way, therefore organizing the data in DRAM in an optimal way for the CPU to access. Column- and Row-store Tables in SAP HANA The SAP HANA database supports both column-based and row-based tables. However, the table storage is optimized for column tables. When creating a table, you need to decide whether the table should be column- or row-store, depending on the use case. Use a column table when: Performing aggregations on a small number of columns. Performing searches based on the values in only a few columns. The table has a large number of columns. The table has a large number of rows and mostly columnar operations are performed.  Achieving a high column compression rate is required. Column-based storage is used for large tables with bulk updates. However, in a compressed column table the update and insert performance is slower than on row tables. SAP has addressed this slower update and insert of columnar tables by introducing a delta store. Every table has a write-optimized uncompressed delta store. This makes columnar tables have fast read and write capabilities. You can join row tables with column tables in the SAP HANA database. However, it is more efficient to join tables of the same storage type. Use a row table when: You want to process single records at once, or many selects and updates. You want to access complete records. Columns contain mainly distinct values. You do not need aggregations or fast search. The number of rows is small. You can change an existing table from one storage type to the other (ALTER TABLE ALTER TYPE). SAP HANA as an Application Platform SAP HANA is different by design. It stores all data in-memory and in a compressed columnar format. Because SAP HANA has this different design, it does not require sums, indexes, materialized views, or aggregates. This reduces the database footprint. Everything is calculated on demand and in the main memory. In addition, SAP has built solutions to all well-known problems of columnar databases, such as concurrency (SAP HANA uses MVCC), and row-level insert and update performance (SAP HANA uses various mechanisms, such as a delta store). SAP also added engines inside SAP HANA to provide the following functions: SAP HANA supports the following open standards: Representational State Transfer (REST) JavaScript Object Notation (JSON) OLE DB for OLAP (ODBO) Multidimensional expressions (MDX) Open Database Connectivity (ODBC)  Java Database Connectivity (JDBC) SAP HANA Platform The SAP HANA platform combines database, data processing, and application platform capabilities. It provides libraries for predictive planning, text, spatial, and business analytics to enable business to operate in real time. SAP HANA is an in-memory database management system, but it also contains many additional features for specific use cases. Examples are spatial processing, search, text mining, and integrated libraries. Some of these features can be used when running traditional applications on SAP HANA. Others are used in entirely new in-memory applications. Virtual online analytical processing (OLAP): Processing large amounts of data for analytical purposes, support of complex calculations, modeling, and data mining. Data virtualization: Access data across organizational, application, and data storage boundaries to gain full business visibility. Text analysis: Feature enabled with full-text index to discover and classify entities in documents, supporting many entity types, analysis, and languages. Search: Support for search on single or multiple columns of almost any visible data type, and standard string search.  Geospatial: Analyze spatial data for your business, build geospatial applications, and geo-content and services. Graph: Support for graph processing, allows you to execute typical graph operations on the data stored in an SAP HANA system. Web: Web-based development workbench, without installing further tools. SAP HANA Extended Application Services, Advanced Model In simple terms, SAP HANA extended application services, advanced model is basically the Cloud Foundry open-source Platform-as-a-Service (PaaS) with a number of tweaks and extensions provided by SAP. These SAP enhancements include the following: Integration with the SAP HANA database OData support Compatibility with SAP HANA extended application services, classic model (XSC) Additional features designed to improve application security SAP HANA extended application services, advanced model (XSA) also provides support for business applications that are composed of multiple micro-services. These are implemented as separate Cloud Foundry applications, which combined are also known as multi-target applications (MTA), which include multiple modules like an equivalent of Cloud Foundry applications. SAP HANA Extended Application Services Engine SAP HANA extended application services is the application server for native SAP HANA-based web applications. It is installed with the SAP HANA system and allows developers to write and run SAP HANA-based applications without the need to run an additional application server. SAP HANA extended application services is also used to run web-based tools that come with SAP HANA, for instance for administration, lifecycle management, and development. Server on the Classic Model of SAP HANA Extended Application Services The classic model of SAP HANA extended application services is the original implementation of SAP HANA extended application services. The server on the classic model of SAP HANA extended application services can run as a separate server process or embedded within the index server. The SAP Web Dispatcher, which runs as a separate database service on the host of the system database, is used to route incoming HTTP requests from clients to the correct XS classic server based on virtual host names. This is part of network configuration. In addition to the system-internal Web Dispatcher, you can implement an external Web Dispatcher for load distribution. See the section on using the SAP Web Dispatcher for load balancing with tenant databases. Note SAP HANA XS Classic and the SAP HANA Repository have been deprecated for SAP HANA. See also SAP Note 2465027 – Deprecation of SAP HANA extended application services, classic model, and SAP HANA Repository. In addition, check SAP Note 2695472 – Statement on SAP HANA XS Classic and the SAP HANA Repository and SAP Cloud Platform, SAP HANA Service. Runtime for the Advanced Model of SAP HANA Extended Application Services The runtime for the advanced model of SAP HANA extended application services consists of several processes for platform services and for executing applications. For more information about the individual services, see the SAP HANA Administration Guide. The runtime for the advanced model of SAP HANA extended application services runs either on dedicated hosts or together with other SAP HANA components on the same host. Note SAP recommends that customers and partners who want to develop new applications use the advanced model of SAP HANA extended application services (XSA). If you want to migrate existing applications from the classic model of SAP HANA extended application services to run in the new advanced runtime environment, first check the features available with the installed version of SAP HANA extended application services, advanced model. If the features of the advanced model of SAP HANA extended application services match the requirements of the classic application that you want to migrate, then you can start the migration process. For more information, see the SAP HANA XS Advanced Migration Guide. Additional Information Sources Further SAP HANA documentation and information can be found in the following resources: SAP HANA online documentation (HTML) SAP HANA Cockpit online documentation (HTML) Note Select the Download PDFs link on the SAP HANA and SAP HANA Cockpit documentation landing page to download the complete documentation set in PDF format as one.ZIP file. The SAP HANA Master Guide is the entry point for planning the installation of your SAP HANA system landscape (PDF) The SAP HANA Server Installation and Update Guide explains how to install and update an SAP HANA database system with the SAP HANA Lifecycle Management tools (PDF) The SAP HANA Administration Guide for SAP HANA Platform explains how to configure, manage, maintain, and optimize your SAP HANA database system using SAP HANA administration tools (PDF) The SAP HANA Security Guide for SAP HANA Platform explains how to ensure the security of the SAP HANA platform and its components (PDF) The SAP HANA SQL Reference Guide for SAP HANA Platform describes the SQL features supported by SAP HANA (PDF) The SAP HANA Configuration Parameter Reference gives an overview of the most important SAP HANA parameters (HTML) The SAP HANA Troubleshooting and Performance Analysis Guide explains how to troubleshoot and do performance analysis for the SAP HANA database (PDF) The SAP HANA Tenant Databases Operations Guide shows how to configure, manage, and monitor an SAP HANA system that supports SAP HANA tenant databases (PDF) The SAP HANA Quick Sizer Web site with sizing guidelines The Certified and Supported SAP HANA Hardware Web site lists all the certified SAP HANA hardware Download the SAP HANA software via the SAP HANA Software Download Center The new SAP Learning Web site with lots of free content Meet the SAP HANA Community SAP HANA Database Administration Curriculum The following courses are prerequisites to become C_DBADM_2404 certified in the area of SAP HANA database system administration: HA200 - Installing and Administering SAP HANA  HC200 - Provisioning and Administering Databases in SAP HANA Cloud HA2HC - Migrating SAP HANA to SAP HANA Cloud Performing SAP HANA Sizing General Concept of Sizing SAP HANA Business Example Your company has decided that all SAP Business Suite and SAP BW systems will be migrated to the SAP HANA database. It is your task to investigate what is the best method to deploy the SAP HANA database systems, that is, to deploy as an SAP HANA appliance or to deploy following the SAP HANA tailored data center integration (TDI) approach. Sizing of the SAP HANA database revolves mainly around the main memory size. The required memory to hold the dataset base in memory is determined from the size of the source database. SAP HANA compresses the data stored in memory. The compression rate depends on the used scenario, so you cannot estimate the amount of memory needed. A memory sizing must always be performed using the Quick Sizer for SAP HANA, or the SAP HANA sizing reports and SAP Notes. Hint If you are interested in how SAP HANA compression works, see SAP Note 2112604: FAQ – SAP HANA Compression. Based on this memory value, you can choose a hardware configuration. The SAP HANA database system can be deployed as an SAP HANA tailored data center integration (TDI) or as an SAP HANA appliance setup. In both cases, you can choose a fitting hardware from the catalog of certified hardware. Note The following information refers solely to the sizing of the SAP HANA database server. Depending on the scenario, the sizing of other components, such as the SAP ABAP application server(s), must be considered separately. When sizing an SAP HANA database, the sizing approach depends on the implementation scenario used by the customer. The possible sizing approaches are as follows: Customers new to SAP applications and SAP HANA can use the Quick Sizer to size the required memory for an SAP HANA system. This method can also be used for existing SAP customers who want to perform a greenfield implementation. Customers who want to migrate their existing SAP NetWeaver based systems to run on SAP HANA can execute a sizing report, which calculates the required memory. For non-SAP NetWeaver based systems, you use the sizing method described in SAP Note 1514966. Any system that is large or complex requires sizing from an SAP sizing expert. An SAP expert sizing is required in the following scenarios: Consolidating multiple ERP source systems into one ERP system on SAP HANA. Carving out ERP functionality from the source system to the ERP on SAP HANA system. Migrating a high-volume legacy system to SAP HANA. Overview of SAP HANA Tailored Data Center Integration (TDI) In an SAP HANA on-premise deployment, SAP HANA runs on dedicated hardware. The on-premise SAP HANA is deployed through the following offerings: SAP HANA appliance combines SAP HANA software components on proven hardware provided by hardware partners. This approach is valid for Intel-based hardware platforms only. While this approach is simple, it has limitations for hardware flexibility and compliance with existing IT operation processes. Therefore, SAP HANA tailored data center integration is offered as a new option to provide customers with greater flexibility. SAP HANA tailored data center integration (TDI) provides the customer with more flexibility regarding the hardware components required to run SAP HANA in the data center. Leveraging this approach, customers will have the following benefits: o Reduce hardware and operational costs by reusing existing hardware components and operation processes o Mitigate risks and optimize time-to-value by enabling existing IT management processes for SAP HANA implementations o Have more flexibility in hardware vendor selection by leveraging the existing ecosystem In short, SAP HANA tailored data center integration helps you to stay within your IT budget, shortens implementation cycles, and allows better consumption of hardware innovations to drive the adoption of SAP HANA. SAP does not offer any formal certification of a given SAP HANA tailored data center integration infrastructure. Instead, SAP certifies hardware components together with its SAP HANA hardware partners, and requires customers to only use these certified configurations for SAP HANA tailored data center integration. Use the official SAP HANA Hardware Directory to verify that your compute nodes and storage systems are listed there with the exact same bill of material as the compute servers of certified SAP HANA appliances but without storage. The installation of SAP HANA needs to be performed by a person who possesses a valid SAP Certified Associate - Database Administrator - SAP HANA (C_DBADM_2404) or newer. SAP HANA hardware partners and their employees do not need this certificate. However, companies, or their employees, who are sub-contractors of SAP HANA hardware partners must be certified to perform HANA software installations. Note IBM provides a process to support mapping of the SAP sizing to a hardware or partition configuration that meets the sizing needs of the customer. For more information, see SAP Note 2055470: SAP HANA on POWER Planning and Installation Specifics – Central Note. Tailored data center integration can reduce hardware and operations cost by reusing existing hardware components and processes. Note Tailored data center integrations offer freedom and flexibility, which also leads to the customer’s increased responsibility for the system, ranging from the installation up to running the landscape. SAP HANA Tailored Data Center Integration General Requirements SAP and our SAP HANA hardware and software partners will support SAP HANA tailored data center integration system configurations if they use the following guidelines: Use of certified hardware: Only servers listed in the Certified and Supported SAP HANA Hardware directory are supported. These are the same servers as for SAP HANA appliances. Use of certified storage: Only storages listed in the enterprise storage tab of the Certified and Supported SAP HANA Hardware directory fulfill the requirements for data throughput and latency, and are supported by SAP. Installation performed by an SAP HANA certified person: The person who installs SAP HANA needs to have a valid certification. Current valid C_DBADM_xxxx certification can be found on the SAP Learning web site. Tailored Data Center Integration Storage Requirements For certification, each storage vendor must file in a vendor-specific configuration guide. This guide explains how to configure the storage for optimal collaboration with SAP HANA. The storage vendor provides the guide to the customer. Read the storage white paper attached to SAP Note1900823 - SAP HANA Storage Connector API carefully. Use the SAP HANA Hardware and Cloud Measurement Tool for Tailored Data Center Integration to check your storage KPIs. You can do this every time you change your storage configuration. Note Customers should consider involving SAP Digital Business Services to perform a SAP HANA Go-Live Check prior to going productive. SAP HANA Tailored Data Center Integration Enterprise Network Requirements With the introduction of tailored data center integration with enterprise networks, SAP supports hardware setups, which comply with the prerequisites mentioned below: Network Segmentation – All networks need to be properly segmented, and can be connected to the same core/backbone switch. SAP recommence to use the following zones setup: Client zone - used by the SAP HANA clients like application servers, data sources, and BI clients. Internal zone - used for the communication between the SAP HANA worker nodes (inter- node communication). Storage zone - used for reading and writing to the enterprise storage, and for writing backups to the backup infrastructure. The minimum bandwidth requirement for Ethernet is ≥ 10 GbE for the Internal and Storage zone. The minimum bandwidth requirement when using Fibre Channel for the enterprise storage is ≥ 8 GbF. Note Network security and segmentation is a function of the network switch vendor and must be configured according to the specifications of the switch vendor. Apart from that, no further approval by SAP is required. Important Documents and Tools SAP HANA Master Guide  SAP HANA Storage white paper attached to SAP Note 1900823 - SAP HANA Storage Connector API SAP HANA Network Requirement white paper SAP Note 2407186- How-To Guides & white papers For SAP HANA High Availability SAP Note 2493172 – SAP HANA 2.0 Hardware and Cloud Measurement Tools Sizing Method for the SAP HANA Tailored Data Center Integration Sizing an SAP HANA Tailored Data Center Integration Setup Sizing an SAP HANA tailored data center integration setup consists of three main steps, as follows: RAM sizing for static and dynamic data Disk sizing for the persistence storage CPU sizing for the queries and calculations The three sizing steps are explained in the following sections. DRAM Sizing for Static and Dynamic Data The first step to sizing an SAP HANA tailored data center integration system is to perform a memory sizing. Depending on the use case, you would use the following resources: Quick Sizer SAP Note 2786237 – Sizing SAP HANA with Persistent Memory SAP Note 1793345 – Sizing for SAP Suite on SAP HANA SAP Note 1872170 – ABAP on HANA sizing report (S/4HANA, Suite on HANA...) SAP Note 3470136 – HANA memory Sizing report - Advanced correction 21 SAP Note 2758146 – SAP Readiness Check for SAP S/4HANA SAP Note 2408419 – SAP S/4HANA – Multi-Node Support SAP Note 2428711 – S/4HANA scale-out sizing SAP Note 1637145 – SAP BW on HANA: Sizing SAP In-Memory Database SAP Note 2610534 –HANA BW Sizing Report (/SDF/HANA_BW_SIZING) SAP Note 2296290 – New Sizing Report for SAP BW/4HANA SAP Note 2363248 – SAP BW/4HANA Hardware Sizing SAP Note 2055470 – SAP HANA on POWER Planning and Installation Specifics – Central Note When performing the first initial SAP HANA memory sizing, it is good practice to use both methods. The Quick Sizer and the SAP Notes determine the required SAP HANA memory size in two different ways. When both values are similar, you know that you did not make any mistakes. Sizing for Suite on SAP HANA The report /SDF/HDB_SIZING is regularly updated and improved, so always check the SAP Notes for newer versions of the report. Due to the continuous update of the report /SDF/HDB_SIZING, the screenshots shown in this section might be outdated. Always check SAP Note 1872170 - ABAP on HANA sizing report (S/4HANA, Suite on HANA...) for the current version of the report /SDF/HDB_SIZING. Sizing for SAP BW/4HANA The sizing notes describe the memory sizing (column, row store, and additional components), the disk sizing for data and log files, and the CPU sizing. Some additional information is attached to some of these SAP Notes. Note The ZNEWHDB_SIZE report runs with a low system load. Depending on the size of your Suite on SAP HANA system, it takes up to eight to twelve hours or more. Therefore, we recommend that you test the report in your consolidation system before loading. Static Versus Dynamic Memory Requirements Distinguish between the static and the dynamic RAM requirement as follows: Static Data Memory Requirements The static RAM requirements refer to the amount of main memory that is used for holding the table data. Static memory sizing of SAP HANA is determined by the amount of data that is to be stored in memory. Specifically, this figure relates to the amount of disk space covered by the corresponding database tables, excluding their associated indexes.  Note that, if the database supports compression, the space of the uncompressed data is needed. Based on this amount of data, a compression factor is applied to determine the size of the RAM needed for SAP HANA. Dynamic Data Memory Requirements Additional memory is required for objects that are created dynamically when new data is loaded, or queries are executed. Because we recommend reserving as much memory for dynamic objects as for static ones, calculate the total RAM by multiplying the static RAM by two. In an SAP HANA virtualized environment, you should also consider the following SAP Notes: SAP Note 2779240 – Workload-based sizing for virtualized environments SAP Note 2652670 – SAP HANA VM on VMware vSphere SAP Note 1788665 – SAP HANA Support for virtualized/partitioned (multi-tenant) environments SAP Note 2315348 – SAP HANA on VMware vSphere 6 in production SAP Note 2393917 – SAP HANA on VMware vSphere 6.5 and 6.7 in production SAP Note 2284516 – SAP HANA virtualized on SUSE Linux Enterprise hypervisors SAP Note 2599726 – SAP HANA on Red Hat Virtualization in production SAP Note 2659955 – SAP HANA on Fusionsphere KVM SAP Note 2686722 – SAP HANA virtualized on Nutanix Acropolis Hypervisor In a scale-out environment, you should also consider the following SAP Notes: SAP Note 2680623 – Multiple SAP HANA Scale-out Systems (SIDs) on the Same Underlying Servers SAP Note 1886462 – HANA Scale-out configuration of /etc/hosts files SAP Note 1781986 – Business Suite on SAP HANA Scale-out SAP Note 1825774 – SAP Business Suite Powered by SAP HANA – Multi-Node Support SAP Note 1950470 – Hardware Prerequisites for Business Suite on SAP HANA Scale- out SAP Note 1702409 – HANA DB: Optimal number of Scale-out nodes for BW on HANA Sizing SAP HANA Storage Requirements SAP HANA is an in-memory database, which stores and processes the bulk of its data in-memory. Additionally, it provides protection against data loss by saving the data in persistent storage locations. For further storage sizing recommendations, follow the guidelines described in the SAP HANA Storage Requirements white paper attached to SAP Note 1900823 - SAP HANA Storage Connector API. Persistent storage distinguishes between the data volume and the log volume. In the data volume of SAP HANA, a copy of the in-memory data persists by writing changed data to the data volume. The log volume ensures the recovery of the database with zero data loss in case of faults. SAP HANA records each transaction in the form of a redo log entry. Disk Space Required for the Data Volume Whenever a savepoint or a snapshot is created, or a delta merge operation is performed, data is written from memory to the data volume located at the mount point /hana/data/. The recommended size of the data volume for a given SAP HANA system is equal to the calculated results from the sizing reports. Use the net data size on the disk plus an additional free space of 20%. The figure, Determining the Data Volume Size, shows an example sizing report result for Suite on HANA. The sizing report shows the net data size on disk. To determine the required SAP HANA data volume size, add 20%. This 20% of additional space is required during delta merge operations, because the affected tables are temporarily duplicated on disk for a short period of time. Also include the anticipated year-on-year growth, for example, 15% per year for the next three years. This would lead to a factor of 1,52 (= 1,153) that needs to be added to the Sizedata equation. During the migration of a non-SAP HANA database to SAP HANA, the system may temporarily need more disk space for data than calculated in the sizing phase. With Enterprise Storage, this is not considered relevant for the overall storage sizing, because the storage system can provide that additional space, if required. Disk Space Required for the Log Volume The minimum size of the log volume depends on the number of data changes occurring between two SAP HANA savepoints, which, by default, are created every five minutes. The more data changes that are executed by write transactions in that period, the more redo log segments that are written to the log volume under /hana/log/. When sizing the log volume, consider the following points: The redo log must not be overwritten before a savepoint entry is available in the data volume, otherwise, the SAP HANA database may be unable to restart. Situations may occur where the writing of a savepoint is delayed. For example, delays occur if a high workload must be processed during a database migration process in an environment with slow input/output between the source and target (SAP HANA) database. In such cases, as long as the savepoint has not been written to the data volume, the amount of redo logs in the log volume continue to grow until all log segments are full. If the parameter LOG_MODE = NORMAL is set, the redo log must not be overwritten before a backup takes place. Therefore, keep some extra space available for situations where incidents or faults may interrupt the backup process. That extra space allows system administrators to fix and finish the backup process before the log volume runs full. Determining the Log Volume Size There is no direct correlation between the SAP HANA database size and the required log volume size. Nevertheless, we recommend using the formula in the figure, Determining the Log Volume Size, because it is based on best practice and experiences with productive SAP HANA installations. Unlike the formula for the data volume, it is calculated depending on the total memory requirement (RAM). Examples of log volume size are as follows:  128 GB system ≥ Size log volume = 64 GB 256 GB system ≥ Size log volume = 128 GB 512 GB system ≥ Size log volume = 256 GB 1 TB system ≥ Size log volumemin = 512 GB 2 TB system ≥ Size log volumemin = 512 GB 4 TB system ≥ Size log volumemin = 512 GB Note For systems with more than 512 GB of in-memory database size, the previous formula represents a minimum value. As of today, based on the experience made with productive SAP-internal SAP HANA installations, this value is considered sufficient for each SAP HANA use case. Nevertheless, as described previously, as the amount of data stored in the log volume depends on the workload processed, there may be situations where this value is not sufficient for log volume sizing. Disk Space Required for SAP HANA Installation All binary, trace, and configuration files are stored under /hana/shared/ for a single-host configuration. Note The documentation and configuration parameter files refer to the /hana/shared/ file system as the installation path or the mount point sapmnt. The /hana/shared/ file system can be set up as a shared file system, or as a local file system. The advantage of setting up /hana/shared/ as a shared file system is that it makes the conversion from a single-host system to a multi-host system easier. For single-node SAP HANA systems, the minimum recommended disk space for /hana/shared/ is shown in the figure, Determine Share Single-Host Size, with a maximum of 1 TB. The following are examples of single-node SAP HANA installation sizes: Single-node 128 GB ≥ Sizeinstallation = 128 GB Single-node 256 GB ≥ Sizeinstallation = 256 GB Single-node 512 GB ≥ Sizeinstallation = 512 GB Single-node 1 TB ≥ Sizeinstallation = 1 TB  Single-node 2 TB ≥ Sizeinstallation = 1 TB Single-node 4 TB ≥ Sizeinstallation = 1 TB Determining the Share Scale-Out Size For a multi-host (scale-out) system all binary, trace, and configuration files are stored on a shared file system that is exposed to all worker nodes of an SAP HANA system in the file system /hana/shared/. In the installation path (sapmnt), additional space is required per worker node for the writing the traces files of a scale-out SAP HANA database system. Experience with productive SAP HANA installations shows that the bigger the size of the SAP HANA database, the more traces that are written. Therefore, the calculation is based on the total memory requirement (RAM). For scale-out SAP HANA systems, the recommended disk space for /hana/shared/ depends on the number of worker nodes. Disk space of 1x worker node RAM is recommended for every four worker nodes in a given scale-out system. The following are examples of scale-out SAP HANA installation sizes: 3 system, 512 GB per node ≥ Sizeinstallation = 1x 512 GB = 512 GB 4 system, 512 GB per node ≥ Sizeinstallation = 1x 512 GB = 512 GB 5 system, 512 GB per node ≥ Sizeinstallation = 2x 512 GB = 1 TB... 9 system, 512 GB per node ≥ Sizeinstallation = 3x 512 GB = 1.5 TB... 3 system, 1 TB per node ≥ Sizeinstallation = 1x 1 TB = 1 TB 4 system, 1 TB per node ≥ Sizeinstallation = 1x 1 TB = 1 TB 5 system, 1 TB per node ≥ Sizeinstallation = 2x 1 TB = 2 TB 9 system, 1 TB per node ≥ Sizeinstallation = 3x 1 TB = 3 TB Note In a scale-out system, a node can also have the role Standby. A node with the role Standby does not require any additional disk space as it will take over the data and log volumes of the failed node. Disk Space Required for Backups A complete data backup contains the entire payload of all data volumes. The size required by the backup directory not only depends on the total size of the data volumes, but also on the number of backup generations kept on disk, and on the frequency with which data is changed in the SAP HANA database. For example, if the backup policy requires you to perform complete data backups daily and to keep those backups for one week, the size of the backup storage must be seven times the size of the data area. In addition to data backups, backup storage for log backups must be reserved to provide the possibility for a point-in-time database recovery. The number and size of log backups to be written depend on the number of change operations in the SAP HANA database. Technically, it is possible to store the backups of several SAP HANA databases in a central shared backup storage. But if several backup or recovery processes run in parallel, this impacts the overall data throughput of the given backup storage. That is, if the backup storage cannot guarantee a constant level of data throughput once the number of parallel processes exceeds a certain number, backup and recovery processes can slow down significantly. Backup Strategy: All Full Backups Code snippet 1 28x 2.50TB = 70TB 2 28x 0.25TB = 7TB + 3 --------------------------------- 4 Backup size = 77TB Backup Strategy: Weekend Full Backups, Workdays Incremental Backups Code snippet 1 4x 2.50TB = 10.0TB 2 24x 0.05TB = 1.2TB 3 28x 0.25TB = 7.0TB + 4 --------------------------------- 5 Backup size = 18.2TB Disk Space Required for Exports Sometimes, the database content is needed for a root cause analysis of problems. For this purpose, sufficient disk space must be provided to hold the binary exports. In most cases, it is not necessary to export the entire database content for root cause analysis. Therefore, it is sufficient to reserve storage space of about two times the size of the largest database table. Network Requirements Customers often also create an Admin zone to handle the communication between virtualized devices (for example, hypervisor failover), administration hosts (such as SAP HANA Database Cockpit), and boot servers. When you deploy SAP HANA as an appliance, "network connectivity" is provided for the internal and storage zones. The client zone and admin zone are within your responsibility. Should you deploy SAP HANA using the tailored data center integration approach, the recommendation for internal zone and storage zone is minimum 10 Gbit/s. For more information on network configuration in SAP HANA, including sizing recommendations, read the SAP HANA Network Requirement. Database CPU Sizing The CPU requirements for migrating to SAP HANA standalone are difficult to anticipate, as there is no real reference against which to compare. Therefore, the sizing referred to previously has the following formula: 300 SAPS per active user / 0.65 for a CPU utilization buffer. An active user is one that consumes CPU power at a given point in time. In sizing, customers often overestimate the (overlapping) activity patterns of their end users. Some end users also may perform complex or less intensive calculations on the database level. Consider this recommendation as an initial estimate that needs verification. The more users there are on the system, the less likely it is that this formula will be accurate. The decision of whether you invest time into further CPU analysis depends upon the risk of reaching CPU limits. SAP HANA servers with two sockets, for example, deliver about 60,000 SAPS. If you want to verify the CPU requirements, a test with the top five to ten SAP HANA transactions can be helpful, either within a single user test or a load test. Sizing Method Quick Sizer for SAP HANA SAP HANA database can also be sized using Quick Sizer. For more information, see Quick Sizer. The Quick Sizer calculates the following: CPU Disk Memory Input/output resource categories It calculates these based on throughput numbers and the number of users working with the different SAP solutions in a hardware and database-independent format. Sizing is an iterative process that continuously brings together customers, hardware vendors, and SAP. So, for example, direct links to SAP hardware vendors facilitate the tendering procedure. For an initial sizing recommendation using the Quick Sizer, follow the steps shown in the figure, Quick Sizer Tool. For sample configurations, see SAP Standard Application Benchmarks. In the Quick Sizer, multiple predefined scenarios can be selected. For example, the following scenarios can be selected: SAP Business Suite powered by SAP HANA SAP S/4HANA SAP BW/4HANA Standalone SAP HANA SAP S/4HANA Cloud For each of the scenarios, the expected compression of the data is different. Sizing Method for the SAP HANA Appliance The result of the memory sizing is the basis for the hardware recommendation for an SAP HANA system. If you decide to buy an SAP HANA appliance, check the SAP HANA Hardware Directory list where you will find all hardware that has been certified or is supported. You don’t need to consider storage and CPU sizing for an SAP HANA appliance, because they are included in the certified appliance offering. Caution Applications other than the SAP HANA database software must not be installed on the database server, except for scenarios that are explicitly supported by SAP. This is discussed in the lesson Illustrating Deployment Options. To calculate the memory requirements, use the following SAP Notes: Quick Sizer SAP Note 2786237 – Sizing SAP HANA with Persistent Memory SAP Note 1793345 – Sizing for SAP Suite on SAP HANA SAP Note 1872170 – ABAP on HANA sizing report (S/4HANA, Suite on HANA...) SAP Note 3338309 – HANA memory Sizing report - Advanced correction 17 SAP Note 2758146 – SAP Readiness Check for SAP S/4HANA SAP Note 2408419 – SAP S/4HANA – Multi-Node Support SAP Note 2428711 – S/4HANA scale-out sizing SAP Note 1637145 – SAP BW on HANA: Sizing SAP In-Memory Database SAP Note 2296290 – New Sizing Report for SAP BW/4HANA SAP Note 2363248 – SAP BW/4HANA Hardware Sizing SAP Note 2055470 – SAP HANA on POWER Planning and Installation Specifics – Central Note SAP HANA Appliances An overview of the available and certified SAP HANA appliances can be found on the SAP HANA Hardware Directory. Caution It is mandatory to begin with SAP HANA 2.0 computing nodes with at least an Intel Haswell CPU or later. See SAP Note 2399995 - Hardware requirement for SAP HANA 2.0. Sizing recommendations apply for certified hardware only. Contact your hardware vendor for suitable hardware configuration. The SAP HANA development team is constantly optimizing the SAP HANA database. We recommend that you always check the latest documentation and SAP Notes when performing an SAP HANA memory sizing. Sizing Method for SAP HANA Non- NetWeaver The SAP Note 1514966 - SAP HANA 1.0: Sizing SAP In-Memory Database describes the sizing of SAP HANA in a non-NetWeaver scenario, for example, when the data is coming from an external data source and SAP HANA is used to model and analyze that data. Do not use these sizing rules for sizing SAP BW/4HANA, Business Suite on SAP HANA systems, or SAP S/4HANA as they will produce incorrect values. Additional Remarks For various SAP HANA scenarios, native and third-party technologies provide features to displace data not frequently used either for the SAP HANA persistence or for other database management systems. If such a technology is used, this is considered in the main memory sizing. The following are examples: SAP HANA Native Storage Extension (SAP Note 2775588) and Data Aging in SAP HANA (SAP Note 2816823) SAP HANA native storage extension is a general-purpose, built-in warm data store in SAP HANA that lets you manage less-frequently accessed data without fully loading it into memory. SAP HANA native storage extension adds a native warm data tier to an SAP HANA database, managing page-loadable warm data  in the SAP HANA database with expanded disk capacity, and an intelligent buffer cache to transfer pages of data between memory and disk. It integrates disk-based database technology with the SAP HANA in-memory database for an improved cost-to-performance ratio, while complementing other warm data tiering solutions such as SAP HANA extension node and SAP HANA dynamic tiering. However, it is important to note that SAP HANA native storage extension does not interfere with the existing data aging functionality of SAP HANA. It neither replaces data aging nor changes any aging processes and access in SAP S/4HANA. The SAP S/4HANA data aging tables still remain under the full control of SAP S/4HANA and they must not be changed as any changes to the database tables outside of SAP S/4HANA may result in SAP S/4HANA failure. Non-active data concept for SAP BW/4HANA and Nearline Storage Solutions (SAP Note 1767880 and SAP Note 2165650) Large SAP BW systems contain large amounts of data that are no longer, or rarely, used. However, they remain in the system, for example, historical data, keeping data for legal reasons, and so on. This data is called nonactive data. An implementation for SAP BW/4HANA allows for the displacement of nonactive data if the main memory bottlenecks use a last-recently-used concept. This concept improves main memory resource management, which has positive effects on hardware sizing for a large amount of nonactive data. For more information, see SAP Note 1736976. In addition, nearline storage solutions could be used to store cold data, which can also help to reduce the memory amount. SAP HANA Smart Data Access 2.0 (SAP Note 2352696) SAP HANA smart data access lets you access remote data via SQL queries as if they are local tables in SAP HANA. You don't need to copy the data into SAP HANA first. This capability provides operational and cost benefits and supports the development and deployment of the next generation of analytical applications, which require the ability to access, synthesize, and integrate data from multiple systems in real-time, regardless of where the data is located, or what systems are generating it. Deprecated: SAP HANA 2.0 Dynamic Tiering (SAP Note 3414255) SAP HANA dynamic tiering is an optional add-on to the SAP HANA database for managing historical data. Its purpose is to extend SAP HANA memory with a disk-centric columnar store (as opposed to SAP HANA’s in-memory store) for managing less frequently accessed warm data. Warm data has relaxed performance requirements compared to highly active "hot" data. Data in the extended store is on line, and available for both queries and updates. Although it is possible to add dynamic tiering to small SAP HANA databases, dynamic tiering  is targeted at SAP HANA database sizes of 512 GB and larger, where large data volumes begin to necessitate a data lifecycle management solution. Identifying Supported SAP HANA Hardware SAP HANA Hardware Options SAP HANA Hardware Directory Certified SAP HANA hardware can be found at the SAP HANA hardware directory. The SAP HANA hardware directory lists all hardware that has been certified or are supported under the following scenarios: Hardware that has been certified within the SAP HANA hardware certification program Previously validated hardware based on Westmere technology, as reflected earlier in the Product Availability Matrix (PAM) Supported Intel® Systems: Only single-node systems with minimum eight cores per supported Intel architecture and valid for particular SAP HANA SPS releases SAP HANA Setup Scenarios Consistent documentation for the group of appliances is applicable for all SAP HANA setup scenarios, including single node, scale-up, and scale-out, as follows: Scale-up (single-host) BWoH/BW4H/DM/SoH/S4H includes hardware approved for all single-server configuration scenarios for SAP BW, powered by SAP HANA, SAP S/4HANA. SoH/S4H includes additional single-server configurations specific for SAP Business Suite powered by SAP HANA and SAP S/4HANA, not covered by scale-up: BWoH/BW4H/DM/SoH/S4H. Scale-out (Multi-host) BWoH/BW4H/DM includes multi-server configuration scenario for SAP BW powered by SAP HANA. S4H includes multi-server configuration scenario for SAP S/4HANA (see SAP Note 2408419 – SAP S/4HANA – Multi-Node Support). Note BWoH = BW on HANA BW4H = BW for HANA DM = Data Mart SoH = Suite on HANA S4H = SAP S/4HANA Hardware Supported by SAP HANA A list of all certified and supported hardware can be found in the SAP HANA hardware directory. The link can be found in the SAP Note 2622671 – SAP HANA Certified and Supported Hardware. Use that list to determine the required hardware. The SAP HANA hardware and cloud measurement tool allow you to check the interoperability of SAP HANA with your existing enterprise storage, network, and server in production environments. The SAP HANA hardware and cloud measurement tool provide tests and reports for new single host and scale-out systems to determine if the hardware you intend to use meets the minimum performance criteria required to run SAP HANA in production use. The tools consist of the SAP HANA hardware and cloud measurement tool, which can be downloaded from the SAP Support Portal, and the SAP HANA hardware and cloud measurement analysis, which is available online. For more information about installing and using the tools, see SAP Note 2493172 – SAP HANA hardware and cloud measurement tool. Identifying the Linux Operating System Requirements Linux Operating System Requirements Business Example You need to set up the Linux operating system so that all of the SAP HANA requirements are fulfilled and you can start the SAP HANA installation. Operating Systems Supported by SAP HANA Depending on the CPU architecture used, SAP HANA is available on the SUSE Linux and Red Hat Linux. Before starting the SAP HANA installation, make sure that you have followed the recommendations made in the SUSE (SLES) and Red Hat (RHEL) specific SAP Notes. Supported Operating Systems for SAP HANA on Intel-Based Hardware Platforms For an SAP HANA system on Intel-based hardware platforms, both SUSE and Red Hat are supported for SAP HANA 2.0. Use the recommended OS setting SAP Notes from the following list to optimize the Linux operating system settings even further: SAP Note 1944799 – SAP HANA Guidelines for SLES Operating System Installation SAP Note 2578899 – SUSE Linux Enterprise Server 15: Installation Note SAP Note 2684254 – SAP HANA DB: Recommended OS settings for SLES 15 / SLES for SAP Applications 15 SAP Note 2205917 – SAP HANA DB: Recommended OS settings for SLES 12 / SLES for SAP Applications 12  SAP Note 2772999 – Red Hat Enterprise Linux 8.x: Installation and Configuration SAP Note 3108316 – Red Hat Enterprise Linux 9.x: Installation and Configuration SAP Note 3108302 – SAP HANA DB: Recommended OS Settings for RHEL 9 SAP Note 2777782 – SAP HANA DB: Recommended OS Settings for RHEL 8 SAP Note 2292690 – SAP HANA DB: Recommended OS settings for RHEL 7 Supported Operating Systems for SAP HANA on IBM Power Servers With the introduction of SAP HANA 2.0, the supported operating systems list was extended to include SUSE SLES 12 SPx or SLES for SAP Applications 15 SPx and Red Hat. RHEL 7.3 or newer and RHEL 8.x. To make sure that the Linux operating system is configured according to the SAP standards, use the recommended OS setting given in the SAP Notes from the following list. For an SAP HANA system on IBM Power servers, the following operating system is available for SAP HANA 2.0: SAP Note 2055470 – HANA on POWER Planning and Installation Specifics – Central Note SAP Note 2188482 – SAP HANA on IBM Power Systems: Allowed Hardware SAP Note 2554012 – FAQ: SAP HANA big-endian to little-endian Migration for IBM Power SAP Note 2537080 – Migrate SAP HANA 1.0 on IBM Power Systems big-endian to SAP HANA 2.0 on IBM Power Systems little-endian SAP Note 2684254 – SAP HANA DB: Recommended OS settings for SLES 15 / SLES for SAP Applications 15 SAP Note 2205917 – SAP HANA DB: Recommended OS settings for SLES 12 / SLES for SAP Applications 12 SAP Note 3108302 – SAP HANA DB: Recommended OS Settings for RHEL 9 SAP Note 2777782 – SAP HANA DB: Recommended OS Settings for RHEL 8 SAP Note 2292690 – SAP HANA DB: Recommended OS settings for RHEL 7 Hint SAP strongly recommends using "RHEL for SAP Solutions" or "SLES for SAP Applications" due to their additional features, optimized setup for SAP applications, and extended support cycles. File Systems Supported by SAP HANA In general, the Linux distributions support many file systems. Depending on the application that you run on the Linux OS, not every file system is supported. In the SAP environment, the supported file system types depend on the used application, for example, ABAP or Java application server, or used database, for example, SAP HANA or MS-SQL server. For non-SAP applications, the recommendations are supplied by the respective third-party application vendors. This applies in particular to the SAP HANA database system. Only file systems that were tested successfully are supported for SAP HANA. Supported file systems can be found in the SAP Note 2622671 – SAP HANA Certified and Supported Hardware. The file system recommendations are only valid for the SAP HANA data volume, log volume, and backup volume. Make sure that you follow these recommendations to avoid problems like performance degradations, inconsistencies, or terminations. Single-Host File System Setup The figure, Single-Host System, shows the file system layout for a single-host system. The file systems Installation Path, Data path, and Log path are located on the shared storage, which makes it easier to expand this configuration to a multi-host SAP HANA system. Multi-Host File System Setup The figure, Multi-Host System, shows the file system layout for a multi-host system. Here, all hosts connect to the shared storage file system Installation Path so that they all use the same SAP HANA kernel and configuration setting. In the shared storage file system Data path and Log path, every host connects to a separate mnt0000x directory. Which hosts connects to which directory is handled by partition numbers that were created during the installation. This partition assignment isn't fixed, because in a high-available scenario, the standby host needs to take over the partition number of the failing host. SAP HANA Disk Space Layout The figure, Disk Space Layout, shows a list of the most important file systems to include on an SAP HANA host. As these values can change over time, it is important that you always check the current SAP HANA installation guides and SAP installation notes. For patching, you will need approximately 5 GB free space in your working directory. Hint SAP strongly recommends that you keep the data and log volumes on different disks. Outlining how to use the Hardware Measurement Tool SAP HANA Hardware and Cloud Measurement Tool Downloading and Installing the SAP HANA Hardware and Cloud Measurement Tool Download and set up the SAP HANA hardware and cloud measurement tool (HCMT) to be able to measure whether the infrastructure planned for SAP HANA deployment meets the system and performance requirements that are needed for certification. Caution The test should only be used before going into production. Because the tests stress the system to the maximum, it is not possible to use the tools in production systems. Before you can download and install the HCMT application, you need to have a valid S- user for accessing the SAP Support Portal, the latest version of SAPCAR, and have read the latest version of SAP Note 2493172 – SAP HANA Hardware and Cloud Measurement Tool. Perform the following steps to download and install the HCMT application: Download the HCMT application using the search function of the SAP Support Portal (https://launchpad.support.sap.com/#/softwarecenter/search). In the search field, search for HANA CLOUD OPTIM. In the search results, select the HANA HW CLOUD OPTIM TOOLS 2.0, and download the latest version that fits your CPU architecture. Unpack the downloaded HCMT archive using the command: SAPCAR -vxf HCMT_0XX_0-80003261.SAR Change into the extracted setup directory with the command: cd setup  Install the HCMT application by starting the hcmtsetup application with the command:./hcmtsetup Test the HCMT application installation by listing an overview of all available test using the command:./hcmt -l System Configuration and Performance Measurement The measurement enables you to decide whether the system planned for SAP HANA deployment meets the desired system and performance requirements. The SAP HANA hardware and cloud measurement tool performs a series of automated tests, for example, network tests, file system consistency tests, system management BIOS tests, and CPU benchmark tests. The duration and repeat rate of the tests depends on the type of execution plan that you intend to run. The following execution plans are available: executionplan.json – Default execution plan that helps you to check if the KPIs for SAP HANA certification are met. full_executionplan.json – Performs the same tests as the default execution plan, but has a higher test repeat rate and thus a longer test duration. This test is required for SAP HANA certification. SAP HANA Hardware and Cloud Measurement Tool Checks The following checks are executed by the SAP HANA hardware and cloud measurement tool: CPU Micro Benchmark (CPU Benchmark Test) Benchmarks CPU performance on number of found primes during search period, number of floating point arithmetic operations (+,-,*,/) per second, and number of integer arithmetic operations (+,-,*,/) per second. NUMA Timer Test (NUMA Timer) Measures NUMA node timer behavior. To optimize its internal resource use and calculation, SAP HANA extensively uses the capabilities of the underlying Intel Xeon chipset family. In most cases, the resource management and optimization are handled directly in the SAP HANA database kernel rather than using the operating system capabilities. To continually improve performance, SAP strives to optimize the use of CPU cores and memory, also in relation to NUMA awareness. In case of virtualization through a hypervisor, SAP HANA hence requires a read-only guest SDK that provides a kind of mapping table between vCPUs and physical NUMA cores as well as between virtual memory and physical NUMA nodes. NUMA Memory Latency Test (NUMA Memory Latency Test)  Measures NUMA node memory latency. A Simple NUMA Memory Latency Check and a Simple NUMA Memory Latency Check are performed. NUMA Memory Bandwidth Test (NUMA Memory Bandwidth Test) Measures NUMA node memory access bandwidth. File System Write Test (File System Write) Storage testing measures data throughput and latency between SAP HANA computing nodes and the external storage system. To perform the test, it is not necessary that SAP HANA software is installed on the system. The test uses the same libraries for file system access and the same I/O patterns as SAP HANA does. The process of measurement is related to the I/O engine of the SAP HANA database to ensure that the projected results meet the requirements of SAP HANA. The SAP HANA I/O engine uses the AIO interface and some operations are not well represented in some file systems such as ext4. This means that certain types of file-enlarging writes are completely unsupported and block all other activities for the entire duration of the operation. File System Read Test (File System Read) Storage testing measures data throughput and latency between SAP HANA computing nodes and the external storage system. To perform the test, it is not necessary that SAP HANA software is installed on the system. The test uses the same libraries for file system access and the same I/O patterns as SAP HANA does. The process of measurement is related to the I/O engine of the SAP HANA database to ensure that the projected results meet the requirements of SAP HANA. The SAP HANA I/O engine uses the AIO interface and some operations are not well represented in some file systems such as ext4. This means that certain types of file-enlarging writes are completely unsupported and block all other activities for the entire duration of the operation. NUMA Jobs Query Performance Test (NUMA Query Performance) Measures NUMA node query performance. With this test brutto/netto scan operations per second and the overhead time are measured. NUMA Jobs Throughput Performance Test (NUMA Throughput) Measures NUMA node throughput. With this test brutto/netto scan operations per second and the overhead time are measured.  Network Device Information (Network Device Information) Queries network device information like IP address, device name, max. speed in Mbits/s and TCP segmentation offload. Network Loopback Test (Network Loopback Adapter) Measures network speed using the network loopback adapter. The networking test module tests the network behavior with the same network properties and communication stack used in SAP HANA. It measures the minimum bandwidth of the intra-node network, that is, the bandwidth available between the SAP HANA computing nodes that comprise a scale-out system. The tool consists of a server and a client component. To perform a point-to-point network test, it is necessary to start the server component on one of the servers and connect it to the client component on another server in the SAP HANA cluster. To check the network performance, all network combinations between the servers in the SAP HANA cluster must be measured. Network Topology Test (Network Topology Test) Checks the network performance between computer nodes. Process Tree Information (System Process Tree) Collects system process tree data. System Management BIOS (System Management BIOS) Collects system management BIOS data. File System Mounts (File System Mounts) Analyzes the file system configuration. Running Processes (Process List) Lists all running processes. Installed Packages (Installed Packages) Collects the installed packages and validates against given prerequisites. Hyper-Converged Consistency Check (File System Consistency)  Checks hyper-converged infrastructure systems for file system consistency. CPU States (Processor C States) Collects the power setting states for all processors. Landscape Test (Landscape Test) Collects detailed system information and logs from the SAP HANA system landscape and uses this information to validate OS configuration and check the consistency of the landscape. The SAP HANA hardware and cloud measurement tool supports both Internet Protocol version 4 (IPv4) and version 6 (IPv6). However, all hosts must use the same IP version. A combination of different IP versions is not supported. Measure System Configuration and Performance on Single Host Systems Before you can run the HCMT application on a single host system, you need to make sure that the system meets the minimum requirements for running the tool. The prerequisites are as follows: You have installed the latest version of the SAP HANA hardware and cloud measurement tool on the system. You have at least 20 GB of free storage space in the location where SAP HANA data can be placed during the test. When using nonvolatile memory, mounts for all hosts or an alias of the same name must be available. Port 50001 must be open for communication. Now you can start a measurement on the single host system to check whether the system planned for SAP HANA deployment meets the requirements. The measurement tool executes a series of tests based on the execution plan that you specify. The two main execution plans are named executionplan.json and the full_executionplan.json. You can find these in the config directory. You will find several more execution plans in the config directory, but they are to be used for a scale-out system test or are smaller subsets of the two main execution plans. Note The executed tests in the executionplan.json and the full_executionplan.json file are identical, only the test repeat rate is higher. Start the measurement tool in verbose mode using the following command: hcmt -v You can now interactively adjust the variables or accept the default values. The following table shows the adjustable variables: Default Variable name Description value Specify the location where logs should be written. /hana/log Specify an existing location where SAP HANA data can be /hana/data placed. If persistent memory is available, specify the mount paths of this persistent memory separated by commas. If no persistent memory is available, leave empty. Leave empty. It will run the test on the local host. The results of the measurement are saved in the hcmtresult- [timestamp].zip file. How to upload the results to the SAP HANA hardware and cloud measurement analysis for a more detailed analysis will be explained later in this lesson. Measure System Configuration and Performance – Scale-out Systems Before you can run the HCMT application on a scale-out system, you need to make sure that the system meets the minimum requirements for running the tool. The prerequisites are as follows: You have installed the latest version of the SAP HANA hardware and cloud measurement tool on the system.  You have at least 20 GB of free storage space in the location where SAP HANA data can be placed during the test. When using nonvolatile memory, mounts for all hosts or an alias of the same name must be available. Port 50000 and 50001 must be open for communication. Now you can start a measurement on the scale-out system to check whether the system planned for SAP HANA deployment meets the requirements. For scale-out systems, you start the measurement tool on the coordinator host and specify any worker hosts on which the tests should run as well. The tool reads the execution plan, starts the test locally, and delegates tests marked for scale-out to the worker hosts. The tool waits for the completion of the tests on the worker hosts before starting the next test in the execution plan. All test measurement data and the host manifests are collected in one result file written by the coordinator host instance. Starting the Measurement Tool on a Scale-Out System Start the measurement tool on all worker hosts in verbose mode by executing the command:./hcmt -v -S Start the measurement tool on the coordinator host in verbose mode by executing the command:./hcmt -v Adjust the following variables that are contained in the execution plans: Default Variable name Description value Specify the location where logs should be written. /hana/log Specify an existing location where SAP HANA data can be /hana/data placed. If persistent memory is available, specify the mount paths of this persistent memory separated by commas. If no persistent memory is available, leave empty. Specify, in no particular order and separated by commas, the remote hosts that you want to measure. You do not have to enter host 1, because it is included automatically in the measurement. Analyzing the Measurement Results Upload the measurement results file and analyze the results to see whether your systems meet the configuration and performance requirements. You use the SAP hardware and cloud measurement analysis to upload the measurement results file and analyze the setup and performance of the systems that are intended for SAP HANA deployment. Use the SAP HANA Hardware and Cloud Measurement Tool Aalysis Service to review the results. Adding Systems to the SAP HANA Hardware and Cloud Measurement Analysis Before you can upload the measurement data, you need to add a system. To add a system, you need to specify the system details, for example, the system name, deployment model, and anticipated number of users. Perform the following steps to add a system to the SAP HANA hardware and cloud measurement analysis Web site. 1. On the SAP HANA hardware and cloud measurement analysis start page, choose the Manage Your Systems link. 2. On the System/Measurement pane, choose the + (Add System) button. 3. In the Add New system pane, enter the system details like the system name, deployment option, memory size, and the anticipated number of users. 4. To store your entries, choose the Save button. Uploading Measurement Results Upload the measurement results file and display the results to see whether your systems meet the configuration and performance requirements.  1. Select the system for which you want to upload the measurement data, and choose the Upload Measurement button. 2. In the Add Measurement screen, specify a name for the measurement and the system that has been measured. 3. In the Add Measurement screen, choose the Browse … button. 4. In the Open pop-up windows, search for the measurement results zip file, and select it. 5. To import the measurement results zip file, choose the Open button. 6. Review your entries and submit the file. You uploaded the results file for the corresponding system and can now display and further analyze the measurement results. Analyzing the Measurement Results SAP HANA hardware and cloud measurement analysis provides a graphical and textual representation of your measurement results. It allows you to see which parts of your system are doing well and which parts may need some changes or improvements to achieve the required performance. You can display the results of the system measurement and drill down into test and measurement details. To display more detailed information regarding systems, measurements, individual tests, parameter sets, or single measurements in the Selection Details pane, select one of the items mentioned. To display the information for more than one item, use Ctrl and select the desired items. If you select Filter Measurements, only measurements related to KPIs and certain other important measurements are displayed. Note that you can't adjust the filter settings yourself. The information on the Systems/Measurements pane is displayed as indicated in the table. Hierarchy level Hierarchy level detail info Selection Details info Additional data regarding the system, for Name of the system that you example, the overall analysis result in 1. System specified. percent, number of users, creation time, or the number of measurements. Name of the measurement that Additional data regarding the 1.1 you specified when uploading the measurement, for example, memory, tool Measurement results file. set, or machine topology. Name of the tests that have been Overall result of the test and additional 1.1.1 Individual carried out, for example, information, which may assist you in Test FileSystem Read or FileSystem optimizing your system. Consistency. 1.1.1.1 Collect The results for all parameter sets of this - All particular test. This means that you don’t  Hierarchy level Hierarchy level detail info Selection Details info have to select each individual parameter set to compare different block sizes or log volumes in the FileSystem Write test, for example. Parameter set for which the tests 1.1.1.2 have been carried out, for Details of the parameter set for the test. Parameter Set example, different block sizes or log volumes. The results of the individual measurements displayed as a graph or text. Most test results are displayed Individual measurements for a graphically, that is, in a bar or graph 1.1.1.3 Single given parameter set, for example, chart. When you hover the mouse Measurements AsynchronousSubmitTime, over the bar, you see the detailed Latency, or LatencyNumOps. results, for example, the name of the measurement, KPI value, and measurement value. In addition, you can also choose to view the results in a table or download the table to a *.csv file. The tool performs several measurements, some of which are related to parameters that ensure your system can achieve high performance. Others are target KPIs that must be met to pass certification. These KPIs are labeled as such and the required target values are displayed in the charts. The analysis results are displayed as a percentage of the number of tests that meet the requirements defined by SAP. If all requirements are met, the analysis result is 100% and represented by a green bar. If any thresholds or KPIs are not met, the percentage is lower and displayed by a red bar. If there is no bar shown, then the analysis does not entail KPIs that are relevant for certification, but other performance indicators. Installing SAP HANA 2.0 SAP HANA Lifecycle Management Tools Platform Lifecycle Management Tools You can customize platform lifecycle management aspects of your SAP HANA system by accessing the SAP HANA database lifecycle manager from three user interfaces: the graphical user interface, the command-line interface, or the Web user interface in a stand-alone Web browser via the SAP HANA cockpit. SAP HANA platform lifecycle management encompasses the installation and update of an SAP HANA server, mandatory components, and additional components, as well as the post-installation configuration. The complete concepts and procedures for SAP HANA platform installation and update are described in the SAP HANA Server Installation and Update Guide on the SAP Help Portal. Several system configuration features are integrated into the SAP HANA database lifecycle manager, such as the following: The initial configuration of your SAP HANA platform to integrate it into your landscape. For example, by registering it in a system landscape directory, or configuring the usage of the network interface via the inter-service communication Adapting the topology of your SAP HANA platform by adding or removing additional SAP HANA hosts Reconfiguring the system SAP HANA Database System Terminology It is important to understand the following terms as they apply to the SAP HANA database system: Host A host is the (virtual) hardware and operating environment in which the SAP HANA database system runs. SAP HANA is supported on SUSE Linux Enterprise Server and Red Hat Enterprise Server. The host provides all the resources and services (CPU, memory, network, and storage) that the SAP HANA database system requires. The storage for an installation does not have to be on the host; it can be shared storage as well. Multi-host SAP HANA database systems require shared storage or storage that is accessible on demand from all hosts. SAP HANA Database System An SAP HANA database system consists of one or more SAP HANA instances with the same SAP HANA and instance number. The term SAP HANA database system is interchangeable with the term system. An SAP HANA database system can be distributed over several hosts. In such a distributed system, each instance must have the same SAP HANA and SAP HANA Instance number. The SAP HANA  The SAP HANA is the name of your SAP HANA database. This is assigned during the installation, and is unique throughout your organization. The consists of exactly three alphanumeric characters, and it contains only uppercase letters. The first character has to be a letter. Instance Number The SAP instance number is a two-digit number between 00–99. In the SAP HANA database system all the instances have the same instance number. SystemDB database The system database contains information about the system as a whole, as well as all its tenant databases. It is used for central system administration. A system has exactly one system database. It contains the data and users for system administration. System administration tools, such as the SAP HANA cockpit, can connect to this database. The system database stores overall system landscape information, including knowledge of the tenant databases that exist in the system. However, it doesn't own database-related topology information, that is, information about the location of tables and table partitions in databases. Database-related topology information is stored in the relevant tenant database catalog. Administration tasks performed in the system database apply to the system as a whole and all of its databases (for example, system-level configuration settings), or can target specific tenant databases (for example, backup of a tenant database). Tenant Database SAP HANA supports multiple isolated databases in a single SAP HANA system. These are referred to as tenant databases. An SAP HANA system is identified by a single system ID (SID). Databases are identified by a SID and a database name. From the administration perspective, there is a distinction between tasks performed at system level and those performed at database level. Database clients, such as the SAP HANA cockpit, connect to specific databases. All the tenant databases share the same installation of SAP HANA database system software, the same computing resources, and the same system administration. However, each tenant database is self-contained and fully isolated with its own: Set of database users Persistence Backups  Traces and logs Database catalog Repository Application Lifecycle Management Tools SAP HANA application lifecycle management tools can be accessed in different user interfaces: an interface that runs as an SAP HANA XS application in a Web browser, a command-line tool hdbalm, or via the SAP HANA cockpit. SAP HANA application lifecycle management supports you in all phases of the lifecycle of an SAP HANA application or add-on product, from modeling your product structure, through application development, transport, assembly, to install and update products that you have downloaded from SAP Support Portal or which you have assembled yourself. All application lifecycle management tasks are documented in the guide SAP HANA Application Lifecycle Management on the SAP Help Portal. SAP HANA database system administrators use SAP HANA platform lifecycle management mainly to install and update SAP HANA applications or add-on products. During this course, we will only focus on these tasks of the SAP HANA platform lifecycle management. Tasks related to SAP HANA development are documented in the SAP HANA Developer Guide for SAP HANA Web-Based Development Workbench on the SAP Help Portal. Supported SAP HANA Single- and Multiple-SID Installations The SAP HANA lifecycle management tools allow you to install single- and multi-SID systems. When installing a multi-SID system, the instance numbers and the SIDs must be different. SAP supports running multiple SAP HANA systems represented by multiple system IDs (SIDs) on a single production SAP HANA hardware installation (or single virtual machine). See SAP Note 1681092 for the details on supported single host systems. SAP also supports running multiple SAP HANA systems represented by multiple system IDs (SIDs) on a production scale-out hardware installation. For more information, see SAP Note 2680623 for the details on supported single host systems. Note Keep in mind that multi-SID requires significant attention to various detailed tasks related to system administration and performance management. SAP HANA Installation Tool The HDBLCM User Interfaces The SAP HANA platform lifecycle management tool can be used to install and update an SAP HANA database system and to add mandatory components and additional components. Note The graphical user interface supports fewer actions than the command-line version. The SAP HANA database lifecycle management tool also provides a browser-based user interface, but this can only be used for SAP HANA updates and several other lifecycle management tasks. Location of the HDBLCM Tools The SAP HANA database system can be installed using the command-line user interface or by using a graphical user interface. For advanced tailored data center integration (TDI) installations, the command-line interface with a configuration file is the best option. The location for the HDBLCM tools depends on the download location and the CPU architecture used. From your base, the tools are to be found in the following locations:  HDBLCM (Intel based): Code snippet 1 //DATA_UNITS/HDB_LCM_LINUX_X86_64 HDBLCM (IBM Power): Code snippet 1 //DATA_UNITS/HDB_LCM_LINUX_PPC64 HDBLCM via the Command-Line Interface The command-line version of the HDBLCM can be used if you don’t have a graphical user interface installed on your Linux server. On an Intel-based system, to start the HDBLCM, connect to the SAP HANA server using ssh, and execute the following commands as root user: Code snippet 1 2 cd //DATA_UNITS/HDB_LCM_LINUX_X864 3 and start the application: Code snippet 1./hdblcm HDBLCM via the Graphical User Interface If you have a graphical user interface installed on your Linux server, the graphical user interface version of the HDBLCM can be used. On the graphical desktop as root user, use the file explorer to change to the directory: Code snippet 1 cd //DATA_UNITS/HDB_LCM_LINUX_X86_64 and start the application: Code snippet 1./hdblcmgui There are many options to connect to the X Window System – you can use VNC, tunnel X Window over ssh, or even use Remote Desktop via xrdp. Describing Advanced Installation Options Advanced Installation Options Business Example You want to install several SAP HANA systems and need insight to the advanced, batch-oriented installation methods that are available for installing multiple SAP HANA systems. Installation automation is designed for those who are familiar with SAP HANA and are installing it regularly in various production environments. It refers to the installation of SAP HANA database systems using the batch mode, with a combination of a configuration file and call options passed on to the command line. To provide flexibility, you can install the same SAP HANA database system in several ways. The differences between the installation methods are best shown by a one-to-one comparison of the same system installed with each available method. The following figure shows the specifications for an installation as an example. These parameters reflect a minimalistic approach by providing at least all mandatory parameters and their values, in order to execute an unattended installation without the need of further user interaction. For such a demand, various installation methods can be used. The follow-up examples show the use of the command line with fully qualified options, and even the batch execution of an installation with a formerly created (and maintained) parameter installation file. Using the Command Line The hdblcm tool on the command line can be used in the two different ways. Both methods can be used in a batch mode, which does not require any user interaction, as the following options show: Command line options (in batch mode) Configuration file (in batch mode) Using the Command Line with Parameters in Batch Mode When using the option --batch, the parameters specified on the command line are used and the default parameters are accepted without conformation. As shown in the figure, it is even possible to provide the mandatory parameters for the passwords on the command line. However, avoid providing the password on the command line like this because the statement is stored in the history file on Linux. Instead, create a configuration file that holds all the required parameters and values, including passwords. Alternatively, there are safeguarding options to store the passwords in an explicit xml-file and start the installation in batch mode with a parameter, which reads the passwords from this file. If you do not use the --batch option, the SAP HANA installation is performed semi- automatically. The parameters specified on the command line are used, but the installer must still confirm the default parameter values. Caution The password parameters are mandatory, so values must be provided interactively or using a file. For details, read the sections Specifying Passwords and Tutorial: Installing a Single-Host System with Passwords Read from XML Standard Input Stream or even protect this file with a signature in the SAP HANA Server Installation and Update Guide. Generating a Configuration File with Installation Parameters The SAP HANA database lifecycle manager (HDBLCM) uses default values during installation, unless you decide to change them via the command line options, or via a configuration file that contains the parameters you want to change. To generate a configuration file template using the SAP HANA platform lifecycle management tool, execute the following command: Code snippet 1./hdblcm --dump_configfile_template=/root/hdblcmTemp.cfg The parameter template file lists parameters in sections like General, Server, Client, and some others. Within those sections, the corresponding parameters can be found with a short description and possible values, which is useful as a kind of value help. For some generic use cases, this function might be sufficient. Nevertheless, the parameters are described in the SAP HANA Server Installation and Update Guide.  Hint The SAP HANA Server Installation and Update Guide covers details in the unit Parameter Reference. The complete list of changeable parameters is documented there. Using a Configuration File in Batch Mode To perform an automated installation with the SAP HANA lifecycle management hdblcm tool, you must combine the configuration file and the batch mode. Note that until now, you had to enter passwords interactively or specify them on the command line. Batch mode is designed to automate the installation process. Batch mode runs the installer without asking for any confirmation or parameter entry. This allows the installation to run to completion without any user interaction. It can be started from the command line with the use of a configuration file. With the configuration file and batch mode, the SAP HANA installation is installed completely without user interaction. This is useful if you want to set up many systems with a standard setup, or if you want to redeploy a system on a weekly basis because of system copies. Users Created During Installation The adm User The user adm is the operating system user required for administrative tasks such as starting and stopping the system. This user is created/validated during the installation by the HDBLCM tools. The user identifier (UID) of the adm user is defined during the system installation. The password of the adm user is set during installation with the password parameter. If you do not want the operating system user adm and its primary group to be created automatically, you can create it before installation. This might be the case if you use central user management such as Lightweight Directory Access Protocol (LDAP) or Network Information System (NIS). The SAP HANA database lifecycle manager (HDBLCM) will not modify the properties of any existing user or group. The following requirements apply: The name of the user must follow the schema adm. All letters must be lowercase. The user should have a UID greater than 999. The primary group of the user must be sapsys and the default GID of the sapsys group is 79. The UID of this operating system user and GID of its primary group must be unique and identical on each host of a multiple-host system. The sapadm User This user is the SAP Host Agent administrator. If there is no SAP Host Agent available on the installation host, it is installed during the installation and at the same time the user sapadm is created. If the SAP Host Agent is already available on the installation host, it is not modified by the installer. The sapadm user and password are also not modified. The password of the sapadm user is set during installation with the sapadm_password parameter. If you do not want the user sapadm and its primary group to be created automatically, you can create it before installation. The following requirements apply: The primary group of the user must be sapsys. The default GID of the sapsys group is 79 The GID of the primary group of the sapadm user must be unique and identical on each host of a multiple-host system The SYSTEM User This user is the database superuser. Initially, the SYSTEM user has all system permissions. Additional permissions can be granted and revoked again, however the initial permissions can never be revoked. Assuming it is a standard installation, two SYSTEM users are created: one for the system database and one for the tenant database. The password of the SYSTEM user is set during installation with the system_user_password parameter. The crypt User This user is the trusted local secure store (LSS) user. The user crypt owns the storage of the encryption keys and other similarly sensitive data. This user is created when you decide to install the trusted local secure store (LSS). The user crypt is the only trusted user of the LSS. Only processes called by a trusted user are accepted by the local secure store right away. Troubleshooting a Failed Installation Troubleshooting should be referred to if the installation fails for an unknown reason, or for workarounds in special circumstances. Note As a starting point for troubleshooting a failed Installation, the tool collection of HDBLCM should be taken into account. SAP Note 2078425 can be used be to guided through different questions by answering according to the given situation. Because HDBLCM is used for installations and updates, this note can be used for failures in both scenarios. Accessing the Underlying Installer Components (pass_through_help) Because hdblcm and hdblcmgui are wrapper tools, in some troubleshooting cases, you can pass component options on to the underlying component tools (hdbinst or hdbupd) in combination with the call to the hdblcm or hdblcmgui SAP HANA lifecycle management tools. This might be helpful in case there is a problem with the installation and detailed information from involved components is needed. By using this function, various use cases are supported: Get more detailed information about the component(s), which caused the failed installation or update Use parameters to overcome the problem caused by a component (for example skip a step or set a port via a parameter) Stop or deactivate a specific step or task executed by a underlying component in the installation or update procedure (for example no start of SAP HANA at the end of an update procedure or skip a specific check) To view the available underlying component parameters as extended help output, use the pass_through_help parameter. Specify the action parameter and --help or -h in combination with pass_through_help. To view the help output for the installation or the update pass_through_help parameters, use the following syntax: Code snippet 1 --action=[install|update] --pass_through_help --help 2 or 3 --action=[install|update] --pass_through_help -h These operating system commands can be used to identify the wide range of parameters, which are used in the installation and update procedure, including the syntax, a description, and the use case (install, update, product-specific usage) of an involved component, as well as the XML tags used for the password input stream. At the end of the output environment variables are mentioned to enable the tracer or to create a copy of the log directory. Hint See the SAP HANA Server Installation and Update Guide for a complete list of available pass_through_help parameters. Location of the SAP HANA Temporary Files In addition to the main components installed in the default file systems, you can also locate the temporary files from the SAP HANA system. They can be found in the directories shown in the figure, SAP HANA Temporary Files Location. Enabling the Installer Trace If the installer crashes or loops, it may make sense to trace the installer until the problem occurs, open a CSS ticket, and attach the trace file for further analysis. You can switch on the installer trace by setting the environment variable HDB_INSTALLER_TRACE_FILE to. The directory containing the trace file must already exist. Checking the Log Files The SAP HANA lifecycle management tools hdblcm and hdblcmgui write log files during installation. The most recent log file is always available under /var/tmp/hdblcm.log or /var/tmp/hdblcmgui.log. Additionally, a copy of the log files is archived in the directory hdb__hdblcm__. Since the SAP HANA lifecycle management tools hdblcm and hdblcmgui are wrappers for underlying component installers, it is also possible to check the component logs. It is recommended to review and analyze the SAP HANA lifecycle management tools hdblcm and hdblcmgui logs first. Once the source of the problem is narrowed down to a specific component, then the component logs can be further analyzed. The component log files are stored in the following path: Code snippet 1 /var/tmp/hdb__hdblcm__ 2 where :: = install | update | addhost | uninstall | and so on. The following log files are written while performing the :.log: Can be read using a text editor.msg: XML format for the display in the installation tool with the GUI _tracediff.tgz: Provides a delta analysis of the original trace files, and makes a detailed analysis easier After the trace is generated, you can open it and check the trace file for error messages. If needed, open an SAP support ticket and attach the trace file for further analysis. Illustrating Deployment Options SAP HANA Deployment Options Business Example At the time of its market introduction, SAP offered SAP HANA following an appliance model – a certified combination of hardware and software that could be deployed as an on-premise solution. Meanwhile, SAP is continuously working on increasing the flexibility and choice of deployment options for SAP HANA. For customers, it is essential to understand which deployment options exist, what their capabilities and limitations are, and which scenarios can be combined and run together on one SAP HANA server or database. SAP HANA can be deployed in on-premises, in the cloud, or even as a hybrid deployment where on-premises and cloud are combined. Which option is chosen depends on the customer's requirements. A new customer might start with a 100% cloud strategy in mind, whereas a longtime SAP customer over time wants to move to cloud solutions. With SAP HANA deployment options, you can distinguish between a preconfigured on- premise appliance, SAP HANA tailored data center integration (TDI) deployments, an SAP HANA Cloud deployment, or a hybrid deployment model that combines cloud and on-premise instances. Technical Deployment Options The technical deployment options determine how SAP HANA systems, the hosts used for SAP HANA systems, and applications running on SAP HANA are deployed. To run multiple scenarios on one system or database, you need to understand the availability and capabilities of the technical deployment options. Technical Deployment Options