No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. Please see http://global12.sap.com/corporate-en/legal/ copyright/index.epx for additional trademark information and notices. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.
Typographic Conventions American English is the standard used in this handbook. The following typographic conventions are also used.
This information is displayed in the instructor’s presentation
Lesson: SAP HANA - A Short Introduction Lesson: SAP HANA Information Sources Unit 2:
18 31 39
Unit 3:
123 139 146 165
Installation Lesson: Introduction SAP HANA Lifecycle Management Tools Exercise 1: Install a Single-Host SAP HANA System Lesson: Advanced Installation Options Lesson: SAP HANA Studio installation Exercise 2: Install SAP HANA Studio Lesson: Performing a Distributed System Installation
Unit 4:
88 96 109 114 121
Preparing Installation Lesson: Sizing of SAP HANA Lesson: Requirements
41 49 56 68 73 78 87
SAP HANA Introduction
Post Installation Lesson: Post-Installation Steps Lesson: Updating SAP HANA Exercise 3: Patch SAP HANA Lesson: Revision strategy of SAP HANA
Unit 5:
20 Minutes
Architecture and Scenarios Lesson: SAP HANA Memory Management and Data Persistence Lesson: Software Packaging Lesson: SAP HANA Roadmap and Scenarios Lesson: Deployment Options
Lesson: Administration Tool Overview Lesson: SAP HANA Studio and SAP HANA Cockpit Exercise 4: Connect to the SAP HANA Database and Opening the Administration Console
205 211
Lesson: SHINE - SAP HANA Interactive Education Exercise 5: Install the SAP HANA Interactive Education (SHINE) Content Lesson: DBA Cockpit Exercise 6: Monitor SAP HANA with DBACockpit Lesson: HDBSQL Command Line Tool Exercise 7: Work with HDBSQL
219 231 237 243 249
Unit 7:
Lesson: Starting and Stopping SAP HANA Exercise 8: Start and Stop SAP HANA using SAP HANA Studio Lesson: Configuring SAP HANA
279 286 301 308 337
Exercise 9: Configure SAP HANA Studio Lesson: SAP HANA Table Administration Exercise 10: Table Administration Lesson: Periodic Tasks Exercise 11: Monitor SAP HANA using Administration Console Tools Lesson: Configuring Traces Exercise 12: Configure SAP HANA Traces Lesson: Working with Diagnosis Information and Diagnosis Files Exercise 13: Work with Diagnosis Files Exercise 14: Collect Diagnosis Information Lesson: SQL Console Exercise 15: Analyze Queries Lesson: Transporting Changes Exercise 16: Export Tables Exercise 17: Optional: Transport Changes
Backup and Recovery Lesson: Concept of Backup and Recovery Lesson: Data Area Backup Lesson: Log Area Backup Lesson: Additional Backup Topics Lesson: Recovery Exercise 18: Backup and Recovery Lesson: Backup and Recovery using Storage Snapshot Lesson: Database Copy
High Availability and Disaster Tolerance Lesson: High Availability Lesson: SAP HANA Scale Out Exercise 23: Install an SAP HANA Scale Out System Lesson: Disaster Recovery
Unit 12:
Minutes
Maintaining Users and Authorization Lesson: User Management Lesson: Types of Privileges Lesson: Roles Lesson: Administrative Tasks Lesson: Information Sources for Administrators Exercise 21: Maintaing Administrative Users and Authorization Exercise 22: Optional: Maintain Users and Authorization Lesson: SAP HANA Live Authorization Assistant
Unit 11:
10 Minutes
15 Minutes
Multitenant Database Containers Lesson: Architecture and Technology Lesson: Administration of Multitenant Database Containers Lesson: Backup and Recovery of Multitenant Database Containers
Unit 13:
Appendix Lesson: Monitoring with SAP Solution Manager Lesson: Remote Support Lesson: SAP Early Watch Alert (EWA) Lesson: Appendix
LESSON OVERVIEW This lesson gives you a short introduction about: ●
What is SAP HANA?
●
Which components are part of SAP HANA?
LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Understand the basics of SAP HANA
Approximation to SAP HANA
Figure 1: SAP HANA as a Platform
Some years ago, the SAP HANA database was the fastest database on the market. SAP HANA is an in-memory database and application platform, which is, for many operations, 10-1000 times faster than a regular database, such as Oxxxxx on the same hardware. This allows simplification of design and operations, as well as real-time business applications. Customers can finally begin to reduce IT complexity by removing the need for separate and
multiple Application Servers, Operational Data Stores, Datamarts, and business intelligence (BI) tool implementations. What is the technical secret behind SAP HANA? SAP HANA is different by design. It stores all data in-memory, in columnar format, and compressed. Because SAP HANA is so fast, sums, indexes, materialized views, and aggregates are not required, and this can reduce the database footprint by 95%. Everything is calculated ondemand, in main memory. This makes it possible for companies to run on-line transaction processing (OLTP) and analytics applications on the same instance at the same time, and to allow for any type of real-time, ad hoc queries and analyses. On top of this, SAP built solutions to all of the 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 virtual on-line analytical processing (OLAP) functionality, data virtualization, text analysis, search, geospatial, graph (which will be available soon), and Web. It supports open standards, such as REST, JSON, ODBO, MDX, ODBC, and JDBC. Daily Irritations
The Past Disk-Centric, Singular Processing Platforms
Figure 4: The Past Disk-Centric, Singular Processing Platforms are the Bottleneck
The existing technology was never designed for these challenges and use cases. Long-running transactions cannot keep pace with the speed of information. First and foremost, you need a new technology platform: a unified, low latency, and low complexity platform that can support real-time business requirements. Explosion in data volume is causing major bottleneck in data transfers. I/O transfer rates from storage disks to servers have not kept up with data volumes. Disk-centric computing is
causing major bottlenecks in data management. As a result, users are experiencing slow online transactions and batch processes. To overcome these performance bottlenecks, IT systems have added complex deployment architectures that have compromised business user flexibility, as well as added significant cost. The Future: Low Latency Computing Driven by In-Memory Technology
Figure 5: The Future: Low Latency Computing Driven by In-Memory Technology
So it was time for a change, leveraging the new innovation of the recent years to build software that takes key characteristics into its design principles. Some unique features of in-memory technology are to store massive amounts of information compressed in main memory, utilize parallel processing on multiple cores, and move dataintensive calculations from the applications layer into the database layer for even faster processing. Since all the detailed data is available in main memory and processed on the fly, there is no need for aggregated information and materialized views, fundamentally simplifying the architecture and hence reducing latency, complexity, and cost. In addition, with new multicore multi-threaded processors, 64-bit address space, and advancement in parallel data processing, you can achieve scalability beyond anything that you have seen so far. Application Libraries SAP HANA In-Memory Computing Engine offers various algorithms for in-memory computing. It provides several application libraries for developers, partners, and customers who develop applications that run on SAP HANA. The libraries are linked dynamically to the SAP HANA database kernel. The Business Function Library (BFL) is one of these application libraries. It contains pre-built parameter-driven functions in the financial area. The functions are implemented by C++. The functions include the following: ●
This library helps you to develop compound business algorithms that are fully compliant with the SAP HANA calculation engine. It offers you the flexibility and efficiency to develop SAP HANA-based applications with incredible performance. An example is shown in the figure, SAP HANA Deployment View. SAP HANA Deployment View
Figure 7: One Platform for Any Kind of Application
Component Architecture View
Figure 8: Component Architecture View
SAP HANA INA Toolkit HTML Content The UI Toolkit for INA is a set of widgets that can be used in Web Applications to provide real time access to information stored in an SAP HANA database. You can also use the widgets to provide faceted search features for structured and unstructured text data. For those not familiar with this term, faceted search means returning
results grouped by attribute values instead of a flat list. These groups (facets) enable navigation, filtering, refining, and visualization of the dimensions of the result set. The toolkit is based on HTML5 and JavaScript libraries, such as JQuery/JQueryUI, d3 (Data Driven Documents), Tempo, and FancyBox (in case this means something for you). The widgets consume “search enabled” Attribute Views. Every time you create a “search enabled” Attribute View, the SAP HANA REST service automatically creates an Entity Set, so to be more precise, the widgets consume Entity Sets through the SAP HANA REST service whose responses are provided in JSON format. SAP HANA INteractive (SHINE) SHINE is a demo application that makes it easy to learn how to build native SAP HANA applications. The demonstration application, delivered with SAP HANA in a special delivery unit (DU), comes complete with sample data and design-time developer objects for the application's database tables, data views, stored procedures, OData, and user interface. There is a special lesson about it in this course. More information about SHINE is available in the following file: http://help.sap.com/hana/sap_hana_interactive_education_shine_en.pdf. Enterprise Procurement Model The Enterprise Procurement Model is a Framework developed by SAP and it includes all the data models, tables, views, dashboards and so on, with a real enterprise use case. Application Function Library The Application Function Library includes the Predictive Analysis Library (PAL and Business Function Library (BFL). Predictive Analysis Library (PAL) The Predictive Analysis Library (PAL) defines functions that can be called from within SQLScript procedures to perform analytic algorithms. This release of PAL includes classic and universal predictive analysis algorithms in nine data-mining categories: ●
Clustering
●
Classification
●
Regression
●
Association
●
Time Series
●
Preprocessing
●
Statistics
●
Social Network Analysis
●
Miscellaneous
For PAL and BFL you find separate documents on help.sap.com/hana/. The file loader is a set of HTTP services that you can use to develop your own applications to search in file contents. The file loader package also contains a basic example application with monitoring and statistical information about the current file loader schedule. The SAP HANA HW Configuration Check Tool allows you to measure the performance of your hardware components to ensure that they meet the criteria for running SAP HANA.
LESSON OVERVIEW In this lesson, you learn how to find documents and guidelines for SAP HANA. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Find the most important information sources
The Most Important Information Sources for SAP HANA
Figure 11: The Most Important Information Sources for SAP HANA
You will find many guides at SAP Community Network. The SAP HANA installation guide describes how to install SAP HANA.
The most important guide is the SAP HANA Administration Guide. The Technical Operations Manual provides an end-to-end picture of the administration tools available with SAP HANA and the key tasks that a system administrator needs to perform. Links to the relevant administration documentation of each of the components included in the SAP HANA solution are provided for details and step procedures. The SAP HANA Database Admin Guide describes the administration of the SAP HANA database using the Administration Console of the SAP HANA studio. SAP HANA Content Location Table 1: SAP HANA Content Location Content
Platform Availability Matrix (PAM) With Platform Availability Matrix (PAM), you can use your own storage, but this memory should be certified. The same applies for the appliances. The book, “SAP HANA Administration”, written by Richard Bremer and Lars Breddemann and published by Galileo Press, covers the administration of SAP HANA.
SAP HANA Curriculum Additional courses, which focus on specific aspects of SAP HANA, are available and include the following: ●
SAP HANA — Administration and Operations
●
SAP HANA — Implementation and Modeling
●
SAP — Development
Other SAP HANA courses include the following: ●
SAP HANA Data Provisioning
●
SAP HANA Cloud, Reporting, and Frontend
●
SAP BW on SAP HANA
More information about these courses can be found at https://training.sap.com/de/de/ courses-and-cirricula/hana.
LESSON OVERVIEW The goal of this lesson is to understand what needs to be considered for a correct sizing of SAP HANA for an SAP HANA appliance or an SAP HANA Tailored Datacenter Integration (TDI) approach. In addition to presenting the slides, you can also demonstrate the certified hardware configurations in the SAP HANA Hardware Directory on the http://global.sap.com/ community/ebook/2014-09-02-hana-hardware/enEN/appliances.html Web site. You might also want to show the SAP Sizing Web site; the URL is: http://service.sap.com/sizing. There is now also a new SAP HANA Quick Sizer version available under the URL: http:// service.sap.com/hanaqs
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, that is, to deploy as an SAP In-Memory Appliance (SAP HANA) or to deploy following the SAP HANA Tailored Datacenter Integration (TDI) approach. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Describe what needs to be taken into consideration for sizing of an SAP HANA server
●
Identify where to look up sizing information depending on the SAP HANA scenario
●
Use the SAP Quick Sizer for sizing an SAP HANA database server
●
Describe sizing of main memory, persistence, and CPU
●
Identify where to look up sizing information depending on the SAP HANA scenario
●
Run the SAP Quick Sizer for sizing an SAP HANA database server
General Concept of Sizing in SAP HANA The SAP HANA database can be deployed as an SAP In-Memory Appliance (SAP HANA) or deployed following the SAP HANA Tailored Datacenter Integration (TDI) approach.
Hint: The following information solely refers to the sizing of the SAP HANA database server. Depending on the scenario, sizing of other components. such as the application server, would need to be considered additionally.
As the first step in sizing an SAP HANA system, every SAP HANA customer must perform a memory sizing. Depending on the SAP HANA deployment, the sizing approach differs as follows: ●
●
For new SAP HANA implementations, it is necessary to size the memory for an SAP HANA system using the SAP Quick Sizer in Related Information. For systems that are migrating to SAP HANA, we recommend the following: -
-
●
If the migration is from an SAP NetWeaver based system, use the sizing report on the source database. If the migration is from a non-SAP NetWeaver data source, use the sizing as in SAP Note 1514966.
Any system that is large or complex requires sizing from an SAP sizing expert.
Depending on the used scenario, the following table gives the recommended sizing approach.
Figure 16: SAP HANA Sizing Scenarios
Sizing of the SAP HANA database is based mainly on the required main memory size. The memory size is determined by the amount of data that is to be stored in memory. The data is compressed in SAP HANA. Since the compression factor depends on the used scenario, you cannot guess the amount of memory needed. The memory sizing must always be performed using the Quick Sizer for SAP HANA or the SAP HANA Sizing Reports and SAP Notes.
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, Deployment Options.
Sizing Approach for the SAP In-Memory Appliance If you decide to buy the In-Memory Appliance, you have a selection of certified appliances from certified hardware partners. Check the SAP HANA Hardware Directory for hardware that matches your memory sizing results.
Note: For an In-Memory Appliance, you do not need to consider storage and CPU sizing, because they are included in the certified appliance offering. Calculate the memory requirements using the following SAP notes: ●
SAP Quick Sizer: http://service.sap.com/quicksizer
●
SAP Note 1514966: SAP HANA: Sizing SAP In-Memory Database
●
SAP Note 1637145: Sizing for SAP BW on HANA
●
SAP Note 1736976: SAP BW on HANA Sizing Report
●
SAP Note 1793345: Sizing for SAP Suite on HANA
●
SAP Note 1872170: Suite on HANA memory sizing report The Product Availability Matrix (PAM) on the SAP Support Portal does not show the certified SAP HANA appliances anymore. You will be redirected to the SAP HANA Hardware Directory on the http://global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/ appliances.html Web site.
An overview of the available and certified SAP HANA appliances can be found on the SAP HANA Hardware Directory. The list can be found using the URL http://global.sap.com/ community/ebook/2014-09-02-hana-hardware/enEN/appliances.html.
The KPIs applicable for the certification of SAP HANA appliances are communicated to the SAP HANA Hardware Partners only. 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 preforming an SAP HANA memory sizing.
Sizing Approach for the SAP HANA Tailored Datacenter Integration (TDI) System Next to the black-box appliance approach, a customer can choose to use available hardware or to reuse hardware to save costs, to have more flexibility according to the IT landscape, and to optimize for special requirements. If you decide to build the SAP HANA system based on the SAP HANA TDI approach, you must become TDI certified. For storage sizing recommendations, see the SAP HANA Storage Requirements whitepaper (http://scn.sap.com/docs/DOC-62595) found on the SAP Community Network (SCN).
Sizing an SAP HANA TDI Setup Sizing an SAP HANA TDI 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
Main Memory Sizing As the first step to sizing an SAP HANA TDI system, every SAP HANA customer must perform a memory sizing. Depending on the use case, shown in the figure, Example Sizing Report Result for Suite on SAP HANA memory, you would use the following: ●
SAP Quick Sizer: http://service.sap.com/quicksizer
●
SAP Note 1514966: SAP HANA: Sizing SAP In-Memory Database
●
SAP Note 1637145: Sizing for SAP BW on HANA
●
SAP Note 1736976: SAP BW on HANA Sizing Report
●
SAP Note 1793345: Sizing for SAP Suite on HANA
●
SAP Note 1872170: Suite on HANA memory sizing report
Using the SAP Quick Sizer or the SAP Notes help you to determine the SAP HANA memory size. SAP Note 1793345 and 1872170: Sizing for Suite on SAP HANA These two SAP Notes describes the approach of sizing a Business Suite system on SAP HANA and SAP S/4 HANA. There is also a sizing script attached to these notes.
Figure 18: Example Sizing Report Result for Suite on SAP HANA memory
SAP Notes 1637145 and 1736976: Sizing for BW on HANA These two SAP notes describe the approach of sizing an SAP BW system on SAP HANA. The sizing describes the memory sizing (column, row store, and additional components), the disk sizing for data and log files, and the CPU sizing. There is also a sizing script attached to these notes.
Figure 19: Example Sizing Report Result for SAP BW on SAP HANA
Note: This report ZNEWHDB_SIZE is running with low system load but, depending on the size of your suite on SAP HANA system it takes up to 8 to 12 hours or more. Therefore, we recommend that you test it before in your consolidation system. SAP Note 1514966: SAP HANA: Sizing SAP In-Memory Database This SAP Note describes the sizing of the SAP HANA as it is used, for example, for replication of ERP data coming from an SAP ERP system. In particular, these rules must not be used for sizing SAP BW on SAP HANA and Business Suite on SAP HANA systems.
Figure 20: General SAP HANA Main Memory Sizing Approach
We distinguish between the static and the dynamic RAM requirement. Static data memory requirements The static RAM requirements relate to the amount of main memory that is used for the holding the table data. Static memory sizing of SAP HANA is determined by the amount of data that is to be stored in memory, that is, 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, for calculating the total RAM, the static RAM is multiplied by two.
Note: Read SAP Note 1995460 for SAP HANA supported production scenarios on VMware. Read SAP Notes 1781986, 1825774 and 1950470 Support for Business Suite on SAP HANA
Additional Remarks For various SAP HANA scenarios, native and third party technologies provide features to displace data that is not frequently used either to the SAP HANA persistence or to other database management systems. If such a technology is used, this would need to be taken into account in the main memory sizing. Examples are as follows: ●
Non-active data concept for BW on HANA (SAP Note 1767880) and Nearline Storage Solutions Large BW systems contain large amounts of data that are no longer, or rarely, used, but that should remain in the system (historical data, keeping data for legal reasons, and so on). This data is called non-active data. An implementation for BW on HANA allows the displacement of non-active data if the main memory bottlenecks, leveraging a lastrecently-used concept. This concept improves main memory resource management, which has positive effects on hardware sizing for a large amount of non-active data. For more information, see SAP Note 1736976. In addition, nearline storage solutions could be used to store “cold data”, which can additionally help to reduce the memory amount.
●
SAP HANA Smart Data Access (SAP Note 1879294) SAP HANA smart data access enables remote data to be accessed as if it was stored in local tables. Since the data is not copied to SAP HANA, it does not need to be considered for the main memory sizing of the SAP HANA server.
●
SAP HANA Dynamic Tiering (SAP Note 2225582 - SAP HANA Dynamic Tiering SPS 11 Release Note SAP HANA dynamic tiering is a native big data solution for SAP HANA. Dynamic tiering adds smart, disk-based extended storage to your SAP HANA database. Dynamic tiering enhances SAP HANA with large volume, warm data management capability. By using dynamic tiering to place hot data in SAP HANA in-memory tables, and warm data in extended tables, highest value data remains in-memory, and cooler less-valuable data is saved to the extended store. This can reduce the size of your in-memory database.
Disk Sizing 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. Persistent storage distinguishes between the data volume and the log volume. In the data volume SAP HANA, a copy of the in-memory data persists, by writing changed data to the data volume. The log volume is to ensure 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 is performed, data is persists from memory to the data volume under /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 value net data size on disk plus an additional free space of 20%. The figure, Determining the SAP HANA 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%.
Figure 21: Determining the SAP HANA Data Volume Size
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 is capable of providing 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 5 minutes. The more data changes are executed by write transactions in that period of time, the more redo log segments are written to the log volume under /hana/log/. When sizing the log volume, the following points have to be considered: ●
The redo log must not be overwritten before a Savepoint entry is available in the data volume; otherwise, the SAP HANA database may become unable to restart. Situations may occur where the writing of a Savepoint is delayed, for example if a very high workload needs to be processed during a database migration process in an environment with slow I/O between 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 will keep on growing until all log segments are full.
●
If LOG_MODE = NORMAL is set the redo log must not be overwritten before a backup took place. Therefore, we recommend that you have some extra space available for situations where incidents or faults may interrupt the backup process. That extra space should allow for system administrators to fix and finish the backup process before the log volume runs full.
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, Determine 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”):
Note: For systems with more than 512 GB of in-memory database size, the formula above 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 above, 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 on a shared file system that is exposed to all hosts of a system under /hana/shared/. Therefore, additional space is required for the traces written by the compute node or nodes of the SAP HANA database. Experience with productive SAP HANA installations shows that the bigger the size of the SAP HANA database, the more traces are written. Therefore, the calculation is based on the total memory requirement (RAM). For single-node SAP HANA systems, the recommended disk space for /hana/shared/ is as follows:
Figure 23: Determine Share Single-Host Size
The following are single-node SAP HANA installation size examples:
Determine Share Scale-Out Size For scale-out SAP HANA systems, the recommended disk space for /hana/shared/ depends on the number of worker nodes. Per each four worker nodes of a given scale-out system, a disk space of 1x RAM of one worker is recommended:
Figure 24: Determine Share Scale-Out Size
The following are scale-out SAP HANA installation size examples: ●
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 on a daily basis 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 will have an impact on the overall data throughput of the given backup storage. That is, backup and recovery processes may slow down significantly, if the backup storage cannot guarantee a constant level of data throughput once the number of parallel processes exceeds a certain number. 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 as a rule of thumb it should be sufficient to reserve storage space of about two times the size of the biggest database table.
DB CPU Sizing The CPU requirements for migrating to SAP HANA standalone are difficult to anticipate, as we have no real reference against which to compare. Therefore, the sizing referred to above 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 more or less intensive calculations on DB level.
Figure 26: CPU Sizing Approach
Consider this recommendation as an initial estimation that needs verification. The more users there will be on the system, the less likely will this formula 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 round about 60,000 SAPS. If you want to verify the CPU requirements, a test with the top 5 to 10 “SAP HANA transactions” can be helpful, either within a single user test or a load test.
Sizing SAP HANA Using the Quick Sizer SAP HANA Database can also be sized using SAP Quick Sizer. Go to http://service.sap.com/ quicksizer for further information. The Quick Sizer calculates the following: ●
CPU
●
Disk
●
Memory
●
I/O 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.
Figure 27: SAP Quick Sizer Tool
For an initial sizing recommendation using the SAP Quick Sizer, follow the steps described above. Sample configurations can be checked at http://www.sap.com/benchmark. In SAP Quick Sizer multiple predefined scenarios can be selected, for example: ●
LESSON OVERVIEW This lesson describes the Linux operating system requirements that have to be fulfilled before you can start the installation of an SAP HANA system. This lesson does not replace the “SAP HANA Server Installation and Update Guide” for SPS11 and the SAP HANA installation SAP Notes. 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. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the SAP HANA system concepts and system types
●
Clarify the SAP HANA System concepts and system types
●
Explain the required file system structure and directories and their recommended sizes
System Requirements for SAP HANA Before we start explaining the SAP HANA requirements for the Linux operating system, we first need to explain some terms that are often used in the SAP HANA documentation. SAP HANA systems are available in two types, known as System Types: ●
●
A single-host system is the simplest system installation type. The SAP HANA system is running entirely on one host and the server needs to handle the full query load. A multi-host system is a system with more than one host, which can be configured as active worker hosts or idle standby hosts. This means that load can be balanced between different hosts.
Single-Host System The following figure shows the file system layout for a single-host system.
Multi-Host System The following figure shows the file system layout for a multi-host system.
Figure 29: Multi-Host System
Note: SAP HANA certified hardware partners or owners of a current E_HANAINS are allowed to install an SAP HANA system. In both cases, the hardware running SAP HANA needs to be certified by SAP. Basic Components of an SAP HANA System An SAP HANA system is composed of three main components:
It is important to clearly understand what these terms mean in the context of the SAP HANA system. Host A host is the hardware and operating environment in which the SAP HANA database 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 requires. The storage for an installation does not have to be on the host; it can be shared storage as well. For multi-host SAP HANA systems shared storage or storage that is accessible on-demand from all hosts is required. System A system is one or more instances with the same SAP system ID and instance number. The term system is interchangeable with the term SAP HANA database. If an SAP HANA system has more than one instance, it is distributed over several hosts. The SAP system ID (SAPSID or short SID) is the identifier for the SAP HANA system. Instance An SAP HANA instance is the set of SAP HANA system components that are installed on one host. A system can be distributed as several instances among several hosts, but each instance in a multi-host system must have the same instance number. Standalone SAP HANA System with Single-SID and Multiple-SID Installations The following figure shows two possible single-host SAP HANA system configurations.
Figure 31: Standalone SAP HANA System with Single-SID and Multiple-SID Installations
Operating System and Hardware Requirements SAP HANA is available on the SUSE Linux and Red Hat Linux. Make sure that you use the SAP supported version. Supported Operating System for SAP HANA Before the SAP HANA installation can be started, you must configure the Linux system according to the recommended OS settings for SUSE Linux Enterprise Server (SLES) and Red Hat Enterprise Linux (RHEL).
Note: See SAP Note 2235581 - “SAP HANA: Supported Operating Systems” for an overview of all of the supported Linux versions.
●
●
●
●
●
●
34
SUSE Linux Enterprise Server (SLES) for SAP 11 SP2. See SAP Note 1310037 and 1824819 - SAP HANA DB: Recommended OS settings for SLES 11 SP2 SUSE Linux Enterprise Server (SLES) for SAP 11 SP3. See SAP Note 1310037 and 1954788 - SAP HANA DB: Recommended OS settings for SLES 11 SP3 SUSE Linux Enterprise Server (SLES) for SAP 11 SP4. See SAP Note 1310037 and 2240716 - SAP HANA DB: Recommended OS settings for SLES 11 SP4 SUSE Linux Enterprise Server (SLES) for SAP 12. See SAP Note 2205917 - SAP HANA DB: Recommended OS settings for SLES for SAP Applications 12 Red Hat Enterprise Linux (RHEL) 6.5 for SAP HANA. See SAP Note 2136965 - SAP HANA DB: Recommended OS settings for RHEL 6.6 Red Hat Enterprise Linux (RHEL) 6.6 for SAP HANA. See SAP Note 2013638 - SAP HANA DB: Recommended OS settings for RHEL 6.5
Red Hat Enterprise Linux (RHEL) 6.7 for SAP HANA. See SAP Note 2247020 - SAP HANA DB: Recommended OS settings for RHEL 6.7
Note: See SAP Note 2188482 - SAP HANA on IBM Power Systems: Allowed Hardware Hardware Requirements For a new installation, you need to have at least 20 GB RAM in total just for the software, 15 GB for the basic software plus 5 GB for programs, as well as some space for trace files. The additional memory required for data and log volumes varies according to your requirements. For an update, you also need to allow the space stated, because the old software version is not deleted.
Note: During an installation or update of the SAP HANA database a hardware check is performed, to ensure that the hardware used is supported. The hardware check is a script that is automatically called by the SAP HANA installation tool and aborts the installation process if unsupported hardware is detected. The certified SAP HANA configurations have been designed and tested together with our hardware partners to ensure that the SAP HANA database runs optimally on the used hardware. SAP HANA performance and stability cannot be guaranteed when using unsupported hardware. Hardware Requirements for SAP HANA Network Connection We recommend a dedicated server network communication of 10 GBit/s between the SAP HANA landscape and the source system for efficient data replication. Important Directories and Their Sizes The following figure shows a list of the important file systems that have to be available on an SAP HANA host.
Note: If you want to implement a multi-SID scenario, you have only to start the hdblcm(gui) tool once more with the new SID. An SAP HANA system in a production environment must not share any infrastructure with another SAP HANA system. Hosts running more than one SAP HANA system (sometimes referred to as multi-SID installations) can only be used for non-production purposes such as development, quality assurance, or testing. For production systems with high availability, it is possible to share some temporarily unused resources from the standby hosts. As soon as the standby resources are needed, they must become exclusively available for the production system and are no longer shared. For more details, refer to the high availability information in the SAP HANA Administration Guide.
Caution: We strongly recommend that you keep the data volumes on different disks.
Note: As of SAP HANA SPS09, SAP supports running multiple SAP HANA systems on a single host in production. This is restricted to single host and scale-up scenarios only. Keep in mind that multi-SID requires significant attention to various detailed tasks related to system administration and performance management. For more information read SAP Note 1681092 - Multiple SAP HANA DBMSs (SIDs) on one SAP HANA system
LESSON SUMMARY You should now be able to: ●
Explain the SAP HANA system concepts and system types
●
Clarify the SAP HANA System concepts and system types
●
Explain the required file system structure and directories and their recommended sizes
LESSON OVERVIEW This lesson explains the various SAP HANA Lifecycle Management tools for installing SAP HANA system. In this unit, the SAP HANA LCM tools are explained. The participants install a single host system and the SAP HANA Studio. You, as a trainer, should demonstrate the installation on wdflbmt7194 using hdblcmgui. If you have time, you can demonstrate the installation on wdflbmt7195, using HDBLCM on the command line, or demonstrate the Scale-Out installation on both hosts.
Business Example You want to install an SAP HANA single-host system and are investigating which SAP HANA Lifecycle Management tools are the best to use. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain SAP HANA Lifecycle Management Tools
●
Explain the various installation methods
●
Install SAP HANA as a single-host
●
Install and configure SAP HANA Studio
●
Install the SAP HANA SHINE content
●
Explain a multiple-host system installation
Introduction to SAP HANA Lifecycle Management Tools With the release of SAP HANA SPS09, the SAP HANA lifecycle management (HDBLCM) tools replace all the other tools in the previous releases. The SAP HANA unified installer, the on-site configuration tool, SUM for HANA, hdbinst, and the SAP HANA lifecycle manager tools are all replaced by the, in SPS08 introduced, SAP HANA lifecycle management tools.
Platform Lifecycle Management Aspects The Platform lifecycle management tasks on your SAP HANA system can be performed by using one of the three SAP HANA database lifecycle manager tool user interfaces.
Figure 35: SAP HANA Database Lifecycle Manager User Interfaces
Lesson: Introduction SAP HANA Lifecycle Management Tools
Note: The Web interface can be used stand-alone, via a Web browser, or in the SAP HANA studio. Overview of HDBLCM Tool Tasks SAP HANA platform lifecycle management tools can be used to install, configure, and update an SAP HANA server, adding both mandatory components and additional components. The tools can also be used to perform post-installation configuration tasks.
Note: In general, installation and update is carried out from the installation medium. Configuration tasks are performed using the SAP HANA resident HDBLCM tool.
Figure 36: Overview of HDBLCM Tool Tasks
Location of the HDBLCM Tools What task can be performed by the different HDBLCM tools? Depending on the task, you will need to select the correct HDBLCM tool. The following figure provides an overview of the tools and their specific tasks.
Application Lifecycle Management (ALM) Aspects SAP HANA application lifecycle management tasks can also be performed using different user interfaces. The available interfaces are as follows: ●
A Web interface
●
A command-line tool (hdbalm)
●
ALM integrated in SAP HANA studio
SAP HANA application lifecycle management supports you in all phases of the lifecycle of an SAP HANA application or add-on product, from modelling your product structure, through to application development, transport, assembly, installing, and updating products that you have downloaded from SAP Service Marketplace or which you have assembled yourself. System administrators use SAP HANA application lifecycle management mainly to install and update SAP HANA applications or add-on products.
Using the SAP HANA Platform LCM Tools The SAP HANA database lifecycle manager (HDBLCM) is used to perform tasks such as installing, updating, and configuring an SAP HANA system. The SAP HANA database lifecycle manager is created to help hardware partners and administrators to perform their tasks in an efficient way. The SAP HANA database lifecycle manager can be run with a Graphical User interface, Command-line interface, a Web user interface in a browser, or from the SAP HANA Studio, and it replaces the old tools completely. The first choice to make is which SAP HANA database lifecycle manager (HDBLCM) interface type you prefer to use. You change the default behavior of the LCM tools by using parameters. Parameters can be modified in a number of ways, for example, in the entry field of a graphical interface, as a call option with the program call, or in a configuration file. These options can be mixed and matched depending on the parameters that you need to use and the program interaction mode that you choose.
Figure 38: Many Paths Leading to a Common Goal
Once you have chosen the graphical user, command-line, or Web user interface, you can decide whether you prefer to enter parameter values interactively, or to provide all of the required parameters with the call to the platform LCM tool, and let it run, unattended, to completion. Interactive mode is available for all user interfaces, and is the default mode for program interaction. To use the interactive mode, you simply call the SAP HANA HDBLCM user interface, and enter parameter values as they are requested by the program. Advanced interactive mode involves entering some parameter values interactively and providing some
Lesson: Introduction SAP HANA Lifecycle Management Tools
parameter values as call options or in a configuration file. This is the recommended interaction mode if you would like to modify parameter default values that are not requested in interactive mode. Batch mode is an advanced platform LCM interaction method because all required parameters must be provided with the call to the LCM program on the command line. Batch mode is designed for large-scale platform LCM tasks, which would be time consuming to perform interactively. Platform LCM parameters can be entered interactively (only available for interactive mode or advanced interactive mode), as a call option on the command line, or via a configuration file. If you are performing platform LCM tasks in advanced interactive mode, you can choose any of the three parameter entry methods (or use more than one). If you are using batch mode, you must enter parameter values either as call options to the SAP HANA database lifecycle manager or from a configuration file.
Use the Graphical User Interface to Perform Platform LCM Tasks SAP HANA platform lifecycle management tasks can be performed from a graphical interface. In the following figure, you see an example of the user interface.
Figure 39: hdblcmgui versus Resident hdblcmgui
In general, installation and update is carried out from the installation medium. Configuration tasks are performed using the SAP HANA resident HDBLCM. Start the SAP HANA platform lifecycle management tool hdblcmgui from the appropriate directory.
Use the Command-Line Interface to Perform Platform LCM Tasks SAP HANA platform lifecycle management tasks can be performed from the command line.
In general, installation and update is carried out from the installation medium. Configuration tasks are performed using the SAP HANA resident HDBLCM. Start the SAP HANA platform lifecycle management command line tool hdblcm from the appropriate directory.
Use the Web User Interface to Perform Platform LCM Tasks The SAP HANA database lifecycle manager (HDBLCM) can be accessed as a Web user interface in either a standalone browser or in the Platform Lifecycle Management view within the SAP HANA studio.
Figure 41: Web User Interface for hdblcm
The prerequisites for using the Web user interface for hdblcm are as follows: ●
The SAP HANA database must be revision 90 or higher.
●
The communication port 1129 is open.
Several browsers are supported when using the Web user interface. The following Web browser are supported:
46
●
Internet Explorer - Version 9 or higher
●
Mozilla Firefox - Latest version and Extended Support Release
Lesson: Introduction SAP HANA Lifecycle Management Tools
●
Safari 5.1 or higher on Mac OS
To start the Web interface depends on if you use SAP HANA Studio or a browser, proceed as follows: ●
●
In the browser open https://:1129/lmsl/HDBLCM//index.html. In SAP HANA Studio, open the context menu of your system and select Lifecycle Management→Platform Lifecycle Management→SAP HANA Platform Lifecycle Management
Business Example During the SAP HANA implementation project there is the need for a sandbox system, where the SAP HANA developers and modelers can gain experience with the newest SAP HANA features in the SPS11 release. To facilitate this request, you need to install a Single-Host SAP HANA system. Log on to the SAP HANA host using Microsoft Remote Desktop and install a single-host SAP HANA system. Use the Microsoft Remote Desktop application to connect from the SAP Training WTS landscape to the Linux Desktop assigned to you by the instructor. From the Linux desktop, you will install the single-host SAP HANA system using the installation tool hdblcmgui. Note: ## is the placeholder for the group number that the instructor assigned to you. $$$ is the placeholder for the training landscape number the instructor has assigned to you. 1. Connect to your SAP HANA Landscape using the Remote Desktop tool. Group
hostname
01
wdflbmt7194
02
wdflbmt7195
Use the following credentials to log on to the SAP HANA landscape: Username: train-## Password: initial Use the following credentials to wdflbmt719x: Username: ha200root Password: ha200_KPS$ 2. Check the availability of the SAP HANA installation DVD. 3. Install SAP HANA using hdbclmgui. Use the following values on the Specify the System Properties screen: SAP HANA System ID: SHS Instance Number: 20 Password: Welcome123
Business Example During the SAP HANA implementation project there is the need for a sandbox system, where the SAP HANA developers and modelers can gain experience with the newest SAP HANA features in the SPS11 release. To facilitate this request, you need to install a Single-Host SAP HANA system. Log on to the SAP HANA host using Microsoft Remote Desktop and install a single-host SAP HANA system. Use the Microsoft Remote Desktop application to connect from the SAP Training WTS landscape to the Linux Desktop assigned to you by the instructor. From the Linux desktop, you will install the single-host SAP HANA system using the installation tool hdblcmgui. Note: ## is the placeholder for the group number that the instructor assigned to you. $$$ is the placeholder for the training landscape number the instructor has assigned to you. 1. Connect to your SAP HANA Landscape using the Remote Desktop tool. Group
hostname
01
wdflbmt7194
02
wdflbmt7195
Use the following credentials to log on to the SAP HANA landscape: Username: train-## Password: initial Use the following credentials to wdflbmt719x: Username: ha200root Password: ha200_KPS$ a) Open the Microsoft Remote Desktop application on your local PC. b) Connect to the SAP HANA Landscape provided by the instructor. The hostname of the SAP HANA landscape is provided by the instructor. c) Log on to the SAP HANA landscape using the credentials provided in the exercise step.
d) In the WTS session, click the Windows button, search for the Remote Desktop application, and start it. e) In the Remote Desktop application, enter the hostname according to you group number. f) Click Yes on the Remote Desktop Connection dialog bix. g) On the Login to xrdp screen, use the Module “sesman-Xvnc” and enter the credentials provided in the exercise step. You are now on the Linux Desktop with the blue background. 2. Check the availability of the SAP HANA installation DVD. a) On the Linux desktop, double-click the Training icon. The file explorer opens the installation DVD and shows the directory DATA_UNITS. b) Double-click the DATA_UNITS directory and search for the HDB_LCM_LINUX_X86_64 directory. This directory contains the SAP HANA installation program. 3. Install SAP HANA using hdbclmgui. Use the following values on the Specify the System Properties screen: SAP HANA System ID: SHS Instance Number: 20 Password: Welcome123 a) Open the HDB_LCM_LINUX_X86_64 directory and start the SAP HANA installation program by double-clicking hdblcmgui. On the Select Software Components Location screen, an overview screen shows the detected Software Components. b) Choose Next. c) On the Install new SAP HANA System screen, select Install New System and choose Next. d) On the Select additional components for installation screen, leave the default selection and choose Next. e) On the Choose System Type screen, select Single-Host System and choose Next. f) On the Specify the System Properties screen, change the fields as outlined in the exercise step. g) Leave all other field values as default and choose Next. h) On the Specify the Data and Log Area screen, keep the default settings and choose Next. i) On the Enter Certificates Hosts Properties screen, keep the default setting and choose Next. j) On the Specify the Properties for the System administrator screen, enter and confirm the password provided in the exercise step. k) Choose Next.
Lesson: Introduction SAP HANA Lifecycle Management Tools
l) On the Specify Password of Database User System screen, enter and confirm the password provided in the exercise step. m) Choose Next. n) On the Summary screen, check your input and choose Install. o) The installation takes around 10 minutes. p) On the SAP HANA System install screen, check the logs by pressing View Log and the finish the installation by pressing Finish. You have installed a single-host SAP HANA system. 4. Check that the SAP HANA services are running. a) Open a Gnome Terminal by right clicking the Linux desktop and selecting Open in Terminal from the context menu. b) In the Terminal, execute the command SU – SHSADM. c) In the Terminal, execute the command HDB INFO. This shows an overview of the running SAP HANA services.
SAP HANA Master Guide - http://help.sap.com/hana/SAP_HANA_Master_Guide_en.pdf SAP HANA Server Installation and Update Guide - http://help.sap.com/hana/ SAP_HANA_Server_Installation_Guide_en.pdf
LESSON OVERVIEW This lesson explains the various advanced installation methods of an SAP HANA system. This is a short lesson about the advanced installation options. Keep it short and, at the end, you can review the success of the single-host installation from the previous lesson.
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. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the use of the command line options
●
Explain the use of the configuration file.
●
Explain the use of the configuration file in batch mode
Advanced Installation Options Installation automation is designed for those who are familiar with SAP HANA, and are installing it regularly, in various production environments. In particular, installation automation refers to installing SAP HANA systems using batch mode and a combination of a configuration file and call options passed on the command line. To provide flexibility, it is possible to install the same SAP HANA system in several ways. The differences between installation methods are best depicted through a one-to-one comparison of the same system installed with each available method. The following figure shows an example that illustrates the differences between the installation methods. The target is to install an SAP HANA single-host system with the following specifications.
Using Batch Mode Let us look at the automated installation with the SAP HANA lifecycle management tool hdblcm. For this, you have to use the batch mode. It is important to note that, up to this point, it was necessary to enter passwords interactively and confirm other default parameters as part of the interactive mode. Batch mode runs the installer without asking for any confirmation or parameter entry, allowing installation to run to completion by the push of one button. It can be started from the command line alone or in combination with the configuration file. Batch mode is designed to automate the installation process.
Default Parameters The installer uses the following default values unless you change them during installation. Some default values are based on the predefined values on the current host.
Caution: In a multiple-host system, it is recommended to manually check the mandatory values on each host before installation. In a multiple-host system, we recommend that you check the mandatory values on each host manually before installation.
User Descriptions Table 2: User Descriptions During Installation the following users are created automatically: User
Description
adm
The user adm is the operating system user required for administrative tasks such as starting and stopping the system. The user ID of the adm user is defined during the system installation. The user ID and group ID of this operating system user must be unique and identical on each host of a multiple-host system.
sapadm
The SAP host agent administrator. ●
●
SYSTEM
If there is no SAP host agent available on the installation host, it is created during the installation along with the user sapadm. 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.
Initially, the SYSTEM user has all system permissions. Additional permissions can be granted and revoked again, however the initial permissions can never be revoked.
Overview of Advanced Installation Options Table 3: Overview of Installation Methods Installation Variant
Detailed Characterization
hdblcm only
All parameters are available
hdblcm + configuration file
All parameters are available
hdblcm + batch modus
All parameters are available; makes automation possible
hdblcm + configuration file + batch modus
All parameters are available; makes automation possible
Further SAP HANA Platform Lifecycle Management Changes Since SPS07
Figure 48: Further SAP HANA Platform Lifecycle Management Changes Since SPS07
Troubleshooting a Failed Installation Troubleshooting should be referred to if the installation fails for an unknown reason, or for workarounds in special circumstances. 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: /var/tmp/ hdb___ where ::= install | update | addhost | uninstall | and so on The following log files are written during performing the action:
62
●
.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, makes a detailed analysis easier.
You can also view the last three log files in the SAP HANA studio using the administration function Diagnosis Files.
Enabling the Installer Trace If the installer crashes or loops it may make sense to trace the installer until the problem occurs, open an SAP Support Ticket on http://support.sap.com, 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.
Locating all SAP HANA File System Components In addition to the main components installed in the default file systems, it may also be necessary to locate the temporary files from the SAP HANA system. They can be found in the following directories.
Figure 49: Locating all SAP HANA File System Components
Accessing the Underlying Installer Components (pass_through_help) Since hdblcm and hdblcmgui are wrapper tools, in some troubleshooting cases, it may be useful to 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. To view the available underlying component parameters as extended help output, use the pass_through_help parameter. The action parameter and --help or -h must be specified in combination with pass_through_help.
Relocation of SAP HANA It may become necessary to move the SAP HANA system to different hardware. If so, the SAP HANA system must be unregistered, and re-registered on the new hardware. As of SPS 08, system relocation can be performed with the SAP HANA lifecycle management tool hdblcm(gui).
Example Scenario: Scale Up – System Relocation from Source to Target Host - Register
Figure 51: Example Scenario: Scale Up – System Relocation from Source to Target Host - Register
What are the step for register the new host? ●
Log on to the target host and mount the shared area.
●
Execute HDBLCM –ACTION=REGISTER_RENAME_SYSTEM.
●
Execute the host mapping.
SAP HANA Installation Certification Program With the introduction of SAP HANA Tailored Datacenter Integration (TDI), customers were allowed to install their own SAP HANA systems on certified hardware. To ensure quality and consistency in the installations in the customers’ datacenter, SAP has setup a special certification program for installing SAP HANA systems. The execution of the installation requires that you have a special SAP Certificate (Booking code: E_HANAINS151).
Note: E_HANAINS151 means installation certification of the year 2015 in the 1 half year. Examples include the following: ●
The installation certification exam SAP Certified Technology Specialist (Edition 201x) – SAP HANA Installation is in line with our SAP HANA Tailored data center integration program. Further information about the installation certification exam (E_HANAINSxxy) includes the following: ●
Mandatory prerequisite: passed the C_HANATECxxy
●
Duration: 90 Minutes
●
No. of Questions: 40
We strongly recommend that you attend the completely revised HA200 classroom training before you book the exam.
Hint: SAP Note 1905389 contains a collection of important documents.
How to Obtain the Installation Certificate
Figure 52: The Way to the Installation Certificate
The prerequisite to pass the Certification C_HANATECxxy are the courses HA100,HA200, HA240, and HA250. These courses have a different weighting for the certification. For further details on the topics and their weighting, consult the SAP Training and Certification Shop (https://training.sap.com/).
Caution: The Data Provisioning part is based on HA100.
Note: For details on the certification C_HANATEC_10, see https://training.sap.com/ shop/certification/c_hanatec_10-sap-certified-technology-associate---sap-hanaedition-2015-g/ A certification continues to be valid until the next three SAP HANA SPS. The following table outlines the C_HANATEC certifications and the status of each. Table 4: C_HANATEC Certifications and Status Certification name
SAP HANA SPS level
Status
C_HANATEC141
SPS07
Expired
C_HANATEC142
SPS08
Soon to be expired
C_HANATEC151
SPS09
Active
C_HANATEC_10
SPS10
Active
C_HANATEC_11
SPS11
Active
Related Information ●
Training and Certification Shop: https://training.sap.com
●
SAP Learning Hub: https://training.sap.com/shop/learninghub
LESSON SUMMARY You should now be able to: ●
Explain the use of the command line options
●
Explain the use of the configuration file.
●
Explain the use of the configuration file in batch mode
LESSON OVERVIEW This lesson explains the various installation options of SAP HANA Studio In this lesson, we review the SAP HANA Studio installation, but we do not install SAP HANA Studio because it is already installed on the Citrix desktop. We connect our SAP HANA Studio to the SAP HANA Database that was installed in the previous lesson.
Business Example During the implementation project, the SAP HANA Administrator, Modelers, and Developers need an up to date SAP HANA Studio on their PC or laptop. It is your task to provide a good strategy to keep all the SAP HANA Studios up to date. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Install and configure SAP HANA Studio
●
Understand the different installation features
●
Setup an SAP HANA Studio Update site
About the SAP HANA Studio The SAP HANA studio runs on the Eclipse platform 3.6 and has a collection additional applications for SAP HANA. The SAP HANA studio enables technical users to manage the SAP HANA database, to create and manage user authorizations, and to create new, or modify existing, models of data in the SAP HANA database. It is a client tool, which can be used to access local or remote SAP HANA databases. SAP HANA Studio is available on Windows, Linux, and Mac OS. For the details about which platform versions are supported, check the SAP HANA Studio Installation and Update Guide on http://help.sap.com/hana_platform.
Installing SAP HANA Studio Use the graphical installation tool HDBSETUP to install SAP HANA Studio. This installation tool is available on all of the supported front-end platforms. Before you start the SAP HANA Studio installation, make sure that you have checked all of the platform-specific prerequisites.
Default Installation Paths The default installation paths are specific to the operating system on which the SAP HANA studio is installed. Table 5: Default Installation Paths The table shows the default installation paths for different operating systems. OS Platform
Package Version
Installation Path
Microsoft Windows x86 (32bit)
32-bit
C:\Program Files\sap \hdbstudio
Microsoft Windows x86 (64bit)
64-bit
C:\Program Files\sap \hdbstudio
Microsoft Windows x86 (64bit)
32-bit
C:\Program Files (x86)\sap \hdbstudio
Linux x86 (64-bit)
64-bit
/usr/sap/hdbstudio
Mac OS
64-bit
/Applications/sap/hdbstudio
The default installation paths can be changed during the installation of SAP HANA Studio.
Installation of SAP HANA Studio Features During installation or update you can select which SAP HANA studio features are installed. Depending on your use case for SAP HANA Studio you select between the following installation options: ●
SAP HANA Studio Administration An installation setup for various administration tasks, excluding transportable design-time repository objects. General troubleshooting tools like tracing, the catalog browser, and SQL Console are also included.
●
SAP HANA Studio Database Development An installation setup for content development. Used for DataMarts and ABAP on SAP HANA scenarios.
●
SAP HANA Studio Application Development An installation setup suited for developing SAP HANA native applications (XS and UI5 tools). SAP UI5 Tools are not included and need to be installed separately.
Figure 54: Installation Options in SAP HANA Studio
Update the SAP HANA Studio Using an Update Site An update site can be used to provide the newest installation media for a large number of installations. Before you can manually update the SAP HANA studio and configure the SAP HANA studio to check automatically for updates, you must have configured the update site from which updates are downloaded. The SAP HANA XS Web server is used to provide the installation files for the SAP HANA studio update.
The update site setup procedure is as follows: 1. In the SAP HANA studio, specify the update site as follows: a) From the main menu, choose Window → Preferences → Install/Update → Available Software Sites. b) Choose Add... and specify the name of the update repository (optional) and its location. If you are using the SAP HANA XS Web server, choose http://: 80/sap/hana/studio/. If you are using a file system location file, choose:/.
Note: The path for Mac OS X is different. Check the SAP HANA Studio Installation and Update Guide on http://help.sap.com/hana_platform for the details. 2. To update the SAP HANA studio manually, proceed as follows: a) From the main menu, choose Help → Check for Updates. The SAP HANA studio checks the specified software site for an update. b) If an update is available, follow the on-screen instructions to install the update. 3. To configure the SAP HANA studio to check for updates automatically and notify you of their availability, proceed as follows: a) From the main menu, choose Window → Preferences → Install/Update → Automatic Updates. b) Specify your update settings. You are automatically notified if an update is available in accordance with your settings.
Note: By default, the SAP HANA studio does not automatically check for updates and notify you.
The IT department plans to roll out the SAP HANA Studio to the SAP HANA developers, modelers, and system administrators. It is your task to install the SAP HANA Studio and investigate what installation options are needed. Note: ## is the placeholder for the group number that the instructor assigned to you. $$$ is the placeholder for the training landscape number the instructor has assigned to you.
1. Connect to your Linux server using the Remote Desktop tool. (You can skip this step if you are still connected to the Linux Desktop via Remote Desktop) Group
hostname
01
wdflbmt7194
02
wdflbmt7195
The hostname of the SAP HANA landscape is provided by the instructor. Log on to the SAP HANA Landscape using the following credentials: Username: train-## Password: initial In the Login to xrdp dialog box, use the Module “sesman-Xvnc” and enter the credentials provided in the exercise step: Username: ha200root Password: ha200_KPS$ 2. Install SAP HANA Studio on the Linux server
The IT department plans to roll out the SAP HANA Studio to the SAP HANA developers, modelers, and system administrators. It is your task to install the SAP HANA Studio and investigate what installation options are needed. Note: ## is the placeholder for the group number that the instructor assigned to you. $$$ is the placeholder for the training landscape number the instructor has assigned to you.
1. Connect to your Linux server using the Remote Desktop tool. (You can skip this step if you are still connected to the Linux Desktop via Remote Desktop) Group
hostname
01
wdflbmt7194
02
wdflbmt7195
The hostname of the SAP HANA landscape is provided by the instructor. Log on to the SAP HANA Landscape using the following credentials: Username: train-## Password: initial In the Login to xrdp dialog box, use the Module “sesman-Xvnc” and enter the credentials provided in the exercise step: Username: ha200root Password: ha200_KPS$ a) Open the Microsoft Remote Desktop application on your local PC. b) Connect to the SAP HANA Landscape provided by the instructor. c) Log on to the SAP HANA Landscape using the credentials provided in the exercise step. d) In the WTS session, click the Windows button, search for the Remote Desktop application, and start it. e) In the Remote Desktop application, enter the hostname according to you group number. f) Click Yes on the Remote Desktop Connection pop-up.
g) In the Logon to the wdflbmt719x dialog box, log on with the credentials provided in the exercise step. 2. Install SAP HANA Studio on the Linux server a) On the Linux desktop, double-click the Training icon. The explorer opens the installation DVD and shows the directory DATA_UNITS. b) Double-click the DATA_UNITS directory and search for the directory HDB_STUDIO_LINUX_X86_64. This directory contains the SAP HANA Studio installation program. c) Open the HDB_STUDIO_LINUX_X86_64 directory and start the SAP HANA Studio installation program by double clicking hdbsetup. d) On the Choose an Installation to update, or choose a path for a new installation screen, keep the default setting, and choose Next. e) On theSelect feature to install screen, keep the default setting and choose Next. f) On the Summary screen, check your selections and choose Install. g) The installation takes around 5 minutes. h) On the You have successfully installed the SAP HANA Studio screen, choose View Log to view the logs, or choose Finish to complete the installation of SAP HANA Studio.
LESSON OVERVIEW In this lesson, you learn what needs to be prepared to install a distributed system, and the steps for to perform this kind of installation. The installation of a distributed system is described in the SAP HANA Server Installation Guide. As an instructor you could demonstrate the Scale-Out installation here. If you demonstrate the MHS installation here, then later in the Unit 7 lesson on table administration, you can demonstrate the table move and partitioning on the scale-out system. It is not mandatory to demonstrate the MHS installation here.
Business Example The reason for a distributed landscape consisting of multiple hosts is to have more memory or more CPU power beyond the limitation of a single physical hardware box. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the preparatory steps required to install a distributed system
●
Describe the steps for installing a distributed system
Multi-Host System Installation It is important to review multi-host system concepts, such as like host grouping and storage options before installing a multi-host system.
Hint: Host Types When configuring a multi-host system, the additional hosts must be defined as worker machines or standby machines (worker is default). Host Types Worker machines process data Standby machines do not handle any processing and instead just wait to take over processes in the case of a worker machine failure. Another important term is the Server role. There are two definitions for the server role, as follows:
Lesson: Performing a Distributed System Installation
●
MASTER The master index server is assigned on the same host as the name server with the actual role MASTER. The actual index server role of this host is MASTER. The master index server provides metadata for the other active index servers (that is, those with actual indexserver role SLAVE).
●
SLAVE The index server role of the remaining hosts (except those configured as standby hosts) is SLAVE. These are active index servers and are assigned to one volume. If an active index server fails, the active master name server assigns its volume to one of the standby hosts.
Figure 55: Scale Out
Note: We recommend that all servers have the same size. A Typical Configuration for a Distributed System
Figure 56: A Typical Configuration for a Distributed System
Host grouping does not affect the load distribution among worker hosts; the load is distributed among all workers in an SAP HANA system. If there are multiple standby hosts in a system, host grouping should be considered, because host grouping decides the allocation of standby resources if a worker machine fails. If no host group is specified, all hosts belong to one host group called "default". The more standby hosts in one host group, the more failover security.
Note: The installer distinguishes between two types of groups: sapsys groups and host groups. The SAP system group (sapsys group) is the group that defines all hosts in a system. Therefore, all hosts in a multi-host system must have the same sapsys group ID, which is the default configuration with hdblcm. A host group is a group of hosts that share the same standby resources only. Therefore, if the multi-host system has one standby host, it is important to leave all hosts in the same host group ("default") so that all hosts have access to the standby host in case a worker host fails.
Distributed Systems and Scale Out Note the following: ●
●
80
In the context of SAP HANA, it is the name for multiple connected nodes of an SAP HANA database that uses the same server software installation. Every system has a unique SAP system ID. This is called the .
Lesson: Performing a Distributed System Installation
Figure 58: Multi-Host System
Both the hdblcm and hdblcmgui SAP HANA lifecycle management tools can be used to install an SAP HANA multi-host system in one of the installer modes, and with a combination of parameter specification methods. Creating a Multi-Host System During Installation The SAP HANA lifecycle management tools, hdblcm and hdblcmgui, have the ability to build a multi-host system during installation in interactive mode, in batch mode, and with the available parameter specification methods: interactively, using command line options, or with the configuration file. The prerequisite for creating a mutli-host system is that the shared file systems for the data files and log files are configured, so that they are present and mounted on all hosts, including the primary host. The suggested locations for the file systems are as follows: ●
Lesson: Performing a Distributed System Installation
Test and Simulation
Figure 61: Test and Simulation
For testing and debugging, it is possible to copy a scale-out landscape to a single node. You will find the necessary copy function in SAP HANA studio to scale out and scale up a distributed landscape.
Hint: We recommend that you have a separate sandbox system to test all of the administrator tasks, such as backup and recovery.
Storage Options In single-host SAP HANA systems, it is possible to use plain attached storage devices, such as SCSI hard drives, SSDs, or SANs. However, to build a multi-host system with failover capabilities, the storage must ensure the following: ●
The standby host has file access.
●
The failed worker host no longer has access to write to files, called fencing.
There are two fundamentally different storage configurations that meet these two conditions: shared storage devices or separate storage devices with failover reassignment. A shared storage subsystem, such as NFS or IBM's GPFS, is the commonly used storage option because it is easy to ensure that the standby host has access to all active host files in the system.
Shared Storage System In a shared storage solution, the externally attached storage subsystem devices are capable of providing dynamic mount points for hosts. Because shared storage subsystems vary in their handling of fencing, it is the responsibility of the hardware partner and their storage partners to develop a corruption-safe failover solution. A shared storage system could be configured as shown in the figure, however, mounts may differ among hardware partners and their configurations.
Figure 63: Shared Storage System
LESSON SUMMARY You should now be able to: ●
84
Explain the preparatory steps required to install a distributed system
LESSON OVERVIEW In this lesson, you learn what to do after the installation SAP HANA. Business Example As part of initial setup you have to establish SAP Solution Manager connectivity and configure a Remote Service Connection (via SAP Router). LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Configure connections for remote support
●
Install/check HANA licenses
Solution Manager Connectivity In addition to running the on-site configuration tool, we recommend establishing SAP Solution Manager connectivity and configuring a Remote Service Connection (via SAP Router) as part of initial setup. ●
As of Solution Manager 7.1 SP04, the SAP HANA databases can be integrated into SAP Solution Manager.
●
Performance Warehouse
●
Alerting Infrastructure
●
DBA Cockpit (also available in SAP BW systems as of SAP BW 7.30 SP05)
Remote service connection can be established through the SAP Router. New connection type allows SAP support to access customer databases via local SAP HANA studio installation.
Figure 64: Solution Manager Connectivity: Technical System Overview
Remote Connection to Solution Manager As part of initial setup, the Solution Manager connectivity and the Remote Service Connection (via SAP Router) should be established.
Figure 65: Remote Connection to Solution Manager
Configure Remote Support via SAP Router to HANA DB Studio For setting up Root Cause Analysis, System Monitoring, and EarlyWatch Alert for SAP HANA with Solution Manager Version 7.10, refer to SAP Note 1747682. The note has attachments. Detailed instructions on how to set up are described in the attached documents within the note.
Figure 66: Configure Remote Support via SAP Router to HANA DB Studio
Configure Remote Support via SAP Router to HANA DB Studio (2)
Figure 67: Configure Remote Support via SAP Router to HANA DB Studio (2)
1. In some support cases, it may be necessary to provide OS-level access to SAP support. For SAP HANA Linux systems, an SSH or telnet remote connection should be set up. Refer to SAP Notes 1275351 and 1327257.
2. For Windows-based systems (potentially used for BusinessObjects components), therefore , we recommend setting up a Netviewer connection (see SAP Note 1036616). A Netviewer connection requires the customer to actively Accept a connection request. 3. For unattended access, a Windows Terminal Server connection can be set up (see SAP Note 605795). The General Licensing Process As with all SAP products, you need to obtain a license from SAP in order to run SAP HANA. For all tasks around the license management, you need the system privilege LICENSE ADMIN. Generally, there are two kinds of license keys, as follows: ●
Temporary license keys Temporary license keys are automatically installed by the SAP HANA system. This license is valid for 90 days. After 90 days, the license expires and the system is locked down. Once you have installed a valid permanent license, your system is usable until this license expires.
●
Permanent license keys Permanent license keys are issued by SAP on request. Note that these licenses may also be limited with respect to time. At any time, you can install and reinstall a new permanent license. If the current permanent license expires, a temporary license will be installed automatically. This temporary license following a permanent license is only valid for 28 days.
To request your license key, access SAP Service Marketplace at https://support.sap.com/ licensekey. This is a simple and safe way to request your license key. You can also use SAP HANA studio.
License Key There are two types of permanent license key available for SAP HANA: unenforced and enforced. If an unenforced license key is installed, the operation of SAP HANA is not affected if its memory consumption exceeds the licensed amount of memory. However, if an enforced license is installed, the system is locked down when the current memory consumption of SAP HANA exceeds the licensed amount of memory plus some tolerance. If this happens, either SAP HANA needs to be restarted, or a new license key that covers the amount of memory in use needs to be installed.
Note: The following able contains licensing-related SAP Notes for further reference. Table 6: Licensing-Related SAP Notes SAP Note
Description / Content
1644792
License key req./installation SAP HANA databases
1704499
System Measurement for License Audit
Figure 69: License Key
Changing the SSFS Master Keys The initial default master keys that protect the two secure stores in the file system (SSFS) used by SAP HANA are changed during installation or upgrade. If you received your system pre-installed from a hardware or a hosting partner, we recommend that you change them immediately after handover to ensure that they are not known outside of your organization.
Prerequisites The following are prerequisites for changing the SSFS Master Keys: ●
●
You have the credentials of the Operating system user adm that was created when the system was installed. You have the system privilege INIFILE ADMIN.
SAP HANA uses the instance SSFS to protect the root encryption keys listed below. These root keys protect all encryption keys used in the SAP HANA database from unauthorized access. ●
The root key used for the internal data encryption service of the database
●
The root key used for data volume encryption
In a system that supports multitenant database containers, the system database and all tenant databases have their own root encryption keys for both the data encryption service and data volume encryption. You can change the SSFS master keys using the command line tool rsecssfx, which is installed with SAP HANA and available at /usr/sap//HDB/exe. Before changing the SSFS master keys, note the following: ●
●
●
Changing SSFS master keys requires system downtime. In a distributed SAP HANA system, every host must be able to access the file location of the instance SSFS master key. In a system that supports multitenant database containers, the SSFS master keys only have to be changed once for whole instance and not per tenant database.
Procedure To change the SSFS Master Keys, proceed as follows: 1. Log on to the SAP HANA system host as the Operating system user adm. 2. Shut the system down using the sapcontrol program: /usr/sap/hostctrl/exe/sapcontrol -nr -function Stop 3. Change the master key of the instance SSFS as follows: a. Re-encrypt the instance SSFS with a new key with the command: RSEC_SSFS_DATAPATH=/usr/sap//SYS/global/hdb/security/ssfs RSEC_SSFS_KEYPATH= rsecssfx changekey $(rsecssfx generatekey -getPlainValueToConsole) b. Configure the specified key file location in the global.ini configuration file at /usr/sap/ /SYS/global/hdb/custom/config/global.ini . If the file does not exist, create it. Add the following lines: [cryptography] ssfs_key_file_path = < path to key file> 4. Re-encrypt the system PKI SSFS with a new key with the following command:
RSEC_SSFS_DATAPATH=/usr/sap//SYS/global/security/rsecssfs/data RSEC_SSFS_KEYPATH=/usr/sap//SYS/global/security/rsecssfs/key rsecssfx changekey $(rsecssfx generatekey –getPlainValueToConsole 5. Restart the system: /usr/sap/hostctrl/exe/sapcontrol -nr -function Start Next Steps In a system-replication setup, configure the location of the instance SSFS master key file on the secondary system or systems. The file itself will be automatically copied. For file system-based copies of SAP HANA database installations, you must save and restore the instance SSFS master key file manually; otherwise data loss can occur. In regular backup and recovery scenarios (including snapshots), you do not have to take any actions regarding the master key, because only the content of the instance SSFS, not the master key, is contained in the backup.
Note: It is not necessary to save the system PKI SSFS key file. The system will generate a new system PKI SSFS automatically, if required. Comments and Further Information ● Number 2147483647 is the virtual unlimited licensed memory that the temporary license provided after SAP HANA installation. ●
●
The licensed memory is the amount of memory that a customer wants to assign to a particular HANA instance. When a customer requests a license key from the SAP Service Marketplace, it asks the customer to provide such a number. The customer can decide how much they want to assign to the particular instance from the whole amount the customer bought. Then the specified number will be put into the generated license key file. Once the license key is installed into the designated HANA instance, the number will be set in the HANA instance and it shows in SAP HANA studio. Memory allocation in HANA Database implements a pool concept. That is, memory is preallocated from the operating system to gain performance on actual allocations done in HANA DB code. By default, the Memory manager allocatesup to 90% of the available physical memory and it is shown as Peak memory usage in SAP HANA Studio.
Note: You are alerted 30 days before the license expires.
Hint: Only a system with a valid license, that is not locked down, can be backed up. The license will also be backed up and then restored with Recovery. When the Recovery of the backup is performed on the same system, there is no change in System ID and Hardware Key; the license key from the backup will be recovered and used for license check. If the backup is too old, the license key from the backup might have expired. In this case, the database will be locked after recovery and a new valid license key is needed to unlock the database.
LESSON OVERVIEW This lesson describes how you can update the SAP HANA system using the HANA lifecycle manager (HDBLCM) This lesson shows the participants how to update SAP HANA to a higher revision. The instructor performs a demonstration to help revision. The participants also have an exercise, in which they update SAP HANA. In the second part of the lesson, the different lifecycle management options of HDBLCM are shown.
Business Example Hint: The detailed information about updating SAP HANA and its different components is described in: SAP HANA Administration Guide SAP HANA Server Installation and Update Guide
Hint: Plan to have a business downtime during the update process.
LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the update process as a whole
●
Update dependent components
Two ways for upgrading SAP HANA The SAP HANA lifecycle manager tools HDBLCM (command line) and HDBLCMGUI were introduced with the SPS 07 release of SAP HANA. They are wrapper tools, which make use of their underlying tools, including hdbinst for system installation, and hdbupd for update.
Note: In the rest of the lesson, hdblcm refers to the tools hdblcm and hdblcmgui. As of the SAP HANA SPS 08 release, hdblcm has additional configuration functionality that can be performed locally from system hosts. As of SAP HANA SPS09, the SAP HANA lifecycle manager tool (HLM) is fully replaced by the SAP HANA database lifecycle manager HDBLCM. The SAP HANA lifecycle manager tools are available in two versions; The HDBLCM on the installation media, and the RESIDENT HDBLCM. Both tools are needed and perform different tasks. The following figure outlines the differences between the tools.:
Figure 70: Task Overview of hdblcm and the Resident hdblcm
The Update Process Before updating the SAP HANA components, make sure that no read or write processes are running on the SAP HANA database. Perform the update process in offline mode during a business downtime. After the update, you have to start SAP HANA and its components again. The sequence of the steps you that have to perform is as follows: 1. Stop all processes. 2. If necessary, backup the system 3. Perform an update. 4. Update the depending components. 5. Perform the post-update steps. 6. Restart all processes. When starting the SAP HANA Lifecycle Management tool from SAP HANA Studio you are presented with a nice user-friendly Fiori interface. How long will the upgrade take? Time for upgrade = (Time for shut down) + (Time for restarting SAP HANA) + 20 minutes.
The resident SAP HANA lifecycle manager tool (HDBLCM) helps to perform the following tasks: ●
Add additional hosts to the SAP HANA system
●
Configure inter-service communication
●
Configure System Landscape Directory (SLD)
●
Rename the SAP HANA System
●
Uninstall SAP HANA components
●
Unregister the SAP HANA System
●
Install or update additional components
You can update SAP HANA using the SAP HANA lifecycle manager tool from the installation media.
SAP HANA Lifecycle Management Function in Detail In the rest of this lesson, we briefly explain all the options provided by the resident SAP HANA lifecycle manager tool. Add Additional Hosts to the SAP HANA System You can add hosts to an SAP HANA system using the SAP HANA database lifecycle manager (HDBLCM) resident program in the graphical user interface or the command-line interface.
Figure 73: Add Additional Hosts to the SAP HANA System
Configure Inter-Service Communication In addition to external network connections, SAP HANA uses separate, dedicated connections exclusively for internal communication. These internal communication channels can be defined using the SAP HANA database lifecycle manager. In a multiple-host system environment, inter-service communication takes place between the hosts of a multiple-host system on one site. Certified SAP HANA hosts contain a separate network interface card that is configured as part of a private network, using separate IP addresses and ports.
Figure 74: Configure SAP HANA Inter-Service Communication
Configure SLD Registration You can configure an SAP HANA system to connect to the System Landscape Directory (SLD) using the SAP HANA database lifecycle manager (HDBLCM) resident program in the graphical user interface.
Rename the SAP HANA system An SAP HANA system can be renamed by changing the system identifiers, such as host names, SID, and instance number. Changing system identifiers can be performed with the SAP HANA database lifecycle manager (HDBLCM).
Uninstall the SAP HANA Components SAP HANA system components can be installed, updated, or uninstalled using the SAP HANA database lifecycle manager (HDBLCM). The following types of components can be managed: ●
●
●
SAP HANA mandatory components (SAP HANA server and client) SAP HANA additional components (Application Function Libraries, SAP liveCache applications, and SAP HANA smart data access) SAP HANA options (SAP HANA dynamic tiering and SAP HANA smart data streaming)
Uninstall the SAP HANA System You can uninstall the previously installed SAP HANA system by running the SAP HANA database lifecycle manager (HDBLCM) from the SAP HANA resident HDBLCM directory.
Manage SAP HANA Application Content SAP HANA Application Lifecycle Management supports you in all phases of an SAP HANA application lifecycle, from modeling your product structure, to application development, transport, assemble, and install. You can import content using the SAP HANA StudioFile → Import... → SAP HANA Content → Delivery Unit. As of SAP HANA SPS09 it is also possible to use the SAP HANA Application Lifecycle Management tool. The figure, Import SAP HANA Application Content, shows how to start the SAP HANA Application Lifecycle Management tool.
Troubleshooting the SAP HANA Lifecycle Manager If the SAP HANA lifecycle manager does not behave as expected, you can check the logs for the source of the problem, restart the lifecycle manager, or update to a more recent version. 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__. Because the SAP HANA lifecycle management tools hdblcm and hdblcmgui are wrappers for underlying component installers, it is also possible to check the component logs. We recommend that you review and analyze the SAP HANA lifecycle management tools hdblcm and hdblcmgui logs first. Once the source of the problem is isolated to a specific component, the component logs can be further analyzed.
You can also view the last three log files in the SAP HANA studio using the administration function Diagnosis Files. Phased Update With a standard SAP HANA system update, the system is offline from the time the update is triggered, including the preliminary checks, and actual software switch. Starting with SPS 10, you can run an SAP HANA system update in two phases, to reduce system downtime. The phased system update is performed in two steps: 1. Running the LCM update action with the prepare update flag set. This phase is performed while the system is online. 2. Running the LCM update action a second time as usual, which resumes the updates and takes the system offline for the software switch. You can perform the prepare update phase using either the SAP HANA database lifecycle manager graphical user interface, command-line interface, or Web user interface. The update resume phase can be performed from any of the three SAP HANA database lifecycle manager user interfaces. Prerequisites The prerequisites for a phase update are as follows: ●
●
●
You are updating to a new SPS from an installation medium or you have prepared for update, either in the SAP HANA studio or manually. You have stopped the data replication. You have performed a system backup. Note that, during the update, there is a business downtime for your SAP HANA system.
●
You know the adm, and database administrator passwords.
●
You have applied a valid license key for the SAP HANA system.
The SAP HANA system has been installed or updated with the SAP HANA database lifecycle manager (HDBLCM) Support Package Stack (SPS) 10 or later. The SAP HANA database server is up and running. Otherwise, inconsistencies in the configuration occur.
Benefits of a Phased System Update After downloading the SAP HANA software and preparing the downloaded archives for update execution, you can update your SAP HANA system in one step, or in a phased approach to minimize system downtime. When you start the SAP HANA database lifecycle manager with the prepare_update flag set, the SAP HANA database lifecycle manager extracts the packages (such as the SAP Host Agent and delivery units) from the new source, but does not perform the update. The software switch occurs when the SAP HANA database lifecycle manager is run a second time, which resumes the system update. The phased update includes the following benefits: ●
●
Decreased system downtime Reduced chance of a failed system update due to preliminary steps including archive preparation or dependency conflicts
Figure 81: Phased Update
Performing a Phased System Update To perform a phased system update, proceed as follows: 1. Change to the following directory on the installation medium: cd / DATA_UNITS/HDB_LCM_LINUX_X86_64Note 2. Perform the update preparation phase step with the SAP HANA database lifecycle manager using one of the following commands: ●
./hdblcmgui --action=update --prepare_update
●
./hdblcm --action=update --prepare_update
3. Resume the SAP HANA update. During the planned maintenance window, you can resume the prepared update using any of the standard update procedures.
Business Example You have downloaded SAP HANA revision 111 from http://support.sap.com and stored it on the SAP HANA Linux server in the directory /data/training/install/REV111. Now you need to update the SAP HANA system SHS to this new revision using the SAP HANA lifecycle management tools. You decided to use a html5 compatible Web browser. In this exercise, you log on to the SAP HANA host using Microsoft Remote Desktop and install a single-host SAP HANA system. Use the Microsoft Remote Desktop application to connect from the SAP Training WTS landscape to the Linux Desktop assigned to you by the instructor. From the Linux desktop you install the single-host SAP HANA system using the installation tool hdblcmgui. Note: ## is the placeholder for the group number that the instructor assigned to you. $$$ is the placeholder for the training landscape number the instructor has assigned to you.
1. Connect to your Linux server using the Remote Desktop tool. (You can skip this step if you are still connected to the Linux Desktop via Remote Desktop) Group
Business Example You have downloaded SAP HANA revision 111 from http://support.sap.com and stored it on the SAP HANA Linux server in the directory /data/training/install/REV111. Now you need to update the SAP HANA system SHS to this new revision using the SAP HANA lifecycle management tools. You decided to use a html5 compatible Web browser. In this exercise, you log on to the SAP HANA host using Microsoft Remote Desktop and install a single-host SAP HANA system. Use the Microsoft Remote Desktop application to connect from the SAP Training WTS landscape to the Linux Desktop assigned to you by the instructor. From the Linux desktop you install the single-host SAP HANA system using the installation tool hdblcmgui. Note: ## is the placeholder for the group number that the instructor assigned to you. $$$ is the placeholder for the training landscape number the instructor has assigned to you.
1. Connect to your Linux server using the Remote Desktop tool. (You can skip this step if you are still connected to the Linux Desktop via Remote Desktop) Group
hostname
01
wdflbmt7194
02
wdflbmt7195
a) Open the Microsoft Remote Desktop application on your local PC. b) Connect to the SAP HANA Landscape provided by the instructor. The hostname of the SAP HANA landscape is provided by the instructor. c) Log on using the following credentials: Username: train-## Password: initial d) In the WTS session, click the Windows button, search for the Remote Desktop application, and start it. e) In the Remote Desktop application, enter the hostname according to you group number. f) Click Yes on the Remote Desktop Connection pop-up.
g) In the Login to xrdp dialog box, use the Module “sesman-Xvnc” and enter the credentials provided in the exercise step: Username: ha200root Password: ha200_KPS$ 2. Patch SAP HANA using the browser a) In the WTS session (gray background) start Internet Explorer. b) Open the URL: https://wdflbmt719x:1129/lmsl/HDBLCM/SHS/index.html to start the SAP HANA Platform Lifecycle Management tool. c) On the There is a problem with this website’s security certificate screen, click Continue to this website (not recommended). The security warning is because the SAP HANA is using the self-signed certificate that was created during the installation. d) In the pWindows Security dialog box, enter the following credentials: Username: shsadm Password: Welcome123 e) On the SAP HANA Platform Lifecycle Management screen click Update System and Components. f) On the SAP HANA Database Installation Kit Location screen, enter the following path:/ data/training/install/REV111/SAP_HANA_DATABASE and choose Proceed with Update. On the Detected Software Components screen you see an overview of the detected components. g) Choose Next. h) On the Choose Components to be installed or updated for System SHS screen, keep the default selection and choose Next. i) On the Specify Authorization Properties screen, enter the system user shsadm and the password Welcome123 and choose Next. j) On the Update Properties screen, check your selection, and choose Update. k) The patch will run take around 10 minutes. l) On the Update of the SAP HANA System Finished Successfully screen, review the logs by choosing View Log. m) Finish the SAP HANA patch by choosing Close.
LESSON OVERVIEW SAP HANA is a fast changing and dynamic product. It is important to know the best way to keep your SAP HANA database up to date. This lesson provides information and recommendations about how to proceed. Be aware the SAP HANA Revisions are NOT released every two weeks anymore. This was only the case in the beginning of SAP HANA. As of SPS06 and later, the SAP HANA Revisions are released when there is a mayor fix that requires a new revision. For the latest information on the SAP HANA Release strategy, see SAP Note 2021789 - SAP HANA Revision and Maintenance Strategy.
LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Understand Support Package Stack, Support Packages and SAP HANA Revisions
●
Know the difference between Maintenance Revisions and Datacenter Service Points
●
Explain the SAP HANA Maintenance Strategy
●
Know about SAP HANA Zero Downtime Maintenance
●
Explain the following terms within the framework of SAP HANA revision strategy
Business Example As an IT Architect, you need to set up an SAP HANA Maintenance Strategy that aligns with the customer’s datacenter maintenance strategy. SAP HANA Revision Strategy Terminology In the context of the SAP HANA platform, there are several terms used to describe parts of the SAP HANA revision strategy, including the following:
SAP HANA Revisions The term “Revision” refers to packages containing fixes for the SAP HANA core components (SAP HANA Database, Studio, Clients, AFLs, LCapps, SDA, HWCC tool) Support Package The term “Support Package” refers to all other parts of the SAP HANA platform that are noncore components for the SAP HANA Database, that is, the SAP Host Agent or SAP HANA Smart Data Access. These components are visible on SAP Service Marketplace as “Support Packages (SP)”. Support Package Stack New capabilities are only introduced twice a year, every time a new SAP HANA Support Package Stack (SPS) is released. For easier handling, the numbering of SAP HANA SPS and Revisions had been aligned. Revision 80 for example refers to the first SAP HANA Revisions, which contains SPS08related capabilities. See the following list, for more details on the connection SPS to Revisions. ●
Revision 70 => SPS07
●
Revision 80 => SPS08
●
Revision 90 => SPS09
●
Revision 100 => SPS10
●
Revision 110 => SPS11
SAP HANA Maintenance Revisions The SAP HANA Maintenance Revisions are minor-version shipments of the last SAP HANA Revision within a certain SPS, for example 69.01, 69.02, or 74.01. Maintenance Revisions by definition only provides fixes for: ●
Major bugs concerning critical functionality in key SAP HANA scenarios (Business Suite on SAP HANA, SAP BW on SAP HANA, SAP HANA Data Marts)
●
Production systems or endangered go-lives within the next 6 weeks
Minor code dependencies and code changes or impact
Note: More details on possible update paths from SAP HANA Maintenance to standard SAP HANA Revisions can be found in SAP Note 1948334. SAP HANA Datacenter Service Point (DSP) The SAP HANA Datacenter Service Point (DSP) is a point in time, providing customers with more guidance as to when and on the base of which revision they should plan their production SAP HANA maintenance. ●
●
SAP HANA revisions which are referenced by a DSP had been running in production systems at SAP prior they are officially released. In consequence, we recommend that you stay on the current Support Package Stack (SPS) until the next DSP is reached. (See SAP Note 2021789 for DSP release information.) Once the DSP is reached, that is, in March and in September, customers are advised to update their system to referenced, or any newer SAP HANA Revision of the same SPS to ensure all available fixes as of date are being adopted.
Note: Customers who already downloaded or have run a revision referenced by a DSP do not need to update to a successor revision, unless they are facing an issue or there is an SAP Note, which reports a critical bug, which applies to the specific scenario the customer is running. SAP HANA Maintenance Strategy The SAP HANA maintenance strategy is based on incremental, non-disruptive innovation updates. Updates to the SAP HANA Platform will be released in the form of SAP HANA Support Package Stacks twice per year, delivered from within a single delivery stream. As updates shipped for the SAP HANA Platform are strictly downward compatible, earlier Revisions may be removed from SAP Service Marketplace with availability of a newer SAP HANA Revision of the same SPS. Incompatible changes may be considered for legal or security reasons, but are subject to a strict exception approval process.
Note: The SAP HANA Platform product remains in maintenance as long as any SAP business application releases built on top of SAP HANA are in mainstream maintenance, extended maintenance, or priority-one support.
Incremental, Non-Disruptive Innovation, and Planned Maintenance For customers running SAP HANA in production (or with a planned go-live of less than 6 weeks), SAP provides SAP HANA Maintenance Revisions, allowing them to stay on an older SPS for up to three months longer. These Maintenance Revisions contain only a subset of available fixes, identified to be relevant for production environments. For customers running SAP HANA in a non-production environment (or planning for initial system setup), SAP proposes the implementation of the highest SAP HANA Revisions available on SAP Service Marketplace, to benefit from incremental, but non-disruptive improvements.
Figure 84: SAP HANA Revision for Patching Production
The best upgrade or update path depends on the specific customer situation. System landscapes that are in production are best maintained using SAP HANA Maintenance Revisions and Datacenter Service Points (DSP) releases. Landscapes that are nonproductive, or sandbox landscapes, can be maintained using SAP HANA Revisions. These SAP HANA Revisions are released more often than a DSP, so new or fixed functions are available more quickly.
Revision Update with SAP HANA Zero Downtime Maintenance SAP offers its customers business continuity with the use of the SAP HANA Zero Downtime Maintenance capability based on connectivity suspend feature of the SAP NetWeaver AS ABAP stack. The DBSL of the database interface decouples transaction management of AS ABAP stack and of SAP HANA database. This keeps transaction on AS ABAP layer alive and allows you to change components (software versions) on the layers below on secondary (shadow) SAP HANA instance.
Figure 86: SAP HANA Revision Zero Downtime Maintenance
It is important to understand that the software upgrade order is to be started on end of chain and continued to the head of chain (ensuring use of the downwards compatibility ability of SAP HANA).
Note: See SAP Note 1913302 or Step-by-Step Implementation Guide for SAP HANA System Replication available for https://scn.sap.com/docs/DOC-47702 for further details. Summary Make sure you understand the SAP HANA Revision strategy and incorporate this into your software update strategy.
Figure 87: SAP HANA Revision Summary
LESSON SUMMARY You should now be able to: ●
Understand Support Package Stack, Support Packages and SAP HANA Revisions
●
Know the difference between Maintenance Revisions and Datacenter Service Points
●
Explain the SAP HANA Maintenance Strategy
●
Know about SAP HANA Zero Downtime Maintenance
●
Explain the following terms within the framework of SAP HANA revision strategy
LESSON OVERVIEW Even though SAP HANA is often referred to as “in-memory database management system”, data is not solely kept in the RAM, but also durably persisted in data and log volumes. This lesson provides you with details on the memory management and persistence. Tell the participants that, even though this lesson is theoretical, it is important to understand the basics, to be able to administrate and monitor an SAP HANA database. The participants will have a chance to test the features in the next unit with various administrative tools.
Business Example For monitoring purposes, you want to understand the SAP HANA memory usage and allocation behavior in detail and know about optimization potential. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Identify the components for memory management and persistence in the SAP HANA database architecture
●
Describe the SAP HANA memory usage and allocation behavior
●
Describe memory management in row store and column store
●
Explain how data is persisted in data and log volumes
●
Identify optimization potential with regard to memory management and persistence
SAP HANA Database Architecture Note: The SAP HANA database architecture is covered in detail in the course HA100. Therefore, the following is a short recap, focusing on memory management and persistence.
Figure 88: Core Processes on an SAP HANA Single-Node Instance
The SAP HANA Database functionalities are implemented in different services that are shown and briefly described in the figure, Core Processes on an SAP HANA Single-Node Instance. Following the idea of a shared architecture, each of the processes persists data in the corresponding data and log volumes independently.
Hint: Note that some of the services are optional. For example, the xsengine service can be deactivated and removed if not required. For details, see SAP Note 1867324. Because it keeps the tables in main memory and executes requests, for this lesson, the indexserver process is most relevant. It is described in detail below. The Statistics Service The statistics service collects and evaluates information about status, performance, and resource consumption from all components belonging to the system. It is a central element of the internal monitoring infrastructure of SAP HANA to monitor the status of the system and its services and the consumption of system resources. It notifies you when critical situations arise in your systems and provides you with historical monitoring data for analysis. The monitoring and alerting features of the SAP HANA database can be performed by two mechanisms: the statistics server or the statistics service. Statistics server The statistics server runs as a separate server process. It is an enhanced index server with a monitoring extension on top. Statistics service The statistics service does not run as a separate server process (statisticsserver). It is implemented as an embedded service in the master index server
Lesson: SAP HANA Memory Management and Data Persistence
The embedded statistics service is the recommended mechanism, because it offers more flexible configuration options and uses fewer system resources. As of revision 93, the embedded statistics service is enabled by default after installation or upgrade. For more information, see SAP Note 2091313. In earlier revisions (but at least revision 74), the statistics server is the default mechanism. For more information about how to migrate from the statistics server to the statistics service, see SAP Note 1917938. Architecture of the SAP HANA Indexserver
Figure 89: Architecture of the SAP HANA Indexserver
From an architectural point of view the SAP HANA Indexserver consists of several components that implement various features: ●
External Interfaces SQL, MDX, and Web interfaces allow clients to connect and communicate with the SAP HANA database
●
Request Processing / Execution Control Depending on the interface and the statement different components for processing can be invoked, for example, SQL Script implementations are executed within the so-called Calculation Engine.
●
Relational Engines The table data in SAP HANA is kept in two different relational stores: Row Store and Column Store. Each of these stores shows substantial differences with regard to the main memory management. This is discussed in detail in this lesson.
●
Storage Engine and Disk Storage To achieve consistency and persist changes durably, a Storage Engine with Page Management and Logger is used. This ensures that the database can be restored to the
most recent committed state after a restart and that transactions are either completely executed or completely undone. Disk Storage is divided in Data Volumes and Log Volumes. While changes need to be written to the log area before a successful commit of a transaction (synchronous writing), the data area contains the complete main memory content at a specific point in time and is written asynchronously.
Persistence
Figure 90: In-Memory Data Is Regularly Saved to Disk
Disk storage is still required to ensure the ability to restart in case of power failure and for permanent persistency. The SAP HANA persistency layer stores data in persistent disk volumes that are organized in pages. It is divided in log and data area: ●
●
Data changes such as insert, delete, and update are saved on disk immediately in the logs (synchronously). This is required to make a transaction durable. It is not necessary to persist the complete data, but the transaction log can be used to replay changes after a crash or database restart. In customizable intervals (standard: every five minutes) a new savepoint is created, that is, all of the pages that were changed are refreshed in the data area of the persistence.
Whether or not disk access can become to a performance bottleneck depends on the usage. Since changes are written to the Data Volumes asynchronously, the user or application does not need to wait for this. When data that already resides in the main memory is read, there is no need to access the persistent storage. However, when applying changes to data the transaction cannot be successfully committed before the changes are persisted to the log area. To optimize the performance, for the log area fast storage is used, such as SSD or Fusion-io drives (see also, certified hardware configurations in the Product Availability Matrix).
Lesson: SAP HANA Memory Management and Data Persistence
Storing Data in Data Volumes: Details
Figure 91: Storing Data in Data Volumes: Details
Like many modern database management system, SAP HANA can use the file abstraction layer of the host operating system. Each data volume contains one file, in which data is organized into pages, ranging in size from 4KB to 16MB (page size class). Data is written to and loaded from the data volume page-wise. Over time, pages are created, changed, overwritten, and deleted. The size of the data file is increased automatically as more space is required. However, it is not decreased automatically when less space is required. This means that, at any given time, the actual payload of a data volume (that is the cumulative size of the pages currently in use) may be less than its total size. This is not necessarily significant; it simply means that the amount of data in the file is currently less than at some point in the past (for example, after a large data load). If a data volume has a considerable amount of free space, it might be appropriate to shrink the data volume. However, a data file that is excessively large for its typical payload can also indicate a more serious problem with the database. SAP support can help to analyze the situation.
With large SAP HANA appliances – in particular, single-host SAP ERP systems – the situation can occur that the Ext3 file system file size limitation of 2 TB is reached. In this case, SAP HANA automatically creates additional files. This allows the use of Ext3 file systems even with applications that have a larger memory requirement per host.
Lesson: SAP HANA Memory Management and Data Persistence
Shadow Paging Concept
Figure 93: Shadow Paging Concept
While (redo) log entries are written synchronously, changed data in data volumes is periodically copied to disk in a savepoint operation. During the savepoint operation, the SAP HANA database flushed all changed data from memory to the data volumes. The data belonging to a savepoint represents a consistent state of the data on disk and remains so until the next savepoint operation has been completed.
Note: The frequency for savepoint creation can be configured (described in detail later in this course). Savepoints are also triggered automatically by a number of other operations such as data backup, and database shutdown and restart. You can trigger a savepoint manually by executing the following statement ALTER SYSTEM SAVEPOINT. The phases of the savepoint operation are shown in the graphic above. SAP HANA uses a “Shadow Paging Concept”. This means that write operations write to new physical pages and the previous savepoint version is still kept in shadow pages. Consequently, if a system crashes during a savepoint operation, it can still be restored from the last savepoint.
In the event of a database restart (for example after a crash) the data from the last completed savepoint can be read from the data volumes and the redo log entries written to the log volumes since the last savepoint can be replayed. This allows restoring the database to the last committed state.
Note: After a system restart, by default, not all tables are loaded into the main memory immediately.
Lesson: SAP HANA Memory Management and Data Persistence
Start of SAP HANA Database
Figure 95: Start of SAP HANA Database
While the row store is always to loaded entirely, only those columns of column tables that are essential are loaded into memory. The other columns are loaded, if requested. For example, if a query only uses some of the fields (columns) of a table, only those fields are loaded into the memory at time of query execution. All row-based tables (usually system tables) are available in the main memory. Their size significantly influences the time required to start the database. Other factors that influence startup time are mentioned in the figure, Start-Up Process. During the normal operation, SAP HANA tracks a list of column tables that are currently loaded (once per day). This list is now the basis of loading the necessary tables into main memory during restart. Reloading column tables in this way restores the database to a fully operational state more quickly. However, it does create performance overhead, and may not be necessary in non-productive systems. You can deactivate the reload feature in the indexserver.ini file by setting the reload_tables parameter in the sql section to false.
Note: It is possible to mark individual columns as well as entire column tables for preload. When the preload flag is set, tables are loaded into memory automatically after an index server start. The current status of the preload flag is visible in the system table TABLES in the PRELOAD column. Possible values are 'FULL', 'PARTIALLY' and 'NO'. Also in system table TABLE_COLUMNS in column PRELOAD with possible values being 'TRUE' or 'FALSE'.
Note: When fields of large column tables are not in the main memory, the first access to the table might be significantly slower, because all requested columns are loaded to main memory before the query can be executed. This applies even if a single record will be selected.
Caution: Simply flagging all tables for preload in order to accelerate initial queries, could slow down startup time tremendously. The preload flag is a tuning option and should be used carefully depending on the individual scenario and requirements.
Memory Usage The total amount of memory used by SAP HANA is referred to as used memory. It includes program code and stack, all data and system tables, and the memory required for temporary computations. In the Linux operating environment, memory is allocated for the program code (sometimes called the text), the program stack, and data. Most of the data memory, called the heap, is under program control.
Lesson: SAP HANA Memory Management and Data Persistence
Figure 97: SAP HANA Memory Pool
As an in-memory database, it is critical for SAP HANA to manage and track its own consumption of memory carefully. For this purpose, the SAP HANA database preallocates and manages its own data memory pool. The memory pool is used for storing in-memory tables, for thread stacks, and for temporary computations, intermediate results, and other data structures. The utilization of memory by SAP HANA, therefore, includes its program code (exclusive and shared), the program stack, and the memory pool, which includes all of the data tables (row and column), system tables, and created tables. At any given time, parts of the pool are in use for temporary computations. The total amount of memory in use is referred to as used memory. This is the most precise indicator of the amount of memory that the SAP HANA database uses. Virtual, Physical, and Resident Memory
Figure 98: Virtual, Physical, and Resident Memory
When (part of) the virtually allocated memory actually needs to be used, it is loaded or mapped to the real, physical memory of the host and becomes “resident”. Physical memory is the DRAM memory installed on the host. On SAP HANA hosts, it typically ranges from 128 Gigabytes (GB) to 4 Terabytes (TB). It is used to run the Linux operating system, SAP HANA,
and all other programs. Resident memory is the physical memory actually in operational use by a process. Memory Consumption
Figure 99: Memory Consumption
The SAP HANA database, across its different processes, reserves a pool of memory before actual use. This pool of allocated memory is preallocated from the operating system over time, up to a predefined global allocation limit, and is then efficiently used as needed by the SAP HANA database code. When memory is required for table growth or for temporary computations, the SAP HANA code obtains it from the existing memory pool. When the pool cannot satisfy the request, the HANA memory manager will request and reserve more memory from the operating system. At this point, the virtual memory size of the HANA processes grows. Once a temporary computation completes, or a table is dropped, the freed memory is returned to the memory manager, which recycles it to its pool, without informing Linux. Thus, from the perspective of SAP HANA, the amount of Used Memory shrinks, but the process virtual and resident sizes are not affected. This creates a situation where the Used Memory may even shrink to below the size of SAP HANA's resident memory, which is perfectly normal.
Note: The database may also actively unload tables or individual columns from memory, for example, if a query or other processes in the database require more memory than is currently available. It does this based on a least recently used algorithm.
Caution: Due to the preallocation of memory as described above, Linux memory indicators such as top and meminfo do not accurately reflect the actual SAP HANA used memory size. Main memory monitoring should always be based on SAP HANA monitoring features.
Memory Management in the Column Store The column store is optimized for read operations, but also provides good performance for write operations. This is achieved through two data structures: main storage and delta storage.
Lesson: SAP HANA Memory Management and Data Persistence
Figure 100: Column Store Memory Management
The column store uses efficient compression algorithms that help to keep all relevant application data in memory. Fortunately you do not need manually choose the compression for each column. Instead SAP HANA does this during compression optimization, a process step that is automatically applied after an automatic delta merge, if the table contents have been changed substantially since the last compression optimizations. Parameters The threshold for optimization compression to kick in are defined as parameter, as shown in the following table: Table 7: Threshold for Optimization Compression Parameter
Default
Description
Active
Yes
Compression optimization status
min_change_ratio
1.75
Minimum required change row count (ratio)
min_hours_since_last_merge_of_part
24
Minimum hours since the last merge of part
min_rows
10240
Minimum required rows (which stored in the table)
Write operations on this compressed data would be costly, as they would require reorganizing the storage structure. Therefore, write operations in column store do not directly modify compressed data. All changes go into a separate area called the delta storage. The delta storage exists only in main memory. Only delta log entries are written to the persistence layer when delta entries are inserted.
The features of the Delta merge operation include the following: ●
●
●
●
The delta merge operation is executed on table level. Its purpose is to move changes collected in write-optimized delta storage into the compressed and read-optimized main storage. Read operations always have to read from both main storage and delta storage and merge the results. The delta merge operation is decoupled from the execution of the transaction that performs the changes. It happens asynchronously at a later point in time.
Note: For the delta merge operation a double buffer concept is used. This has the advantage that the table only needs to be locked for a short time. Details can be found in the Administration Guide.
Caution: The minimum memory requirement for the delta merge operation includes the current size of main storage + future size of main storage + current size of delta storage + some additional memory. It is important to understand that even if a column store table is unloaded or partly loaded, the whole table is loaded into memory to perform the delta merge. The Art of Merging
Figure I-1: The Art of Merging
The request to merge the delta storage of a table into its main storage can be triggered in several ways, as follows:
Lesson: SAP HANA Memory Management and Data Persistence
●
Auto Merge The standard method for initiating a merge in SAP HANA is the auto merge. A system process called mergedog periodically checks the column store tables that are loaded locally and determines for each individual table (or single partition of a split table) whether or not a merge is necessary based on configurable criteria (for example, size of delta storage, available memory, time since last merge, and others).
●
Smart Merge If an application powered by SAP HANA requires more direct control over the merge process, SAP HANA supports a function that enables the application to request the system to check whether or not a delta merge makes sense now. This function is called smart merge. For example, if an application starts loading relatively large data volumes, a delta merge during the load may have a negative impact both on the load performance and on other system users. Therefore, the application can disable the auto merge for those tables being loaded and send a “hint” to the database to do a merge once the load has completed. When the application issues a smart merge hint to the database to trigger a merge, the database evaluates the criteria that determine whether or not a merge is necessary. If the criteria are met, the merge is executed.
●
Hard and Forced Merges Delta merge operations for a table can be manually triggered using an SQL statement. This is called a hard merge and results in the database executing the delta merge immediately once sufficient system resources are available. An immediate merge (regardless of the system resource availability) can be triggered by passing an optional parameter in the statement.
●
Critical Merge The database can trigger a critical merge in order to keep the system stable. For example, in a situation where auto merge has been disabled and no smart merge hints are sent to the system, the size of the delta storage could grow too large for a successful delta merge to be possible. The system initiates a critical merge automatically when a certain threshold is passed. Critical merge is inactive by default.
Hint: The delta merge operation is a potentially expensive operation and must be managed according to available resources and priority. There are various options for controlling and monitoring delta merge operations. For more details, see the SAP HANA Administration Guide.
Note: Detail detailed information on memory management do you find in appendix 1 “Deep Diving into Memory Management and Persistence”
LESSON OVERVIEW This lesson discusses Software Packaging in SAP HANA. In addition to explaining the content of the slides, you can show the SAP HANA software components in the Service Marketplace.
Business Example The SAP HANA Platform Edition is the foundation of various other SAP HANA editions, like the SAP HANA Enterprise Edition. These editions bundle additional components that customers might require, for example, for data replication. For landscape planning and setup it is important to know about the content of the software editions and to understand which components are installed per default and which can be activated additionally. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Talk about solution packages
●
Describe the elements of the SAP HANA Platform Edition
●
Name additional components that are included in SAP HANA Enterprise Edition
●
●
Name the components that are installed by default, and those that can be activated additionally as add-ons Describe how content is bundled and provided with SAP HANA
SAP HANA system components can be installed, updated, or uninstalled using the SAP HANA database lifecycle manager (HDBLCM). You can install additional SAP HANA system components like the SAP HANA client, SAP HANA studio, and additional system components like Application Function Libraries (AFL and the product-specific AFLs POS, SAL, SCA, SOP, UDF), SAP liveCache applications (SAP LCA or LCAPPS-Plugin), XS advanced runtime applications, or SAP HANA smart data access (SDA) using the SAP HANA database lifecycle manager (HDBLCM) resident program. The SAP HANA system is made up of the following mandatory components: ●
SAP HANA server The SAP HANA database software is installed on the Linux operating system on certified hardware.
●
SAP HANA client SAP HANA client software is required for connecting to the SAP HANA database. Versions exist for AIX, HP-UX, Linux, Microsoft Windows, and Solaris.
The SAP HANA system also has the following components: ●
SAP HANA studio The SAP HANA studio is a collection of applications for the SAP HANA appliance software. It enables technical users to manage the SAP HANA database, to create and manage user authorizations, and to create new or modify existing models of data in the SAP HANA database.
●
Application Function Libraries (AFL and the product-specific AFLs POS, SAL, SCA, SOP, TRD, UDF) This refers to an optional application framework supporting function libraries (AFL, BFL, PAL).
●
140
SAP liveCache applications (SAP LCA or LCAPPS-Plugin)
The SAP liveCache application functions are provided by database procedures (liveCache Applications) having an extremely fast access to all application data, which can be completely cached in main-memory and are organized in a relational, but mainly objectoriented, manner. ●
SAP HANA Smart Data Access Smart data access drivers are required for transparent access to remote database tables via HANA proxy tables.
●
SAP HANA XS Advanced Runtime SAP HANA SPS 11 includes an additional, new run-time environment for application development: SAP HANA extended application services (XS), advanced model. SAP HANA extended application services, advanced model represents an evolution of the application server architecture within SAP HANA by building upon the strengths (and expanding the scope) of SAP HANA extended application services, classic model.
SAP HANA Software Editions The SAP HANA software editions are bundled into editions as license bundles for special purposes.
Figure 102: SAP HANA Software Editions
The SAP HANA software editions are as follows: ●
SAP HANA, base edition SAP HANA is a full transactional, ACID compliant relational in-memory database with standard SQL support, designed to run transactions and analytics on a single copy of data, with maximum performance. SAP HANA, base edition provides the basic capabilities of the SAP HANA platform, such as the SQL, calculation, aggregation engines, and smart data access.
●
SAP HANA, platform edition SAP HANA, platform edition provides all capabilities of the SAP HANA, base edition. In addition, SAP HANA, platform edition provides additional capabilities for data
warehousing, libraries for predictive algorithms and R integration, search and text mining, and use of spatial data. ●
SAP HANA, enterprise edition SAP HANA, enterprise edition provides all the capabilities of the SAP HANA, base edition and the SAP HANA, platform edition. SAP HANA, enterprise edition provides additional integration capabilities such as smart data integration and replication, and includes the data distribution rights for exporting data out of SAP HANA to be consumed in third-party applications without named user requirements.
SAP HANA Options
Figure 103: SAP HANA Options
Several extensions can be optionally installed or added to the SAP HANA server, including the following: ●
SAP HANA dynamic tearing SAP HANA dynamic tiering is a native big data solution for SAP HANA. Dynamic tiering that adds smart, disk-based extended storage to your SAP HANA database. Dynamic tiering enhances SAP HANA with large volume, warm data management capability. By using dynamic tiering to place hot data in SAP HANA in-memory tables, and warm data in extended tables, the highest value data remains in-memory, and cooler less-valuable data is saved in the extended store. This can reduce the size of your in-memory database.
●
SAP HANA smart data streaming The SAP HANA smart data streaming option processes high-velocity, high-volume event streams in real time, allowing you to filter, aggregate, and enrich raw data before committing it to your database. With SAP HANA smart data streaming, you can accept data input from a variety of sources including data feeds, business applications, sensors, IT monitoring infrastructure, and so on, apply business logic and analysis to the streaming data, and store your results directly in SAP HANA.
●
SAP HANA information management option The information management option for the SAP HANA platform offers data integration, data quality management, and information stewardship as native SAP HANA platform services, which simplifies the landscape and allows for better data management in both SAP HANA and non-SAP HANA applications while providing the basis for new data management applications from SAP and partners.
SAP HANA real-time replication option This option allows customers to use the runtime license of SAP Landscape Transformation replication server, SAP Replication Server, and SAP SQL Anywhere capabilities to replicate data from any supported source to the SAP HANA database in real time.
●
SAP HANA Operational Process Intelligence powered by SAP HANA SAP Operational Process Intelligence powered by SAP HANA is a platform that enables you to create smart process applications that comprises business scenarios, workflows, rules, and tasks. These smart process applications enable business users to ensure a smooth running of their business processes and take necessary action to resolve any bottlenecks.
●
SAP HANA accelerator for SAP ASE option The accelerator for SAP ASE adds analytics acceleration to the SAP ASE database engine leveraging SAP HANA. SAP ASE users can run reports in SAP HANA using the data in SAP ASE for real-time analytics by either replicating the data from SAP ASE to SAP HANA, or by creating virtual tables in SAP HANA, which access SAP ASE data. You can also use the SAP HANA accelerator for SAP ASE to accelerate SAP ASE stored procedures (not OTLP applications) by pushing down the stored procedure execution to SAP HANA. Minimal or no code changes to the existing stored procedures are needed. The stored procedures continue to execute against the SAP ASE reporting server with the execution being pushed to SAP HANA. The results are brought back to SAP ASE and then sent to the client SAP ASE application.
Caution: Be aware that you need additional licenses for SAP HANA options. Contact your SAP sales representative for details.
Detailed Information on Selected Components The SAP HANA Application Function Library (AFL) is part of the SAP HANA Platform edition and can be used to implement complex logic.
Figure 104: Application Function Library – General Overview
Predictive Analysis Library and Business Function Library are implemented using the AFL Framework. Application Function Library Framework in SAP HANA – Architecture and Features
Figure 105: Application Function Library Framework in SAP HANA – Architecture and Features
Application Function Modeler Instead of pure text-based implementations, the Application Function Modeler can also be used as graphical editor to facilitate the creation of wrapper-procedures.
Figure 106: Application Function Modeler
LESSON SUMMARY You should now be able to: ●
Talk about solution packages
●
Describe the elements of the SAP HANA Platform Edition
●
Name additional components that are included in SAP HANA Enterprise Edition
●
●
Name the components that are installed by default, and those that can be activated additionally as add-ons Describe how content is bundled and provided with SAP HANA
LESSON OVERVIEW This lesson focuses on SAP HANA use cases and scenario categories. These are discussed in conjunction with the SAP HANA roadmap and customer examples. In addition to the theoretical scenario explanation, you could also discuss a real customer example or show one of the customer story videos (see links below).
Business Example While SAP HANA can be used as database management system in classic system setups for existing applications, it can also be the basis for a new generation of in-memory applications and use cases. For customers, it is important to understand the different use cases and scenario categories to be able to discuss potential roadmaps and migration paths for the system landscape. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Describe SAP HANA use cases and scenario categories
●
Discuss the SAP HANA roadmap
●
Look up customer stories and use cases
Overview: SAP HANA Roadmap The figure below depicts a potential roadmap for the adoption of SAP HANA: side-car scenarios allow starting with a comparably small SAP HANA system implementing clear scenarios and solving existing issues. Using SAP HANA as primary persistence for existing applications facilitates more comprehensive optimizations and the maximum improvement can be achieved by implementing tailor-made applications for SAP HANA.
Figure 107: A Potential Roadmap for Using SAP HANA in Your System Landscape
Note: This is just an example for a potential roadmap with an increasing adoption of SAP HANA in the system landscape, not a standard recommendation. Depending on the customer requirements, other steps could be more reasonable, for example, using SAP HANA as primary database already in the first wave.
SAP HANA Scenarios Depending on the system architecture we generally distinguish between side-by-side scenarios and integrated scenarios. While in side-by-side scenarios, SAP HANA is added as additional component to an existing landscape to facilitate analytical features or accelerate processed, in integrated scenarios, SAP HANA is used as primary database. Furthermore, SAP HANA contains features that allow using it as platform for a new generation of applications. Examples of SAP HANA side-by-side scenarios are operational and agile data marts, as well as SAP HANA-based accelerators.
Data Mart Scenarios Agile and operational data marts leverage the analytical capabilities of SAP HANA and the tight integration with various data acquisition technologies. Agile Data Marts
Figure 108: Side-by-Side Scenarios: Agile Data Marts
The focus of using SAP HANA as an agile data mart is based in the objective of creating more flexibility compared to an Enterprise Data Warehouse, because it is often realized using SAP Business Warehouse. Data is typically loaded by means of traditional ETL (for example, SAP BusinessObjects Data Services) and has already been transformed. On top of this, data models in SAP HANA can be implemented to connect data in different tables or implement additional logic. Agile data marts generally do not target realizing a real-time reporting, but target increasing the modeling and reporting flexibility. Operational Data Marts
Figure 109: Side-by-Side Scenarios: Operational Data Marts
In contrast to agile data marts, operational data marts are oriented towards the requirements of operational reporting. Data can be acquired with low latency from SAP and non-SAP sources using SAP System Landscape Transformation Replication Server for SAP HANA (SLT) or similar technologies. Since data models implemented in SAP HANA do not require to materialize aggregated data, the combination of using SAP HANA data models with a (near) real-time data acquisition technologies allows you to implement reporting solutions that reflect data changes in the source systems immediately.
SAP HANA accelerators enable the acceleration of standard ABAP reports, as well as selected business processes in SAP Business Suite Systems. One example for this is a solution for SAP HANA accelerated finance and controlling that comprises using SAP HANA for financial accounting, controlling, material ledger, production cost analysis, and profitability analysis. It is also offered as RDS (for details see also SAP Service Marketplace: https:// websmp109.sap-ag.de/rds-hana-fin). Various other SAP HANA-based accelerators are offered by SAP. It is also possible to use SAP HANA as accelerator also for customer-individual implementations. Architecturally, data is transferred with low latency to SAP HANA, which is used as secondary database. Using the appropriate Database Shared Library (DBSL), the SAP Business Suite system accesses SAP HANA instead of the primary database for the reports or processes specified to benefit from the acceleration or additional functionality implemented in SAP HANA.
SAP HANA as Primary Persistence
Figure 111: SAP HANA as Primary Persistence
In integrated scenarios, SAP HANA is used as primary persistence for applications. This can be achieved by migrating existing SAP Business Suite systems to SAP HANA, or performing greenfield installations directly on SAP HANA. With SAP HANA becoming the primary
persistence of the ABAP application server, all objects and processes can make use of the inmemory technology
Caution: Even though architecturally it looks like as if the change solely affected the database layer, the application running on SAP HANA has to be explicitly optimized in advance to leverage the capabilities and push down calculation intense logic to the database. Hence minimum versions respectively EHP levels exist that contain SAP HANA support. Examples for SAP applications that have been optimized to use SAP HANA as primary persistence are follows: ●
SAP BW 7.30 SP05
●
EHP 7 for SAP ERP 6.0
●
EHP 3 for SAP CRM 7.0
●
EHP 3 for SAP SCM 7.0
●
EHP 3 for SAP SRM 7.0
●
SAP Portfolio and Project Management 6.0
Deployment Options for SAP HANA and SAP NetWeaver AS ABAP SAP HANA and SAP NetWeaver AS ABAP could be deployed on two different servers, or on one server.
Figure 112: Deployment Options for SAP HANA and SAP NetWeaver AS ABAP
Deployment of SAP HANA and SAP NetWeaver AS ABAP on one hardware is available for all productive and non-productive SAP HANA SPS7 single node installations. All products based on SAP NetWeaver AS ABAP 7.4 are supported. The requirements are as follows:
Additive sizing; additional memory resources for the SAP NetWeaver AS ABAP system needs to be available on the SAP HANA server. Separate SIDs for both systems are required.
Migration to SAP HANA Technically, a migration to SAP HANA is only a change of the database that does not affect most of the other components in the landscape. An SAP Business Suite system running on SAP HANA can still connect to, and be integrated with, other systems and hubs in same way as a Business Suite system running on any other database. Furthermore, the same frontends and clients can be used to connect to the system. Even the application servers can be reused as they are, because they are running on separate servers and not on the database host.
Figure 113: Overview: Migration of SAP Systems to SAP HANA
Migrating your existing SAP system to the SAP HANA database means switching the SAP system to a new database that is running on a new host, since SAP HANA is an appliance. Two Ways to Migrate to SAP HANA A migration to SAP HANA could be performed in two ways: ●
Heterogeneous system copy using Software Provisioning Manager (SWPM).
●
Database migration option (DMO) of the Software Update Manager (SUM)
Initial Situation The classical migration is the sequence of SAP software update (using Software Update Manager (SUM) and heterogeneous system copy (using Software Provisioning Manager (SWPM)). DMO simplifies the migration and is often referred to as the one-step procedure to SAP HANA.
Figure 115: Initial Situation
DMO is not a new tool, it is just an option; a new option in an existing tool named Software Update Manager (SUM).SUM is the trusted tool for system maintenance, such as:
The Migration Process In case of an inplace migration using DMO, upgrade and migration are performed in a combined procedure which reduces TCO and risks.
Figure 116: The Migration Process
Performing the migration in a combined procedure offers the following benefits: ●
The combined procedure requires only one maintenance phase (not two). Reduces business downtime (TCO), less regression tests necessary.
●
Original database is kept, can be reactivated as fallback. Reduces risk, no restore required, more time for testing before cutover.
●
Lower prerequisites for SAP and DB start releases. Reduces effort (TCO), no additional licenses for traditional database updates.
●
In-place migration keeps application server and System ID stable. Low impact on system landscape: only the database server is new.
●
For SAP BW, DMO can be applied when PCA (Post Copy Automation) is used.
SAP HANA can be used as not only a sidecar to or primary database of existing applications, but also as entire application platform as follows: ●
●
Any application could directly connect to SAP HANA using standard interfaces, such as JDBC and ODBC. Native SAP HANA applications can be implemented in SAP HANA, without requiring an additional application server on the basis of SAP HANA Extended Application Services (XS). This is described in detail in next pages.
SAP HANA Extended Application Services SAP HANA XS facilitates the development of new applications directly in SAP HANA and can also be used by SAP customers or partners to implement own applications.
Figure 118: SAP HANA Extended Application Services
SAP HANA Extended Application Services (2) A combination of several technologies can be used for controlling the data processing and calculation logic, implementing the control flow, and creating the front-end.
Figure 119: SAP HANA Extended Application Services (2)
Combination of Multiple SAP HANA Scenarios Note: When discussing potential SAP HANA scenarios and implementation roadmaps, be aware that, under certain circumstances, it is also possible to implement several scenarios on the same SAP HANA database. For example, one SAP HANA database could be used as primary persistence of an SAP BW system providing accelerator capabilities to an SAP ERP system at the same time. Examples are shown in the figure, Combination of Multiple SAP HANA Scenarios. This topic is also discussed in detail in the lesson on deployment options.
Figure 120: Combination of Multiple SAP HANA Scenarios
SAP HANA Platform The SAP HANA platform converges database, data processing, and application platform capabilities, and provides libraries for predictive planning, text, spatial, and business analytics to enable business to operate in real-time.
Figure 121: SAP HANA – A Platform to Innovate Enterprise Applications
SAP HANA is More Than an In-Memory Database Management System SAP HANA is an in-memory database management system, but also comprises many additional features for specific use cases. Examples are spatial processing, search, and text mining and integrated libraries. Some of these features can be used when running traditional applications on SAP HANA, others are leveraged in entirely new in-memory applications.
Figure 122: SAP HANA is More Than an In-Memory Database Management System
These features enable new scenarios and use cases. However, applications need to be explicitly adapted to tap the full potential of SAP HANA. Customers use SAP HANA in different scenarios. Besides the optimization potential, the way in which SAP HANA is integrated into the system landscape has also an impact on aspects like system architecture, administration, operations, and security. Therefore it is essential to include all stakeholders into the scenario discussion.
S/4 HANA S/4HANA stands for SAP Business Suite 4 SAP HANA where S means Simple, but it stands for Suite too, and the 4 stands for fourth generation. SAP S/4HANA is our next generation business suite. It is a new product, fully built on the SAP HANA platform and designed with SAP Fiori user experience. SAP S/4HANA delivers massive simplifications (adoption, data model, user experience, decision-making, and business processes) and innovations (for internet of things, big data, business networks, mobile first) to help reinvent businesses. SAP S/4HANA brings the next big wave of innovation to customers, similar to the transition from SAP R/2 to SAP R/3.
What is new in SAP S/4HANA compared to SAP Business Suite powered by SAP HANA? With SAP Business Suite powered by SAP HANA, SAP was the only software vendor in the market at that time to allow SAP Business Suite customers to bring together transactions and analysis into a single in-memory platform. This innovation has been extremely successful in the market, as 1,850+ customers (existing and new) acquired SAP Business Suite powered by SAP HANA – in less than two years – to run their business in real time, making it one of the fastest-growing product in the history of SAP. With SAP Business Suite powered by SAP HANA, our product approach has been to port the applications on the SAP HANA platform and optimize the code to allow customers the ability to gain significant performance in their mission-critical business processes and reporting activities, and by that, in turn, also improve performance on relational databases. SAP HANA represented a new database alternative for existing customers, with a simple database migration required to drive the entire business in real time. S/4HANA creates unique opportunities to not only run your day-to-day business in real-time with industry best practices but also to reinvent business models and drive new revenues.
Reimagined business models Simplicity to connect to people, devices, and business networks in real-time to deliver new experiences and value to customers. The Internet of Things and big data become accessible to any business, eliminating the need for more complex business collaboration and interactions.
●
Reimagined business decisions Simplicity to get any insight on any data from anywhere in real-time: planning, execution, prediction, simulation are now all done on the fly to drive faster business impact.
●
●
Reimagined business processes Simplicity to focus on the essential tasks in real-time and gain flexibility and agility to change business processes as needed for new efficiencies.
SAP S/4HANA is a new business suite of applications. It is built to drive instant value across enterprises, industries, lines of business, data, regions, and deployments, with the ultimate sophistication: simplicity. ●
●
●
Simple User Experience purposefully built around the way business users work with a rolebased, consistent user experience available on any device. Simple Business Solutions purposefully built around the way businesses want to work with real-time insights and business processes across a digitally connected network. Simple Data Model with purposefully built around the way applications should all work to offer the best level of responsiveness and performance with the lowest data footprint.
From an IT value perspective, this means that SAP S/4HANA creates unique opportunities to simplify the landscape dramatically, and reduce TCO with SAP HANA as the great simplifier. First, enterprises can now significantly reduce their data footprint and work with larger data sets in one system (for example, ERP, CRM, SRM, SCM, and PLM in one system) to save hardware costs, operational costs, and time. They will no longer face discrepancies between the different systems with one common source of live data on one system. Second, innovation is also made simple with an open platform (the SAP HANA Cloud Platform) to drive advanced applications - for example predicting, recommending, simulating - while protecting existing investments. Third, business users can leverage a simple and role-based user experience based on modern design principles minimizing training efforts while increasing productivity. Please note that we also support the clients with simple configuration: setting up the system and furthermore during the usage. And finally, enterprises get choice of deployment: cloud, on-premise and even hybrid to drive easy adoption. SAP S/4HANA is only built on SAP HANA because only the SAP HANA platform can deliver such level of massive simplifications and innovations.
On the data side, we simplify the underlying data structure to the utmost extend until a highly performing and optimized system is left. The underlying data structure is based on no indices, no aggregates, and no redundancies. SAP S/4 HANA Benefits SAP S/4 HANA include the following key benefits: ●
Smaller total data footprint
●
Higher throughput
●
Faster analytics and reporting
●
Less process steps
●
No locking, parallelism
●
Actual data (25%) and historical (75%)
●
Predict, recommend, simulate
●
SAP HANA Cloud Platform extensions
●
SAP HANA multitenancy
●
All data: social, text, geo, graph, processing
●
New SAP Fiori User Experiences for any device (mobile, desktop, tablet)
Finally, this example from an early adopter of Simple Finance shows the impact a simplified architecture has on IT operations and server resources. SAP S/4 HANA Simple Finance This new type of architecture has been piloted in Simple Finance, adopted for Simple Logistics and we know that it works and performs for HANA – this is the target architecture for all other simplified components. In the past, indices and total tables were created to avoid that systems were always calculating. This happened to ensure overall system performance, but at the price of complexity and inflexibility. Both have now been eliminated from the system. A typical booking in FIN touched 15 tables – now its 4, working on document level. SAP HANA and SAP BW Does SAP HANA Replace SAP BW? No, they complement each other. SAP BW is better on SAP HANA, SAP BW is free. There is plenty of pre-built content for SAP BW, and you have instant, certified solutions on top of SAP BW. There is no plan to retire SAP BW. Many SAP BW customers have SAP Business Warehouse Accelerator to accelerate their slow disk based RDBMS for SAP BW. SAP HANA provides a much simpler landscape, reducing TCO and complexity. It reduces your hardware footprint dramatically, for example, to accelerate 5TB of BW data, you would need 21 blades in SAP BWA versus 1 HANA server, with the added benefit of no third party database, because SAP HANA is the single persistent database. SAP HANA is many things (a database for SAP BW, a high-performance analytical appliance, a platform for new applications), but matching the entire system, known as SAP BW, pointfor-point is a huge project for any company.
Customer Stories and Use Cases In a summary there are standard SAP solutions and scenarios for SAP HANA, but, at the same time, a lot of flexibility for customers to use SAP HANA according to their individual requirements and for implementing their own scenarios and applications. Therefore, SAP has
created a community in which use cases and customer stories are shared and discussed, which might help to inspire and contribute to scenario and roadmap discussions.
Figure 128: SAP HANA Community: Use Cases
SAP HANA use cases can be viewed and shared on http://www.saphana.com/community/ implement/use-cases. They are ordered in different categories, for example, Automotive, Banking and Retail, and can be filtered by tags.
More than 50 videos are available, in which customers explain their SAP HANA scenarios and share, which improvements they were able to achieve by adopting it: http:// www.saphana.com/community/learn/customer-stories
LESSON SUMMARY You should now be able to:
164
●
Describe SAP HANA use cases and scenario categories
LESSON OVERVIEW Depending on the requirements for productive and non-productive usage, various deployment options for SAP HANA exist. These are explained in detail in this lesson. You could also discuss with the participants which of the deployment options they have already tried out and what the requirements are in their companies.
Business Example At the time of its market introduction, SAP HANA was only offered following an appliance model as a certified combination of hardware and software that could be deployed as an onpremise 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. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the different deployment options for SAP HANA
●
Explain SAP HANA cloud offerings
●
Describe the availability and capabilities of virtualization for SAP HANA
●
Describe the option for tailored data center integration
●
Identify available co-deployment scenarios
●
Describe which limitations exist with regard to productive usage
●
Describe the new option for multitenant database containers
Overview When discussing SAP HANA deployment options, we generally distinguish between a preconfigured on-premise appliance, a cloud deployment, and a hybrid model that combines cloud and on-premise instances. For each of the deployment option, various solutions exist, which are discussed in detail below.
Figure 130: SAP HANA Deployment Options Overview I
SAP HANA on Premise On-premise and on-demand options and offerings are explained in detail below.
Figure 131: SAP HANA on Premise
From an infrastructure point of view, SAP HANA can be deployed on premise as single server or scale out cluster (distributed system) and runs on x86 based hardware. SAP HANA hardware is not proprietary, but following an appliance model certified combinations of hardware and software are offered by several hardware vendors.
The appliance model allows a deployment of SAP HANA in a standardized and highly optimized way. Due to the preconfigured hardware setup and the preinstallation of the software package a fast implementation that is fully supported by SAP and the hardware vendors is ensured. SAP HANA Tailored Data Center Integration Option - Overview In an on-premise deployment, SAP HANA runs on dedicated hardware. On-premise SAP HANA is deployed through the following offerings: ●
●
As an appliance, SAP HANA combines software components from SAP optimized on proven hardware provided by our hardware partners. This approach is valid for Intel-based hardware platforms only. While this approach is easy and comfortable, it might bring limitations with regard to 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 more flexibility. Compared with the appliance delivery approach, SAP HANA tailored data center integration is a more open and flexible approach to serve your needs regarding the integration of SAP HANA in the data center. The requirements for this deployment option are as follows -
The storage solution has successfully passed SAP HANA hardware certification
-
The server is certified and belongs to the allowed hardware
-
The storage solution has successfully passed SAP HANA hardware certification.
-
The components of SAP HANA can only be installed by certified hardware partners, or any person holding a certification, on validated hardware running an approved operating system.
Figure 132: SAP HANA Tailored Data Center Integration Option - Overview
Tailored data center integration can help to reduce hardware and operations cost by reusing existing hardware components and processes.
Note: Tailored data center integrations offers freedom and flexibility, which also leads to an increased responsibility of the customer for the system that ranges from the installation up to running the landscape. SAP HANA Tailored Data center Integration
Figure 133: SAP HANA Tailored Data center Integration with Enterprise Storage
In the first wave, all storage that successfully passed the hardware certification can be used in combination with servers listed in the Product Availability Matrix. Visit the Partner Information Center for details: http://www.sap.com/partners/overview.html There is also a new installation certification exam offered which is in line with the tailored data center integration program. This exam needs to be passed successfully to perform SAP HANA installations at customer side. Detailed information can be found in the SAP Training and Certification Shop: https://training.sap.com The following documents and tools provide information about SAP HANA TDI with enterprise storage: ●
Storage Whitepaper – Background Knowledge -
168
Conceptual storage layout, non-shared storage versus shared storage
For certification, each storage vendor must file in a configuration guide
-
Explains how to configure the storage for optimal collaboration with SAP HANA
-
Get a copy directly from your storage vendor
SAP HANA HW Config Check Tool (HWCCT) -
Command-line tool
-
Used by storage vendors, SAP Support, and customers
-
Measures the data throughput and latency times between the SAP HANA servers and the Enterprise Storage system
-
Download it from SAP Support Portal
-
Documented in PDF attachment of SAP Note 1943937
Read the SAP Storage Whitepaper carefully, and get a copy of your storage vendor’s configuration guide for SAP HANA. Make sure that you run the SAP HANA HW Config Check Tool to check your storage KPIs every time you change your storage configuration.
Note: Customers should consider involving SAP Active Global Support to perform a HANA Go-Live Check prior to going productive
SAP HANA Tailored Data Center Integration with Enterprise Network
Figure 134: SAP HANA Tailored Data Center Integration with Enterprise Network
With the introduction of TDI with Enterprise Network, SAP supports hardware setups, which comply with the prerequisites mentioned in the figure, SAP HANA in the Cloud - Overview. Apart from that, no further approval by SAP is required. SAP does not introduce any certification of network components for TDI setups. Customers should consider involving SAP Active Global Support to perform an SAP HANA Go-Live Check prior to going productive.
SAP HANA in the Cloud Several options are offered by SAP and partners to run SAP HANA in the cloud. SAP HANA is more than just an in-memory database, but rather a complete application development platform in its own right. Given this unique characteristic and the wide range of usage scenarios three distinct packages that are logically based on each other are available.
SAP HANA Infrastructure Services (IaaS) This package provides SAP HANA infrastructure on a subscription basis for customers who already have a license and who want to get up and running quickly and without having to invest into hardware.
●
SAP HANA DB Services (DBaaS) This package provides both infrastructure and license subscriptions for SAP HANA and it comes in two flavors: a Base and a Platform Edition. Both editions provide native development capabilities such as SQLScript, Extended Application Services (XS) and River. SAP HANA Cloud Integration for data services, an ETL-tool, is pre-configured and ready to be used for initial and delta loads. In addition to all the features included in the Base Package, the Platform Edition also includes Advanced Engines (Planning, Geo-Spatial, Predictive, Graph, Text Search & Tech Analytics), the Planning SDK, the Predictive Analysis Library and Hadoop/R Integration. For more details about these features, consult the document.
●
SAP HANA App Services (PaaS) This package includes all of the capabilities of the DB Services package, and, in addition, provides shared Application Services and capabilities typically required for the development of new multi-tenant cloud applications or extensions of existing solutions residing either on-premise or in the cloud. To facilitate the rapid development of cloud applications, the platform provides a vast set of platform services for the most common pattern in software engineering such as persistence, connectivity, identity, document management, and so on. Addressing the needs it requires to develop first-class business applications these application management services are complemented by profiling and monitoring tools, logging capabilities and remote debugging of cloud applications.
SAP HANA Enterprise Cloud is an enterprise-class SAP HANA managed cloud offering. The infrastructure and managed services are available for a monthly subscription (license bought separately). SAP HANA One is fully-featured SAP HANA hosted in the public cloud.
The infrastructure and license are available for an hourly subscription In addition, SAP also offers a set of higher-level services based on the SAP HANA Cloud Platform, which provide specialized capabilities as needed for specific scenarios such as the following: ●
Mobile — SAP Mobile Platform Enterprise Edition cloud version
●
Portal — SAP HANA Cloud Portal
●
Analytics — SAP Lumira Cloud
●
Connectivity — Gateway as a Service (GWaaS)
●
Integration — SAP HANA Cloud Integration
Technical Deployment Options The “classical” deployment option is a single application on one SAP HANA system, which is also known as Single Component on One System (SCOS). To describe the various other options for technical deployment, it is useful to first illustrate the simple approach to deploying an application on an SAP HANA system. This is useful for comparison purposes. In this configuration, a single application runs in a single schema, in a single SAP HANA database as part of an SAP HANA system. This is a simple, straightforward scenario that is supported for all scenarios without restriction.
Figure 136: Single Application on One SAP HANA System (SCOS)
For running multiple scenarios on one system or database, it is required to know about the availability and capabilities of the technical deployment options. An overview is depicted below. Technical Deployment Options ● Multiple Components on one System (MCOS)
Figure 137: Multiple Components on One Database (MCOD)
In MCOD scenarios, multiple applications are running on one database. Data can be separated using different database schemas. This deployment type is available, with restrictions, for production SAP HANA systems. For production systems, whitelists exist, in which supported scenarios are explicitly specified.
Figure 138: Multiple Components on One System (MCOS)
MCOS refers to the installation and operation of multiple SAP HANA databases on a single SAP HANA system. SAP does support running multiple SAP HANA systems (SIDS) on a single production SAP HANA host. This is restricted to single-host / scale-up scenarios only. Keep in mind that multi-SID requires significant attention to various detailed tasks related to system administration and performance management. Production support is restricted to SPS09 or higher due to the availability of some resource management parameters (for example affinity). Be aware that running multi-SID on one SAP HANA host may impact performance of various types of operations, as contention for computing resources may occur (memory, cpu, i/o, and so on). We strongly recommend performing requisite testing in any project before going live; in general, stress or volume testing is recommended to provide good indicators of expected performance. When operating a system that features a multi-SID deployment, we recommend that you actively make use of the resource management features of SAP HANA (for example, parameters controlling memory limits, and influencing utilization of CPU cores, and so on) to optimize performance.
Virtualization One benefit of virtualization is the possibility to assign dedicated CPU and memory resources to specific databases and, increasing the flexibility of hardware usage.
For customers already standardizing on virtualization technology, SAP HANA offers the customer TCO reductions and additional options for planning and managing their systems landscapes. ●
Ease of HW replacement and avoidance of re-certification of OS and SAP installations
●
Separation of IT Ownership (HW and SW layer)
●
OS independent monitoring
●
Low-cost HA capabilities in Dev and Test environments
Private and Public Cloud offerings also lower entry barrier, or example, for startups by starting their business small and later scale along their needs in regards to user and data volume. ●
Positive impact on capital expenditures
Technical Co-Deployment Technical co-deployment is an additional alternative that can be used to combine several applications. This is available for Supplier Relationship Management (SRM) and Supply Chain Management (SCM) being provided as ERP add-on and can be used productively.
Multitenant Database Containers SAP HANA multitenant database containers establish a foundation for providing multitenancy in SAP HANA. When discussing multitenancy the first question will be to define the term multitenancy. Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple tenants. A tenant is a group of users sharing the same view on a software they use. With a multitenant architecture, a software application is designed to provide every tenant a dedicated share of the instance including its data, configuration, user management, tenant individual functionality and non-functional properties. Multitenancy contrasts with multi-instance architectures where separate software instances operate on behalf of different tenants. From http://en.wikipedia.org/wiki/ Multitenancy. In the standard SAP HANA Deployment Scenario you have one SAP HANA Database Management System (DBMS), one database, one application, one schema. The benefits of this scenario are as follows: ●
●
●
Simple, straightforward scenario Maximum resource allocation to single application or scenario with no resource contention with others Supported with no restrictions
The concept of SAP HANA multitenant database containers allows you to manage several databases in one DBMS.
LESSON OVERVIEW Before going into details, this lesson provides you with an initial overview of tools that can be used for administration of an SAP HANA database. You can ask the participants, which (SAP HANA) monitoring tools they already know and what they currently use for monitoring their systems.
Business Example Administrators of SAP HANA systems need to know about the tools for administration and monitoring, how they are integrated with SAP HANA, and what their capabilities are. Previously, the most common tool was the SAP HANA studio, but, with SPS09, the SAP HANA Cockpit is used increasingly. Because several tools are available for the administration of SAP HANA, it is important to know the differences between these tools. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Describe which administration tools exist for SAP HANA
●
Explain what capabilities the various administration tools have and when to use them
SAP HANA Administration Tools - Overview Table 8: SAP HANA Administration Tools - Overview The following table provides an overview of the most important SAP HANA administration tools (a thorough overview is available in the SAP Administration guide). Tool
Description
SAP HANA studio
The SAP HANA studio is main tool for general system administration and monitoring tasks. You will be hearing more about this in a special lesson within this course.
SAP HANA cockpit
Web-based tool for administration and monitoring of a single SAP HANA database The SAP HANA cockpit is an SAP Fiori Launchpad site that provides you with a single point-of-access to a range of Webbased applications for the administration of SAP HANA. We discuss in this functionality further in the next lesson.
The DBA Cockpit is a platform-independent tool that you can use to monitor and administer your SAP HANA database. The DBA Cockpit offers a subset of the functionality of the SAP HANA studio. In addition, you can use the DBA Cockpit to schedule backups and configure logging. There is a special lesson for this topic in this course.
SAP Solution Manager
If you are using SAP HANA with other SAP business applications, it is possible to integrate with SAP Solution Manager. SAP Solution Manager provides basic administration and monitoring features for SAP HANA systems, within existing SAP system landscapes, through the enablement of the DBA Cockpit, solution manager diagnostics, the System Landscape Directory (SLD), and the Maintenance Optimizer (MOPZ).
SAP HANA HDBSQL SAP HANA HDBSQL is a command line tool for executing commands on SAP HANA databases. There is more about this tool in a separate lesson during this course. SAP DB Control Center
Web-based tool for administration and monitoring of your landscape of SAP HANA databases. Support thousands of SAP Databases (including ASE, IQ ) in Data Center or Cloud. The inclusion of MaxDB is in progress.
SAP HANA Administration Tools - Overview The SAP HANA studio is both the central development environment and the main administration tool for the SAP HANA database. With SPS09 additionally a first version of the web-based tools SAP DB control center and SAP HANA cockpit was introduced for monitoring SAP HANA. These tools can also be used on mobile devices. Furthermore SAP HANA is fully integrated into SAP Solution Manager. Following the cloud strategy of SAP, SAP HANA offers Web-based tools for monitoring and administration. SAP HANA cockpit follows an alert-driven guided-procedure approach. A DBA will be enabled to drill down to the root cause of an issue.
Figure 142: SAP HANA Administration Tools - Overview
Note: It is planned to replace the administration perspective of HANA studio with SAP DB Control Center and SAP HANA cockpit in the long term. SAP DB Control Center and SAP HANA Cockpit
Figure 143: SAP DB Control Center and SAP HANA Cockpit
SAP DB Control Center (SAP DCC) enables you to perform aggregate monitoring of SAP database products, including SAP HANA, and manage the cockpits (management consoles) that manage the database products. Use the control center to check the overall health of systems located within a data center or across your enterprise. You can drill down into status indicators for more detailed information, monitor the databases running on monitored systems, and access cockpits on those systems. Status displays focus on four high-level areas, as follows: ●
●
●
●
Availability - is the system running and accessible on the network? Is it able to serve the business needs of its users, including humans and applications? Performance and capacity issues can affect availability. Performance - is the system meeting the response time expectations of database users, including humans and applications? Capacity - is the system meeting its service level agreements? Alerts - are there errors to resolve, or event messages that to review? Alert events, given priorities of high, medium, or low, are triggered when the system exceeds state and range thresholds set by system and database administrators.
SAP DB Control Center SAP DB Control Center is not part of auto installed content. Installation and configuration is described in the “SAP DB Control Center Guide”.
LESSON OVERVIEW This lesson gives an introduction to the SAP HANA Studio and SAP HANA Cockpit and explains some basic features of both tools. Further details are discussed in the respective topics in other lessons of this course. The figures included in this lesson are for reference purposes. You can also give a live demonstration and explain the features in the SAP HANA Studio directly.
Business Example With SPS09 a new Administration tool is available, the SAP HANA cockpit. The SAP HANA cockpit is a Fiori launchpad based tool. It is currently not a replacement of SAP HANA Studio, but it is a long-term goal to have only one administration tool. The current version is not yet complete, but more features will be included in the next version. The well-known SAP HANA studio runs on the Eclipse platform, and is both the central development environment and the main administration tool for SAP HANA. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Understand the basic functions of the SAP HANA studio and SAP HANA Cockpit
●
Explain the concept of perspectives
●
Add an SAP HANA system to an SAP HANA Studio installation
●
Obtain an initial system overview in the Administration Console of the SAP HANA studio
Administrators use the SAP HANA studio, for example, to start and stop services, to monitor the system, to configure system settings, and to manage users and authorizations. The SAP HANA studio accesses the servers of the SAP HANA database by SQL. Developers can use the SAP HANA studio to create content such as modeled views and stored procedures. These development artifacts are stored in the repository, which is part of the SAP HANA database. SAP HANA Studio - Available Perspectives The SAP HANA studio is developed in Java and based on the Eclipse platform. The SAP HANA studio presents its various tools in the form of perspectives. Database administration and monitoring features are contained primarily within the SAP HANA Administration Console perspective. Additional perspectives include the SAP HANA Modeler perspective and the SAP HANA Development perspective.
Figure 146: SAP HANA Studio - Available Perspectives
SAP HANA Studio - Adding a System After the installation, SAP HANA Studio does not contain any system. By right-clicking into the system window, SAP HANA systems can be added. Two options exist: ●
The second option allows you to insert a link to a centrally-stored archive of SAP HANA systems. To allow users who work in the SAP HANA studio to connect efficiently to multiple SAP HANA systems, you can manage a list of all systems in a centrally-accessible archive. Users can then link to this archive. A centrally-stored archive of SAP HANA systems is an efficient way to deploy system information to all users of the SAP HANA studio, for example, developers, content modelers, and other administrators. It avoids users having to obtain the connection details of all systems individually and then having to add them all individually. In addition, if you change the central file, for example to add new systems or change the host of an existing system, you can ensure that users always have up-to-date system access.
Having added the system, it appears in the system navigator screen on the left side of the SAP HANA Studio window. It contains the following elements: ●
Backup Here you can configure the backup (Destination, File size) and here you could find the backup catalog too.
●
Catalog The catalog contains all schemas that include the respective column and row tables. While some schemas exist by default (for internal SAP HANA usage), others can be created by users respectively administrators.
●
Content The content folder holds packages in which development and modeling artifacts are stored.
●
Provisioning Provisioning relates to the functionality of “Smart Data Access”. It contains remote sources and proxy tables.
●
Security Within the security folder, users, and roles, as well as other security settings can be maintained.
Administration Console Perspective: Screen Areas The figure provides an overview of the administration and monitoring activities of SAP HANA using the administration console of the SAP HANA studio (the studio). The administration console of the studio allows system administrators to manage the database including creating and managing user authorizations. The studio also contains perspectives for other tasks, such as the information modeler that allows modeling users to create new or modify existing models of data, and the lifecycle management that allows you to update the HANA system.
Figure 151: Administration Console Perspective: Screen Areas
The administration console is predelivered by SAP. You can access the administration console in one of the following ways: ●
Select the Administration icon in the top right corner.
●
Double-click the system in the system monitor.
●
Double-click the system in the Navigator view.
View Context Menu of SAP HANA Studio The SAP HANA Systems view provides you with a hierarchical view of all the SAP HANA systems managed in the SAP HANA studio and their contents (database catalog, users, roles). This view allows you to see the status of your systems at a glance. It is also the central access point for performing system-specific administration and monitoring activities. From the context menu of the systems view, a range of administrative functions can be accessed. Administration Console – Overview Tab The administration console comprises the following tabs: ●
Regularly check the database status on the Overview tab page of the Administration editor. To open the Administration editor, choose Administration in the context menu or double-click on the database entry. Here, the most important database information is displayed. In the upper part of the screen, the overall database state and general database information (software versions, and so on) are displayed. The warning section shows the latest warnings generated by the statistics server. The bar views provide an overview of important database resources: the amount of memory, CPUs, and storage space available on the server as well as the used amount of these resources (used by all processes, not only by the SAP HANA database). In a distributed landscape, the amount of available resources is aggregated over all servers. In addition, the resource information of the server with the highest resource consumption is displayed. Links in each section guide you to more detailed information about the specific topic, for example, a database version history, a detailed alert list, or detailed storage information.
Figure 153: The Administration Editor – Diagnosis Mode
The SAP HANA studio normally collects information about the system using SQL. However, when the system has not yet started or is down, no SQL connection is available. In this situation, the SAP HANA studio collects information about the database using the connection of the SAP start service (sapstartsrv). You can view this information in the Administration editor in diagnosis mode. In this way, you can analyze any problems that may occur during startup or while the system is stopped. You can also access diagnosis files. You can only open the Administration editor in diagnosis mode as the operating system user, adm.
Note: The other tabs, for example, Landscape, Alerts, Performance, and so on, are not explained in this lesson, but in subsequent chapters of this course.
When you save the Administration editor, all statements, together with the defined folder structure, are saved to a single XML file and are available on the System Information tab of the Administration editor for all systems registered in the SAP HANA studio.
SAP HANA Cockpit With SPS09 the first version of SAP HANA cockpit is available in addition to the SAP HANA studio. The SAP HANA cockpit has the following features: ●
The SAP HANA cockpit is an SAP Fiori Launchpad site that provides single point-of-access to a range of web-based applications for the administration of SAP HANA.
●
It is installed with SAP HANA as automated content.
●
It displays content as tiles arranged in groups
●
●
The default homepage of tiles is customizable by modifying existing groups and creating new groups; tiles can be removed and added from any of the available tile catalogs. The SAP HANA cockpit implements a role-based concept so that users only have access to those tile catalogs for which they are authorized.
●
It provides access to the SAP HANA Administration Guide.
●
The URL of the SAP HANA cockpit is http://:/sap/hana/admin/cockpit.
●
It can also be opened from the SAP HANA studio context menu.
It will be explained further in the Unit 'Operation'.
The tiles of the SAP HANA cockpit were already available in SAP HANA studio version SPS08, on the monitoring Dashboard. That was an interim solution; a way to provide a Web-based monitoring tool. Tiles not only function as entry points to individual applications, but also display selected, application-specific data for immediate review. For example, the Latest Alerts tile shows you the number of high and medium priority alerts currently in the system. From these tiles, you can drill down into the relevant application for more detailed information and functions. All SAPUI5 editors were moved from SAP HANA Studio to the SAP HANA cockpit to provide a single point of access to these tools.
Note: The required privileges are granted automatically to roles sap.hana.admin.roles::Administrator and sap.hana.admin.roles::Monitoring.
Figure 156: SAP HANA Cockpit for Offline Administration
The SAP HANA cockpit for offline administration is a version of the SAP HANA cockpit that communicates with SAP HANA using SAP Host Agent. You can use it to perform administration tasks, such as starting the system or troubleshooting a system experiencing performance problems, as operating system user adm. Content is displayed as tiles that function as entry points to individual applications. However, there are no groups or tile catalogs, and it is not possible to modify the content or the homepage. The SAP HANA cockpit for offline administration is accessible at https://:1129/ lmsl/hdbcockpit//index.html (recommended) or http://:1128/ lmsl/hdbcockpit//index.html. You can also navigate to the SAP HANA cockpit for offline administration from the standard SAP HANA cockpit. HANA Cockpit Automatic Privileges To ensure that SAP HANA cockpit can be used immediately after database creation, the database user SYSTEM is automatically granted several roles the first time the cockpit is opened with this user.
Using SAP HANA SPS09 these roles have to be granted manually to the system user before the first time the cockpit is opened. Role-Based Access to SAP HANA Cockpit Access to functionality in SAP HANA Cockpit is role-based. For catalogs and groups delivered as default content, standard roles are available. A user needs to be assigned the standard role of a catalog or group in order to be able to access the tiles in that catalog or group. Information on which roles are required to access which content is available in the SAP HANA Security Guide and the SAP HANA Administration Guide. You can also use custom roles for accessing functionality in SAP HANA Cockpit.
Connect to the SAP HANA Database and Opening the Administration Console
Business Example You need to log in to the SAP HANA studio and create a connection to the SAP HANA database. This is required for using the SAP HANA Studio for further administration activities. Connect to the SAP HANA Database Connect to the SAP HANA database using the SAP HANA studio. 1. Log on to the SAP HANA cloud landscape using the remote desktop connection. (cloud) User
train-##
(cloud) Password
initial
2. Open the SAP HANA Studio. 3. Connect to the SAP HANA system with SYSTEM user. View the System Status Obtain an overview of the system status in the System Monitor and Administration Console 1. Open the System Monitor to see an initial overview of the system status. 2. Open the Administration Console of the SAP HANA system and display the overview. Add Roles to your User Account In this step we add an authorization that we need in an later exercise. 1. Add the role sap.hana.xs.lm.roles::Administrator to your user account. Start the SAP HANA Cockpit 1. Start the SAP HANA cockpit using Google Chrome Browser. Create an own group in the SAP HANA cockpit. Choose as group name: HA200-## (where ## is your group number). Add the following tiles in alphabetical order to your group: ●
Connect to the SAP HANA Database and Opening the Administration Console
Business Example You need to log in to the SAP HANA studio and create a connection to the SAP HANA database. This is required for using the SAP HANA Studio for further administration activities. Connect to the SAP HANA Database Connect to the SAP HANA database using the SAP HANA studio. 1. Log on to the SAP HANA cloud landscape using the remote desktop connection. (cloud) User
train-##
(cloud) Password
initial
a) Choose (from the CITRIX connection) Start Menu → Remote Desktop Connection. b) Choose System Monitor icon when prompted. c) Enter the cloud alias and credentials provided by the instructor. d) Choose Yes when prompted. Choose OK when prompted with IE language set to English. 2. Open the SAP HANA Studio. a) In the WTS session click the Windows button and search for the Remote Desktop application and start it. 3. Connect to the SAP HANA system with SYSTEM user. a) In the Welcome, Overview screen, click Administration Console. b) Right-click the white space in the Systems screen. c) Choose Add System... System ID: SHS Instance ID: 20 d) Enter the connection data as provided by your instructor (hostname, instance number, and so on). e) Leave the Locale default to English and leave the remaining fields blank. f) Click Next. g) Select Authentication by Database User and enter your credentials chosen during installation. User Name
Password h) Click Finish. i) If the Secure Storage prompt displays, choose No. Return to the Systems tab. j) Verify that the system appears in the Systems window View the System Status Obtain an overview of the system status in the System Monitor and Administration Console 1. Open the System Monitor to see an initial overview of the system status. a) Click the SAP HANA system in the Systems window. b) Click the System Menu icon (in the top left corner of the Systems window). A System Monitor tab opens, which displays the status of all SAP HANA systems Note: Although you have added multiple users, for each of the systems added, only one entry in the System Monitor is displayed. c) Verify that all services are started. 2. Open the Administration Console of the SAP HANA system and display the overview. a) Right-click the SAP HANA system in the Systems window. b) Click Administration (available as separate icon in navigation bar or in context menu under Configuration and Monitoring). c) Check the system status in the Overview tab: ●
General Information
●
Current Alerts and Messages
●
Database Used Memory
●
Resident Memory
●
CPU Usage
●
Disk Usage
Add Roles to your User Account In this step we add an authorization that we need in an later exercise. 1. Add the role sap.hana.xs.lm.roles::Administrator to your user account. a) In the Systems view, select the system that you added. Double-click the Security folder and double-click the Users folder. b) Double-click the SYSTEM user account to open the user view. c) Click on the green [+] icon, and in the Select Roles pop-up search for sap.hana.xs.lm.roles::Administrator
d) Select the role. e) In the top, right corner, choose the green icon or press F8 to deploy. Start the SAP HANA Cockpit 1. Start the SAP HANA cockpit using Google Chrome Browser. Create an own group in the SAP HANA cockpit. Choose as group name: HA200-## (where ## is your group number). Add the following tiles in alphabetical order to your group: ●
General Information
●
Alerts
●
Used Memory
●
SAP HANA Documentation (Database Administration)
a) Start the Google Chrome browser. b) To start SAP HANA cockpit, enter the following URL: http://:/sap/hana/ admin/cockpit c) Log on with the SYSTEM user. d) Confirm the assignment of the necessary roles to the SYSTEM user. e) Click on the Pencil Icon to enter the change mode. f) Create a new group and add the tiles as described in the following figure.
LESSON OVERVIEW In this lesson, you learn about the SAP HANA Interactive Education (SHINE) demo application that makes it easy to learn how to build native SAP HANA applications. In this lesson the trainer and the participants will install additional SAP HANA content. The content we will install is the SAP HANA Interactive Education (SHINE). In the rest of the HA200 course we will use this content for all the exercises, so it is MANDATORY for all participants to install the SHINE content.
Business Example In your company the SAP HANA Developers need a sandbox system with some content so that they can get insight in the features provided by SAP HANA SPS10. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the purpose of the SAP HANA Interactive Education (SHINE)
●
List the features provided by SHINE
●
Install and configure SHINE
The SAP HANA Interactive Education (SHINE) Demo Application SAP HANA Interactive Education, or SHINE, is a demo application that makes it easy to learn how to build native SAP HANA applications. The demo application, delivered with SAP HANA in a special delivery unit (DU), comes complete with sample data and design-time developer objects for the application's database tables, data views, stored procedures, OData, and user interface.
The delivery unit defines the following applications: ●
Enterprise Procurement Model Admin Console This application lets you generate large quantities of data for testing, as well as create synonyms for use in currency conversions.
●
Enterprise Procurement Model Sample Application This is a sample Sales Order Dashboard and Purchase Order Worklist to show how you could construct similar native SAP HANA applications.
The delivery unit creates the SAP_HANA_DEMO schema. In this schema the database objects, including the tables, are created. The views and procedures are created in the _SYS_BIC schema. The delivery unit also comes with design-time objects for building the applications based on those database objects, and are located in the sap.hana.democontent.epm package.
Features Available in SHINE After the SHINE demo application is installed the developers and modelers can explore the following features on the SAP HANA system:
HDB Association SAP HANA Extended Application Services (XS) enables you to use the core data services (CDS) syntax to create associations between entities. The associations are defined as part of the entity definition, which are design-time files in the repository.
●
Spatial Spatial data is that which describes the position, shape, and orientation of objects in a defined space. Spatial data is represented as 2-Dimensional (2D) geometries in the form of points, line strings, and polygons.
●
SAP HANA simple info access (SINA) The SINA API is a client-side or front-end JavaScript API for developing browser-based search UIs.
●
SAP HANA UI Integration Services Fiori Launch Pad Site The entry point to Fiori apps on mobile or desktop devices.
●
OData Batch Requests The OData standard allows the collection of multiple individual HTTP requests into one single batched HTTP request.
●
Fuzzy Search Fuzzy search is a fast and fault-tolerant search feature that can be used in SAP HANA.
●
Tax Calculation Using Rules The Rules for Tax Calculation are used to determine the tax code based on the Company (Business Partner ID) and Product ID.
Core Data Services (CDS) / HDBDD Is a new infrastructure for defining and consuming semantically rich data models in SAP HANA. Using a data definition language (DDL), a query language (QL), and an expression language (EL), CDS is envisioned to encompass write operations, transaction semantics, constraints, and more. Rules on SAP HANA This introduces business rules in the form of decision tables in SAP HANA database layer.
●
SAP HANA UI Integration Services Provide the required services and UI patterns to create and design single applications or application easily, sites based on HANA native (XS) applications through efficient development tools, standardized services, and consistent UI experience.
●
Services Many new services have been added.
●
Job Scheduling Scheduled jobs define recurring tasks that run in the background.
●
Outbound XSJS SAP HANA Extended Application Services includes a server-side JavaScript API (Outbound API) that enables access to a defined HTTP destination.
●
SAP HANA UI Integration Services You want to provide the end user a means to personalize your application. For this, you can the personalization mechanism provided by the SAP HANA UI Integration Services (UIS).
Installing and Using the SHINE Demo Application To work with the demo application, a system administrator needs to perform the following tasks. ●
Import the demo application delivery unit.
●
Assign roles to developers who want to work with the demo application.
Afterwards, a developer with the proper role can perform the following tasks. ●
●
Generate additional demo data, if necessary. The demo application comes with an initial set of data. View the demo application and then explore the design-time objects for the demo applications to see how the applications were created.
Using the SHINE Demo Application You can work with and explore the demo EPM application and then view the code behind it to learn how it works. The application makes use of the purchase order data and sales order. To launch and explore, you must have the sap.hana.democontent.epm.roles::User role assigned to your user. If you want to configure the SHINE demo application you need the SAP.HANA.DEMOCONTENT.EPM.ROLES::ADMIN role assigned to your user. The Launch Pad application is the entry point into the SHINE Demo Application. From the Launch Pad you can start the other applications that you want to explore. Open the Launch Pad Application using this URL: http://./sap/hana/ democontent/epm/ui/NewLaunchpad.html
Make sure that you replace and with the host name and port for your SAP HANA XS installation. Generally, the port is 80 plus the 2-digit instance number, for example, if the instance is 00, then the port is 8000.
Figure 162: SAP HANA Interactive Education Launch Pad
ome Examples from the SAP HANA SHINE Demo Apps From the Launch Pad application, you can explore all the SAP HANA Interactive Education applications. Some applications need some extra configuration before being executed. This extra configuration is explained in the SHINE documentation and it is also mentioned in the introduction pop-up windows when you start an application for the first time.
Note: For using this launch pad the role, SAP.HANA.DEMOCENTER.EPM.ROLES::ADMIN is to assign to the user.
Install the SAP HANA Interactive Education (SHINE) Content
Business Example During the SAP HANA implementation project there is the need for a sandbox system where the SAP HANA Developers and Modelers can gain experience with the newest SAP HANA features. It is your task to install the SAP HANA Interactive Education (SHINE) demo content on the sandbox system. Unpack the SHINE Package You need to extract the SHINE package from the SAP HANA Installation DVD before it can be imported into the SAP HANA database. Note: ## is the placeholder for the group number that the instructor assigned to you. $$$ is the placeholder for the training landscape number the instructor has assigned to you.
1. Connect to your Linux server using the Remote Desktop tool. (You can skip this step if you are still connected to the Linux Desktop via Remote Desktop) Group
hostname
01
wdflbmt7194
02
wdflbmt7195
Log on to the SAP HANA Landscape using the following credentials: Username: train-## Password: initial In the Logon to the wdflbmt719x dialog box, use the following credentials: Username: ha200root Password: ha200_KPS$ 2. Go to the HANA Student folder in the Start menu and log on to the network with the following credentials: Field
Import the SHINE Package Use the SAP HANA Application Lifecycle Management to import the SAP HANA SHINE content. 1. In a Web browser, start the SAP HANA Application Lifecycle Management at wdflbmt719x: 8020/sap/hana/xs/lm/index.html. Use the following credentials to log on: Field
Value
User Name
system
Password
Welcome123
2. Import the SHINE Delivery Unit from the HCODEMOCONTENT.tgz file. Check the SHINE Delivery Unit Import After the SHINE demo content import you want to check the successful import. 1. In the browser, use SAP HANA Application Lifecycle Management to check the successful import. Add the SHINE Administrator Role to your User Account The demo application includes definitions for two new roles that are required to generate or reload demo data or to view the demo application. To perform the post-installation step for SHINE, assign the role sap.hana.democontent.epm.roles::Admin to your administrator account. 1. In the SAP HANA Cockpit at http://wdflbmt719x:8020/sap/hana/admin/cockpit, assign the SAP.HANA.DEMOCONTENT.EPM.ROLES::ADMIN role to your administrator account. Generate Time Data and Create Synonyms Now that the SHINE content is imported correctly you need to generate some Time Data and table synonyms. 1. In a Web browser, go to http://wdflbmt719x:8020/sap/hana/democontent/epm/ui/ NewLaunchpad.html. 2. Check the prerequisites for time data and synonyms. Explore SAP HANA SHINE 1. Start the Google Chrome and open the SAP HANA SHINE demo application.
Install the SAP HANA Interactive Education (SHINE) Content
Business Example During the SAP HANA implementation project there is the need for a sandbox system where the SAP HANA Developers and Modelers can gain experience with the newest SAP HANA features. It is your task to install the SAP HANA Interactive Education (SHINE) demo content on the sandbox system. Unpack the SHINE Package You need to extract the SHINE package from the SAP HANA Installation DVD before it can be imported into the SAP HANA database. Note: ## is the placeholder for the group number that the instructor assigned to you. $$$ is the placeholder for the training landscape number the instructor has assigned to you.
1. Connect to your Linux server using the Remote Desktop tool. (You can skip this step if you are still connected to the Linux Desktop via Remote Desktop) Group
hostname
01
wdflbmt7194
02
wdflbmt7195
Log on to the SAP HANA Landscape using the following credentials: Username: train-## Password: initial In the Logon to the wdflbmt719x dialog box, use the following credentials: Username: ha200root Password: ha200_KPS$ a) Open the Microsoft Remote Desktop application on your local PC. b) Connect to the SAP HANA Landscape provided by the instructor. The hostname of the SAP HANA landscape is provided by the instructor. c) Log on to the SAP HANA Landscape using the credentials provided in the exercise step.
2. Go to the HANA Student folder in the Start menu and log on to the network with the following credentials: Field
Value
User Name
hanastudent
Password
hanareadonly
a) In the WTS session, click the Windows button, search for Student — hanastudent — hanareadonly, and start it. b) In the windows _Training double click Student — hanastudent — hanareadonly c) Login with the credentials provided for this step. d) Open the HA200 folder. e) Open the HCO_HANA_SHINE folder and copy the HCODEMOCONTENT11_0.ZIP file to the Documents folder. f) Extract the HCODEMOCONTENT11_0.ZIP file. Import the SHINE Package Use the SAP HANA Application Lifecycle Management to import the SAP HANA SHINE content. 1. In a Web browser, start the SAP HANA Application Lifecycle Management at wdflbmt719x: 8020/sap/hana/xs/lm/index.html. Use the following credentials to log on: Field
Value
User Name
system
Password
Welcome123
a) In a Web browser, go to http://wdflbmt719x:8020/sap/hana/xs/lm/index.html. b) Log on to the system using the credentials from the table. c) Choose Log on. 2. Import the SHINE Delivery Unit from the HCODEMOCONTENT.tgz file. a) On the HANA Application Lifecycle Management window, choose Delivery Units. b) Choose Import. c) Choose Browse. d) Navigate to the Documents folder on your local system. e) Select the HCODEMOCONTENT.tgz file. f) Choose Open. g) In the Import Delivery Unit dialog box, choose Import. h) In the Confirm Import of Delivery Unit dialog box, choose Import. Check the SHINE Delivery Unit Import After the SHINE demo content import you want to check the successful import.
1. In the browser, use SAP HANA Application Lifecycle Management to check the successful import. a) Verify that the message The import Operation Finished displays. Add the SHINE Administrator Role to your User Account The demo application includes definitions for two new roles that are required to generate or reload demo data or to view the demo application. To perform the post-installation step for SHINE, assign the role sap.hana.democontent.epm.roles::Admin to your administrator account. 1. In the SAP HANA Cockpit at http://wdflbmt719x:8020/sap/hana/admin/cockpit, assign the SAP.HANA.DEMOCONTENT.EPM.ROLES::ADMIN role to your administrator account. a) In a Web browser, go to http://wdflbmt719x:8020/sap/hana/admin/cockpit. b) Logon using user: system and password Welcome123. c) In the following 2 dialog boxes, choose OK. d) On the SAP HANA Database Administration window, choose Manage Roles and Users. e) In the navigation pane, choose Users → System. f) On the SYSTEM tab, go to the Granted Roles tab. g) On the Granted Roles tab, choose the green plus. h) In the Find Roles dialog box, in the Type Name to Find Role field, enter epm. i) In the results table, select sap.hana.democontent.epm.roles::Admin. j) Choose OK. k) Choose Save. Generate Time Data and Create Synonyms Now that the SHINE content is imported correctly you need to generate some Time Data and table synonyms. 1. In a Web browser, go to http://wdflbmt719x:8020/sap/hana/democontent/epm/ui/ NewLaunchpad.html. 2. Check the prerequisites for time data and synonyms. a) In the SHINE (SAP HANA Interactive Education) dialog box, choose Check Prerequisites. b) Select Time Data Generated and Synonyms Present. c) Choose OK. d) When the check is complete, choose OK. Explore SAP HANA SHINE 1. Start the Google Chrome and open the SAP HANA SHINE demo application. a) On the SHINE (SAP HANA Interactive Education) window, choose Sales Dashboard. b) In the Sales Dashboard dialog box, choose Continue. c) View the data.
d) Choose Back to return to the main screen. e) On the SHINE (SAP HANA Interactive Education) window, choose Purchase Order Worklist. f) In the Purchase Order Worklist dialog box, choose Continue. g) View the data. h) Choose Back to return to the main screen. i) View other applications by selecting the appropriate tile on the SHINE (SAP HANA Interactive Education) window.
SAP HANA Interactive Education (SHINE) guide on http://help.sap.com/hana/ SAP_HANA_Interactive_Education_SHINE_en.pdf SAP Note 1934114: SAP HANA DEMO MODEL - SHINE Release & Information Note
LESSON OVERVIEW This lesson describes the functionality of the DBA Cockpit. As before, instead of showing the slides, you could demonstrate the features directly.
Business Example The DBA Cockpit in SAP Solution Manager provides a detailed insight into the status of the database. Basically, this is about the same data that you can see in the SAP HANA studio for your in-memory database, but the DBA Cockpit also supports other databases. If you have heterogeneous databases in your environment because your business applications still run on traditional databases, the DBA Cockpit enables you to use the same tool for the different databases. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Describe the basic functions of the DBA Cockpit
●
Explain how to monitor SAP HANA using DBACOCKPIT
DBA Cockpit - Overview The DBA Cockpit is a platform-independent tool to monitor and administer databases from an AS-ABAP environment. It allows remote monitoring of SAP HANA databases using the Solution Manager. For SAP HANA databases, the DBA Cockpit offers much the same functionality as the SAP HANA studio. In addition, you can use the DBA Cockpit to schedule database backups.
To start the DBA Cockpit, use transaction code DBACOCKPIT. Alternatively, you can use the transaction codes for specific SAP monitoring tools to open the corresponding application within the DBA Cockpit. Screen Layout in the DBA Cockpit The initial screen of the DBA Cockpit is divided into the different areas as indicated in the figure, Screen Layout in the DBA Cockpit.
The initial screen of the DBA Cockpit is divided into the following areas: ●
Application toolbar Provides basic functions, for example, to display or hide the System Landscape toolbar and the navigation frame.
●
System landscape toolbar Provides central functions to manage the system landscape, for example, to manage database connections and choose the system to monitor.
●
Navigation frame Provides quick access to a range of analysis information. For example, performance monitoring, space management, and job scheduling.
●
Framework message window The framework message window contains a complete history of the messages sent during the session. The navigation frame on the left shows the available functionality, for example, Overview and Alerts under the Current Status folder, INI files under the Configuration folder, Performance, Jobs, Diagnostics, System Information, and so on.
●
Central system data Provides the following information: time of last refresh; database startup time; name of database.
●
Action area Displays the details of the currently selected action.
●
Action message window Displays additional information for the selected action.
Some functionality is only available in particular tools and not in others, for example, the DBA Planning Calendar is only available in the DBACOCKPIT and not yet in the SAP HANA studio.
Integrating SAP HANA as a Remote Database With SAP Solution Manager Version 7.10 Support Package 4 or higher, SAP HANA can be integrated into monitoring as remote database and included in the end-to-end database analysis. The prerequisites for the Solution Manager integration are as follows: ●
Installation of the HANA client software
●
Supported kernel version (at least 7.20 Patch 100)
●
SAP HANA DBSL (minimum 7.20 Patch 110)
●
SAP Host Agent (at least 7.20 Patch 84)
●
SAP Solution Manager Diagnostics Agent
You can also refer to the following SAP notes: ●
●
●
●
SAP Note 1664432 : DBA Cockpit: SAP HANA database as remote database SAP Note 1612172: Additional corrections for setting up the DBA Cockpit using the Solution Manager SAP Note 1672429: Corrections with regard to the technical system "HANA DATABASE" for the setup in the Solution Manager SAP Note 1721598: Corrections regarding the technical system 'HANA DATABASE'; the system also saves required attributes in the Landscape Management Database (LMDB)
Adding an SAP HANA System as Remote Database
Figure 166: Adding an SAP HANA System as Remote Database
If the prerequisites are met, an SAP HANA system can be added to DBA Cockpit by clicking the Add button.
To connect to a remote SAP HANA database, it is first required to add a respective secondary database connection. The following parameters must be specified: ●
Connection Name
●
Database System (SAP HANA database)
●
User Name (SAP HANA database user with at least monitoring privileges)
Subsequently, a new system entry for the SAP HANA database can be added. This entry refers to the database connection created in the step before. Result of the Configuration
Figure 169: Result of the Configuration
After clicking Save, the DBA Cockpit stores the information and tries to connect to the newly added system. The SAP HANA system should appear in the System Landscape Toolbar (H00 in the figure, Result of the Configuration). The available functionality is displayed by clicking the SAP HANA system.
Monitor: Current Status The Current Status monitor provides an overview of the statuses of the most important database resources. The section overview provides information about the following: ●
The status of the available disk space and physical memory
●
The status of the services
●
The time at which the database was started
●
Current alerts
●
Memory and CPU consumption from the perspective of the SAP HANA database
●
Disk consumption from the perspective of the SAP HANA database
●
Memory and CPU consumption from the perspective of the operating system
●
Disk space used on a particular host, from the perspective of the operating system
Using DBA Cockpit Current Status → Overview you can display the overall SAP HANA system status, for example, CPU, Disk, and Memory allocation. The same values are shown under the Overview tab in the SAP HANA Studio Administration Console.
Figure 171: DBA Cockpit Compared to SAP HANA studio – Overview
Note: Even if the database is unavailable, the Overview section is always available, and jobs can always be scheduled. The other sections in this monitor provide deeper insight into the status of the system services, currently active threads, and the usage of disks and volumes.
Monitor: Performance You can analyze performance data of your database system using the Performance Warehouse. As a prerequisite, an SAP Solution Manager system with Solution Manager Diagnostics (SMD) enabled is required. In the Performance Warehouse, all of the relevant performance indicators that are collected by the DBA Cockpit are stored in an SAP Business Intelligence (BI) system. This SAP BI system is used by the Solution Manager Diagnostics (SMD) back end of an SAP Solution Manager system. SMD already uses this SAP BI to store workload data of SAP applications. To configure the extraction of data into the SMD BI, use the SMD Setup Wizard. Based on this architecture, the DBA Cockpit uses SAP BI technology to provide reports for performance analyses, which you can customize according to your needs. All collected data has a time dimension, so that you can analyze the database performance for any point in time or over a specified time frame. Almost all reports are displayed as a chart to visualize the key performance indicators (KPIs). In addition, there is a detailed table view. To navigate within these reports, you can use the
SAP BI drilldown feature. Violations to performance thresholds are highlighted based on predefined SAP BI exceptions to make you immediately aware of performance issues. The Performance Warehouse is shipped with predefined content that you can use to create your own reports according to your needs.
Monitor: Diagnostics The Diagnostics node comprises the following sections: ●
Audit Log The DBA audit log records all actions that make changes to the database. For example, starting, stopping, and reconfiguring services, changes to parameters in configuration files, deletion of trace files, and table imports.
●
Missing Tables and Indexes Missing Tables and Indexes shows the differences between the database in the SAP system and the ABAP dictionary.
Note: The Missing Tables and Indexes function is only available for local systems or for ABAP systems, for which an additional RFC destination has been assigned. It is not available for remote systems.
●
EXPLAIN EXPLAIN shows the execution plan for SELECT, INSERT, UPDATE, or DELETE statements.
●
SQL Editor
●
You can use the SQL Editor to execute SQL statements.
●
Tables/Views You can display a table view, a view, or a monitoring view.
●
Diagnosis Files Used for SAP HANA databases that are offline (cannot be reached by SQL).
●
SQLDBC Trace Activating, deactivating, and analyzing the SQLDBC Trace
●
Database Trace Activating, deactivating, and analyzing the SQLDBC Trace
Monitor: System Information The information displayed in the sections of this monitor may be helpful for analyzing performance issues. ●
Connections Provides detailed information about open connections
Connection Statistics Provides information about open connections, such as network IO statistics
●
Caches Provides information about caches created by the SAP HANA database. The Total Size column shows the size of the available caches.
●
Query Cache Provides information about the query cache, which is where SQL statements executed are cached.
●
Large Tables Provides information about the largest tables in the SAP HANA system. This information is helpful for analyzing performance and system dimensions. You can see the table sizes in main memory, the delta sizes, and the fastest growing tables.
●
SQL Workload Provides an overview of statements that were executed.
●
Data Browser for System Tables Provides an overview of the tables in schema SYS and schema _SYS_STATISTICS. These tables contain data that is useful for analyzing system performance. To display the content of a table, select the table and choose Display Table/View Content.
Figure 172: System Information → Data Browser for System Tables
DB/OS Cockpit The DB/OS Cockpit provides the following benefits:
Business Example You already use DBACOCKPIT for monitoring of other database management systems than SAP HANA. Now you need to add SAP HANA to the list of databases that you can monitor with this tool. Configure the DBACOCKPIT Connection for SAP HANA 1. Check that the ABAP-Server is already started. Connect to your Linux Server using Putty. Use the following hostnames and ABAP-Systems: Group
hostname
01
wdflbmt7194.wdf.sap.corp
T4N
02
wdflbmt7195.wdf.sap.corp
T4D
Log on as ha200root and run SU - T4NADM or T4DADM, depending on your group number. Check that the dispatcher and the work processes are started using the command PS EF | GREP DW If the dispatcher and the workprocesses are not started, run the command STARTSAP. 2. Create a new SYSTEM Connection to SAP HANA. 3. Test the new DBACOCKPIT connection to SAP HANA. Monitor SAP HANA using the DBACOCKPIT 1. Using DBACOCKPIT, check the SAP HANA Services. 2. Using DBACOCKPIT, determine the configuration for the SAVEPOINT interval. 3. Using DBACOCKPIT, review the definition of the sap.hana.democontent.epm.data::MD.Products table in the SAP_HANA_DEMO schema.
Business Example You already use DBACOCKPIT for monitoring of other database management systems than SAP HANA. Now you need to add SAP HANA to the list of databases that you can monitor with this tool. Configure the DBACOCKPIT Connection for SAP HANA 1. Check that the ABAP-Server is already started. Connect to your Linux Server using Putty. Use the following hostnames and ABAP-Systems: Group
hostname
01
wdflbmt7194.wdf.sap.corp
T4N
02
wdflbmt7195.wdf.sap.corp
T4D
Log on as ha200root and run SU - T4NADM or T4DADM, depending on your group number. Check that the dispatcher and the work processes are started using the command PS EF | GREP DW If the dispatcher and the workprocesses are not started, run the command STARTSAP. a) Open SAP Logon: Start Menu → SAP Logon for Windows. b) Double-click the system entry of the ABAP-System assigned to your group (T4N or T4D and enter the following credentials: User
STUDENT-## (do not forget the dash)
Password
INITIAL
c) When prompted, enter a new password. d) Open DBA Cockpit (transaction DBACOCKPIT). 2. Create a new SYSTEM Connection to SAP HANA. a) In DBACockpit: System Configuration Maintenance,, choose Add System entry. b) In the System field, enter SHS, and select Remote Database. c) Select Database Connection and choose the Create icon. d) Enter the following in DB Connection: Add Connection Entry: Connection Name
wdflbmt7194.wdf.sap.corp or wdflbmt7195.wdf.sap.corp
SQL Port
32015 (means 3++index server)
e) Press Save and navigate back to the Add System Entry screen. f) On the Administration Data tab, enter the description: HANA. g) Press SAVE (at the top of the screen.). You see this message at the bottom of the screen confirming your new connection: Database connection SHS has been saved.
Note: The new connection information is written to the DBCON table. In case of problems, you can check the entries in DBCON table using transaction DBCO, 3. Test the new DBACOCKPIT connection to SAP HANA. a) Return to the initial screen in the DBA Cockpit. From the dropdown list at the end of the SYSTEM button (on the left), choose SHS. b) Under the Current Status folder, double-click Overview. c) Under General System Information, check the Operational State of your SAP HANA Connection. A green light means that all services are started. Monitor SAP HANA using the DBACOCKPIT 1. Using DBACOCKPIT, check the SAP HANA Services. a) On the Current Status → Overview screen, click All services are started. b) Review the status of each of the SAP HANA services. 2. Using DBACOCKPIT, determine the configuration for the SAVEPOINT interval. a) From the initial screen of DBA Cockpit, choose Configuration → INI Files. b) Navigate to INIFILE PARAMETER LIST → global.ini → persistence → savepoint_interval_s.. 3. Using DBACOCKPIT, review the definition of the sap.hana.democontent.epm.data::MD.Products table in the SAP_HANA_DEMO schema. a) From the initial screen of DBACockpit, choose Diagnostics → Tables/Views.
Press c) Choose Display/Find and, in the resulting list, find and select the sap.hana.democontent.epm.data::MD.Products table. d) Select the Columns tab. Review the Column names and definitions. e) Press the Send to SQL Editor button on the top of the screen. f) On the Input Query tab, enter the following SQL statement: select "PRODUCTID", "CATEGORY", "WEIGHTMEASURE", "WEIGHTUNIT", "CURRENCY", "PRICE", "PRODUCTPICURL" from"SAP_HANA_DEMO"."sap.hana.democontent.epm.data::MD.Products" g) To execute the query, choose the Execute icon on the top (above the System button). Note: You can generate this SQL statement in the SAP HANA Studio and copy and paste it to this SQL editor in DBA Cockpit. In the SAP HANA Studio, navigate to the SAP_HANA_DEMO Schema. In the Tables folder, find sap.hana.democontent.epm.data::MD.Products. From the context menu, choose Generate → Select Statement. h) Review the output in the Results tab. i) Exit DBACOCKPIT and return to the SAP Menu.
LESSON OVERVIEW This lesson describes the usage of HDBSQL and some of the most important commands. In addition to showing the slides you can demonstrate how to log on to the system and execute commands.
Business Example SAP HANA HDBSQL is a command line tool for entering and executing SQL statements, executing database procedures, and querying information about SAP HANA databases. This might be required for administrators to execute statements from a command line or schedule scripts that access the SAP HANA database. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the capabilities of HDBSQL
●
Explain different ways of logging on to the SAP HANA database
●
Describe the functionality and usage of the hdbuserstore
●
Establish a connection to SAP HANA using HDBSQL and execute commands
Connecting to SAP HANA with HDBSQL You can use HDBSQL interactively or import commands from a file and execute them in the background. You can access databases on your local computer and on remote computers. The SAP HANA studio provides functions similar to HDBSQL, but has a graphical user interface. HDBSQL can be used on all operating systems supported by the database system. It is a component of the SAP HANA software. Features of HDB SQL ● Execute SQL statements ●
To use HDBSQL interactively and to execute some commands, you must log on to the database as a database user.
Note: The user logging on must be a database user. If you do not specify a username and password of a database user, logon is attempted using Kerberos authentication. Two different options exist: ●
●
One-step logon with username and password (specifying credentials in the start command of hdbsql) Two-step logon with username and password (starting hdbsql first and, subsequently, connecting to the system)
Figure 175: Options to connect to an SAP HANA System
Logon with HDBSQL - An Example In this example, HDBSQL is used to connect to a HANA system with instance number 1 on the localhost. Database user MONA is specified with password RED.
Hint: It is also possible to log on with user credentials for the user store with “-U ”. This would be the preferred option for scripts and is also used for the connection of SAP systems with HANA.
Executing Commands
Figure 177: HDBSQL - Executing Commands
HDBSQL commands can be executed in interactive and non-interactive mode. To execute some commands, you must be logged on to the database. In addition to executing commands individually, you can execute multiple commands from a batch file. HDBSQL imports the commands from the specified file and processes them in the background.
Note: If you execute from a batch file, AUTOCOMMIT mode is activated by default. If you deactivate it, the batch file must contain an explicit COMMIT statement to ensure that HDBSQL executes the SQL statements immediately after the batch file has been imported.
HDBSQL Commands, Source SAP – HANA Administration Guide
Figure 178: HDBSQL Commands, Source SAP – HANA Administration Guide
Note: A more detailed description of the features can be found in the SAP – HANA Administration Guide.
Secure User Store (hdbuserstore) In the secure user store of the SAP HANA client (hdbuserstore), you can securely store user logon information, including passwords, using the SAP NetWeaver secure store in the file system (SSFS) functionality. This allows client programs to connect to the database without having to enter a password explicitly.
Figure 179: Using hdbuserstore for Connecting to SAP HANA - Example
Note: The tool did not check if the user really exists. You can also use the hdbuserstore to configure failover support for application servers in a 3tier scenario (for example, SAP NetWeaver Business Warehouse) by storing a list of all the hosts that the application server can connect to. The secure user store is installed with the SAP HANA client package. After installation, it is located in the /usr/sap/hdbclient directory. The secure user store runs on all platforms supported by SAP HANA client interfaces and SAP BASIS 7.20 EXT. When hdbuserstore is executed (in the context of the correct operating system user), the user store can be opened using a user key. Only the operating system user owning the corresponding secure password store files can access the secure user store.
Business Example You need to execute statements against your SAP HANA database, but do not have a graphical user interface available to use the SAP HANA Studio. Therefore, you decide to perform these activities using HDBSQL. Open Putty and Connect to the SAP HANA Database Open Putty and connect to the SAP HANA database with user adm. 1. Open Putty. 2. Specify the configuration data and open the connection. 3. Insert credentials of adm user. Log On to Your SAP HANA Database Log on to your SAP HANA database using HDBSQL specifying the credentials of user SYSTEM directly. 1. Navigate to the folder of the hdbclient, which contains hdbsql. 2. Log on to the SAP HANA database specifying the credentials of user SYSTEM directly. 3. Test whether the connection works by executing a command. 4. Close hdbsql. Insert an Entry for User SYSTEM Insert an entry in hdbuserstore for user SYSTEM. 1. Create a user key for database user SYSTEM in the user store and store the password under this user key. Connect to Your SAP HANA Database Connect to your SAP HANA database using the hdbuserstore entry. 1. Log on to the SAP HANA database using the user store key. 2. Test whether the connection works by executing a command. 3. Close hdbsql.
Business Example You need to execute statements against your SAP HANA database, but do not have a graphical user interface available to use the SAP HANA Studio. Therefore, you decide to perform these activities using HDBSQL. Open Putty and Connect to the SAP HANA Database Open Putty and connect to the SAP HANA database with user adm. 1. Open Putty. a) Open the Start menu and search for HA200_Putty and start it. b) In the HA200_Putty window, depending on the assigned server, press 1 or 2. c) In the next HA200_Putty window press space. d) If a PuTTy Security Alert appears, click Yes. e) You are now connected to the Linux command line. 2. Specify the configuration data and open the connection. a) Insert hostname: wdflbmt7194.wdf.sap.corp or wdflbmt7195.wdf.sap.corp. b) Leave the default values for the other parameters. c) Click Open. d) If a security alert appears, click Yes. 3. Insert credentials of adm user. a) Enter shsadm as user name and press Enter. b) Enter the password shsadm (chosen during installation) and confirm with Enter. Log On to Your SAP HANA Database Log on to your SAP HANA database using HDBSQL specifying the credentials of user SYSTEM directly. 1. Navigate to the folder of the hdbclient, which contains hdbsql. a) Use command CD /HANA/SHARED/SHS/HDBCLIENT to navigate to the folder. 2. Log on to the SAP HANA database specifying the credentials of user SYSTEM directly. a) Use command HDBSQL -N LOCALHOST -I 20 -U SYSTEM -P . b) Press Enter (a second time) to log on to the database. 3. Test whether the connection works by executing a command.
a) Execute the command SELECT * FROM DUMMY to test whether the connection works. b) Press “q“ to leave the SQL result ” ”. 4. Close hdbsql. a) Use command :Q to close the hdbsql again. Insert an Entry for User SYSTEM Insert an entry in hdbuserstore for user SYSTEM. 1. Create a user key for database user SYSTEM in the user store and store the password under this user key. a) Use command HDBUSERSTORE SET MYSYSTEM LOCALHOST:32015 SYSTEM . b) Confirm that the key has been added by displaying all user store keys, hdbuserstore LIST. Connect to Your SAP HANA Database Connect to your SAP HANA database using the hdbuserstore entry. 1. Log on to the SAP HANA database using the user store key. a) Enter the command HDBSQL -U MYSYSTEM. b) Press Enter (a second time) to log on to the database. 2. Test whether the connection works by executing a command. a) Execute the command SELECT * FROM DUMMY to test whether the connection works. Use command :Q to leave. 3. Close hdbsql. a) Use command :Q to close the hdbuserstore again.
LESSON OVERVIEW The goal of this lesson is to learn about the different ways to start and stop SAP HANA. You can refer the participants to the Administration Guide for a detailed reference.
Business Example As the administrator of the SAP HANA database, you need to stop the system for maintenance purposes. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Start and stop SAP HANA using SAP HANA Studio
Starting and Stopping the SAP HANA Database To be able to start and stop an SAP HANA system, you must have the credentials of the operating system user (adm) that was created when the system was installed. Alternatively, SAP HANA can be started and stopped by root users. The SAP start service (sapstartsrv) is the standard SAP mechanism for starting and stopping systems. It starts all necessary database services, such as the name server, index server, and statistics server services. The SAP HANA database can be started or stopped by using SAP HANA studio or by using OS commands.
Figure 180: Tools for Starting and Stopping the SAP HANA Database
Stopping and Starting the SAP HANA Database with SAP HANA Studio Note: To start and stop SAP HANA using sapcontrol, you need to log on, at the operating system level, as a user with root authorization. When starting the SAP HANA database with the SAP HANA studio, you have to enter the user name and password of the operating system user adm. Optionally, a start timeout can be specified. The start timeout defines how long sapstartsrv waits for a service to start. If the end of the timeout period is reached, the remaining services are not started.
Figure 181: Starting SAP HANA Database – Using SAP HANA Studio
The Administration Editor opens in diagnosis mode and the database services start one by one. When all services have started, a green dot appears in the system icon in the Navigator view. When the system is started, the following activities are executed: ●
●
●
252
The database receives the status of the last committed transaction. All of the changes of committed transactions that were not written to the data area are redone. All of the write transactions that were open when the database was stopped are rolled back.
Row tables are loaded into memory, except those tables that are configured to be loaded on demand and that are not marked for preload. A savepoint is performed with the restored consistent state of the database. Relevant column tables and their attributes are loaded into memory asynchronously, in the background.
Stopping the SAP HANA Database Using HANA Studio When stopping the SAP HANA database, you are able to define how you want to stop the system, as outlined in the following table. Table 9: Stopping the SAP HANA Database Using HANA Studio Option
Description
Hard
A hard shutdown forces all database services on all hosts to stop immediately.
Soft
A soft shutdown triggers a savepoint operation before stopping all database services. During the savepoint operation, all modified data is written to disk. You can also specify a timeout after which a hard shutdown is triggered.
Stop wait timeout (sec)
This value specifies how long to wait for a service to stop. If the timeout expires, the remaining services are shut down anyway.
Stopping the SAP HANA Database – Using HANA Studio
Figure 182: Stopping the SAP HANA Database – Using HANA Studio
The Administration editor opens in diagnosis mode and the database services stop one by one. When all services have stopped, a red dot appears in the system icon in the SAP HANA Systems view. Starting and Stopping the SAP HANA Database – Using OS Commands On operating system level, the SAP HANA database can be started or stopped using the commands SAPCONTROL or HDB.
Figure 183: Starting and Stopping the SAP HANA Database – Using OS Commands
Displaying the Process List
Figure 184: Displaying the Process List
The SAP HANA studio normally collects information about the system using SQL statements. However, when the system has not yet started, no SQL connection is available. Therefore, while the system is starting up or is stopped, the SAP HANA studio collects information about the database using the connection of the SAP Start service (sapstartsrv). You can view this
information in the Administration editor in diagnosis mode. In this way, you can analyze any problems that may occur during startup or while the system is stopped. You can also read diagnosis files even when the system is stopped. The Administration editor opens automatically in diagnosis mode in the following situations: ●
When you open the Administration editor for a system without an SQL connection.
●
When you initiate the start, stop, or restart of a system.
Starting and Stopping a Distributed SAP HANA System Note: HDB start or HDB stop only starts and stops the local host and cannot be used to start or stop the complete SAP HANA system. You can use SAPCONTROL to start or stop all the hosts in a scaled-out SAP HANA system from the command line.
Figure 185: Starting and Stopping Distributed SAP HANA Systems Using sapcontrol
Note: You need to be logged on to the SAP system host as user adm or as user with root permissions.
Stopping and Starting Individual Database Services You can stop and start the individual database services (nameserver, indexserver, statisticsserver, xsengine, and so on) running on hosts.
Figure 186: Stopping and Starting Individual Database Services
To stop and start or restart database services, you must have the system privilege SERVICE ADMIN. Examples of situations where you have to restart an individual database service are, for example: ●
●
A host in a distributed system failed and a standby host took over. However, the services of the failed host remain inactive even after the host is reachable again. In this case, you need to restart the services manually. After an update of SAP HANA Extended Application Services (SAP HANA XS), the xsengine service needs to be restarted.
Table 10: Options for Stopping and Starting Database Services Option
Description
Stop...
The service is stopped normally and then typically restarted.
Kill...
The service is stopped immediately and then typically restarted.
Reconfigure Service...
The service is reconfigured. This means that any changes made to parameters in the system's configuration files are applied.
Start Missing Services...
Any inactive services are started.
Note: The SAP HANA database provides several features in support of high availability, one of which is service auto-restart. In the event of a failure or an intentional intervention by an administrator that disables one of the SAP HANA services, the SAP HANA service auto-restart function automatically detects the failure and restarts the stopped service process.
Use the Microsoft Remote Desktop application to connect from the SAP Training WTS landscape to the Linux Desktop assigned to you by the instructor. You will Start and Stop the SAP HANA database using SAP HANA Studio and the Linux command line. Note: ## is the placeholder for the group number that the instructor assigned to you. $$$ is the placeholder for the training landscape number the instructor has assigned to you.
1. Connect to your SAP HANA Landscape and start SAP HANA Studio. Group
hostname
01
wdflbmt7194
02
wdflbmt7195
Use the following credentials for log on to the SAP HANA landscape: Username: train-## Password: initial 2. Stop the SAP HANA Database and check the services to make sure that all services are stopped. 3. Start the SAP HANA database and check the services to see if all services are started. Start and Stop SAP HANA using HDB Use the HDB commands to stop and start the HANA database. 1. Use the HDB command to stop the HANA database and check the processes before and after stopping the HANA database. Log on to the SAP HANA server with the ha200root account. 2. Use the HDB command to start the HANA database and check the processes after starting the HANA database. Log on to the SAP HANA server with the ha200root account. Start and Stop SAP HANA using sapcontrol Use the sapcontrol commands to stop and start the HANA database. 1. Use the sapcontrol command to stop the HANA database and check the processes before and after stopping the HANA database.
Log on with the ha200root account. 2. Use the sapcontrol command to start the HANA database and check the processes after starting the HANA database Log on with the ha200root account.
Use the Microsoft Remote Desktop application to connect from the SAP Training WTS landscape to the Linux Desktop assigned to you by the instructor. You will Start and Stop the SAP HANA database using SAP HANA Studio and the Linux command line. Note: ## is the placeholder for the group number that the instructor assigned to you. $$$ is the placeholder for the training landscape number the instructor has assigned to you.
1. Connect to your SAP HANA Landscape and start SAP HANA Studio. Group
hostname
01
wdflbmt7194
02
wdflbmt7195
Use the following credentials for log on to the SAP HANA landscape: Username: train-## Password: initial a) Open the Microsoft Remote Desktop application on your local PC. b) Connect to the SAP HANA Landscape provided by the instructor. The hostname of the SAP HANA landscape is provided by the instructor. c) Log on using the credentials provided in the exercise step. d) In the WTS session, click the Windows button, search for the SAP HANA Studio, and start it. 2. Stop the SAP HANA Database and check the services to make sure that all services are stopped. a) In the Systems View, right-click your SAP HANA system. b) Choose Configuration and Monitoring → Stop System .... c) Choose Hard and then click OK. d) If required, enter the user ID and password of adm, then click OK.
(Use the username and password that you created during the single-host SAP HANA installation). e) The status of the services is displayed in the Processes tab of the Administration editor. Wait until all services have been stopped. 3. Start the SAP HANA database and check the services to see if all services are started. a) In the Systems View, right-click your SAP HANA system. b) Choose Configuration and Monitoring → Start System .... c) In the Start the System now window, choose OK. The status of the services is displayed in the Processes tab of the Administration editor. Wait until all services have been started. Start and Stop SAP HANA using HDB Use the HDB commands to stop and start the HANA database. 1. Use the HDB command to stop the HANA database and check the processes before and after stopping the HANA database. Log on to the SAP HANA server with the ha200root account. a) In the WTS session, click the Windows button and search for HA200_Putty and start it. b) Select your SAP HANA server and press any key to continue. c) Execute the command SU — SHSADM to switch to the SAP HANA operating system user. d) As user shsadm, type the command HDB info to check the status of the processes. e) Type the command HDB stop to stop the HANA database. f) After the database has stopped, check the status of the processes using the command HDB info. 2. Use the HDB command to start the HANA database and check the processes after starting the HANA database. Log on to the SAP HANA server with the ha200root account. a) If you are already in Putty, continue with substep d. Otherwise, in the WTS session click the Windows button, search for HA200_Putty and start it. b) Select your SAP HANA server and press any key to continue. c) Once logged on to the SAP HANA server, execute the command SU — SHSADM to switch to the SAP HANA operating system user. d) As user shsadm, type the command HDB info to check the status of the processes. e) Type the command HDB start to start the HANA database. f) After the database is stopped, check the status of the processes using the command HDB info. Start and Stop SAP HANA using sapcontrol Use the sapcontrol commands to stop and start the HANA database.
1. Use the sapcontrol command to stop the HANA database and check the processes before and after stopping the HANA database. Log on with the ha200root account. a) In the WTS session, click the Windows button and search for HA200_Putty and start it. b) Select your SAP HANA server and press any key to continue. c) As user ha200root, type the command /usr/sap/hostctrl/exe/sapcontrol –nr ## –function GetProcessList to check the status of the processes. d) Type the command /usr/sap/hostctrl/exe/sapcontrol Stop to stop the HANA database. e) After the database has stopped, check the status of the processes using the command /usr/sap/hostctrl/exe/sapcontrol –nr ## –function GetProcessList. 2. Use the sapcontrol command to start the HANA database and check the processes after starting the HANA database Log on with the ha200root account. a) If you are already in Putty, continue with step d. Otherwise, in the WTS session click the Windows button and search for HA200_Putty and start it. b) Select your SAP HANA server and press any key to continue. c) As user ha200root, type the command /usr/sap/hostctrl/exe/sapcontrol –nr ## –function GetProcessList to check the status of the processes. d) Type the command /usr/sap/hostctrl/exe/sapcontrol Start to start the HANA database. e) After the database has stopped, check the status of the processes using the command /usr/sap/hostctrl/exe/sapcontrol –nr ## –function GetProcessList. f) Close this session.
LESSON OVERVIEW This lesson shows you how to configure the SAP HANA Studio and the SAP HANA Database. Eplain to the participants that there is no comprehensive list including a description of all potential parameters, but that each of the parameters that can be changed is explained in the respective context (for example, Backup and Recovery chapter in the Administration Guide).
Business Example You are an administrator and want to adjust the configuration of the SAP HANA Studio as well as change database parameters according to your requirements. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Configure the SAP HANA studio
Configuring Properties for SAP HANA Systems The SAP HANA system entry in the SAP HANA Studio and several SAP HANA system details can be configured by right-clicking the system in the Systems window and selecting Properties:
Figure 187: Configuring Properties for SAP HANA Systems
Note: Adding folders only works in the SAP HANA Administration Console perspective. In the SAP HANA Modeler perspective this feature is not available.
Caution: If possible, avoid using space characters for the folder name as in some SAP HANA Studio versions, this can lead to issues.
Define System Usage Type It can happen that you think that you are working in your Test System, but are actually working in the productive system, which can lead to serious issues. With SPS08, you should not have this problem.
To set the usage type, proceed as follows: 1. In the Administration editor, choose the Configuration tab. 2. Navigate to the global.ini file and expand the system_information section. 3. Configure the usage parameter. The available warnings are as follows: Information in Systems View (Navigator) A yellow header in: is displayed in the following: ●
Admin editor
●
SQL editor
Table/Index/… editor: ●
Backup editor
Security console: ●
User editor
A Warning in the wizard appears in the following cases: ●
Deleting catalog objects
●
Changing the configuration
●
Importing objects
●
Starting or stopping the system
●
Backing up or recovering a system
Maintaining SAP HANA Studio Preferences The preferences of the SAP HANA studio include many options for customizing the features of the SAP HANA Administration Console. To open the preferences of the SAP HANA studio, choose Window → Preferences. The preferences related to SAP HANA perspectives are all available under SAP HANA.
Hint: Detailed information on the preferences can be found in the SAP HANA Administration Guide. One example is maintaining the preferences for the networks connections:
Figure 191: SAP HANA Studio Preferences – Network Connections
An error is indicated if sapstartsrv cannot be reached. If this is the case but all other services are running (their status having been determined through an SQL connection), the system itself is operational and accessible. In many cases, sapstartsrv cannot be reached because the HTTP proxy is incorrectly configured in the SAP HANA studio. To resolve this, from the main menu, choose Window → Preferences → Network Connections and change the value for active provider from Native to Direct.
Hint: For more information, see also SAP Note 1639568: SAP HANA Studio displays system status as yellow
Configuring the SAP HANA Database The properties of an SAP HANA database system are determined by the configuration parameters.
Configuration Parameters in SAP HANA Studio The properties of an SAP HANA database system are defined in the parameters of its configuration files. Configuration files are separated into sections; sections bundle parameters of the same category. Parameters can be displayed and changed on the Configuration tab of the Administration Editor of the SAP HANA studio. Do not change parameters directly in the configuration files on operating system level. To be able to change the parameters of configuration files, you must have the system privilege INIFILE ADMIN.
Figure 192: Configuring the SAP HANA Database – Overview
Note: The Filter function is helpful to find a parameter in the parameter structure. Maintain Parameters – Using the Filter Function In the Filter field, simply type the name of a parameter (or few characters of a parameter).
Figure 193: Maintain Parameters – Using the Filter Function
If you upgrade to a new revision of SAP HANA, the newest parameter settings based on the newest experiences are included automatically, but your own changes are unchanged from this update. We distinguish between parameters that are valid at system level and host-specific parameters. Parameters that are valid at system level are indicated by the disabled icon (–) in the Host column of the list view. Parameters that are currently active and deviate from the default settings, are marked with a green icon.
Configuration Files
Figure 194: Example: Configuration File Locations
The configuration files are located in the following directories: ●
/usr/sap//SYS/global/hdb/custom/config
●
/usr/sap//HDB//
Note: Configuration files (.ini files) are only created in the above directories if customerspecific changes are made to them after installation. If no customer-specific changes have been made, these directories may be empty. During installation of SAP HANA database, the following customer-specific configuration files are created: ●
sapprofile.ini: Contains system identification information, such as the system name (SID) or the instance number.
Contains information about which database services to start. ●
nameserver.ini: The nameserver.ini file contains global information for each installation. The landscape section contains the system-specific landscape ID and assignments of hosts to roles MASTER, WORKER, and STANDBY.
Changing Parameter Values Parameters can be changed in the Change Configuration Value dialog box. Therefore choose Change... in the context menu of the configuration parameter.
Caution: SAP only permits changes to configuration parameters of the HANA database if these changes are recommended in SAP documentation, SAP Notes, or by SAP employees (for example, consulting, development, support). To guarantee optimal performance and the highest stability, SAP appliance hardware partners can deliver HANA systems with settings that deviate from the standard. For more information see, SAP Note 1730999: Configuration changes in HANA appliance
Figure 195: Changing Parameter Values in SAP HANA Studio (1)
Changing Parameter Values in SAP HANA Studio (2) Afterwards maintain the values in the dialog box:
Figure 196: Changing Parameter Values in SAP HANA Studio (2)
In the Change Configuration Value dialog box, you can expand the Hosts area if host-specific values are possible. If it is not possible to enter a different value for each host, the disabled icon (–) is displayed in the Host column of the list view, and there is no Hosts area in the Change Configuration Value dialog box. After you have entered a new value for a parameter at system level, it is displayed in the System column with a green circle. After you have entered a new value for a parameter at host level, a gray rhombus appears in the Host column. To show information on a specific host, select the host from the Host filter.
The global_allocation_limit parameter is used to limit the amount of memory that can be used by the database. The value is the maximum allocation limit in MB.
Note: A missing entry or a value of 0 results in the system using the default settings. The global allocation limit is calculated by default as follows: 90% of the first 64 GB of available physical memory on the host plus 97% of each further GB. Or, in the case of small physical memory, physical memory minus 1 GB. If you enter only a value for the system, it is used for all hosts. For example, if you have 5 hosts and set the limit to 5 GB, the database can use up to 5 GB on each host (25 GB in total). If you enter a value for a specific host, then for that host, the specific value is used and the system value is only used for all other hosts. This is relevant only for distributed systems.
Hint: For details on the memory allocation of SAP HANA, see also lesson “Memory Management and Persistence” of this course. savepoint_interval_s save_point_interval_s controls how often the internal buffers are flushed to the disk, and a restart record is written. Upon restart after a power failure or crash, the log since the last savepoint needs to be replayed. Thus, this parameter indirectly controls the restart time.
Figure 198: savepoint_interval_s
Note: Since changes to data are persisted to the log area synchronously, they are not lost in case of a power failure or crash.
enable_auto_log_backup Automatic log backup can be enabled or disabled using the parameter ENABLE_AUTO_LOG_BACKUP.. The default setting is: ENABLE_AUTO_LOG_BACKUP = YES.
Figure 199: enable_auto_log_backup
During normal system operation (log mode normal), we recommend that you keep the automatic log backup activated.
Caution: If automatic log backup is disabled and log mode normal is used (described below), the log area grows until the file system is full. If the file system is full, the database will freeze. log_mode
Using log_mode = normal log segments are automatically backed up if parameter enable_auto_log_backup is enabled. Log mode normal is recommended to provide support for point-in-time recovery. After the system has backed up the full log segment, the system can reuse the space that the full log segment occupied in the log area to overwrite it with new log entries. If the log area becomes full and no more log segments can be created on disk, a log full situation arises and the database freezes. When the log area is full, no more log entries can be written until a log backup has been completed. There is another mode: ●
log_mode = overwrite Log segments are freed by savepoints and no log backup is performed. For example, this can be useful for test installations that do not need to be backed up or recovered. Automatic log backups can prevent log-full situations from arising.
Note: log_mode = overwrite is not recommended for production systems. With log_mode = overwrite, no point-in-time recovery is possible. For recovery, only data backups are used; the logs are not used. Only the following recovery option can be selected: Recover the database to a specific data backup.
Caution: When you change the log mode, you must restart the database system to activate the changes. We also recommend that you create a full data backup of the database. log_buffer_size_kb The parameter log_buffer_size_kb sets the size of one in-memory log buffer in kilobytes.
Figure 201: log_buffer_size_kb
Setting a higher buffer size may increase the throughput at the cost of COMMIT latency. During COMMIT of a transaction, this data must be flushed to the I/O subsystem (provided all preceding buffers are already flushed). content_vendor A delivery unit is a collection of packages that are to be transported together. You assign all the packages belonging to your application to the same delivery unit to ensure that they are
transported consistently together within your system landscape. Each delivery unit has a unique identity. The identity of a delivery unit consists of two parts: a vendor name and a delivery-unit name. The combined ID ensures that delivery units from different vendors are easy to distinguish and follows a pattern that SAP uses for all kinds of software components. To create and manage delivery units you first need to maintain the identity of the vendor, with whom the delivery units are associated, and in whose namespace the packages that make up the delivery unit are stored. This means that, before creating a delivery unit, the content_vendor parameter in indexserver.ini file must be defined:
Business Example After the SAP HANA studio has been installed, you may personalize the user interface by maintaining the Properties and Preferences. Also, if there are many systems, it is possible to create a personalized system landscape in the Navigator within the HANA Studio. The HANA configuration files (*.ini files) should be maintained in the SAP HANA studio, not at the operating system level. Use the Microsoft Remote Desktop application to connect from the SAP Training WTS landscape to the Linux Desktop assigned to you by the instructor. You will Start and Stop the SAP HANA database using SAP HANA Studio and the Linux command line.
Note: ## is the placeholder for the group number that the instructor assigned to you. $$$ is the placeholder for the training landscape number the instructor has assigned to you. 1. Connect to your SAP HANA Landscape and start SAP HANA Studio. Group
hostname
01
wdflbmt7194
02
wdflbmt7195
Log on to the SAP HANA landscape using the following credentials: Username: train-## Password: initial 2. Store the adm user ID and password information in the Secure Store of the HANA Studio so that, when stopping the HANA DB using the HANA studio, it will use this information. 3. Change the Active Provider from Native to Direct for Network Connection. 4. Execute a select statement on a large table (for example, the SAP.HANA.DEMOCONTENT.EPM.DATA::SO.ITEM table in the SAP_HANA_DEMO schema). Determine how many rows are fetched by default. Increase this value to 2000. 5. Organize the system landscape to identify the systems by datacenter. The SAP HANA system on the host wdflbmt7194 and host wdflbmt7195 are displayed in separate folders.
6. Check the database parameter content_vendor so the delivery unit can be created. To change a database parameter, you need the permissions of the SYSTEM user.
Business Example After the SAP HANA studio has been installed, you may personalize the user interface by maintaining the Properties and Preferences. Also, if there are many systems, it is possible to create a personalized system landscape in the Navigator within the HANA Studio. The HANA configuration files (*.ini files) should be maintained in the SAP HANA studio, not at the operating system level. Use the Microsoft Remote Desktop application to connect from the SAP Training WTS landscape to the Linux Desktop assigned to you by the instructor. You will Start and Stop the SAP HANA database using SAP HANA Studio and the Linux command line.
Note: ## is the placeholder for the group number that the instructor assigned to you. $$$ is the placeholder for the training landscape number the instructor has assigned to you. 1. Connect to your SAP HANA Landscape and start SAP HANA Studio. Group
hostname
01
wdflbmt7194
02
wdflbmt7195
Log on to the SAP HANA landscape using the following credentials: Username: train-## Password: initial a) Open the Microsoft Remote Desktop application on your local PC. b) Connect to the SAP HANA Landscape provided by the instructor. The hostname of the SAP HANA landscape is provided by the instructor. c) Log on using the credentials provided in the exercise step. d) In the WTS session, click the Windows button, search for the SAP HANA Studio, and start it. 2. Store the adm user ID and password information in the Secure Store of the HANA Studio so that, when stopping the HANA DB using the HANA studio, it will use this information.
a) Right-click the system in the Systems window. b) Select Properties. c) SAP Start Service Logon d) Enter the adm user ID and password, which is provided by the instructor. e) Select the Store user name and password in secure storage checkbox. f) Choose Apply and choose OK. g) Do not close SAP HANA Studio. 3. Change the Active Provider from Native to Direct for Network Connection. a) In SAP HANA Studio, choose Window → Preferences from the menu bar. b) Choose General → Network Connections. c) If the Active Provider value is not Direct, change the value to Direct. d) Choose Apply and choose OK. e) Do not close SAP HANA Studio. 4. Execute a select statement on a large table (for example, the SAP.HANA.DEMOCONTENT.EPM.DATA::SO.ITEM table in the SAP_HANA_DEMO schema). Determine how many rows are fetched by default. Increase this value to 2000. a) Open the SQL Editor: Select the context menu of the system, and choose SQL Console. b) Execute the following SQL statement: select * from "SAP_HANA_DEMO". "sap.hana.democontent.epm.data::PO.Item" The number of rows displayed in the result is restricted to 1000 by default. To change this value, you have to change the preference option Maximum Number of Rows Displayed in Result. c) Choose Window → Preferences from the menu bar. d) Choose SAP HANA → Runtime → Result. e) Change the value for Maximum Number of Rows Displayed in Result from 1000 to 2000, choose Apply, and choose OK. f) Verify that the new setting is effective by executing the following SQL statement: select * from "SAP_HANA_DEMO". "sap.hana.democontent.epm.data::PO.Item" g) Do not close SAP HANA Studio. 5. Organize the system landscape to identify the systems by datacenter. The SAP HANA system on the host wdflbmt7194 and host wdflbmt7195 are displayed in separate folders. a) Navigate to the Systems tab in the SAP HANA Studio. b) Create two folders.
c) From the Administration Console Perspective, choose File → New → Folder from the menu bar. d) Enter the name of the folder Primary Datacenter under root (/). e) Repeat the same step for Secondary Datacenter folder. f) To organize the systems, drag the HANA system SHS on the host wdflbmt7194 user to the Primary Datacenter folder. g) Drag the HANA system SHS on the host wdflbmt7195 user to the Secondary Datacenter folder. 6. Check the database parameter content_vendor so the delivery unit can be created. To change a database parameter, you need the permissions of the SYSTEM user. a) Open the Administration Editor with the permissions of the SYSTEM user. Double-click the HANA system entry that is using the SYSTEM user for connection. b) Choose the Configuration tab. c) To search for the content_vendor parameter, type a few characters (such as Content) in the Filter field. It searches all the parameters according to what you are typing. d) Double-click thecontent_vendor parameter. The parameter is located in the file indexserver.ini in the repository section. e) Type the name of the content vendor ,sap.training, and click Save.
LESSON OVERVIEW For SAP HANA administrators, table administration is an important task. In this lesson details on table definition and partitioning are covered, and various administrative tasks in this area are explained. Business Example You are an administrator and need to create tables, optimize partitioning, and perform administrative tasks in this context. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Decide when to use column-based and row-based storage
Column-Based and Row-Based Storage Keep in mind that the SAP HANA database supports both row-based and column-based storage. However, it is optimized for column storage. When creating a table you have to choose in advance whether it is stored row- or column-wise.
Figure 205: Column-Based and Row-Based Storage (1) - When to Use Column Store
Tables that are organized in columns are read optimized and have better compression rates than tables organized in rows. Furthermore, some features of the SAP HANA database, such as partitioning, are available only for column tables. Column-based storage is typically suitable for big tables with bulk updates. However, update and insert performance is better on row tables. Row-based storage is typically suitable for small tables with frequent single updates.
Note: The SAP HANA database allows row tables to be joined with column tables. However, it is more efficient to join tables of the same storage type.
Column-Based and Row-Based Storage (2) - When to Use Row Store
Figure 206: Column-Based and Row-Based Storage (2) - When to Use Row Store
Hint: It is possible to change an existing table from one storage type to the other (ALTER TABLE ALTER TYPE).
Creating Tables In order to load data into the SAP HANA database, you need to create tables. As outlined above, tables can be kept in row store or column store depending on the use case.
Note: To create a table, you must be authorized to create objects in the selected schema. Tables can be created using SQL or alternatively using the SAP HANA Studio interface:
Figure 207: Creating Tables (1) - Sample SQL Command for Creating a Column Table
A sample SQL command for creating a column table is depicted above. With that, column table CUSTOMER is created within database schema TRAINING. It contains five different columns of which CUSTOMER_ID is the primary key.
Hint: For details and options, see SAP HANA SQL Reference.
Creating Tables (2) - Using SAP HANA Studio Alternatively, it is possible to create a table directly within SAP HANA Studio:
Figure 208: Creating Tables (2) - Using SAP HANA Studio
Procedure for creating tables using SAP HANA Studio: ●
●
In the Systems view, open the catalog schema in which you want to create the new table. In the context menu of the schema in which you want to create the table, choose New Table.
●
Enter table name and table type (column store or row store).
●
Define the columns of your table (name and properties).
●
If required, you can add indexes.
●
Choose Create Table.
Note: An index does not have to be defined with the table, but can also be created any time.
Displaying Table Definition and Content In SAP HANA Studio multiple options for displaying table definition and content exist.
Figure 209: Displaying Table Definition and Content
Displaying Table Definition Displaying catalog object definitions and changing existing catalog objects requires specific privileges. If these have not been granted to the user, the error Insufficient privilege is returned. To open the table editor, choose Open Definition in the context menu of a specific table.
In the table definition, besides columns and indexes in the column Runtime Information details about the memory and disk consumption as well as the compression of individual columns are displayed.
Note: By default, double-clicking the table in the Systems view opens its definition. You can configure this setting in the preferences of the SAP HANA studio. Displaying Table Content
Figure 211: Displaying Table Content
Displaying the table content can be useful, for example, if you want to view the content of a system view to help you understand what is happening in the database.
Note: By default, only the first 1,000 rows are displayed. You can change this setting in the preferences of the SAP HANA studio under SAP HANA → Runtime → Catalog.
Table Partitioning and Distribution The partitioning feature of the SAP HANA database makes it possible to split column-store tables horizontally into disjunctive sub-tables or partitions. In this way, large tables can be broken down into smaller, more manageable parts.
Hint: Partitioning is typically used in distributed systems, but it may also be beneficial for single-host systems.
Figure 213: Additional DDL Statements for Table Partitioning in the SAP HANA Database
When a table is partitioned, the split is done in such a way that each partition contains a different set of rows of the table. There are several alternatives available for specifying how
the rows are assigned to the partitions of a table, for example, hash partitioning, partitioning by range or value. Advantages of Partitioning
Figure 214: Advantages of Partitioning
Partitioning can lead to several advantages: ●
Load balancing in a distributed system Individual partitions can be distributed across multiple hosts. This means that a query on a table is not processed by a single server but by all the servers that host partitions.
●
Overcoming the size limitation of column-store tables A non-partitioned table cannot store more than 2 billion rows. It is possible to overcome this limit by distributing the rows across several partitions. Each partition must not contain more than 2 billion rows.
●
Parallelization Partitioning allows operations to be parallelized by using several execution threads for each table.
●
Partition pruning Queries are analyzed to determine whether or not they match the given partitioning specification of a table. If a match is found, it is possible to determine the actual partitions that hold the data being queried. Using this method, the overall load on the system can be reduced, thus improving the response time.
●
Improved performance of the delta merge operation The performance of the delta merge operation depends on the size of the main index. If data is only being modified on some partitions, fewer partitions will need to be delta merged and therefore performance will be better.
●
Explicit partition handling Applications may actively control partitions, for example, by adding partitions to store the data for an upcoming month.
Single-level Partitioning: Supported Specifications When a table is partitioned, its rows are distributed to partitions according to different criteria known as partitioning specifications. The SAP HANA database supports the following singlelevel partitioning specifications:
Hash Partitioning Hash partitioning is used to distribute rows to partitions equally for load balancing and to overcome the 2 billion row limitation. The number of the assigned partition is computed by applying a hash function to the value of a specified column. Hash partitioning does not require an in-depth knowledge of the actual content of the table.
●
Range Partitioning Range partitioning can be used to create dedicated partitions for certain values or certain value ranges in a table. Usually, this requires an in-depth knowledge of the values that are used or are valid for the chosen partitioning column. For example, a range partitioning scheme can be chosen to create one partition for each calendar month.
●
Round Robin Partitioning Round-robin partitioning is used to achieve an equal distribution of rows to partitions. However, unlike hash partitioning, you do not have to specify partitioning columns. With round-robin partitioning, new rows are assigned to partitions on a rotation basis. The table must not have primary keys.
Hint: For additional details, see SAP HANA Administration Guide.
Note: Besides single-level partitioning, in SAP HANA various options for multi-level partitioning exist. Details are described in the SAP HANA Administration Guide. Time Selection Partitioning (Aging) With SAP HANA SPS7 a new feature called “Time Selection Partitioning (Aging)” is included:
Example for Creating a Hash-Partitioned Table Using SQL
Figure 217: Example for Creating a Hash-Partitioned Table Using SQL
In the example depicted above, three partitions are created on columns a and b of the table MY_TABLE. Table Distribution Editor (1/2) Alternatively, the Table Distribution Editor in SAP HANA Studio can be used.
The Table Distribution editor provides an overview about the distribution of tables in a distributed system. It can be opened using the context menu on folder Console or any schema or tables folder in the Navigator. For performance reasons not all tables of the selected schema are displayed, but only 1000 tables of that schema (number configurable in Preferences → Administration Console → Common → Table Distribution Editor). A message is displayed, if more tables exist in the selected schema. Table Distribution Editor (2/2) It is displayed, if a table is distributed to several partitions and on which host each of these partitions is stored. Existing partitions can be moved to different hosts. Tables which are not partitioned yet can be moved to other hosts as well. However, it is not possible to split a table or change the partitioning using this view.
SAP HANA Table Administration - Administrative Tasks To ensure consistency for partitioned tables, you can execute checks and repair statements, if required.
Administrative Tasks: Table Replication (Tuning Option) Starting with SAP HANA SPS7 a new tuning option called Table Replication is available, which allows replication of tables to multiple hosts.
Because the SAP HANA database manages the loading and unloading of tables automatically, you should not, normally, have to interfere with this process. However, if necessary, you can load and unload individual tables and table columns manually, , for example in the following cases: ●
●
To measure, precisely, the total memory, or the amount of memory used by a particular table (load) To actively free up memory (unload)
Hint: You can see detailed information about a table's current memory usage and load status by viewing its table definition (as described in the figure, Administrative Tasks: Loading and Unloading Column Tables). Administrative Tasks: Performing Manual Delta Merge Operations As discussed in lesson “Memory Management and Persistence”, by default, SAP HANA controls the delta merge process automatically. However, it may be necessary or useful to trigger a merge operation manually in some situations, for example: ●
●
An alert has been issued because a table is exceeding the threshold for the maximum size of delta storage. You need to free up memory.
Delta merges can be triggered manually using SAP HANA Studio or SQL:
Note: Additional options exist. Refer to SAP HANA Administration Guide for details.
Hint: Even though the delta merge operation moves data from the delta storage to the main storage, the size of the delta storage will not be zero. This could be because while the delta merge operation was taking place, records written by open transactions were moved to the new delta storage. Furthermore, even if the data containers of the delta storage are empty, they still need some space in memory. Load, unload, and merge are available in the context menu of a specific column store table. Multiple tables can be selected at once. The chosen operation is then executed for all selected tables. Administrative Tasks: Importing and Exporting Tables Tables - as other catalog objects - can be easily exported and imported back into another database:
Figure 224: Administrative Tasks: Importing and Exporting Tables
Note: The size of a .CSV format file can be large compared to the Binary file size.
As a default, the exported data will be stored on the database server. However, it is also possible to export the data to the local client machine. Importing data will create the tables in the same schema as in the source system. If the table already exists, you have to mark the flag that it can be overwritten – otherwise the import will abort with an error message.
Business Example You need to create tables in the SAP HANA system that you are administrating. Furthermore, you want to optimize partitioning and check the integrity. Create a Table and Insert Data 1. Create a new table EPM.PO.Item_Part in schema SAP_HANA_DEMO with the same structure as table sap.hana.democontent.epm.data::PO.Item 2. Insert all data from table sap.hana.democontent.epm.data::PO.Item into EPM.PO.Item_Part. Manually Trigger Unload and Load Check the loading status of the table and manually trigger unload and load. 1. Unload the EPM.PO.Item_Part table from the memory of the HANA server. 2. Confirm that the table has been unloaded successfully by checking the loading status in the Runtime Information. 3. Load the table completely into the memory and check the loading status again Manually Trigger a Delta Merge Operation Check the size of the memory consumption of main storage and delta storage and manually trigger a delta merge operation. 1. Check the size of the memory consumption of main storage and delta storage of table EPM.PO.Item_Part 2. Manually trigger a delta merge operation of the EPM.PO.Item_Part table. 3. Check the size of the memory consumption of main storage and delta storage of the EPM.PO.Item_Part table after the delta merge operation has been performed. Create and Merge Table Partitions Create and merge table partitions and verify the integrity with an extended data check 1. Open the Table Distribution Editor and display table partitions of the EPM.PO.Item_Part table. 2. Partition the EPM.PO.Item_Part table by range for the PURCHASEORDERITEM column. 3. Check the integrity of partitions in the EPM.PO.Item_Part table (execute extended data check) 4. Merge the partitions of table EPM.PO.Item_Part
Business Example You need to create tables in the SAP HANA system that you are administrating. Furthermore, you want to optimize partitioning and check the integrity. Create a Table and Insert Data 1. Create a new table EPM.PO.Item_Part in schema SAP_HANA_DEMO with the same structure as table sap.hana.democontent.epm.data::PO.Item a) In the WTS session, click the Windows button, search for the SAP HANA Studio, and start it. b) In the Systems window, right-click the SAP HANA system where you are logged on as user SYSTEM. c) From the context menu, choose Open SQL Console. d) Insert a command to create the table: CREATE TABLE "SAP_HANA_DEMO"."EPM.PO.Item_Part" like "SAP_HANA_DEMO"."sap.hana.democontent.epm.data::PO.Item"; e) Click Execute. f) In the Systems window, navigate to Catalog => SAP_HANA_DEMO, right-click Tables, and click Refresh. g) Confirm that the table has been created h) Open the definition of the table by right-clicking it and selecting Open Definition. i) Confirm that the table has the same structure as the sap.hana.democontent.epm.data::PO.Item table. 2. Insert all data from table sap.hana.democontent.epm.data::PO.Item into EPM.PO.Item_Part. a) In the SQL Console, enter the following statement: INSERT INTO "SAP_HANA_DEMO"."EPM.PO.Item_Part" SELECT * FROM "SAP_HANA_DEMO"."sap.hana.democontent.epm.data::PO.Item"; b) Click Execute. c) In the Systems window, right-click the EPM.PO.Item_Part table and select Open Content. d) Confirm that the entries from the sap.hana.democontent.epm.data::PO.Item table have been inserted into EPM.PO.Item_Part. Manually Trigger Unload and Load Check the loading status of the table and manually trigger unload and load.
1. Unload the EPM.PO.Item_Part table from the memory of the HANA server. a) In the Systems window, right-click the EPM.PO.Item_Part table. b) From the context menu, select Unload from Memory... c) Confirm by clicking OK. 2. Confirm that the table has been unloaded successfully by checking the loading status in the Runtime Information. a) Right-click the table in the Systems window and select Open Definition. b) Navigate to the Runtime Information tab. c) Confirm that the Loaded column in the table Details for Table indicates that the table is not loaded. Additionally, you can see that currently the table does not consume memory (indicated by Total Memory Consumption (KB)). 3. Load the table completely into the memory and check the loading status again a) In the Systems window, right-click the EPM.PO.Item_Part table. b) From the context menu, select Load into Memory... c) Confirm by clicking OK. d) Right-click the table in the Systems window and select Open Definition. When opened, choose Refresh. e) Navigate to the Runtime Information tab. f) Confirm that the Loaded column in the table Details for Table indicates that the table is fully loaded. Additionally, you can see that currently the table now consumes memory (indicated by Total Memory Consumption (KB)) Manually Trigger a Delta Merge Operation Check the size of the memory consumption of main storage and delta storage and manually trigger a delta merge operation. 1. Check the size of the memory consumption of main storage and delta storage of table EPM.PO.Item_Part a) Right-click the table in the Systems window and select Open Definition. b) Navigate to theRuntime Information tab. c) Check the Memory Consumption in Main Storage (KB) and Memory Consumption in Delta Storage (KB) 2. Manually trigger a delta merge operation of the EPM.PO.Item_Part table. a) Right-click the table in the Systems window and select Perform Delta Merge... b) Confirm by clicking OK 3. Check the size of the memory consumption of main storage and delta storage of the EPM.PO.Item_Part table after the delta merge operation has been performed. a) Navigate to the Runtime Information tab in the table definition again and click Refresh.
b) Check the Memory Consumption in Main Storage (KB) and Memory Consumption in Delta Storage (KB) Create and Merge Table Partitions Create and merge table partitions and verify the integrity with an extended data check 1. Open the Table Distribution Editor and display table partitions of the EPM.PO.Item_Part table. a) Expand the SAP_HANA_DEMO schema in the Systems window. b) Right-click the Tables folder in the SAP_HANA_DEMO schema. c) From the context menu, choose Show Table Distribution to open the Table Distribution Editor. d) Select table EPM.PO.Item_Part e) Confirm that the table is not partitioned (visible in partition details of table) 2. Partition the EPM.PO.Item_Part table by range for the PURCHASEORDERITEM column. a) Right-click the EPM.PO.Item_Part table in the Table Distribution Editor. b) Right-click and choose Partition Table.... c) For the Partitioning Specification, select Range and click Next. d) As column leave PURCHASEORDERITEM e) Click Add to add a value range. f) As start value for partition 1 enter 0000000000, as end value 0000000040. g) Add an additional value range with start value 0000000040 and end value 0000000080. Note: Because an additional partition for all other values is created automatically, in total three partitions are created h) Click Finish. i) In the partition details (Table Distribution Editor) of the EPM.PO.Item_Part table, expand the host. The three partitions with their respective sizes should be visible. 3. Check the integrity of partitions in the EPM.PO.Item_Part table (execute extended data check) a) In the Systems window, right-click the SAP HANA system where you are logged on as user SYSTEM. b) From the context menu, choose SQL Console c) Insert the following SQL command to check partitioning consistency of the table: CALL CHECK_TABLE_CONSISTENCY('CHECK_PARTITIONING_DATA', 'SAP_HANA_DEMO','"EPM.PO.Item_Part"');
d) Click Execute. e) Confirm that no errors are displayed, that is, that the extended data check has shown that no issues exist. 4. Merge the partitions of table EPM.PO.Item_Part a) Expand the SAP_HANA_DEMO schema in the Systems window b) Right-click the Tables folder in the SAP_HANA_DEMO schema. c) From the context menu, choose Show Table Distribution to open the Table Distribution Editor. d) Right-click the EPM.PO.Item_Part table. e) Choose Merge Partitions... f) Confirm with OK g) In the partition details of the EPM.PO.Item_Part table, confirm that the table is not partitioned anymore.
LESSON OVERVIEW This lesson describes typical tasks of an administrator and how SAP HANA Studio can be used to support their execution. Instead of showing the slides, you can also directly open the training system and show the functionality in the SAP HANA Studio.
Business Example After installation, you need to have an overview which tasks you need to perform as administrator and how to achieve this using SAP HANA Studio. You want to ensure good performance for the processing of your SAP HANA database. Therefore you perform regular checks and take preventive action, if required. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Name which administrative tasks need to be performed initially, regularly, and on demand
Overview of Administrative Tasks Administrative tasks of the SAP HANA database are performed using the administration console perspective of the SAP HANA studio. The administration console perspective of the SAP HANA studio allows technical users to manage the SAP HANA database as well as to create and manage user authorizations. The administrative tasks are divided into three categories. Overview of Administrative Tasks ●
Monitor disk space that is used for diagnosis files
Initial Tasks Performing an Initial Backup It is strongly recommended that, after the initial setup and after the initial load, you perform a full data and file system backup (including a configuration backup). For more information, see the SAP HANA Database Administration Guide.
Note: Backup and Recovery is covered in detail in a dedicated unit of this course.
Figure 225: Backup from SAP HANA Studio
Installing a Valid License for the SAP HANA Database Additionally, make sure that a valid license is installed (see Configuration lesson for details).
Regular Tasks (Administration and Monitoring) Checking the System Status Overview
Regularly check the system status on the Overview tab page of the administration editor in the SAP HANA studio. This displays the most important system information: ●
Overall system state
●
General system information (software versions and so on)
●
●
The Alerts section shows the latest warnings and messages generated by the statistics server, which is a monitoring tool for the database. It collects statistical and performance information using SQL statements. The bar views provide an overview of important system resources: The amount of available memory, CPUs, and storage space is displayed as well as the used amount of these resources. In a distributed landscape, the amount of available resources is aggregated over all servers. Additionally, the resource information of the server with the highest resource consumption is displayed.
Figure 226: Checking the System Status Overview in SAP HANA Studio
Performing Regular Data Backups Regularly perform data backups (including configuration backups). There are no general guidelines for the backup frequency (this depends on the usage scenario). For more information, see the unit “Backup and Recovery” in this course and the SAP HANA Database – Backup and Recovery Guide. Checking the Status of Services On the Landscape tab page, check that all services that belong to your database are running: preprocessor, name server, and index server for each host and one statistics server. The Services tab page contains information about the status of your database services. Running services are indicated with a green icon.
Figure 228: The Administration Editor – Landscape > Services Tab
In addition, information about resource usage and possible bottlenecks is displayed. Using the context menu, you can restart services: When using the Stop or Kill command, the respective service is stopped or killed and then automatically started again. Because all services are restarted automatically when they are stopped, there is no need to start single services manually. As an administrator, you actively monitor the status of the system, its services, and the consumption of system resources. However, you are also alerted of critical situations, for example: a disk is becoming full, CPU usage is reaching a critical level, or a server has stopped.
The SAP HANA Cockpit Memory Overview Indicates total amount of memory currently used by the SAP HANA database in relation to the allocation limit. For multiple-host systems, values are displayed for all worker hosts. The host with the highest (most critical) memory usage is also shown. This tile provides access to the Memory Overview app, where you can analyze current memory usage in more detail. If the system is distributed, memory usage is available for each host individually. The initial view shows the memory usage of the master host. You can switch between hosts as necessary. SAP HANA Cockpit - Memory Allocation
SAP HANA Cockpit provides a detailed graphical breakdown of the following main categories of memory usage: Physical memory SAP HANA database Table data Database management Other information regarding the current size of used resources can be seen on the Overview tab of the Administration editor. The following information is displayed in screen areas identified in the figure, Memory Allocation Statistics: 1. The components of the selected service listed in descending order of current used memory (default). 2. The current breakdown of SAP HANA used memory displayed as a pie chart. 3. Allocators of the selected component listed in descending order of current used inclusive memory (default). 4. The current breakdown of memory usage of the 10 highest consuming allocators displayed as a pie chart. SAP Cockpit - CPU Usage The new Resource Utilization Statistics editor enables you to visualize and explore the usage history of key system resources.
The tile can help to analyze bottlenecks, identify patterns, and forecast requirements. It can be opened via the context-menu of the specific SAP HANA system.
Monitoring Hosts in a Distributed System In a distributed system, hosts can be monitored from the Hosts sub-tab in SAP HANA Studio:
Figure 235: The Administration Editor – Landscape > Hosts Tab
Redistributing Data in a Scale-Out System In a distributed system, tables and table partitions are assigned to an index server on a particular host at the time of their creation, but this assignment can be changed. In certain situations, changing assignments is necessary. SAP HANA supports several “redistribution operations” that use complex algorithms to evaluate the current distribution and determine a better distribution depending on the situation.
Figure 236: The Administration Editor – Landscape > Redistribution Tab
Setting Up and Monitoring System Replication System replication is a mechanism for ensuring the high availability of an SAP HANA system. Through the continuous replication of data from a primary to a secondary system, including in-memory loading, system replication facilitates rapid failover in the event of a disaster. Productive operations can be resumed with minimal downtime. SAP HANA system replication can be set up and monitored from within the administration console.
Figure 237: The Administration Editor – Landscape > System Replication Tab
Figure 238: Extended System Replication Configuration
Checking Alerts As one of the main components of the monitoring infrastructure of the SAP HANA database, the statistics server performs regular checks and issues an alert when an alert condition is fulfilled.
Figure 239: The Administration Editor – Alerts Tab (1/3)
The priority of the alert indicates the severity of the problem and depends on the nature of the check and configured threshold values. For example, by default, if 90% of available disk space is used, a low priority alert is issued; if 98% is used, a high priority alert is issued. The Administration Editor – Alerts Tab (2/3)
Figure 240: The Administration Editor – Alerts Tab (2/3)
Current alerts are summarized on the Overview tab of the Administration editor and displayed in detail on the Alerts tab.
The left side of the Checks tile shows an overview of all of the checks, and the right side shows the details of the selected check. For each check, you can configure the following: ●
A specific e-mail alert
●
A threshold
●
The schedule and the activation of this concrete check
In addition, you can choose the Run the check now button. This is useful when the check is running, for example, every 6 hours (backup), and you want to know if the process is working now. Assessing Performance Information Gathering and analyzing data regarding the performance of your SAP HANA systems is important for root-cause analysis and the prevention of future performance issues. General information about overall system performance is available in the System Monitor and on the Overview tab of the Administration editor. You can monitor more detailed aspects of system performance on the Performance tab.
The Administration Editor – Performance > Threads Tab (2/2) The Group and sort filter provides a meaningful and clear structure for thread analysis, as follows:
Figure 247: The Administration Editor – Performance > Sessions Tab
As well as identifying active and inactive sessions and their relation to applications, the monitor shows if a session is blocked and if so, by which other session. It shows if a session is blocking other sessions and how many transactions are inside. Statistics, such as average query runtime and the number of DML and DDL statements in a session, are included. The table shows the result from the system information statement sessions. You can cancel a session by right-clicking the session and choosing Cancel Session. The Administration Editor – Performance > Blocked Transactions Tab Blocked transactions, or transactionally blocked threads, can impact application responsiveness.
Blocked transactions are transactions that are unable to be processed further because they need to acquire transactional locks (record or table locks) that are currently held by another
transaction. Transactions can also be blocked waiting for other resources such as network or disk (database or metadata locks). The Administration Editor – Performance > SQL Plan Cache Tab
Figure 249: The Administration Editor – Performance > SQL Plan Cache Tab
Technically, the plan cache stores compiled execution plans of SQL statements for reuse, which gives a performance advantage over recompilation at each invocation. For monitoring reasons, the plan cache keeps statistics about each plan, for instance number of executions, min/max/total/average runtime, and lock/wait statistics. Analyzing the plan cache is helpful as one of the first steps in performance analysis because it gives an overview about what statements are executed in the system.
Note: Due to the nature of a cache, seldom-used entries are evicted from the plan cache. The SQL plan cache can provide you with an insight into the workload in the system as it lists frequently executed queries.
Expensive statements are individual SQL queries whose execution time was above a configured threshold. The expensive statements trace records information about these statements for further analysis and displays them in the Administration editor.
Note: The expensive statements trace is deactivated by default. Personalized Administrator View The individual steps of statement execution are displayed in a hierarchical tree structure underneath aggregated statement execution information.
Hint: Some administrator views in SAP HANA Studio are personalized. The settings are restored the next time the view is opened. The procedure is system independent. This function applies to the following tabs: ●
Sessions, SQL Plan Cache, Expensive Statements Trace, Job Progress, and System Replication
The Administration Editor – Performance > Load Tab
Figure 253: The Administration Editor – Performance > Load Tab
You can use the load graph for performance monitoring and analysis. For example, you can use it to get a general idea about how many blocked transactions exist now and in the past, or troubleshoot the root cause of slow statement performance. Monitoring Disk Usage and Volumes
Figure 254: The Administration Editor – Volumes Tab
To ensure that the database can always be restored to its most recent committed state, you must ensure that there is enough space on disk for data and log volumes. You can monitor disk usage, volume size, and other disk activity statistics on the Volumes tab of the Administration editor. There are two views available on the Volumes tab for monitoring the size of volumes on disk: service and storage type (that is data, log, and trace).
Hint: Although trace files are not stored in volumes, they are displayed on the Volumes tab in the Storage view as they consume disk space and, therefore, need to be monitored. Maintaining the Database Configuration
Figure 255: The Administration Editor – Configuration Tab
Hint: For detailed information, see the lesson “Configuration” in this course.
Figure 256: The Administration Editor – System Information Tab
Double-clicking an entry in this list executes the underlying statement. To see the actual statement, from the context menu, choose Show. SAP HANA Mini Checks During the analysis of complex problems it can be required to determine special database information, which is partially not available in standard functions. For this reason, SAP provides a collection of useful SQL statements for SAP HANA database analysis. The SQL statements can be downloaded as described in SAP Note 1969700.
Note: Mini Checks attachment: SAP Note 1969700 - SQL statement collection for SAP HANA Mini Checks documentation: SAP Note 1999993 - How-To: Interpreting SAP HANA Mini Check Results
After the import of the SQL_Statements.zip file you can execute these checks in the System Information tab to help with daily monitoring and SAP HANA system analysis. For structured storage, we recommend creating a separate folder before importing the Mini checks. SAP HANA Mini Checks Implemented
Figure 258: Mini Checks Implemented
You can use each statement separately, but you can use Mini Checks to execute the most important statements with one call. In general, you should use the version that best fits your system environment, so that the most comprehensive set of checks is executed. It is important to know your SAP HANA revision number and whether or not you are using a standalone or embedded statistics server. The statistics server assists you with monitoring the SAP HANA system, collecting historical performance data, and warning you of system alerts (such as resource exhaustion). The historical data is stored in the _SYS_STATISTICS schema.
Note: The new Statistics Server is also known as the embedded Statistics Server or Statistics Service. Before SP7, the Statistics Server was a separate server process - like an extra Index Server with monitoring services on top of it. The new Statistics Server is now embedded in the Index Server. This simplifies the SAP HANA architecture and helps avoid out of memory issues in the Statistics Server. By default, the Statistics Server is set to use only 5% of the total memory. SP7 and SP8 still use the old server, but you can migrate to the new service by implementing SAP Note 1917938 A drag and drop option is available to help you organize your folder structure. You can also delete queries and folders if they are not of use. We recommend that you start the mini check each day, so that you know what is going on in your system. If you plan to move you system to a never revision, you can precheck your system with the corresponding version of your target revision SAP HANA Mini Checks Results
Figure 259: SAP HANA Mini Checks Results
To analyze the results further, you can export your results to a flat file and import the results to Microsoft Excel.
Note: The values in the Expected_Value column are updated regularly, so it is important to import the newest version of the SQL collection from time to time. Filtering on areas that deviate from their expected values (filter on “X” in column C) provides you with information about which areas to focus on. The example in the figure, SAP HANA Mini Checks Results, shows that there is a problem with the CPU and we should refer to SAP Note 2100040 - FAQ: SAP HANA CPU to understand the CPU consumption of SAP HANA and learn how to resolve the issue.
Avoiding Log Full Situations When the log is backed up, the backed up log segments remain on disk until they have been released automatically after a savepoint. After the log has released, the oldest unused log segment can be overwritten with new log entries. If there are no unused log segments, new log segments are created. If the disk becomes full and no more log segments can be created, a log full situation arises. When the log is full, no more logging is possible until the log backup has completed. Automatic log backup prevents log full situations from arising. Avoid log backup area becoming full. Regularly archive old log backups to a different location (using operating system commands). In case of problems with the SAP HANA database, you can check log and trace files for errors. These log files are available in the SAP HANA studio on the Diagnosis Files tab page of the administration screen.
Figure 261: The Administration Editor – Diagnosis Files Tab
In the Diagnosis Files view, it is possible to show the first lines of a file. It is still possible to display the last lines or to display the entire file. The number of lines can be configured, the max. limit is 100.000 lines. For large files (more than 100.000 lines) showing the entire file is not possible, instead a download option is provided.
Monitor SAP HANA using Administration Console Tools
Business Example As a system administrator, monitoring of the SAP HANA database and landscape is an important task. The Administration Console provides many tools to help you do this. Review the Overall Status of the SAP HANA Landscape, Database, and Services 1. Check the system status 2. Determine the Peak Memory Allocation amount for your SAP HANA database. 3. Check the status of each of the services. 4. Find the top 5 tables in the SAP HANA database in terms of disk size. 5. Monitor the key performance indicators, such as CPU usage, column store, and memory consumption. Use the SAP HANA Studio Tools to Trace SQL Statements 1. Configure and activate a SQL Trace for user SYSTEM, with a table filter on "SAP_HANA_DEMO"."EPM.PO.Item_Part". 2. Run the SQL Trace and review the trace file. Implement Mini Checks in your System 1. Go to the HANA Student folder in the Start menu and log on to the network with the following credentials: Field
Value
User Name
hanastudent
Password
hanareadonly
2. On the System Information tab, create a new folder named Mini Checks with the description Mini Checks. 3. Import the SQL Statements from Documents/kpstransfer/HANA. 4. Start the mini-check and review the results for system issues.
Monitor SAP HANA using Administration Console Tools
Business Example As a system administrator, monitoring of the SAP HANA database and landscape is an important task. The Administration Console provides many tools to help you do this. Review the Overall Status of the SAP HANA Landscape, Database, and Services 1. Check the system status a) Navigate to the system connection for user SYSTEM. b) From the context menu, select Configuration and Monitoring → Open Administration. (Alternatively, click the Administration icon.) c) From the Overview tab, review operational status, database used memory, resident memory, CPU usage, and disk usage. d) Check for alerts. 2. Determine the Peak Memory Allocation amount for your SAP HANA database. a) Navigate to the system connection for user SYSTEM. b) From the context menu, select Properties. c) Click License. d) Choose System Measurement → Peak Memory Allocation. 3. Check the status of each of the services. a) Navigate to the system connection for user SYSTEM. b) From the context menu, select Configuration and Monitoring → Open Administration. (Alternatively, click the Administration icon.) c) From the Landscape tab, choose the Services tab. d) Check the status of each of the services. e) Add columns for CPU Process (%) and CPU Total. f) Find and select the Configure Viewer icon on the top right of the Landscape screen. In the Table Viewer, choose CPU Process (%) and CPU Total (%) on the right column. Press the left arrow to add these columns to the Visible Columns list on the left. 4. Find the top 5 tables in the SAP HANA database in terms of disk size. a) Select the System Information. tab and open the System folder. b) Click Size of tables on disk.
The report is sorted by disk size, showing schema, table name, and disk size for each table. c) Close the report and return to the Systems viewer. 5. Monitor the key performance indicators, such as CPU usage, column store, and memory consumption. a) Select the Performance → Load tab. b) At the bottom of the screen, deselect all of the checkboxes to clear the display. c) Check CPU under Index Server. Deselect and check CPU under Host. d) Deselect all of the checkboxes and check column store. e) Close and return to the Systems view. Use the SAP HANA Studio Tools to Trace SQL Statements 1. Configure and activate a SQL Trace for user SYSTEM, with a table filter on "SAP_HANA_DEMO"."EPM.PO.Item_Part". a) Navigate to the system connection for user SYSTEM. b) From the context menu, select Configuration and Monitoring → Open Administration. (Alternatively, click the Administration icon.) c) Select the Trace Configuration tab. d) On the right, scroll to the right of SQL Trace and click the Edit Configuration icon. e) On the Trace Configuration screen, enter the following filters: Trace Status
Active
Trace File
STUDENT##_sqltrace.py
User Filter
DB User: SYSTEM
Tables and Views
SAP_HANA_DEMO.EPM.PO.ITEM_PART
Applications
All
Statement Types
DML, DDL, PROCEDURE, TRANSACTION, SESSION, SYSTEM
Flush Limit
16 (default)
f) Choose Next. Review the Configuration Details. g) Choose Finish. 2. Run the SQL Trace and review the trace file. a) Navigate to the Catalog folder under the user SYSTEM connection, b) In the SAP_HANA_DEMO schema, find the EPM.PO.ITEM_PART table. c) From the context menu of table EPM.PO.ITEM_PART, select Generate → Select Statement. d) Choose Execute (F8).
e) Return to Administration Tools and select the Diagnosis Files tab. f) In the Filter window, enter: STUDENT##. g) Click the trace file, STUDENT##_sqltrace.py.. h) Review the file. Choose CNTL/F and enter select. Choose Find to find the Select statement. i) Return to Administration Tools, Trace Configuration. j) Choose the Edit Configuration icon next to SQL Trace. k) Set the Trace Status to Inactive. l) Choose Next and finish. Implement Mini Checks in your System 1. Go to the HANA Student folder in the Start menu and log on to the network with the following credentials: Field
Value
User Name
hanastudent
Password
hanareadonly
a) In the WTS session, click the Windows button, search for Student — hanastudent — hanareadonly, and start it. b) In the windows _Training double click Student — hanastudent — hanareadonly c) Login with the credentials provided for this step. d) Open the HA200 folder. e) Copy the SQL Statements.zip file to the Documents folder. 2. On the System Information tab, create a new folder named Mini Checks with the description Mini Checks. a) In the SAP HANA Administration Console, on the Systems tab, select SHS (SYSTEM) HANA.
Figure 262: SHS (SYSTEM) Navigation Tree
b) On the SHS tab, select the System Information tab.
4. Start the mini-check and review the results for system issues. a) In the SAP Administrator Console, on the System Information tab, expand the Configuration → Mini Checks → Rev90+.
LESSON OVERVIEW This lesson describes how to activate the traces within SAP HANA studio. Business Example You are an administrator and you want to activate a trace to analyze an issue. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Activate the trace function
●
Check the trace files
Configuring Traces This section shows how to check the trace files generated as the result of the activation of the trace.
Figure 277: Trace Configuration Tab
Various traces are available for obtaining detailed information about the actions of the database system. You can activate and configure traces on the Trace Configuration tab of the Administration editor. Different configuration options are available for each trace.
Note: To be able to configure traces, you must have the system privilege TRACE ADMIN. To configure the kernel profiler, you must have the SAP_INTERNAL_HANA_SUPPORT standard role.
●
Database trace (including user-specific and end-to-end database traces) The database trace records information about activity in the components of the SAP HANA database. You can use this information to analyze performance and to diagnose and debug errors. Each service of the SAP HANA database writes to its own trace file. By default, the database trace is active with default trace level ERROR.
●
SQL trace The SQL trace collects information about all executed SQL statements and saves it as an executable python program. This is good for recording a scenario. By default, the SQL trace is inactive.
●
Expensive statements trace Expensive statements are individual SQL queries whose execution time was above a configured threshold. The expensive statements trace records information about these statements for further analysis. By default, the expensive statements trace is inactive.
●
Performance trace The performance trace is a performance tracing tool built into the SAP HANA database. It records performance indicators for individual query processing steps in the database kernel. By default, the performance trace is inactive.
Caution: The performance trace is a tool for experts. To interpret the information collected, you require a deep understanding of the system component being analyzed.
●
Plan trace With the Plan trace you can visualize and analyze the execution plans for every query that has been executed in the specified application.
●
Kernel profiler The kernel profiler is a sampling profiler built into the SAP HANA database. It collects, for example, information about frequent and expensive paths during query processing. By default, the kernel profiler is inactive.
Note: Only SAP development support has the technical expertise required to interpret the information collected by the performance trace and the kernel profiler.
Trace with Default Configuration Status Table 11: Trace with Default Configuration Status The table lists the traces and their default configuration status. Trace
Default Configuration or Status
Database trace
Active with default trace level ERROR
SQL trace
Inactive
Performance trace
Inactive
Kernel profiler
Inactive
Expensive statements trace
Inactive
Plan trace
Inactive
To Activate the SQL Trace 1. To activate the SQL trace, click the Edit icon. 2. Select the Active radio button in the trace status, then click Finish.
Figure 278: Activation of SQL Trace
To Activate the JDBC Trace 1. Right-click the system. 2. Select Properties.
Note: There is a warning decorator and tooltip when the JDBC trace is activated. A message is also shown on the administration overview screen.
Check the Diagnosis Files In case of problems with the database, log and trace files can be checked for errors. These diagnosis files are available in the studio on the Diagnosis Files tab of the Administration editor. For more information, refer to the section Working with Diagnosis Files in this unit. To display a diagnosis file, choose Open in the context menu of the list, or double-click the entry of the respective log file.
Configuring Trace File Rotation Trace file rotation prevents trace files from growing indefinitely by limiting the size and number of trace files. You can configure trace file rotation globally for all services in the system and for individual services. For more information, refer to the SAP HANA Administration Guide.
Business Example As an SAP HANA system administrator, you have to activate the traces for issue analyses. 1. Configure the expensive statements trace. 2. Execute expensive SQL statement and view the trace file. 3. Analyze the expensive SQL statements trace.
Business Example As an SAP HANA system administrator, you have to activate the traces for issue analyses. 1. Configure the expensive statements trace. a) Navigate to the system connection for user SYSTEM. b) From the context menu, select Configuration and Monitoring and then Open Administration. (Alternatively, double click the SAP HANA SID.) c) Select the Trace Configuration tab. d) Find Expensive Statements Trace and scroll to the right. Click the Edit Configuration icon. e) Change the Trace Status from Inactive to Active. f) Change the threshold value duration from 1.000.000 microsecond (default) to 100 microseconds. g) Choose Next and Finish. 2. Execute expensive SQL statement and view the trace file. a) Navigate to Administration Console, system connection for user SYSTEM. b) Find the SAP_HANA_DEMO schema in the Catalog folder. c) In the SAP_HANA_DEMO schema folder, find the Tables folder, and select Filters from the context menu. d) Enter the following in Filter for Column Views: Item_Part e) From the context menu of table SAP_HANA_DEMO.EPM.PO.Item_Part, select Generate → Select Statement. The SQL Editor opens and the select statement is displayed. f) In the SQL Editor, choose Execute (F8). g) Close the SQL editor. 3. Analyze the expensive SQL statements trace. a) Navigate to the database connection of user SYSTEM, and in the context menu, select Configuration and Monitoring → Open Administration → Performance → Expensive Statements Trace. b) In the Filter window enter:
Item_Part c) Verify the SQL statement in the STATEMENT_STRING column. d) From the context menu of the first row, choose Visualize Plan. e) On the display, click the black arrow on the top right of the Column Search block. From the context menu in the Project area inside the Column Search block, choose Execute. f) In the Executed tab find the Most Dominant Operator. g) Return to Administration view of the user SYSTEM and select Trace Configuration → Expensive Statements Trace. h) Choose Edit Configuration to the right of Expensive Statements Trace. Set the trace status to Inactive. i) Choose Next and Finish.
Working with Diagnosis Information and Diagnosis Files
LESSON OVERVIEW This lesson shows how to deal with SAP HANA diagnosis files. You can also show the files in SAP HANA Studio and or on the file system (putty).
Business Example When there is an issue in the system, you, as a HANA system administrator, need to analyze diagnosis files for issue resolution. When receiving support from SAP, you as a HANA administrator should be able to send the diagnosis files to SAP. The configuration files must be backed up periodically along with the database backup. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Open diagnosis files for analysis
●
Delete/merge files
●
Download files
●
Collect and download diagnosis information
Working with Diagnosis Files in SAP HANA Studio Diagnosis files include log and trace files, as well as a mixture of other diagnosis, error, and information files. In the event of problems with the SAP HANA database, you can check these diagnosis files for errors. You can also filter, merge, delete, and download diagnosis files. You can access the diagnosis files on the Diagnosis Files tab of the Administration editor. They are stored by default in the following location: /usr/sap//HDB/ /trace In this location you can monitor disk space that is used for diagnosis files and delete files that are no longer needed.
Note: To be able to view diagnosis files and delete trace files, you must have the system privilege TRACE ADMIN.
Lesson: Working with Diagnosis Information and Diagnosis Files
Figure 281: Diagnosis Files Tab in the Administration Editor
Check the Diagnosis Files In case of problems with the database, log and trace files can be checked for errors. These diagnosis files are available in the studio on the Diagnosis Files tab of the Administration editor. To display a diagnosis file, choose Open in the context menu of the list, or double-click the entry of the respective log file. Trace file rotation prevents trace files from growing indefinitely by limiting the size and number of trace files. You can configure trace file rotation globally for all services in the system and for individual services. Filter List To refine the list of diagnosis files, specify a filter. For example, if you want to see anything related to nameserver, enter nameserver.
Figure 282: Filtering in Diagnosis Files
Display File To display a file in the list, right-click it and choose Open, or double-click the file. The Show Start of File and Show End of File buttons help you to navigate particularly large files more easily. You can specify how many lines you want to see when you filter the file in this way.
Note: Depending on the type of data in the diagnosis file, the number of lines actually displayed may be less than or greater than specified. This is because the data in some diagnosis files is fetched in bytes and the number of bytes per line varies.
Note: Crash dump files have a hyperlinked table of contents. To see the hyperlinks, press the CTRL key as you move your mouse over the entries.
Figure 283: Options in Show Files
Display Diagnosis Files Ending with .gz (zipped) File ●
360
The .gz (zipped) file is automatically downloaded to the local computer (SAP HANA studio workspace).
●
The last 1000 lines are displayed by default.
●
Download File in the Log File editor writes this local copy to another directory.
●
The local copy is deleted automatically after closing the Log File editor.
Lesson: Working with Diagnosis Information and Diagnosis Files
Merge Files
Figure 284: Merging Diagnosis Files
You can merge the diagnosis files listed on the Diagnosis Files tab by choosing Choose Merge Files...
Note: This feature is helpful during troubleshooting, because it allows you to review multiple diagnosis files of different types at the same time. The merged file is created from the most recent diagnosis files. Once the file has been created, you can use the filtering options and timeframe slider to drill down and analyze further.
Caution: Merging diagnosis files can take a long time, depending on the size and number of files to be merged. Compress Files If you need to download a diagnosis file (for example, to send it to SAP Support), you can compress it first on the server. This is useful for large diagnosis files and for slow connections. To compress a file, right-click it and choose Compress. After compression, the file has the file format *.zip. You can select multiple files to compress.
Figure 285: Compressing and Deleting Diagnosis Files
Delete Files The following options are available for deleting files: ●
Delete log files and other non-trace files (for example, *.log, *.tpt, *.py) You can delete one or more individual files from the list by selecting the file or files in question and in the context menu, choosing Delete.
●
Delete trace files (*.trc) You can delete trace files in the same way as other diagnosis files by right-clicking them and choosing Delete. Note: The file may not actually be deleted. If a running service is currently writing to the file, it cannot be deleted. If this is the case, the file disappears from the list in the SAP HANA studio and is hidden in the file system at operating system level. As long as a service is still writing to the file, it still exists and consumes disk space. Once the file reaches its maximum size, the system stops writing to it and creates a new trace file. When the file is physically deleted depends on how trace file rotation is configured. You can batch delete trace files, for example all the trace files of a specific service, by choosing Delete Trace Files... and making the required selection. Note: If the trace files are open, it is not possible to delete the trace files. In this case, the contents of the files are cleared but the file still exists and its size is reduced.
Collecting and Downloading Diagnosis Information To analyze and diagnose problems with the system, you can collect diagnosis information into a zip file, which you can then download and attach to a support message. The script was extended to include the following: ●
Collect diagnosis information through the execution of a SQL procedure.
●
Collect diagnosis information through the execution of a Python script.
●
Download and delete collected diagnosis information.
When you trigger the collection of diagnosis information, the system collects the relevant information by executing the Python script FULLSYSTEMINFODUMP.PY. You can execute this script either using an SQL procedure or directly, if no SQL connection is available to the database. Even if an SQL connection is available, it may be desirable to execute the Python script directly if using the SQL procedure would overload the system.
Figure 288: Set Diagnosis Period
Procedure for Collecting Diagnosis Information with SAP HANA Studio: 1. In the Administration Editor, choose the Diagnosis Files tab. 2. Choose Diagnosis Information → Collect (Python Script) or Collect (SQL Procedure).
Note: If there is no SQL connection, Collect (Python Script) is the only option available. 3. Specify the scope of information to be collected (all diagnosis information for a specified number of days or runtime information dump file only).
Lesson: Working with Diagnosis Information and Diagnosis Files
4. After waiting for the system to collect the relevant information, the zip file appears in the list with the other diagnosis files. Dump File Collection
Figure 289: Dump file Collection
Set Diagnosis Period Hint: The information collected varies slightly depending on whether you execute the Python script directly or the SQL procedure. Collecting Diagnosis Information Using the Command Line The FULLSYSTEMINFODUMP.PY script is part of the server installation and can be run from the command line. It is located in the directory $DIR_INSTANCE/exe/python_support.
Figure 290: Collecting Diagnosis Information Using the Command Line
Start the script from its location with the command: python fullSystemInfoDump.py
Trace Files Each of the following trace files is entered into a file with the same name as the trace file. For storage reasons, only the trace files from the last 7 days are collected unabridged. From older trace files, only the most recent 10,000 lines are collected.
Figure 291: Trace Files
Configuration Files All configuration parameters are grouped logically and stored in an ini file.
Lesson: Working with Diagnosis Information and Diagnosis Files
Figure 292: Configuration Files
Database System Log Files The following backup log files are collected unabridged: ●
$DIR_INSTANCE/
●
$DIR_INSTANCE/
Runtime Dump Information For each index server, a runtime dump containing information about threads, stack contexts, and so on, is created and stored in the indexserver_
SYS.M_INIFILE_CONNECTIONS with CONNECTION_ID > 0
Note: The first 2,000 rows of all remaining tables in schema _SYS_STATISTICS are exported ordered by column SNAPSHOT_ID. Additional Information Collected If SQL Connection is Not Available All available topology information is exported to a file named topology.txt. It contains information about the host topology in a tree-like structure. The keys are grouped using brackets while the corresponding values are referenced by the symbol ==>. The following figure shows the content of the topology.txt file as an example.
Lesson: Working with Diagnosis Information and Diagnosis Files
Dealing with a Blocking Situation
Figure 294: Emergency Support Mode
Information for Cancel Status
Figure 295: Information for Cancel Status
Canceling an idle session is currently not possible. CANCEL command can only affect running sessions, IDLE (CANCEL REQUESTED) is mostly to show the internal status of cancel requested by someone. When the next execution request arrives, that flag will be cleared.
Business Example You want to find and display the content of diagnosis files for issue analysis. Find the Trace File Find the trace file of the SQL trace (from the last exercise). 1. Open HANA studio 2. Go to Diagnosis files tab. 3. Set up the filter. Download the Trace File 1. Select the file. 2. Download the file. Delete the Trace File Delete the trace file. 1. Select the file. 2. Delete the file.
Business Example You want to find and display the content of diagnosis files for issue analysis. Find the Trace File Find the trace file of the SQL trace (from the last exercise). 1. Open HANA studio a) From the WTS, choose Start → All Programs → SAP HANA → SAP HANA Studio. 2. Go to Diagnosis files tab. a) Double-click the system. b) Choose the Diagnosis files tab. 3. Set up the filter. a) In the Filter, enter sqltrace. Download the Trace File 1. Select the file. a) Right-click the trace file. 2. Download the file. a) Choose Download. b) Select the path where you want to download. c) Choose Save. Delete the Trace File Delete the trace file. 1. Select the file. a) Right-click the trace file. 2. Delete the file. a) Choose Delete. b) Choose OK to confirm the deletion.
Business Example To analyze and resolve issues with the system, you want to collect diagnosis information into a zip file, which you can then download and attach to a support message. Collect diagnosis information using SAP HANA studio. 1. Open the Administration Console of SAP HANA studio. 2. Navigate to the Diagnosis Files tab. 3. Trigger the collection of diagnosis information. 4. Verify data collection by displaying the list of diagnosis information. 5. Download the collection.
Business Example To analyze and resolve issues with the system, you want to collect diagnosis information into a zip file, which you can then download and attach to a support message. Collect diagnosis information using SAP HANA studio. 1. Open the Administration Console of SAP HANA studio. a) Right-click the SAP HANA system in the Systems view on which you are logged on as user SYSTEM. b) Choose Administration. 2. Navigate to the Diagnosis Files tab. a) Choose the Diagnosis Files tab. 3. Trigger the collection of diagnosis information. a) Choose Diagnosis Information. b) Choose Collect... c) Leave the default settings and confirm by choosing Finish. d) Wait until the data collection has been finished. 4. Verify data collection by displaying the list of diagnosis information. a) Choose Diagnosis Information. b) Choose History. c) Verify that the full system info dump has been created. 5. Download the collection. a) ChooseDiagnosis Information > History.. Select the full system dump that you created and press Download Collection.... b) Choose the Documents folder and choose Save. c) Press OK to close the windows.
LESSON OVERVIEW The lesson briefly describes the following topics: Executing SQL statements in the SAP HANA studioQuery analysis features Plan Visualizer: graphical representation of the query LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Use the SQL console successfully
Executing SQL Statements in the SAP HANA Studio
Figure 296: Executing SQL Statements in the SAP HANA Studio
Any SQL statement can be executed in the SQL editor. For SELECT statements, the explain plan can be generated, This option is available in the context menu. Multiple SQL statements can be entered, separated by the configured separator character, and are then executed one after the other. The connection of the SQL editor can be changed to a different system or user, which means that it is possible to run the same statements on a different database. The used tables must exist in that database as well. To help you to understand and analyze the execution plan of a SQL statement, you can generate a graphical view of the execution plan. Visualize the explain plan of the SQL statement in one of the following ways: ●
●
378
Enter the statement in the SQL console and choose Visualize Plan in the context menu. On the SQL Plan Cache tab, or the Expensive Statements Trace tab of the Performance tab, right-click the statement and choose Visualize Plan.
Plan Visualizer Note: Execution time is given as a pair of values: “self” (the execution time of the node), and “Inclusive” (the execution time including the descendent nodes. If the query used the SAP HANA Column Engine, you can view the details of the various database operations by choosing Visualize Column Plan in the context menu. A detailed graphic is displayed. This graphic is a powerful tool for studying performance of queries on SAP HANA databases. You can explore the graphic further, for example, you can expand, collapse, or rearrange nodes on the screen. You can also save the graphic as an image or XML file, for example, so you can submit it as part of a support query.
Analyzing SQL Execution with the SQL Plan Cache The SQL plan cache collects statistics on the preparation and execution of SQL statements. Hence, it is an important tool for understanding and analyzing SQL processing. You can access the SQL plan cache in the Administration editor on the Performance tab. The two monitoring views associated with the SQL plan cache are M_SQL_PLAN_CACHE and M_SQL_PLAN_CACHE_OVERVIEW in the _SYS_STATISTICS schema. Table 12: Useful Filtering Columns Column
Description
TOTAL_EXECUTION_TIME
The total time spent for all executions of a plan, This helps to identify which statements are dominant in terms of time.
AVG_EXECUTION_TIME
The average time it takes to execute a plan execution. This can help you identify long-running SQL statements.
EXECUTION_COUNT
The number of times a plan has been executed. This can help you identify SQL statements that are executed more frequently than expected.
TOTAL_LOCK_WAIT_COUNT
The total number of waiting locks. This can help you identify SQL statements with high lock contention.
In the Admin editor of SAP HANA Studio on the Performance → SQL Plan Cache tab, the stored parameter set is used when you choose Visualize Plan or Prepare in SQL Console. If a statement is evicted from the SQL plan cache, its parameter information will be removed from the M_SQL_PLAN_CACHE_PARAMETERS view too. Additionally, the M_SQL_PLAN_CACHE_PARAMETERS_FOR_STATISTICSSERVER_RESET monitoring view can be used to reset the parameter list and to view, for example, hourly statistics. In combination with M_SQL_PLAN_CACHE_STATISTICSERVER_RESET: . plan_cache_parameter_for_batch_enabled: currently, plan cache captures the first parameter set of batch execution to reduce performance drop. This configuration has to be turned on to capture all parameter sets of batch execution.
Link Between SQL Plan Cache and Expensive Statements Trace
Figure 304: Link Between SQL Plan Cache and Expensive Statements Trace
Execution in a Distributed System In distributed SAP HANA systems, tables and table partitions are located on multiple hosts. The execution of requests received from database clients may potentially have to be executed on multiple hosts, depending on where the requested data is located. ●
Statement routing is not enabled Requests from the database client are executed on the contacted index server (in this case, the master index server) and the required data is fetched from the index server on the relevant host or hosts.
●
Statement routing is enabled Request execution is routed directly to the host on which the required data is located after initial query compilation.
Note: Execution time should be better with statement routing enabled. Statement routing is controlled by the client_distribution_mode parameter in the indexserver.ini file. It is enabled by default (value = statement).
Business Example When facing a performance issue in the system, especially SQL performance, it is necessary to use the SQL plan cache function for analysis. Find a Query in the Current System Find the query in the current system that took the longest execution time. 1. Launch HANA Studio. 2. Go to SQL Plan Cache. 3. Find the query with the longest execution time.
Figure 306: Where to Find the Configure Viewer
Execute the Visualize Plan for a Query 1. Find the first 'select ...' SQL query in the list. 2. Insert the query into SQL console. 3. Execute the Visualize plan for the query.
Business Example When facing a performance issue in the system, especially SQL performance, it is necessary to use the SQL plan cache function for analysis. Find a Query in the Current System Find the query in the current system that took the longest execution time. 1. Launch HANA Studio. a) Choose Start → All Programs → SAP HANA → SAP HANA Studio. b) Navigate to Administration Console. 2. Go to SQL Plan Cache. a) Double-click the system. b) Select the Performance tab. c) Select the SQL Plan Cache tab. 3. Find the query with the longest execution time.
Figure 306: Where to Find the Configure Viewer
a) Click the Configure Viewer icon right next to Save as file. See the figure above. b) Select all from Visible Column and click the left arrow button. c) From the Available Columns, select the STATEMENT_STRING and TOTAL_EXECUTION_TIME columns and click the right arrow button to move them to Visible Columns. d) Choose OK. e) Sort the list by TOTAL_EXECUTION_TIME by clicking the TOTAL_EXECUTION_TIME column. Execute the Visualize Plan for a Query
1. Find the first 'select ...' SQL query in the list. a) Double click the first 'select ...' SQL query. b) In the STATEMENT_STRING dialog box, choose the Copy button and choose Close. 2. Insert the query into SQL console. a) Right-click the system and select the SQL console. b) Paste the query into the SQL console. 3. Execute the Visualize plan for the query. a) Right-click the SQL query from the SQL console. b) Choose Visualize Plan from the context menu.
LESSON OVERVIEW This lesson provides an overview of the transporting possibilities. Business Example SAP HANA lifecycle management covers two aspects: platform lifecycle management for customizing and updating your SAP HANA platform and application lifecycle management for managing SAP HANA content products and transports. While using SAP HANA Lifecycle Manager has already been covered in a previous lesson, now managing SAP HANA content. This includes modelling, change recording, transports, and installation. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the Application Lifecycle Management of SAP HANA
SAP HANA Application Lifecycle Management – Overview Application lifecycle management includes all the activities that you need to plan and perform to ensure that the software components you develop for SAP HANA are not only produced and shipped in a regulated way, but also meet the requirements laid out for the SAP HANA platform. In SAP HANA several objects can be developed to build standalone applications or integrate with other products such as SAP systems:
Figure 307: SAP HANA Transports – What Do We Need Them For?
SAP HANA Content These objects are regarded as transportable content. What is defined as SAP HANA content is shown in the figure, What is Defined as SAP HANA Content?
Design Time and Rune Time Objects – SAP HANA Repository It is important to distinguish between design time and run time objects. Design time objects are regarded as SAP HANA content.
Figure 309: Design Time and Rune Time Objects – SAP HANA Repository
For ensuring consistency when transporting objects, it is important to ship objects that belong together at the same time. Context: Packages In the repository, SAP HANA objects that belong together are made up of packages, and packages can be assigned to a delivery unit.
Figure 310: Context: Packages
All content delivered as part of the application that you develop for SAP HANA is stored in packages in the SAP HANA repository. The packages are arranged in a hierarchy that you define to help make the process of maintaining the packages transparent and logical. Packages enable you to group together the artifacts that you create and maintain for your applications. You must be aware of the privileges the application developers require to access (and perform operations on) the packages
A delivery unit is a collection of packages that are to be transported together. You assign all the packages belonging to your application to the same delivery unit to ensure that they are transported consistently together within your system landscape. Each delivery unit has a unique identity. The identity of a delivery unit consists of two parts: a vendor name and a delivery-unit name. The combined ID ensures that delivery units from different vendors are easy to distinguish and follows a pattern that SAP uses for all kinds of software components. To create and manage delivery units you first need to maintain the identity of the vendor, with whom the delivery units are associated, and in whose namespace the packages that make up the delivery unit are stored. Overview: Products, Delivery Units, Packages, and Objects Delivery Units are associated with a product instance. A product corresponds to an application – which could be an SAP-delivered application, a partner application, or customer application developed on a project basis.
Figure 312: Overview: Products, Delivery Units, Packages, and Objects
Typical Basic Transport Landscape A typical basic transport landscape for SAP HANA consists of a development system, a test system, and a productive system.
Transporting SAP HANA Content: Available Options For transporting SAP HANA content, multiple options exist. Which one is suitable depends on the use case and integration scenario, as follows: ●
Native SAP HANA Content SAP HANA Application Lifecycle Manager can be used to transport native SAP HANA content. Since this is an SAP HANA standalone transport management tool, it is suitable for customers without an ABAP-footprint. It is a lightweight and easy-to-use transport tool.
●
Native SAP HANA Content or as Part of a Solution Using the Enhanced Change and Transport System (CTS+) SAP HANA content can be transported like any other non-ABAP content with integration in the existing CTS transport landscape and integration in SAP process tools (ChaRM, QGM).
●
SAP HANA Content Exclusively Used by ABAP An alternative for transporting SAP HANA content that is exclusively used by ABAP (ABAP for SAP HANA) is using SAP HANA Transport Containers. With that, SAP HANA artifacts can be transported with standard ABAP transport. Integration in the existing CTS transport landscape and in SAP process tools is ensured as well.
●
Content That Needs to be Transferred Quickly Without Transport Management System Such content can be quickly transferred from one SAP HANA system to another using the export and import functionality. This allows moving objects with little effort. However, in many cases using a transport management solution would be advantageous over this manual approach.
Figure 314: Transporting SAP HANA Content: Available Options
Transporting Native SAP HANA Content Using SAP HANA Application Lifecycle Manager (HALM) The SAP HANA Application Lifecycle Manager enables you to create your product, delivery unit, package, and basic application components. Additionally, the SAP HANA Application
Lifecycle Manager enables administrators to set up the transport of delivery unitsb and Changes, start and monitor transports, and upload or download delivery unit archives.
Figure 315: SAP HANA Application Lifecycle Manager – Use Cases and Constraints
SAP HANA Application Lifecycle Manager – Capabilities
Figure 316: SAP HANA Application Lifecycle Manager – Capabilities
SAP HANA Application Lifecycle Manager – Transport Process As an administrator, you can use the SAP HANA Application Lifecycle Manager as a single point of access to perform the following tasks: ●
Assign the appropriate delivery units or changes to the transport route
●
Execute exports and imports (uploads and downloads)
●
Monitor the transport processes
Note: The SAP HANA Application Lifecycle Manager tool is available on the SAP HANA XS Web server.
Figure 317: SAP HANA Application Lifecycle Manager – Transport Process
Figure 318: SAP HANA Lifecycle Manager – Web Application
The responsibility for common application-lifecycle management performed with the SAP HANA Application Lifecycle Manager is shared between the various lifecycle management roles, which must be assigned to the SAP HANA users who start the SAP HANA Application Lifecycle Manager. For example, the Administrator role enables access to all options and tools in the SAP HANA Application Lifecycle Manager. To start a transport operation based on a defined route, you only need the privileges assigned with the user role ExecuteTransport. The Display role enables a user to view details of the delivery units, routes, and transports, but cannot make any changes. Granularity of Transports ●
Full Deliver Unit / Product (without Change Recording)
●
Full Released Delivery Unit / Product (with Change Recording enabled)
●
Change (with Change Recording enabled)
Change Recording in SAP HANA Change recording is the infrastructure to record changes during development. Change recording provides the following: ●
Automatic recording and grouping of object changes
●
Decoupling of activation and transport
●
Predecessor calculation of changes
Change Recording can be enabled as global system setting in your development environment.
Transporting without change recording has the following features: ●
Delivery Unit transport contains all active objects in the packages of that particular DU.
●
If an object is ready to be transported, its Delivery Unit must be activated.
Transporting with change recording has the following features: ●
Automatic recording of object changes to a change list when an object is activated
●
Team Development Allows a developer (or team) to work on a development artifact and release the “change” only when the artifact is ready to promote to the test system. For developers not contributing to this change the objects are locked.
●
Release in two steps Contributors have to approve first before a change can be released.
●
Transport Delivery Unit transport contains only objects where their change has been released.
Figure 319: Change Tracking
Dependency Viewer HALM includes a graphical tool to display dependencies between delivery units.
Using SAP HANA Application Lifecycle Manager Hint: Detailed information on setting up and utilizing SAP HANA Application Lifecycle Manager can be found in the SAP HANA Developer Guide.
How to Show the Application Lifecycle Manager Showing the Application Lifecycle Manager
Caution: Assign the role sap.hana.xs.lm.roles::Administrator to the user that you want to use for the demonstration in advance. 1. Open SAP HANA Lifecycle Manager: http://wdflbmt7194.wdf.sap.corp:8020/sap/ hana/xs/lm/ 2. Log on with user name and password (user with appropriate role assigned - see above). 3. Show the functionality available in the different tabs: ●
Home
●
Products (Products, Delivery Units, Packages)
●
Transport (System, Routes, Transports, Logs)
●
Settings
●
Manage System
Using the Enhanced Change and Transport System (CTS+) for Transporting SAP HANA Content The Change and Transport System (CTS) of ABAP has been enhanced so that it can also be used for transporting non-ABAP objects, known as CTS+ or enhanced CTS. If you already use CTS, for example to manage non-ABAP transports for applications like the SAP Enterprise Portal or to transport your BW ABAP objects, you might be interested in using the same tool to transport the SAP HANA objects as well. With the integration of SAP HANA into CTS, this is now possible. You can model your landscape for your SAP HANA systems in Transport Management System (TMS) in the same way as any other non-ABAP application supported by CTS. To be able to use SAP HANA with CTS as described in this lesson, your systems have to fulfill the following prerequisites:
Using CTS+ with SAP HANA – Landscape The figure, Using CTS+ with HANA – Landscape, shows the systems that are involved in the scenario. The figure shows, as an example, a three system landscape consisting of a development, a test, and a production system. This is a basic example. You can set up bigger or, simpler landscapes in CTS. All of the options that you might know from TMS are available for SAP HANA systems as well. You can, for example, have several systems in a row, or more than one target system at once. In addition, you need a system where CTS is configured. For the set-up, you have to use an SAP Solution Manager or SAP NetWeaver where the CTS Plug-In contained in Software Logistics (SL) Toolset is installed. The set-up is described in detail in the HowTo-Guide on : http://scn.sap.com/docs/DOC-8576. In this lesson, we will refer to this system as ‘CTS system’.
The figure, Using CTS+ with HANA – Landscape, illustrates the process of exporting and importing objects with SAP HANA. The front end is the SAP HANA Studio, or (starting with SPS08) the SAP HANA Application Lifecycle Management (HALM). You can start the export from within the SAP HANA Developer Studio or SAP HANA Application Lifecycle Management. You should not use the option of exporting content to a file system and attaching manually to a transport request, any more. The next step is to release the transport request. Depending on your configuration, this is either done automatically, or via the Transport Organizer Web UI. You can then start the import. This is done on the CTS system.
Note: As of SAP HANA studio SP05, you are no longer required to export the SAP HANA content to the file system and attach it manually to a CTS transport request. It is now possible to export SAP HANA content and attach it to a transport request in one step (referred to as “Close Coupling”). This is now the preferred way of exporting SAP HANA content to a transport request. Using CTS+ with HANA – Export Process in SAP HANA Studio Before you can use CTS with SAP HANA, you have to configure your CTS system and the SAP HANA development system (Remember: You have to install the CTS plug-in). On the CTS system, there are several elements, which require configuration: ●
The Deploy Web Service is needed to start the deployment on the target systems.
●
The Transport Organizer is used to manage transport requests for non-ABAP applications.
After performing these two steps, the systems and the transport route in CTS are ready. As a last configuration step, you have to configure the connection from your SAP HANA development (source) system to the CTS system. This configuration is done in SAP HANA Application Lifecycle Management (HALM). If CTS is enabled, you have two options for transports: ●
●
Transport full Delivery Units (DU) based on the active state of the contained objects. Transport only the changed objects per Delivery Unit based on released changes (as of SAP HANA SPS08, if Change Recording is enabled).
You can either use SAP HANA Application Lifecycle Management (more details are provided in HowTo-Guide on: http://scn.sap.com/docs/DOC-8576.) or the SAP HANA studio (more details are provided in HowTo-Guide on: http://scn.sap.com/docs/DOC-8576.) for exporting.
Hint: For more detailed information, see: http://scn.sap.com/docs/DOC-8576 and https://scn.sap.com/docs/DOC-45659
Leveraging SAP HANA Transport Containers for ABAP for SAP HANA Content Starting with SAP NetWeaver 7.4, numerous SAP HANA related optimizations are provided that help developing ABAP applications for SAP HANA. The development of ABAP coding and SAP HANA artifacts that belong together leads to the requirement to also transport them together consistently through the system landscape. For this the SAP HANA Transport Container (HTC) can be used.
Figure 327: SAP HANA Transport Container (HTC) – Overview
SAP HANA Transport Container (HTC) – Landscape
Figure 328: SAP HANA Transport Container (HTC) – Landscape
HTC is an ABAP development object, which is required to integrate HANA repository content into the standard Change and Transport System (CTS). As of AS ABAP 7.4, HTC is seamlessly integrated into the Transport Organizer of AS ABAP and so integrating the HANA repository
content into CTS. It ensures an efficient delivery process of applications built out of ABAP and HANA content by means of the proven ABAP transport mechanism. SAP HANA Transport Container (HTC) transports full Delivery Units (DU) based on the active state of the contained objects.
Note: This means that ABAP for SAP HANA applications are transported as normal as any classic ABAP-based application. SAP HANA Transport Container (HTC) – Procedure Overview
Figure 329: SAP HANA Transport Container (HTC) – Procedure Overview
Hint: For more information see: http://scn.sap.com/docs/DOC-43035
Exporting and Importing SAP HANA Content Manually As alternative to using a transport management solution for a quick test transfer, the export and import functionality of SAP HANA can be used. Exporting and importing is possible as client-side and server-side.
Using Client Export and /Import for Models You can export all catalog objects to a file system and then import them back into another database. For example, you want to move data from a test system to a production system, clone your system, or provide the data to SAP Support so they can replicate a scenario.
Figure 331: Using Client Export and Import for Models
Note: If you want to specify a different directory in the server's file system, it must already exist and the database must be authorized to access it.
Figure 332: Export and Import of Tables – Considerations
Note: You can prevent the export of content by means of authorization. For additional information, seethe developer guide.
Hint: For the export of small tables or catalog-only exports, a CSV export to the client file system is appropriate. However, keep the maximum file size of your operating system in mind. A binary export on the server is recommended for large exports (for example, exports over 2 GB).
Business Example In this scenario, we want to try out the export and import functionality of SAP HANA. Since there is only one SAP HANA server, it is not possible to move the change to a different SAP HANA server using export/import method. Therefore, a schema is created and a table is created under the schema. Afterwards the table is deleted and then imported using the files exported. 1. Create a schema and a table under the schema. Schema that you will create
TRAIN## (where the number is provided by the instructor)
Table you will create under TRAIN## where ## ='01' or '02.' This will be provided by the instructor.
PRODUCTS which will be same as sap.hana.democontent.epm.data::MD.Products table from the SAP_HANA_DEMO schema
2. Export the table. 3. Delete the table from the schema. 4. Import the table.
Business Example In this scenario, we want to try out the export and import functionality of SAP HANA. Since there is only one SAP HANA server, it is not possible to move the change to a different SAP HANA server using export/import method. Therefore, a schema is created and a table is created under the schema. Afterwards the table is deleted and then imported using the files exported. 1. Create a schema and a table under the schema. Schema that you will create
TRAIN## (where the number is provided by the instructor)
Table you will create under TRAIN## where ## ='01' or '02.' This will be provided by the instructor.
PRODUCTS which will be same as sap.hana.democontent.epm.data::MD.Products table from the SAP_HANA_DEMO schema
a) Open SAP HANA Studio. b) Right-click the HSAP ANA system, which uses ‘SYSTEM’ user for connection and select SQL Console. c) Enter the sql command below to create a schema and execute it by clicking the little white arrow in a green circle (F8 – Execute) . create schema TRAIN##; The message of the result is displayed at the bottom, and the schema is now created and can be seen in the left panel of the screen. d) Enter the sql command to create a table and execute. create column table “TRAIN##”. “PRODUCTS” like “SAP_HANA_DEMO”. “sap.hana.democontent.epm.data::MD.Products” with data; The message of the result is displayed at the bottom and the table is now created and can be seen in the left panel of the screen after refreshing the screen by right-clicking your schema and selecting Refresh. 2. Export the table. a) Open HANA Studio b) Right click the table under the TRAIN## schema that you have just created and select Export to export the table. The table is selected. c) Choose Next.
d) Select Binary for format, select Including data and Including dependencies, use the Default Directory, which will create the export file under work directory of the SAP HANA server choose Finish. The directory structure index//PR/
under work directory is created and the exported files are located under this directory structure. 3. Delete the table from the schema. a) Open SAP HANA Studio b) Right-click the table under the TRAIN## schema and select Delete. c) Select Cascade, Delete Catalog Object and chose OK. d) Refresh the screen by right-clicking the TRAIN## schema, and choosing Refresh. 4. Import the table. a) Open SAP HANA Studio b) Right-click the Tables folder under the TRAIN## schema and choose Import. c) Select the location where the files are exported choose Next. d) Enter TRAIN##. PRODUCTS, choose Add, and choose Next. Replace ## with the two digit number provided by the instructor. e) Under the Import Selection, keep the default options and choose Finish. f) Refresh the screen by right-clicking the TRAIN## schema, and choosing Refresh.
Business Example In this scenario we want to try out the transport of a delivery unit between two SAP HANA systems using SAP HANA application lifecycle management. Therefore, a delivery unit is created in the source system. Then the source system is registered in the target system and a transport route is created. Source system: SHS on wdflbmt7194 Target system: SHS on wdflbmt7195 Create a Delivery Unit in the Source System wdflbmt7194 using HALM 1. Start SAP HANA application lifecycle management and log on to the source system as user SYSTEM 2. Create a and a delivery unit DU_HA200 and assign it to the product PRODUCT_HA200 3. Create a package PACKAGE_HA200 and assign it to the delivery unit DU_HA200. Register the Source System in the Target System and Create a Transport Route 1. Start HSAP ANA application lifecycle management and log on to the target system as user SYSTEM. 2. Register the source system SHS on wdflbmt794 3. Create a transport route. Transport the Delivery Unit to the Target System 1. Start the transport and check the result.
Business Example In this scenario we want to try out the transport of a delivery unit between two SAP HANA systems using SAP HANA application lifecycle management. Therefore, a delivery unit is created in the source system. Then the source system is registered in the target system and a transport route is created. Source system: SHS on wdflbmt7194 Target system: SHS on wdflbmt7195 Create a Delivery Unit in the Source System wdflbmt7194 using HALM 1. Start SAP HANA application lifecycle management and log on to the source system as user SYSTEM a) Start your browser and enter the URL: http://wdflbmt7194:8020/sap/ hana/xs/lm. b) Log on as user SYSTEM. 2. Create a and a delivery unit DU_HA200 and assign it to the product PRODUCT_HA200 a) Select the PRODUCTS → Delivery Units tab. b) Choose + Create. c) In the dialog box, choose Name: DU_HA200. d) Choose Create. 3. Create a package PACKAGE_HA200 and assign it to the delivery unit DU_HA200. a) Choose Manage Packages in the Assigned Packages area. The SAP HANA Web IDE starts in a new browser tab.
Figure 333: HALM Assign Packages
b) Right-click Content and choose New → Package. c) In the dialog box, choose Package name: PACKAGE_HA200. d) Choose Create.
e) Go back to the HALM browser tab. f) Select the delivery unit DU_HA200 and choose Assign in the Assigned Packages area. g) In the dialog box, choose PACKAGE_HA200 and choose Assign. Register the Source System in the Target System and Create a Transport Route 1. Start HSAP ANA application lifecycle management and log on to the target system as user SYSTEM. a) Start your browser and enter the URL: http://wdflbmt7195:8020/sap/ hana/xs/lm. b) Log on as user SYSTEM. 2. Register the source system SHS on wdflbmt794 a) Select Transports in HALM. b) Choose + Register on the TRANSPORT → Systems tab. c) In the dialog box, choose: Host: WDFLBMT7194, and choose XS Engine HTTP(S) Port: 8020 d) Choose Next. e) Choose Maintain Destination to maintain log on information.
Figure 334: HALM Register System
f) On HTTP Destination Details screen, select the Authentication Details tab, and choose Edit. g) Choose Authentication Type BASIC and enter the log on information for the user SYSTEM. h) Choose Save. i) Close the HTTP Destination Details screen and choose Finish. 3. Create a transport route. a) Choose + Create on theTRANSPORT → Transports tab. b) In the dialog box, choose: Name: T_ROUTE_HA200, Source System: SHS (WDFLBMT7194), Content: DU_HA200.
c) Choose Create. Transport the Delivery Unit to the Target System 1. Start the transport and check the result. a) Choose Start Transport on the TRANSPORT → Transports tab. b) In the dialog box, choose OK. c) Check the logs on the TRANSPORT → Logs tab. In SAP HANA Studio you find the package PACKAGE_HA200 in the content.
LESSON OVERVIEW Business Example You have to perform backups for the SAP HANA database. Therefore, you need to know the backup and recovery concept of the SAP HANA database. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the concept of backup and recovery
SAP HANA Persistence To ensure optimal performance, the SAP HANA database holds the bulk of its data in memory. However, it still uses persistent storage to provide a fallback in case of failure.
Figure 336: SAP HANA Persistence
During normal database operation, data is automatically saved from memory to disk at regular savepoints. Additionally, all data changes are recorded in the redo log. The redo log is saved from memory to disk with each committed database transaction. After a power failure,
the database can be restarted as they can with any disk-based database, and it returns to its last consistent state by replaying the redo log since the last savepoint. While savepoints and log writing protect your data against power failures, savepoints do not help if the persistent storage itself is damaged. To protect against data loss due to disk failures, backups are required. Backups save the payload (the actual data) of the data area and log area to different locations. Unused space in the database is not backed up. The data backup includes all the data structures that are required to restore the database. This includes user data, information models, topology information, and the secure storage file system (SSFS). A data backup does not include customer-specific configuration. Overview of Backup and Recovery Backups are performed while the database is running. The impact of backups on system performance is negligible, and users can continue to work normally while the backup is running.
Figure 337: Overview of Backup and Recovery
The properties of an SAP HANA system are defined in the parameters of its configuration files. These files are not backed up as part of the database backup. If you want to back up configuration files that contain customer-specific changes, you can do so manually. In a recovery situation, this can be helpful to more easily identify and restore the customerspecific changes. The configuration files are not essential to perform a recovery. If you want to use a customer-specific configuration, you need to reconfigure the recovered system using the SAP HANA studio. For more information on the configuration file backup, see SAP Note 1651055 - Scheduling SAP HANA Database Backups in Linux.
Overview Data backups save the content of the data area to a different location in the file system. Depending on the usage scenario, this includes the replicated business data from ERP and all the modeling data.
Destinations for Backups You can specify whether data and log backups are written to the file system (see SAP Note 1820529) or using third-party backup tools (see SAP Note 1730932). The Backint for SAP HANA interface performs all the actions needed to write the backup data to external storage. The backup tools communicate directly with the SAP HANA database through the Backint for SAP HANA interface.
Figure 343: Destinations for Backups
Backint for SAP HANA “Backint for SAP HANA” is an API that can be implemented by a 3rd party backup agent.
Provides functions for backup, recovery, query, and delete. 3rd party backup agent runs on the SAP HANA server and communicates with the 3rd party backup server. Backups are transferred through pipes. Full integration with SAP HANA studio (configuration and execution of backups to Backint). Backint can be configured both for data backups and for log backups.
Note: SAP certification is required for “Backint for SAP HANA” implementations by 3rd party vendors. The default configuration is defined when a third-party backup tool is installed. After a backup tool has been installed, you can back up and recover the SAP HANA database without making any further changes. Backup and Recovery Strategy This is an overview of important information to consider when planning your backup and recovery strategy with SAP HANA database. You can find more information on the individual points in the subsequent sections. ●
●
Only the database payload is backed up.
●
During data and log backup, the system is available as usual.
●
Backup supports both files as backup media and Backint for SAP HANA.
●
●
●
●
●
●
●
430
Data and logs can only be backed up when the SAP HANA database is online (when all configured services are running).
The configuration path for data and log backup must be valid throughout the whole system, and not only for specific hosts. Backup and recovery always applies to the whole database. It is not possible to backup and recover individual database objects. To recover the database, you need at least one data backup. At the beginning of a recovery, all the data and log backups to be used must be either accessible in the file system or available through the third-party backup tool. To recover the SAP HANA database, the database needs to be shut down. For this reason, during recovery, the database cannot be accessed by end users or applications. Shared storage must be used for file-based backups. This is to ensure that the nameserver process can access the backup files at the time of recovery. The SAP HANA database software version used during the recovery must always be the same or higher than the version of the software used to create the backup.
Privileges for Backup and Recovery Table 13: Required Authorizations To perform operations related to backup and recovery, the following authorizations are required: Task
Required authorizations
Backup
●
BACKUP ADMIN or BACKUP OPERATOR
●
CATALOG READ This privilege is required in order to collect the information needed by the backup wizard
Recover
Open the Backup editor
Delete data and log backups from the backup catalog and physically from the backup location
The recovery process is executed as the operating system user (adm).You must therefore have the logon credentials of this user. ●
BACKUP ADMIN
●
CATALOG READ
BACKUP ADMIN
What is the difference between the BACKUP ADMIN and BACKUP OPERATOR? The system privileges BACKUP ADMIN and BACKUP OPERATOR exist so that you can implement a finer-grained separation of duties, if this is necessary in your organization. A user with the system privilege BACKUP ADMIN can perform all of the backup-related operations, including backup deletion and configuration. A user with the system privilege BACKUP OPERATOR can only perform backups. For example, if you have automated the regular performance of backups using Cron, it is more secure to use a user with the privilege BACKUP OPERATOR to avoid the malicious deletion of backups.
LESSON OVERVIEW The goal of this lesson is to understand how the data backup works. Business Example You have to define a backup strategy for your SAP HANA database. Therefore, you need to know how to perform data area backups. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Perform a data area backup
●
Estimate the size of a backup
Overview of Data Area Backup The payload of the data area can be backed up performing a complete data backup or a delta backup. Delta backups contain data that was changed since the last complete data backup. Two types of delta backups are available, as follows: Incremental The smallest data backup as unchanged data will not be backed up in multiple backups – > fast backup. During recovery, they need to be applied individually –> longer recovery times. Differential Increase the amount of data saved with each backup –> longer backup times. Reduce the number of data backups needed during recovery –> fast recovery.
Note: Delta backups are data backups. In contrast to delta backups, log backups contain the redo log entries of a closed log segment. Depending on your specific backup and recovery requirements, decide which delta backups fit best. You can also mix incremental and differential backups.
Note: In terms of backup and recovery 'changed data' is related to the physical layout of the data in the SAP HANA persistent storage. This does not always correlate to the amount of data actually changed. for example, a delta merge of a column store partition does not change the content of an SAP HANA database at all but recreates the whole partition for optimized read access of the data. In this case the whole partition is to be backed-up in a delta data backup even if no data was changed.
When the data area is backed up, all the payload data from all the servers is backed up. This happens in both single-host and multihost environments. Backup Files
The data backup files are written to the location specified by the parameter basepath_databackup in the persistence section of the global.ini configuration file. By default, the location for data backup files is $(DIR_INSTANCE)/backup/data. To use a different location, you can specify a different path when you perform the backup. If you need to, you can specify a different path for each backup. Alternatively, you can change the value of basepath_databackup. Go to the Configuration tab in the SAP HANA studio and choose global.ini → persistence. If you change the backup location in basepath_databackup, the change takes effect immediately. For improved data safety, we recommend that you specify a path to an external backup location. The backup location should never be on the same file system as the data or log areas.
Note: All the files for a particular data backup are written to the same location. The files belonging to the same data backup cannot be written to multiple locations. Different data backups can be written to different locations, but all the files belonging to one particular data backup are written to the same location. We recommend that you create the directory structures before the backup is started.
Note: The default backup destination can only be changed for file-based backups. Backups made using third-party tools always use the destination /usr/sap/ /SYS/global/hdb/backint. For this reason, it is not possible to change the backup destination for third-party tools. Each backup file name comprises the following elements: <>. The and are optional. If no complete path is specified, the default backup location is used. You can specify a prefix for the backup file name, or you can use the prefix proposed by the system. The system adds a unique suffix to each backup file name. Because this is done for each service that is included in the backup, you only need to specify one file name prefix for all the backups on the different hosts. The suffix that is appended to a file name prefix is only unique for each service. Consequently, the next time you back up a service, the system assigns the same backup suffix to the backup file for that service. If you do not change the file name, the existing backup file for that service will be overwritten by the new backup. During the backup process, a backup file for each service is created in the backup location. The example shows a set of backup files from one data backup created with SAP HANA studio. The files can have different names. In is example, COMPLETE_DATA_BACKUP is the file name prefix; databackup_0_1 is the suffix. We therefore recommend that you copy a data backup to a new location as soon as it is created. Alternatively, specify a different file prefix or location when starting the next backup.
The configuration of backup settings (for example, third-party backup tool integration, backup destination paths, log backup settings) is available in the Backup Editor of SAP HANA Studio. Overview of Configuration Options
Figure 347: Overview of configuration options
In large SAP HANA systems, data backup files might be larger than the maximum file size that can be stored on the respective file system. The configuration options allow you to specify the maximum file size for backup files. If a backup exceeds this size, it is split up in several files.
The Administrator has to ensure that sufficient free space for the backup files is available. The amount of free space that will be needed in the backup directory needs to be calculated. To estimate the size of a backup, you can use the system table M_CONVERTER_STATISTICS in the SQL Editor in the SAP HANA studio. This system table contains information about the used blocks. To estimate the size of the next complete data backup, you can use either of the following commands: ●
●
select sum(allocated_page_size) from M_CONVERTER_STATISTICS The result is a single value that gives the sum of the sizes of all services in bytes. The size may differ between SELECT statement and DATA BACKUP execution. For this reason, it is advisable to include a reserve of free space. select volume_id, sum(allocated_page_size) from M_CONVERTER_STATISTICS Group by volume_id This displays a list of the volumes (index server, name server, statistics server), with the size of each volume in bytes.
Hint: The more difficult part is the sizing for log Backups, because this depends on the amount of data changes that occur in the database, which in turn is a unique quantity for each system and timeframe. When loading data the experiences shows that the disk size of log entries is typically at least twice of the loaded data after compression in SAP HANA.
Performing Backups Using SAP HANA Cockpit If a backup is started the backup wizard also shows the estimated backup size. See the figure below.
Figure 349: Performing Backups Using SAP HANA Cockpit
Performing a Data Backup Using SAP HANA Cockpit To create a data backup using SAP HANA Cockpit, perform the following steps: ●
●
●
●
Select the Data Backup tile in SAP HANA Cockpit. To open the backup settings page, click the Back Up button at the bottom of the backup catalog. Select the type of the data backup: -
Complete Data Backup
-
Differential Data Backup
-
Incremental Data Backup
Specify the location (directory) and the backup file prefix to use and choose Next. SAP HANA Cockpit uses the time stamp for the backup file prefix by default. The default location shows the path specified in global.ini under the backup parameter basepath_databackup.
When all the settings are correct, choose Finish. The backup then starts. The progress of the backup is shown for all types of services (for example, the name server, and index servers).When all the volumes have been backed up, a confirmation message is displayed. Once you have started the backup, the progress is displayed on the Backup Data tile. To view the progress details, click the tile.
Performing a Data Backup Using SAP HANA Studio To create a data backup using SAP HANA Studio, perform the following steps: ●
In the Navigator view, select the system for which you want to start a backup.
●
From the context menu, choose Back Up.
●
Select the type of the data backup:
●
●
-
Complete Data Backup
-
Differential Data Backup
-
Incremental Data Backup
Specify the location (directory) and the backup file prefix to use and choose Next. The default location shows the path specified in global.ini under the backup parameter basepath_databackup. When all the settings are correct, choose Finish. The backup then starts. The progress of the backup is shown for all types of services (for example, the name server, and index servers).When all the volumes have been backed up, a confirmation message is displayed.
Note: A data backup performed with the SAP HANA studio only saves the payload of the data volumes of the database. The database configuration files (and .ini files) are not backed up. Configuration files (.ini files) that contain customer-specific changes can be backed up manually in order to more easily identify and restore customer-specific changes in a recovery situation. Performing a Data Backup Using SAP HANA Cockpit Backup operations are also available in SAP HANA Cockpit.
Note: Snapshots, delta backups, and recovery operations are not yet available in SAP HANA Cockpit. Overview of Backup Operations Once you have started the backup, the progress is displayed on the Backup Data tile. To view the progress details, click the tile. When the backup is finished, the backup details are shown on this screen. A running data backup could be canceled from the progress details screen.
Performing a Data Backup Using SQL Commands You can enter SQL commands either by using the SQL editor in SAP HANA studio, or by using the hdbsql program on the command line.
Figure 351: Database Backup Using SQL Commands
Note: Backups using SQL commands are only recommended for batch mode (see section “Backup and Recovery” of the administration guide).
Action Parameters – If different from the default, specify the location and prefix for the file. Recurrence – Specify when the action will be repeated or whether it will be executed only once.
LESSON OVERVIEW This lesson gives you an overview of the configuration and the different log modes. Business Example You have to define a backup strategy for your SAP HANA database. In addition to performing data area backups, you have to configure a log area backup. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
The system can reuse the space that is occupied in the Log Volume by the Log Segments. The LOG_MODE parameter controls how the Log Segments are re-consumed. Overwrite mode: LOG_MODE = OVERWRITE. Log segments are freed by savepoints and no log backup is performed. This can be useful, for example, for test installations that do not need to be backed up or recovered.
Caution: LOG_MODE = OVERWRITE is not recommended for production systems. With LOG_MODE = OVERWRITE, no point-in-time recovery is possible. For recovery, only data backups are used; the logs are not used. The Recover the database to a specific data backup recovery option is the only option that can be selected. Normal mode: log_mode = normal (default). ●
Keeps log segments until backup
●
Automatic log backup available (time-based or when segment is full)
●
Log backup directory configured with parameter BASEPATH_LOGBACKUP
●
Backup catalog maintenance
●
Restoring of any available data backup with log replay to the last committed state
●
Restoring of any available backup without log replay
Overview of Log Area Backup For productive systems, we recommend log mode NORMAL because it provides the highest security with regard to the restoration of data for a recovery of the SAP HANA database. In NORMAL log mode, the system automatically creates log backups that can be used for a recovery in addition to the data backups. However, more backup space is required in this log mode due to the log backups. Therefore, an operational concept for administrating data and log backups is a prerequisite for using log mode NORMAL. After changing the log mode parameters, you must restart the database system to activate the changes. We also recommend that you create a full data backup of the database.
Figure 356: Overview of Log Area Backup
The system can perform regular log backups to allow the reuse of log segments. During a log backup, the payload of the log segments is copied from the log area to service-specific log backup files. A log segment is backed up in the following situations: ●
The log segment is full.
●
The log segment is closed after exceeding the configured time threshold.
●
The database is started.
If you do not regularly move the log backup files to an external destination, you run the risk of the file system to become full. Log segments can only be overwritten by the system after they have been backed up.
Caution: Do not delete log segments on operating system level, as the log area will become unusable and the database may stop working immediately.
Note: If backups go to the file system, you must also regularly archive the log BACKUPS to avoid the log BACKUP DESTINATION from becoming full.
Configuring the Log Backup
Figure 357: Backup Configuration for the Log Area
Location of the Log Backup Files by Using Destination Type FILE The log backup files are written to the location specified by the BASEPATH_LOGBACKUP parameter in the persistence section of the global.ini configuration file. By default, the location for log backup files is $(DIR_INSTANCE)/backup/log. To use a different location, change the value of BASEPATH_LOGBACKUP. Go to the Configuration tab in the SAP HANA studio, choose global.ini → persistence. If you change the backup location in BASEPATH_LOGBACKUP, the change takes effect immediately.
Automatic log backup can be enabled or disabled using the ENABLE_AUTO_LOG_BACKUP parameter. The default setting is ENABLE_AUTO_LOG_BACKUP = YES.
Note: In the default log_mode normal, if automatic log backup is disabled, the log area grows until the file system is full. At that stage, the database will freeze. Log Backup Timeout Parameter The LOG_BACKUP_TIMEOUT_S parameter forces log backups at a fixed time interval, specified in seconds. Log backups triggered by LOG_BACKUP_TIMEOUT_S are performed in addition to the log backups that are performed when a log segment becomes full. We recommended that you specify a time interval, for example, 900s. A time interval of 0 means that log backups are only made when a log segment is full and when services are restarted. Specifying an appropriate time interval for log backups enables you to recover an SAP HANA database with minimum data loss. For example, if you need to recover the database in a situation where the log area is unusable, and only the data and log backups are available.
Note: The LOG_BACKUP_TIMEOUT_S parameter only takes effect if ENABLE_AUTO_LOG_BACKUP is set. For LOG_MODE = NORMAL, these parameters must have the following values: ●
ENABLE_AUTO_LOG_BACKUP = YES
●
LOG_BACKUP_TIMEOUT_S > 0
Automatic log backups need to be enabled in production systems in order to provide full point-in-time recoverability. As of SPS09, a new alert notifies administrators when automatic log backups have been disabled.
Note: Improvements for log backups when using backint include the following: ●
●
In some cases, third-party backup tools have encountered deadlocks when two SAP HANA database services requested log backups from the same tape (no concurrent access possible to the tape). The internal recovery handling of SAP HANA has been adapted, to avoid deadlock situations when retrieving log backups from a 3rd party backup tool that uses tapes. In some scenarios, the start of a 3rd party backup agent for a log backup may take longer than the actual log backup itself. During times of high load, this may lead to many pending log backups and, in the worst case, to “log full” situations (log segments are only released for overwrite after a successful log backup). SAP HANA now uses a single backup call to the 3rd party agent for all log segments of a service that are ready for backup.
LESSON OVERVIEW This lesson explains how the backup catalog provides information about the backups you have performed. Business Example You have to define a backup strategy for your SAP HANA database. Therefore, you have to define a strategy to backup the configuration files of your database. After you have defined a strategy for the data area and the log area backup, you need information about the execution of backups and their history. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Use the backup catalog to get Information about backups
●
Perform backups using scripts
Backup Log
Figure 359: Monitoring Backups
The backup.log file records information about the data and log backups. Open backup.log and choose Diagnosis Files from the SAP HANA studio.
The Backup Catalog tab displays a list of past backups. This list allows you to see the status of each catalog entry, as well as its key information, at a glance. To see the full details of a particular entry, select it in the list. Detailed information appears in the Backup Details area. This includes, for example, backup start and completion times, duration, size, throughput time, and a breakdown for each service. By default, only full data backups are displayed. To see log backups or delta backups, select the Show Log Backups or the Show Delta Backups checkbox. Backup Catalog in the SAP HANA Cockpit
Figure 361: Backup Catalog in the SAP HANA Cockpit
The backup catalog is backed up and versioned after every completed backup operation. The backup catalog is written as a separate backup to the location where the log backups are stored. This allows the backup catalog to be accessed during a recovery. Even in situations such as when LOG_MODE = OVERWRITE is set, where logs are not written, the backup catalog is still backed up. The backup catalog is assigned a name in the following format: log_backup_0_0_0_0. In earlier versions, a backup of the backup catalog was written after each individual log backup of each service. Since there is only one backup catalog (service-independent), this could lead to a lot of pending backup requests for the backup catalog and thus block the release of log segments, for example, in scale-out scenarios under heavy load. As of SPS09, by default, SAP HANA only writes one backup of the backup catalog for concurrent log backups of different services. This means that the backup of the backup catalog covers all log backups that were written since the last backup of the backup catalog.
This behavior is enabled by default. To disable it, set global.ini → backup → enable_accumulated_catalog_backup database configuration parameter to False.
Backup Lifecycle Management Backup lifecycle management provides a framework to delete old data and log backups from the backup catalog only, or from the backup catalog and physically from the backup location. Backups can be deleted from the file system or from a connected 3rd party backup server via the Backint interface. This allows you to manage your backup storage space or to fulfill regulatory deletion requirements. The deletion functionality is available both in SAP HANA studio and on the command line using SQL commands.
Figure 362: Backup Lifecycle Management
There is an audit event that you can enable to create an entry in the audit trail whenever a backup is deleted using this function.
Consistency Check for Data and Log Backups SAP HANA can check data and log backups for integrity using the hdbbackupcheck command line tool. We recommend that you check backups, for example, after transfer to a different storage medium. Both backups to the file system and backups to a 3rd party backup tool via the Backint interface can be checked using hdbbackupcheck. hdbbackupcheck reads in the specified part of the backup, checks its metadata for correctness and consistency, and checks the content for any later changes. For more information, see SAP Note 1869119 - Checking backups using hdbbackupcheck.
Performing Backups Using Scripts In addition to performing backup and recovery operations using the SAP HANA studio, you can also use SQL statements. The syntax for these statements is described in the SAP HANA Administration Guide. These SQL statements could be used to define scripts that trigger a database backup using SAP HANA backup functionality. An example of such a backup script is presented in SAP Note 1651055.
Figure 363: Scheduling a Backup Using Scripts
Example of Database-Specific Parameters Table 14: Example of database-specific parameters
454
Name
Default
Description
SID *
---
SYSTEM ID of the SAP HANA database system
INSTANCE *
---
Instance number of the SAP HANA database system
HOSTNAME *
---
Hostname (the local host name of the database server. Do not use 'localhost'. Do not use the fully qualified (.) name.
SIDPATH **
/usr/sap/${SID}
The directory into which the binaries of the SAP HANA database system have been installed
The directory containing the instance data of the SAP HANA database
(*) means that the parameter must be adjusted to your particular installation, (**) means that typically this parameter refers to a default setting of the SAP HANA database that is unlikely to be changed in any database installation. Parameters must be specified as follows: ●
=
●
No space on either side of the ‘=’ operator
●
The name of parameters must not be changed
●
Case-sensitive
●
Use ${} for parameters that reference other parameters
Command Line Options Table 15: Command Line Options The backup script offers the following command line options: Name
Description
-h
Display usage information and exit (regardless of any other command line parameters given)
-t
Test mode: Do not create or delete backup files, that is, do not create data backup, do not create configuration file backup. Writes log messages into file ${SCRIPT_LOG}.
-q
Suppress wait time and information output (recommended in batch mode)
-d
Only create a data backup. Do not back up configuration files.
-c
Only back up configuration files. Do not run a database backup.
-p
Add script parameterization and command line switches to the script log file
--suffix=
Create backup files that do not contain the weekday as part of the name, but instead. Note: There must not be any white space on either side of the ‘=’ sign.
Backup of Configuration Files The properties of an SAP HANA system are defined in the parameters of its configuration files.
The nameserver.ini file contains global information for each installation. The landscape section contains the system-specific landscape ID and assignments of hosts to roles MASTER, WORKER, and STANDBY. If the system landscape is changed, for example, hosts are added or removed, the landscape section of the nameserver.ini is also changed.
Caution: The sapprofile.ini contains information that is specific to each host. For this reason, in a recovery situation, the sapprofile.ini file must not be copied manually to a different host, as it will not be compatible with a new landscape. The configuration files (.ini files) contain the SAP HANA database configuration settings. The configuration files are not backed up as part of the database backup. Configuration files that contain customer-specific changes can be backed up manually in order to more easily identify and restore customer-specific changes in a recovery situation. The configuration files are not essential to perform a recovery. If you want to use the customer-specific configuration, you need to reconfigure the system using the SAP HANA studio. To display the configuration values, go to the Configuration tab in SAP HANA studio. The configuration files (.ini files) are located by default in the following directories: Example Directory Paths ●
●
For global configuration settings: $(DIR_INSTANCE)/../SYS/global/hdb/ custom/config Example Configuration Files: global.ini, indexserver.ini, nameserver.ini For host-specific configuration settings: $(SAP_RETRIEVAL_PATH) Example Configuration Files: daemon.ini
Configuration files are only created in these directories if customer-specific changes are made to them after installation. If no customer-specific changes have been made, these directories may be empty.
Binary Configuration File In addition to the configuration files, all customer-specific changes are also saved in one separate (Binary) configuration file. This file is created when SAP HANA is installed and is stored in the same directory as the configuration files. The Binary configuration file is versioned. When the file is changed, a new version is created and the previous version is renamed sequentially. All the file versions are stored in the same directory. If you want to back up customer-specific configuration changes, you should back up all the versions of the binary configuration file manually together with the other configuration files. In a recovery scenario, if you wish to restore customer-specific settings, you can use both the configuration files (.ini files) and the binary configuration file. To restore customer-specific configuration settings from the binary file, use the command line tool hdbparam. If you do not want to restore the most recent version of the binary file, use hdbparam to check the individual parameter values and decide which version of the binary file to restore.
Parallel Backup Streaming via Backint
Figure 365: Parallel Backup Streaming via Backint
For improved performance, Backint can now use multiple parallel streams for data backups. If parallel streams have been configured, the individual service backups are distributed across all available streams. Note that the different services always use dedicated backup streams. Backups will only be distributed if they are bigger than 128 GB. Both full and delta backups are supported. To configure the number of parallel streams, use the parallel_data_backup_backint_channels ini file parameter (default: 1, max: 32). During recovery, the number of streams used is the same as during backup (this is independent of the current setting of the parameter).
LESSON OVERVIEW This lesson explains when it is necessary to recover SAP HANA und how you can do this. Business Example Due to a hardware error, the database cannot be started any more. After solving the hardware problem, you must perform a recovery of the database. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Perform a database recovery
Recovery of an SAP HANA Database
Figure 366: Overview
The steps to recover the database depend on the recovery scenario and the reason for the recovery. This section describes some recovery scenarios. Data Area is Unusable If the data area is unusable, and all the data changes after the last complete data backup are still available in the log backups and log area, the data from committed transactions that was in memory at the time of failure can be recovered. No committed data is lost.
For recovery, the data backups, the log backups, and the log area are used. When the data backup has been successfully restored, the log entries from the log backups and the log area are replayed automatically. It is also possible to recover the database using an older data backup and log backups. All relevant log backups made after the data backup are needed for the recovery. For more information, see SAP Note 1705945 (Determining the files needed for a recovery) Log Area is Unusable If the log area is unusable, it is only possible to replay the log backups. As a consequence, any changes that were made after the most recent log backup will be lost. In addition, all the transactions that were open during the log backup will be rolled back. It is still possible to recover the database to a point in time within the existing log backups. For recovery, the data backups and the log backups are used. When the data backup has been successfully restored, the log entries from the log backups are automatically replayed. In the Recovery Wizard, specify the Initialize log area option to prevent the recovery of entries from the unusable log area. Logical Error – Point in Time Recovery To reset the database to a particular point in time, you need a data backup from before the point in time to recover to, the subsequent log backups, and the log area. All changes made after the recovery time will be lost. If you need to perform this recovery, consider recovering the database to a different system. Recovery Types The figure, Backup History, shows an overview of the possible backup types during normal operation.
Figure 367: Backup History
Recovery Types The following recovery types are available:
(A) Recover the database to its most recent state This option recovers the database to as close as possible to the current time. This recovery option uses the following data: ●
The most recent data backup
●
Log backups made since the most recent data backup
●
Log area
(B) Recover the database to a specific point in time This recovery option uses the following data: ●
The last data backup available before the specified point in time
●
Log backups made since the data backup to be used
●
Log area
(C) Recover the database to a specific data backup This recovery option uses the following data: ●
The specified data backup
Note: Option (C) is not supported for delta backups. Log entries are not replayed, neither from the log backups nor from the log area. All log entries that still exist in the log area are deleted.
To perform an SAP HANA database recovery, the following requirements must be met: ●
The SAP HANA database software must be installed, so that an initial database exists. In a recovery situation, you can use the SAP HANA studio to restore customer-specific changes to this initial database.
Note: If you want to restore customer-specific configuration settings, you can do this either before you restore the database and the log backups or at the end of the recovery.
●
●
●
●
Ensure that the target system and the source system have identical configurations. The number and types of services (for example, index server) on each host must be identical for both system landscapes. At the beginning of a recovery, all the data and log backups to be used must be either accessible in the file system or available through the third-party backup tool. At least one data backup must be available before the recovery is started. To restore the database to a particular point in time, a data backup and all the log backups up to the point in time for recovery are needed (including the log backups made after the desired point in time of the recovery).
The following constraints apply to SAP HANA database recovery:
462
●
Recovery to a lower system release is not possible.
●
If an error occurs during a recovery, the complete recovery must be repeated.
Note: To recover the SAP HANA database, the database needs to be shut down. For this reason, during recovery, the database cannot be accessed by end users or applications.
Performing Recovery
Figure 370: Perform Recovery
To recover an SAP HANA database perform the following steps: ●
Confirm that the system can be shut down
●
Choose the recovery type: -
Recover the database to its most recent state.
-
Recover the database to a specified point in time.
-
To a specified log position.
-
To a specified data backup.
●
Specify the data and log backup directories.
●
Specify the relevant data backup.
●
The database is restarted automatically after the recovery.
Recovery Features The following section describes the recovery features Automatic checks for file system backups at the start of a recovery In addition to checking for missing backups at the start of a recovery, SAP HANA also automatically checks file system backups for corruption. If a corruption is detected, for example size or backup ID do not match with the information that is recorded in the backup catalog, the recovery is not started and details are displayed in the recovery wizard and written to the backup log file.
Note: The extended checks are executed for file system backups only. If a 3rd party backup tool is used, only the existence of the backups on the 3rd party backup server is verified. Progress reporting for a recovery shows the recovery process in detail After the initial collection of system information for the recovery, the recovery wizard shows the following phases (progress per service) ●
Phase 1: Data recovery Using data backup or snapshot
●
Phase 2: Log recovery Using log backups or log that is still available in the log area
●
Phase 3: Restart
Check whether recovery can be executed with the available backups An option to check whether you can reach a specified recovery target with the available backups has been added to the hdbbackupdiag command line tool. Checks that can be performed using hdbbackupdiag: ●
All necessary backups are available and can be accessed
●
For file system backups: -
File exists at the original location or at a location that has been specified.
-
The current operating system user has read privileges for the file.
-
File size matches the size information from the file header.
-
●
For backups written to a 3rd party backup tool: -
464
The backup ID in the file matches with the backup ID recorded in the backup catalog.
Note: hdbbackupdiag does not check the backup content for consistency (use hdbbackupcheck). For more information, see SAP Note 1873247: Checking recoverability with hdbbackupdiag -check.
Performing Recovery using the Command Line Tool SQL statements for recovery cannot be executed using the normal SQL clients such as hdbsql and cannot be executed when the database is online. For this reason, the Python script recoverSys.py is used to pass SQL statements to SAP HANA. The following is the procedure for performing Recovery using the Command Line Tool: 1. The administrator calls the script with the required parameters, specifying recovery target time, recovery type, and further options. 2. The script stops the SAP HANA database, prepares, and executes the recovery. 3. After the master name server of the SAP HANA database started successfully, the script terminates. Note that, at this point, the recovery is not complete yet. We recommend that you call the script using the --wait option, which ensures that the script waits until the recovery has finished.
Resume Recovery
Figure 371: Recovery Phases
Resume Recovery After Error Data recovery usually takes up most of the time of a recovery. If a recovery fails during log replay, SAP HANA can now resume the recovery after the data recovery, thus shortening the outage significantly. A typical example that could cause a failure during log replay would be a temporary outage of the backup network.
Perform Recovery After Error If a recovery failed during log replay, SAP HANA Studio will display the successful data recovery part as a RESUME option in the recovery wizard.
Check the location of the directory for the data backups and the log backups. Ensure that sufficient free space for the backup files is available. Therefore, estimate the amount of free space that will be needed in the backup directory. Check the Location of the Directory Check the location of the directory for the data backups and the log backups. Ensure that sufficient free space for the backup files is available. Therefore, estimate the amount of free space that will be needed in the backup directory. 1. Check the location of the directory for the data backups. 2. Perform an estimation of the size of a backup. Check the Parameter Settings The next step is to check the parameter settings, which control the log backup behavior (log_mode and enable_auto_log_backup). 1. Check the parameter settings, which control the log backup behavior. Perform a Data Backup of your Database After the preparation steps, perform a data backup of your SAP HANA database and check the size of the backup in the file system. 1. Perform a data backup of your HANA database. 2. Check that the backup has finished successfully. 3. Check the size of the backup in the file system Review the Data and the Log Backups Open the backup.log file to retrieve information about the data and the log backups. Information about the execution of backups and their history is provided by the backup catalog. You could use the monitoring views M_BACKUP_CATALOG and M_BACKUP_CATALOG_FILES to display information about the backup catalog. This information is also provided by the Backup Console. Find out the backup_id of your complete data backup and determine the names of the backup files and their size. 1. Open the backup.log file to retrieve information about the data and the log backups. 2. Find out the backup_id of your complete data backup. 3. Determine the names of the backup files and their size. Simulate a File System Crash and Recover the Database Simulate a file system crash and recover the database to its most recent state. 1. Simulate a file system crash by deleting one of the data volumes. For this, you can delete the content of the directory /hana/data/SHS/mnt00001/hdb00003.
Check the location of the directory for the data backups and the log backups. Ensure that sufficient free space for the backup files is available. Therefore, estimate the amount of free space that will be needed in the backup directory. Check the Location of the Directory Check the location of the directory for the data backups and the log backups. Ensure that sufficient free space for the backup files is available. Therefore, estimate the amount of free space that will be needed in the backup directory. 1. Check the location of the directory for the data backups. a) Open the Administration View in SAP HANA studio. b) Select the Configuration Tab. c) The data backup files are written to the location specified by the basepath_databackup parameter in the persistence section of the global.ini configuration file. By default, the location for data backup files is $(DIR_INSTANCE)/ backup/data. d) The log backup files are written to the location specified by the basepath_logbackup parameter in the persistence section of the global.ini configuration file. By default, the location for log backup files is $(DIR_INSTANCE)/backup/log. e) As an alternative, you can use the Backup Console to view this information. Open the tree for user SYSTEM in the Navigator view and double-click the Backup folder. Select the Configuration tab in the Backup Console. 2. Perform an estimation of the size of a backup. a) Open the SQL Editor in SAP HANA studio. b) To estimate the size of the next complete data backup, use the following command: SELECT SUM(ALLOCATED_PAGE_SIZE) FROM M_CONVERTER_STATISTICS The result is a single value that gives the sum of the sizes of all services in bytes. The size may differ between the SELECT statement and DATA BACKUP execution. For this reason, it is advisable to include a reserve of free space. Check the Parameter Settings The next step is to check the parameter settings, which control the log backup behavior (log_mode and enable_auto_log_backup). 1. Check the parameter settings, which control the log backup behavior. a) Open the Administration view in SAP HANA studio. Select the Configuration tab. b) The parameters that control the log backup behavior are located in the persistence section of the global.ini configuration file. The correct parameter settings to perform log backups are:
log_mode = normal and enable_auto_log_backup = yes These parameter settings manage that log backups are created on a continuous basis. As an alternative, you can use the Backup Console to view this information. c) To use the Backup Console, open the tree for user SYSTEM in the Navigator view and double-click the Backup folder. Select the Configuration tab in the Backup Console. Perform a Data Backup of your Database After the preparation steps, perform a data backup of your SAP HANA database and check the size of the backup in the file system. 1. Perform a data backup of your HANA database. a) In the Navigator view of in SAP HANA studio, select the database (database user SYSTEM) for which you want to start a backup. b) From the context menu, choose Backup and Recovery → Back Up System. c) Specify the location (directory) and the backup file prefix to use. (Use the default settings.) d) When all the settings are correct, choose Next and Finish. The backup then starts. The progress of the backup is shown for all types of services (for example, the statistics server, name server, and index servers). When all the volumes have been backed up, a confirmation message is displayed. 2. Check that the backup has finished successfully. a) Choose Open log file in the view Backup Execution Summary. b) Close the view Backup Execution Summary. The log file is displayed in the SAP HANA studio. c) Check that the backup has finished successfully. 3. Check the size of the backup in the file system a) Log on to the HANA system on OS-level using telnet. b) Open a telnet session by choosing Start → Programs → Putty → putty.exe. c) If you see a security alert, confirm with Yes. d) Enter the password of the OS-User shsadm. e) Navigate to the backup directory: cd /usr/sap/SHS/HDB20/backup/data. f) Determine the size of the backup files and the backup directory using the command: LS -LH. g) Compare this result with the estimation you performed in the first task, second step. Review the Data and the Log Backups Open the backup.log file to retrieve information about the data and the log backups. Information about the execution of backups and their history is provided by the backup catalog. You could use the monitoring views M_BACKUP_CATALOG and
M_BACKUP_CATALOG_FILES to display information about the backup catalog. This information is also provided by the Backup Console. Find out the backup_id of your complete data backup and determine the names of the backup files and their size. 1. Open the backup.log file to retrieve information about the data and the log backups. a) Open the Administration view in SAP HANA studio. b) Select the Diagnosis Files tab. c) Search for backup in the Filter field d) Open thebackup.log file. 2. Find out the backup_id of your complete data backup. a) Open the SQL Editor in SAP HANA studio. b) To find the backup_id of your complete data backup, query the monitoring view M_BACKUP_CATALOG: select * from M_BACKUP_CATALOG c) Identify your backup according to the starting time in the SYS_START_TIME field. 3. Determine the names of the backup files and their size. a) Open the SQL Editor in SAP HANA studio. b) To find the names of the backup files and their size, query the monitoring view M_BACKUP_CATALOG_FILES: select * from M_BACKUP_CATALOG_FILES where BACKUP_ID =’’ (Make sure you remove the commas from the backup is value!!) You find the information about the names of the backup files and their size in the fields BACKUP_SIZE and DESTINATION_PATH fields. As an alternative, you can use the Backup Console to view this information. c) To use the Backup Consoles, open the tree for user SYSTEM in the Navigator view and double-click the Backup folder. Select the Backup Catalog in the Backup Console. Simulate a File System Crash and Recover the Database Simulate a file system crash and recover the database to its most recent state. 1. Simulate a file system crash by deleting one of the data volumes. For this, you can delete the content of the directory /hana/data/SHS/mnt00001/hdb00003. a) Log on to the HANA system on OS-level using telnet. b) Open a telnet session by choosing Start menu and search for HA200_Putty. c) If you see a security alert, confirm with Yes. d) Enter the password of the OS-User shsadm. e) Navigate to the directory containing the data volumes: cd /hana/data/SHS/mnt00001
f) Display the content of the ls –lh directory. The data volumes are located in the hdb0000X subdirectories. g) Delete the subdirectory hdb00003: rm –rf hdb00003. 2. Recover the database to its most recent state. When the recovery is complete, the system is online. a) In the Navigator view in SAP HANA Studio, select the database (database user SYSTEM) for which you want to start a recovery. b) Open the context menu and choose Backup and Recovery → Recover System. A dialog box is displayed, requesting that you confirm that the system can be shut down for the recovery. c) Confirm and choose OK. A dialog box is displayed, requesting you to enter user name and password for adm. d) Enter user shsadm and the respective password and choose Next. e) Specify the recovery type: “Recover the database to its most recent state”. f) Choose Next. g) Specify the locations of the data and log backup files if they are not in the default location. h) Choose Next. The next screen gives an overview of data backups that where recorded in the backup catalog as successful. i) Select your backup and choose Next. An Other Settings dialog box is displayed, requesting you to install a new license. This is only needed when you recover from a different system. j) k) Keep the default settings and choose Next. A summary of the selected recovery options is displayed. l) If the settings are correct, choose Finish. The recovery is then started. The progress of the recovery is displayed in the Recovery Progress Information screen. When the recovery is complete, the system is online.
LESSON OVERVIEW This lesson gives a short overview on performing backup and recovery using a storage snapshot. Business Example You have to perform backups for the SAP HANA database. Therefore, you need to know how storage snapshots are integrated in the backup concept. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the concept of backup and recovery using a storage snapshot
Storage Snapshots Storage snapshots created by tools provided from the storage hardware vendor offer an additional option to safeguard the SAP HANA data area. A storage snapshot captures the content of the SAP HANA data area at a particular point in time, and has a consistent database state.
Note: A database snapshot is used to create a storage snapshot. A database snapshot provides a read-only view of the database with a consistent state at the point in time that the snapshot was created. The consistent database state is ensured for both single-disk and multiple-disk systems. As with the data backup types supported by SAP HANA (File or Backint), a storage snapshot is created while the SAP HANA database is running. Whereas a data backup is written to a separate storage location, a storage snapshot needs to be manually stored in a location that is physically separate from the SAP HANA data area.
Note: When a storage snapshot is created, the integrity of the data is not checked. For this reason, we recommended that you combine your use of storage snapshots with data backups (File or Backint), for which the data integrity is checked automatically. An SAP HANA database can be recovered in a single procedure, either using a storage snapshot, or using a storage snapshot in combination with log backups. Log backups can be replayed after the database has been recovered with a storage snapshot.
Lesson: Backup and Recovery using Storage Snapshot
Creation of Storage Snapshots SAP HANA supports the creation of storage snapshots, which can later be used for SAP HANA recovery. There is a loose coupling between SAP HANA and the storage tool; storage snapshots are recorded in the SAP HANA backup catalog.
Figure 374: Creating a Storage Snapshot
To create a snapshot, proceed as follows: 1. Using SAP HANA studio, prepare the database for the storage snapshot. Technically, this creates an internal data snapshot. 2. Using the storage tool, create a storage snapshot of the SAP HANA data area. 3. In SAP HANA studio, confirm the storage snapshot as successful. An entry including the external backup ID is written to the backup catalog. The SAP HANA database automatically deletes the internal snapshot from SAP HANA data area after it has been either confirmed or abandoned.
Figure 375: Creating a Storage Snapshot in SAP HANA Studio
Note: Storage snapshots are not yet supported in SAP HANA Cockpit Creating a Storage Snapshot Using SQL Commands Alternatively, you can use the SQL commands to create a storage snapshot and to confirm the successful storage snapshot and enter the external snapshot ID: BACKUP DATA CREATE SNAPSHOT COMMENT snapshot_test’ BACKUP DATA CLOSE SNAPSHOT BACKUP_ID 3456789 SUCCESSFUL 'storage_id_12345‘ The details about creating storage snapshots using SQL commands are covered in the SAP HANA Administration Guide. Prepared storage snapshots should only exist for a short time (until the storage snapshot was executed using the storage tool). When a storage snapshot was prepared but not confirmed for a longer period of time an alert occurs (for details see SAP Note 1991615).
Recovery using a Storage Snapshot If you are using a storage snapshot as the basis for your recovery, you first need to transfer it back to the data area of the SAP HANA database using the storage tool. The procedure for recovery using a snapshot is as follows:
Lesson: Backup and Recovery using Storage Snapshot
1. Using the storage tool, transfer the storage snapshot to the data area of the SAP HANA database 2. Using SAP HANA studio, recover the database using the storage snapshot as basis (available in the recovery wizard)
Note: All recovery options are available, including point-in-time recovery using log backups from the log area.
Note: You can also call up the recovery wizard before transferring the storage snapshot to the data area of SAP HANA. In that case, the recovery wizard show all of the storage snapshots recorded in the SAP HANA backup catalog, and you can decide which one to transfer to the data area of SAP HANA. After the recovery, SAP HANA automatically deletes the internal data snapshot from the data area (which was contained in the transferred storage snapshot). Recovery of delta backups using a storage snapshot as the basis is currently not supported. LESSON SUMMARY You should now be able to: ●
Explain the concept of backup and recovery using a storage snapshot
LESSON OVERVIEW This lesson describes how you can clone the database. Business Example To set up a three-system landscape you have to clone your SAP HANA database. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the scenarios for a database copy
Backup Based Database Copy You can create a homogenous copy of a database by recovering an existing source database backup to a different but compatible target database. The source database backup consists of data backup files and the log backup files. A homogenous database copy is a quick way to set up cloned systems for training, testing, and development. For this reason, it can significantly reduce total cost of delivery (TCD). You can copy a database in two ways, as follows: ●
●
Using only data backups or storage snapshots. This restores the content exactly as of the point in time at which a data backup or storage snapshot was. Using both the data backups or storage snapshots and the log backups of the source system. This allows you to restore the database to a point in time after the data backup or storage snapshot was created.
Prerequisites for a Database Copy ● A data backup (file-based backups or backups using a 3rd party backup tool) or a storage snapshot of the source system is available. ●
The version of the target database is the same or higher than the source database.
●
The target database has sufficient disk space and memory.
●
478
The target database must have the same number and types of services as the source database.
●
The target system configuration is usable for the recovery of the source system.
●
Customer-specific changes can be manually applied to the target system.
●
A license key file is available for the target database.
The procedure to copy a Database using a database backup is as follows: ●
●
●
Create the target database (new installation). Copy the required backups to the target database backup folder (using operating system commands). Recover the target database to the desired point in time.
Note: If you are using a storage snapshot, you first need to stop the SAP HANA database, then make available the storage snapshot in the target database. Database Cloning Using a Storage Snapshot A backup using a storage snapshot of the data area can be used to clone a database, similar to the procedure for data backup. The snapshot in the cloned database is restored during the first restart.
Figure 377: Database Cloning Using a Storage Snapshot
When the recovery has successfully completed, the database is started. The source database has now been recovered to the target database, and you can work with the recovered database. Copying a database using backup and recovery is described in detail in the SAP HANA Administration Guide.
Note: If the target system has less resources, for example, less CPU and RAM, performance cannot be expected to be the same as in the source system. Database Copy from System with m Nodes to a System with n Nodes
Figure 378: Database Copy from System with m Nodes to a System with n Nodes
You can copy a scale-out SAP HANA database with m nodes to SAP HANA database with n nodes (m > n). This functionality is needed, for example, when you want to use a copy of your production system for tests on a smaller QA system.
The steps to perform a database copy from a system with m nodes to a system with n nodes is as follows: ●
●
●
Create a data backup of the source database. In the target database, configure (m-n) additional index servers to match the source system configuration (.ini file parameter). You can choose how you want to distribute these index servers across the available nodes. Recover the data backup of the source database into the target database.
Note: Before the recovery is executed on the target system, SAP HANA checks whether it has been configured appropriately. All of the steps can be performed using SAP HANA studio. Current limitations: Copies from n nodes → m nodes not supported yet.
Note: For more information, see SAP-Note 1749467 – Copying SAP HANA From a Multiple- to a Single-Host
Storage Based Database Copy Storage Based Offline Database Copy
Figure 379: Storage Based Offline Database Copy
Procedure ●
While the source database is offline, create a filer snapshot of the database. This leads to two databases with the same name.
●
Rename the copy using the hdblcm utility. (Located in /usr/sap//SYS/global/hdb/install/bin/).
LESSON OVERVIEW This lesson gives an overview of the security functions in SAP HANA. Business Example Depending on the implementation scenario, the SAP HANA database facilitates the integration of different security functions. Therefore, you need an overview of the supported security functions. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Describe the security perspective in different implementation scenarios
●
Outline the security functions in SAP HANA
Security Perspective in Different Implementation Scenarios The way in which you implement SAP HANA determines what you need to consider from a security perspective.
Figure 380: Implementation Scenarios
For more information about the security-relevant information that applies to SAP HANA in the different scenarios, see the SAP HANA Security Guide.
In a data mart scenario, data is replicated from a source system, such as SAP Business Suite, into the SAP HANA database. Reporting is then carried out on the data in SAP HANA (for example, using read-only views, dashboards, and so on). Different architectures can be used in this scenario, as follows: ●
●
●
The implemented architecture determines the extent to which security-related aspects are handled in SAP HANA. Usually, at least some end users have direct access to SAP HANA. This means that user and role management in SAP HANA is not only required for technical users and administrators, but also for the end users that access SAP HANA directly. For other security aspects, such as end user authorization for views, SAP HANA security features need to be used.
Figure 382: SAP HANA in a Classic 3-Tier Architecture
SAP HANA can be used as a relational database in a classic 3-tier architecture (client, application server, and database). Security-related features, such as authentication, authorization, encryption, and auditing, are located and enforced primarily in the application server layer. The database is used as a data store only. The classic 3–tier architecture has the following features: ●
●
●
●
486
The same security model for user access applies as with other databases. End users do not have direct access to either the database itself or the database server on which it is running. Security in the database layer is mainly focused on securing administrative access to the database. Specific SAP HANA security features are mainly needed to control access of administrators to the database.
SAP HANA includes SAP HANA Extended Application Services (SAP HANA XS). SAP HANA XS embeds a full-featured application server, Web server, and development environment within SAP HANA. Applications can be deployed directly on SAP HANA XS, which exposes the applications to end users via a web interface. ●
●
The SAP HANA XS security model is directly integrated with the SAP HANA security model. Users of native SAP HANA applications have direct access to SAP HANA: Users must exist in SAP HANA. SAP HANA database privileges and additional application privileges must be assigned.
Security Functions in SAP HANA The features of security functions in SAP HANA include the following: ●
●
●
SAP HANA provides security-related features that enable you to implement different security policies and meet compliance requirements. Depending on the implementation scenario in which SAP HANA is used, only some of these features might be needed, others might be provided in other architecture layers. SAP HANA supports standard interfaces to enable integration with the customer security network and data center infrastructures.
Monitoring Security KPIs in the Security Dashboard
Figure 387: Security Dashboard
Related Information SAP HANA Security Guide http://help.sap.com/hana/SAP_HANA_Security_Guide_en.pdf SAP HANA Master Guide http://help.sap.com/hana/SAP_HANA_Master_Guide_en.pdf SAP HANA Technical Operations Manual http://help.sap.com/hana/SAP_HANA_Technical_Operations_Manual_en.pdf SAP HANA Installation Guide http://help.sap.com/hana/SAP_HANA_Installation_Guide_en.pdf SAP HANA Administration Guide http://help.sap.com/hana/SAP_HANA_Administration_Guide_en.pdf SAP HANA Update and Configuration Guide http://help.sap.com/hana/SAP_HANA_Update_and_Configuration_Guide_en.pdf SAP NetWeaver Identity Management http://help.sap.com/nwidm
LESSON OVERVIEW In this lesson, you will learn about authentication models and authorizations. Business Example The SAP HANA database facilitates the integration of different authentication methods. To integrate the SAP HANA database in your environment, you need an overview of the supported authentication methods. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the different authentication methods
User Access Channels Users are able to connect to SAP HANA via JDBC/ODBC or via HTTP/S. The protocol used for database client access (SQLDBC (ODBC/JDBC)) is used in the following scenarios: ●
Application servers that use SAP HANA as a database
●
End-user clients that access the SAP HANA database directly
●
SAP HANA studio
HTTP/S Client Access is used for a connection between a Web browser or a mobile device to applications based on SAP HANA Extended Application Services (SAP HANA XS).
Database users are created as either standard user or as restricted user. Standard users can create objects in their own schema and read data in system views. Read access to system views is granted by the PUBLIC role, which is granted to every standard user. Restricted users, initially, have no privileges. Restricted users are intended for provisioning users who access SAP HANA through client applications and who are not intended to have full SQL access via an SQL console. If the privileges required to use the application are encapsulated within an application-specific role, then it is necessary to grant the user only this role. In this way, it can be ensured that users have only those privileges that are essential to their work. Compared to standard database users, restricted users are initially limited in the following ways: ●
●
●
They cannot create objects in the database as they are not authorized to create objects in their own database schema. They cannot view any data in the database as they are not granted (and cannot be granted) the standard PUBLIC role. They are only able to connect to the database using HTTP.
For some scenarios, it might not be desirable for users to connect via JDBC/ODBC. As of SAP HANA SPS10, you can enforce that users can only connect via HTTP by disabling JDBC/ ODBC access. By default, JDBC/ODBC access is as follows: ●
Enabled for normal users
●
Disabled for restricted users
To disable or enable JDBC/ODBC access, use either SAP HANA Studio (user editor), or SQL commands.
Note: For restricted users that have been created in SAP HANA database revisions, SPS10 JDBC/ODBC is disabled by default.
Figure 390: User Management and Security in SAP HANA
Overview of Authentication Methods for SQLDBC and HTTP Access The following figure gives an overview of authentication methods for SQLDBC and HTTP access.
Figure 391: Overview of Authentication Methods for SQLDBC and HTTP Access
When using direct logon to the SAP HANA database with user name and password, the SAP HANA database authenticates the user.
Note: For some administrative operations, such as database recovery, the credentials of the SAP operating system user (adm) are also required.
Kerberos
Figure 392: Authentication via Kerberos
SAP HANA supports the Kerberos protocol for single sign-on. It has been tested with the Windows Active Directory Domain Kerberos implementation and MIT Kerberos network authentication protocol. The ODBC database client and the JDBC database client support Kerberos. To implement this, you need to install the MIT Kerberos client software on the host of the SAP HANA database. The users stored in the Microsoft Active Directory or the MIT Kerberos Key Distribution Center can be mapped to database users in the SAP HANA database. For this purpose, specify the user principal name (UPN) as the external ID when creating the database user. One Kerberos ID can only be assigned to one database user.
Note: With SPS 7, SPNEGO (Kerberos with Simple and Protected GSSAPI Negotiation Mechanism) is available as an authentication option for SAP HANA XS.
Security Assertion Markup Language (SAML) The SAP HANA database supports the login of users to the SAP HANA database using the Security Assertion Markup Language (SAML). SAML may be selected as a user authentication method when creating users in the SAP HANA studio.
SAML, Security Assertion Markup Language, is the XML-based standard for communicating identity information between organizations. The primary function of SAML is to provide Internet Single Sign-On (SSO) for organizations. SAML is used to securely connect Internet applications that exist both inside and outside the organization's firewall. SAML is a standard protocol for authentication. Generally speaking, Internet SSO is a secure connection that communicates identity and trust from one organization to another. For users, Internet SSO eliminates additional logins to external resources. For system administrators, it improves security and reduces costs. SAML requires a trusted third-party (identity provider) that can issue SAML assertions for clients (for example, a browser).
●
Single sign-on in middleware or application server scenarios (Use Cases): Whenever the application server needs to connect to the SAP HANA database on behalf of a user, it requests an SAML assertion from the client. The SAML assertion is issued by the identity provider after the client was successfully authenticated there, and is then sent to the SAP HANA database.
●
Restrictions: The SAP HANA database can only act as an SAML service provider. Assertions can be used for authentication only (no support for further properties).
SAML cannot be used for authorization. The configuration page for SAML identity providers is located in the Security editor in SAP HANA studio
Note: Formerly, this configuration page was available in the system properties. SAML in SAP HANA Studio
Figure 394: SAML In SAP HANA Studio
The main purpose of SAML for SAP HANA is to support scenarios where clients are not directly connected to the SAP HANA database, but to a middle-tier application server (XS engine, for example). This middle-tier application server runs an HTTP server. Whenever the application server needs to connect to the database on behalf of the user, it requests an SAML assertion from the client. The assertion is issued by an identity provider after the client was successfully authenticated. The assertion is then forwarded to the SAP HANA database, which will grant access based on the previously established trust to the identity provider. SAML Configuration in XS Administration SAP HANA XS includes a Web-based administration tool that enables you to configure several security-related aspects of SAP HANA XS applications, including authentication (for example, enforced authentication mechanism, trust store configuration and management, and SAML configuration).
Figure 395: SAML Configuration in XS Administration
SAP Logon Ticket and SAP Assertion Ticket Users can be authenticated in SAP HANA by logon or assertion tickets issued to them when they log on to an SAP system configured to create tickets (for example, the SAP Web Application Server or Portal). If you want to integrate an SAP HANA system into a landscape that uses SAP logon or assertion tickets for user authentication, you must configure SAP HANA to accept logon or assertion tickets. SAP HANA validates incoming logon/assertion tickets against certificates signed by a trusted Certification Authority (CA) stored in a dedicated trust store. This trust store must contain all root certificate(s) used to validate logon/assertion tickets. The user named in an incoming SAP logon ticket must exist as a database user. The database user also must be configured for authentication using logon/assertion tickets. This can be done in the user editor of the SAP HANA studio.
Note: Prior to SPS 7, SAP HANA implicitly selected both user name and password and SAP Logon Tickets as authentication methods for new users. Now you have to explicitly set authentication options for new users. To re-enable the old behavior for SAP Logon Tickets, a new configuration parameter has been introduced (Indexserver.ini -> authentication -> SapLogonTicketEnabledForNewUsers). For more information, see SAP Note 1927949. For more information about using logon tickets, see the SAP NetWeaver Library on SAP Help Portal.
Authorization All access to data and execution of actions in the database requires authorization. Every user who wants to work directly with the SAP HANA database must have a database user with the necessary authorizations.
Figure 396: Authorization Framework
After successful logon, the user's authorization to perform the requested operations on the requested objects is verified. This is determined by the privileges that the user has been granted. The user must have both the privilege to perform the operation and the privilege to access the object (for example, a table) to which the operation applies. Privileges can be granted to database users either directly, or indirectly through roles. A role is a set of privileges. Roles are the standard mechanism of granting privileges as they allow you to implement both fine-grained and coarse-grained reusable authorization concepts that can be modeled on business roles. Several standard roles are also delivered with the SAP HANA database (for example, MODELING, MONITORING). You can use these as templates for creating your own roles.
LESSON OVERVIEW In this lesson, you will learn about SSL connection encryption and data volume encryption. Business Example In order to protect against security breaches or outside attacks, companies prefer to protect the data using encryption. The encryption can done on data transfers but also on the data stored on a system. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the TLS connection encryption
●
Explain the data volume encryption
Encryption Overview
Figure 398: Encryption Overview
For the configuration of secure communication using TLS and the encryption of the persistence layer a cryptographic service provider is available on the server. SAP HANA supports the following cryptographic libraries: ●
CommonCryptoLib (default) CommonCryptoLib (libsapcrypto.so) is installed by default as part of SAP HANA server installation at $DIR_EXECUTABLE.
●
OpenSSL The OpenSSL library is installed by default as part of the operating system installation.
SAP CommonCryptoLib is the successor of SAPCRYPTOLIB and is the default cryptographic library for SAP HANA. CommonCryptoLib is installed as part of SAP HANA server installation at the default location for library lookup: /usr/sap//SYS/exe/hdb/libsapcrypto.so.
Note: The OpenSSL library is also installed as part of the operating system installation. For most use cases it is also possible to use OpenSSL instead of CommonCryptoLib. However, there are already some features in SAP HANA that are only supported by CommonCryptoLib, and future features might also only be supported by CommonCryptoLib. For more information, see SAP Note 2093286.
Secure Communication The network communication channels used by SAP HANA can be categorized into those used for database clients connecting to SAP HANA and those used for internal database communication. We recommend that you use encrypted communication channels where possible. To support the different SAP HANA scenarios and setups, SAP HANA has different types of network communication channels. Types of Network Communication Channels ● Channels used for external access to SAP HANA functionality by end-user clients, administration clients, application servers, and for data provisioning through SQL or HTTP ●
Channels used for SAP HANA internal communication within the database, between hosts in multiple-host systems, and between systems in system-replication scenarios
●
Connections used for administrative purposes
●
Connections used for data provisioning
●
Connections from database clients that access the SQL interface of the SAP HANA database
●
Connections from HTTP(S) clients
●
Outgoing connections
Network Integration You can see an example of what these connections look like in the figure, Network Integration. Network connections are depicted by dotted arrows. The direction of each arrow indicates which component is the initiator (start of arrow) and which component is the listener (end point of arrow). Administrative access to and from SAP HANA via the SAP HANA studio is depicted by the blue dotted arrows. Port numbers are shown with a pink background. The xx in the port numbers stands for the number of your SAP HANA instance. For the purposes of illustration, the figure shows a single-host installation of SAP HANA. However, the connections shown apply equally to a distributed scenario.
In addition, the different components of SAP HANA, as well as the hosts in a distributed scenario, communicate with each other via the internal SAP HANA connections. These connections are also used in system replication scenarios for communication between a primary site and a secondary site to ensure high availability in the event of a data center failure. Communications Using TLS Protocol SAP HANA supports encrypted communication for network communication channels. We recommend using encrypted channels in all cases where network attacks such as eavesdropping are not protected by other network security measures, for example, access from end-user networks. Alternatively, virtual private network (VPN) tunnels can be used for the transfer of encrypted information. The network communication can be secured using the transport layer security (TLS) protocol: The network communication can be secured using the transport layer security (TLS) protocol. ●
●
●
●
Communication between the SAP HANA database and clients that access the SQL interface of the database. Internal network communication between the individual components of an SAP HANA system on a single host and also between multiple hosts if the system is distributed. For Client Application Access, the SAP Web Dispatcher can be configured to use HTTPS (TLS) for incoming requests from UI front ends and applications, for example, SAP HANA applications. The requests are then forwarded to SAP HANA. Communication between the SAP HANA Software Update Manager and SAP HANA Studio, SAP Service Marketplace, and SAP Host Agent.
Communication between SAP HANA Studio and sapstartsrv.
●
Communication between SAP HANA Studio and SAP Host Agent.
Figure 400: Required Certificates
Certificates Store As of SAP HANA SPS10 certificates can be stored and managed directly in the SAP HANA database. SAP HANA uses X.509 certificates for securing communication channels and for several user authentication mechanisms.
Certificate Management using SAP HANA Cockpit Certificates in the database can be managed using SAP HANA Cockpit or SQL. There are certificates that are managed in the file system, for example, TLS/SSL for HTTP, and TLS/SSL for internal communication (automatic setup viaSystemPKI). These cannot be managed using the SAP HANA Cockpit functionality. Simplified configuration for these scenarios is achieved by other means (SystemPKI).
The procedure for TLS Configuration for the SAP HANA Studio is as follows: 1. In the SAP HANA studio, choose Add System... in the navigator tree. 2. Enter your user credentials and select Connect using TLS. 3. Select whether you want to validate the certificate and whether you want to also check the host name in the certificate. 4. All connections from the SAP HANA studio to the database will now be encrypted.
Note: The procedure of configuring TLS is described in detail in the SAP HANA Security Guide. Automatic Generation of PKI/Certificates for Internal Communication Channels The following internal communication channels can be secured: ●
Between databases in a multiple-container system; Note: For MDC system currently only encryption is available (but not tenant authentication)
●
Between hosts in a scale-out system (also: between processes in a single-host system)
●
Between SAP HANA systems in system replication scenarios (metadata + data channel)
●
Between the SAP HANA database and additional server components, such as an extended storage server (SAP HANA dynamic tiering option) and smart data streaming server (SAP HANA Smart Data Streaming option).
The features of the keys and certificates used by the system PKI include the following: ●
●
Each component (host, database, additional server, and so on) receives a public/private key pair and a public-key certificate for mutual authentication. The certificates are signed by a dedicated trusted certificate authority (CA), which is unique for each SAP HANA system.
●
The certificates are renewed automatically.
●
CommonCryptoLib is used as the cryptographic library.
Depending on the communication channel, you may need to enable TLS explicitly.
Note: For migration from manual system SSL configuration to SystemPKI, see SAP Note 2175672
Data Volume Encryption The SAP HANA database holds the bulk of its data in memory for maximum performance, but it still uses persistent disk storage to provide a fallback in case of failure. Data is saved from memory to disk automatically at regular savepoints. The data belonging to a savepoint represents a consistent state of the data on disk and remains so until the next savepoint operation has completed. After a power failure, the database can be restarted as any diskbased database, and returns to its last consistent state. Data volume encryption ensures that anyone who can access the data volumes on disk using operating system commands cannot see the actual data. If data volumes are encrypted, all pages that reside in the data area on disk are encrypted using the AES-256-CBC algorithm. Pages are transparently decrypted as part of the load process into memory. When pages reside in memory, they are, therefore, not encrypted and there is no performance overhead for in-memory page accesses. When changes to data are persisted to disk, the relevant pages are encrypted automatically as part of the write operation. Pages are encrypted and decrypted using 256-bit persistence encryption page keys. Page keys are valid for a certain range of savepoints and can be changed by executing SQL statements. After persistence encryption has been enabled, an initial page key is generated automatically. Page keys are never readable in plain text, but are encrypted themselves using a dedicated persistence encryption root key. During start-up, administrator interaction is not required. The root key is stored using the SAP NetWeaver secure storage in the file system (SSFS) functionality and is automatically retrieved from there. SAP HANA uses SAP NetWeaver SSFS to protect the root encryption keys that are used to protect all encryption keys used in the SAP HANA system from unauthorized access.
Non-encrypted Data The persistence encryption feature does not encrypt the following data: ●
Database redo log files If database redo log files need to be protected, we recommend that you use operating system facilities, such as encryption at the file system level.
●
Database backups In general, the contents of database backups are not encrypted. Only data that has been encrypted internally in the database (that is, independently of the persistence encryption feature) remains encrypted in backups.
●
Database traces For security reasons, we recommend that you do not run the system with extended tracing for more than short-term analysis since tracing might expose security-relevant data that would be encrypted in the persistence layer, but not in the trace. Therefore, you should not keep such trace files on disk beyond the respective analysis task.
Note: If encryption of backups is required, we recommend that you use third-party solutions that integrate with the Backint for SAP HANA functionality for backups.
Configure Data Volume Encryption Data volume encryption on disk can be configured using SAP HANA studio or SQL commands. After activating encryption, new data that is saved to disk will be encrypted starting with the next savepoint. Due to the shadow memory nature of SAP HANA persistence, outdated versions of pages may still remain unencrypted on disk.
Caution: To achieve complete protection it is necessary to enable data volume encryption after re-installing the system. Only after this process has completed is all your data encrypted. This also ensures that a new root encryption key is generated. You can monitor the encryption progress in SAP HANA studio.
Figure 407: Configure Data Volume Encryption using SAP HANA studio
The page encryption key for the data volume encryption could also be changed using SAP HANA Studio. After a change of the page encryption key, you can choose whether you also want to reencrypt existing encrypted data with the new key (this will happen in the background).
SSFS Encryption Keys SAP HANA uses the secure storage in the file system (SSFS) to securely store the root encryption keys used to protect all encryption keys used in an SAP HANA system. The encrypted storage of the data prevents unauthorized persons or programs being able to access this data. These are the root encryption keys for the following: ●
Data volume encryption
●
Internal data protection API (DPAPI).
Note: DPAPI is used by the secure internal credential store, which is needed in some scenarios such as smart data access to securely store additional user credentials (for example, for access to remote systems)
The page encryption keys used for data volume encryption are encrypted themselves with the data volume encryption root key. The root key is generated randomly during installation. The page keys are created when data volume encryption is enabled. This secure store, which is used by SAP HANA to store internal root keys is protected by the so called SSFS master key. In order to support automatic unattended start-up of HANA system, the key store and the SSFS master key is stored on the file system, protected by operating system permissions (operating system access with the adm operating system user is required).
Figure 408: Encryption Keys Used in SAP HANA
Caution: The initial default master keys are changed during installation or update. If you received your system pre-installed from a hardware or hosting partner, we recommend that you change them immediately after handover to ensure that they are not known outside of your organization. An administrator can change the SSFS master key using the command line tool rsecssfx using the credentials of the operating system user adm. Therefore the SAP HANA system has to be stopped. For special scenarios like snapshot based backup/restore or system replication, see SAP Note 2194396.
Note: Prior to SPS11, the automatic master key change is available starting with SAP HANA revisions 85.05, 97.01 and 101. For earlier versions of SPS 8, 9, and 10, manual steps are required to change the master keys. The options on how to change the initial key are described in the security guide (see SAP HANA Security Guide, and SAP Note 2183624).
Configure Data Volume Encryption using the Security editor in SAP HANA Studio. 1. Activate Data Volume Encryption 2. Monitor the progress of the data volume encryption.
Configure Data Volume Encryption using the Security editor in SAP HANA Studio. 1. Activate Data Volume Encryption a) In the Systems view in SAP HANA studio, choose Security and open the Data Volume Encryption tab. b) Choose Encrypt data volumes. c) Choose the Deploy button. 2. Monitor the progress of the data volume encryption. a) Choose the Refresh button to monitor the status of the data volume encryption. During encryption the status Encryption running ... is displayed. The status Encrypted indicates that the data volumes are encrypted.
LESSON OVERVIEW This lesson covers the audit logging infrastructure. Business Example Many regulatory requirements require audit logging. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the audit logging infrastructure
Auditing Overview The auditing feature of the SAP HANA database allows you to monitor and record selected actions performed in your system. In other words, it provides you with visibility on who did what (or tried to do what) and when.
Figure 410: Audit Logging – Introduction
The auditing feature of the SAP HANA database allows you to track actions performed in the database: who did what (or tried to do what), and when. SAP HANA provides audit actions for
critical security events and for access to sensitive data. Both successful and unsuccessful events can be logged. In the case of logging of successful and unsuccessful events, one has to specify, for each audit policy, if successful events, unsuccessful events, or both will be audited. Audit logging is not enabled by default. Audit Logging – Infrastructure
Figure 411: Audit Logging – Infrastructure
When an audit policy is triggered, that is, when an action in the policy occurs under the conditions defined in the policy, an audit entry is created in one or more audit trails. The following audit trail targets are supported for production systems: ●
Linux syslog -
●
Database table -
520
The logging system of the Linux operating system (syslog) is a secure storage location for the audit trail because not even the database administrator can access or change it. There are also numerous storage possibilities for the syslog, including storing it on other systems. In addition, the syslog is the default log daemon in UNIX systems. The syslog therefore provides a high degree of flexibility and security, as well as integration into a larger system landscape. For more information about how to configure syslog, refer to the documentation of your operating system.
Using an SAP HANA database table as the target for the audit trail makes it possible to query and analyze auditing information quickly. It also provides a secure and tamperproof storage location.
Internal column store table in the _SYS_AUDIT schema of the SAP HANA database Audit entries are only accessible through the public system view AUDIT_LOG. Only SELECT operations can be performed on this view by users with system privilege AUDIT ADMIN or AUDIT OPERATOR To avoid the audit table growing too large, it is possible to delete old audit entries
Note: For test purposes in non-production systems, you can also use a CSV text file as the audit trail. A separate CSV file is created for every service that executes SQL.
Hint: Multiple audit trail targets could be configured for different audit levels and per audit policy. ●
●
●
System-wide default: Audit entries are written to the audit trail target(s) configured for the system if no other trail target has been configured per audit level Audit level (optional): Audit entries from audit policies with the audit level EMERGENCY, CRITICAL, or ALERT are written to the specified audit trail target(s). If no audit trail target is configured, entries are written to the audit trail target configured for the system. Audit policy (optional): Audit entries from a particular policy are written to the specified audit trail target or targets. If no audit trail target is configured for an audit policy, entries are written to the audit trail target for the audit level if configured, or the audit trail target configured for the system. Several audit trail targets are configurable for each individual policy.
Hint: Only actions that take place inside the database engine can be audited. If the database engine is not online when an action occurs, it cannot be detected and, therefore, cannot be audited. These actions are, for example, an upgrade of an SAP HANA database instance or direct changes to system configuration files using operating system commands. If auditing is active, certain actions are always audited and are therefore not available for inclusion in user-defined audit policies. In the audit trail, these actions are labeled with the internal audit policy MandatoryAuditPolicy. Mandatory audit actions include the following: ●
Creation, modification, or deletion of audit policies
●
Deletion of audit entries from the audit trail This only applies if audit entries are written to column store database tables.
●
Changes to auditing configuration, that is: -
Enabling or disabling auditing
-
Changing the audit trail target
-
Changing the location of the audit trail target if it is a CSV text file
Activation of Audit Policies Auditing is implemented through the creation and activation of audit polices. An audit policy defines the actions to be audited, as well as the conditions under which the action must be performed to be relevant for auditing. For example, actions in a particular policy are audited only when they are performed by a particular user on a particular object. When an action occurs, the audit policy is triggered and an audit event is written to the audit trail. The following slides give an overview how to configure and switch on audit logging.
An audit policy can specify any number of actions to be audited. Not all actions can be combined together in the same policy, therefore compatible audit actions have been grouped together. When you select an action, those actions that are not compatible with the selected action become unavailable for selection. If you need two audit incompatible audit actions, you need to create two separate audit policies. In addition to the actions to be audited, an audit policy specifies additional parameters that further narrow the number of events actually audited, as follows:. ●
●
●
Audited action status -
On successful execution
-
On unsuccessful execution
-
On both successful and unsuccessful execution
Target object or objects -
Tables
-
Views
-
Procedures
Audited user or users -
●
Individual users can be included or excluded from an audit policy
Audit level -
EMERGENCY
-
ALERT
-
CRITICAL
-
WARNING
-
INFO
When an audit policy is triggered, that is, when an action in the policy occurs under the conditions defined in the policy, an audit entry is created in the audit trail. Firefighter logging logs all actions performed by a specific user. This covers not only all actions that can be audited individually, but also actions that cannot otherwise be audited. Such a policy is useful if you want to audit the actions of a particularly privileged user.
Note: Some actions cannot be audited using database auditing even with a policy that includes all actions, in particular, system restart and system recovery.
Caution: Firefighter logging may generate a lot of audit entries, so only enable it if required.
Viewing the Audit Trail Using an SAP HANA database table as audit trail target makes it possible to query and analyze auditing information quickly. It provides a secure and tamper-proof storage location. Audit entries are only accessible through the public system view AUDIT_LOG. This view is read-only, old entries can only be deleted from the underlying internal table via a dedicated command by a user with system privilege AUDIT OPERATOR.
Figure 415: Viewing the audit trail
Monitor the Size of the Audit Trail Table If the audit trail is written to an internal SAP HANA table, you need to manage the size of this table. In order to support administrators to monitor database growth, an alert has been implemented for the size of the audit trail table. SAP HANA monitors the size of the audit table with respect to the overall memory allocation limit of the system and issues an alert when it reaches the following (default) values: 5%, 7%, and 9% of the allocation limit
Note: This alert only applies if database table was selected as audit trail target (not for syslog). You can delete old audit entries from the audit table using SAP HANA Studio.
Caution: If however the table has grown so large that there is not enough memory for deleting old entries, you can now use the following SQL command to completely empty the table: ALTER SYSTEM CLEAR AUDIT LOG ALL Example for Setting up an Audit Policy using SQL The figure, Audit Policy Example, shows an example for setting up an audit policy using an SQL statement. It also shows what the audit logging output (audit trail written via Linux syslog) looks like.
Note: For creating and activating the audit policy you need root-authorization! Column header names are currently not written to the audit trail, they need to be added manually: An audit entry appears as follows: ;;;;;;;;;;;;;;;;;;;;;;;;;;;; For more information, see the SAP HANA Security Guide at http://help.sap.com/hana
Figure 418: Monitor Audit Logging Status and Check Policies
The Auditing tile in the security dashboard in SAP HANA Cockpit allows you to view the audit logging status, and check which audit policies are active.
Business Example Enable audit logging and activate an audit policy, which records read access on table PRODUCTS and an audit policy, which records system configuration changes. Use Database Table as audit trail target. Then perform a select on table PRODUCTS and check the resulting entry in the audit trail. 1. Enable audit logging and use Database Table as audit trail target. 2. Activate an audit policy, which records read access on table PRODUCTS. 3. Activate an audit policy, which records system configuration changes. 4. Perform a select on table PRODUCTS and check the resulting entry in the audit trail.
Business Example Enable audit logging and activate an audit policy, which records read access on table PRODUCTS and an audit policy, which records system configuration changes. Use Database Table as audit trail target. Then perform a select on table PRODUCTS and check the resulting entry in the audit trail. 1. Enable audit logging and use Database Table as audit trail target. a) In the Systems view in SAP HANA studio, choose Security and open the Auditing tab. b) Choose Enabled for the auditing status and Database Table for the audit trail target. c) Choose the Deploy button. 2. Activate an audit policy, which records read access on table PRODUCTS. a) In the Systems view in SAP HANA studio, choose Security and open the Auditing tab. b) Select the Audit Policies tab and click +. c) Enter a name for the audit Policy (for example, READ ACCESS) d) Select the Audited Actions tab. e) Choose the “....” button to open the Edit Actions ... dialog. f) Choose Data Query and Manipulation → SELECT for audited actions. g) Exclude user _SYS_REPO from the audit policy. h) Select the Users tab. i) Choose the “....” button to open the Select Users dialog. j) Select user _SYS_REPO and choose Add. k) Choose Exclude selected users from policy and choose OK. l) Select the PRODUCTS(TRAIN##) table for auditing. m) Select the Target Object tab. n) Select the PRODUCTS(TRAIN##) table and choose Add. o) Choose OK. p) Choose the Deploy button. 3. Activate an audit policy, which records system configuration changes. a) In the Systems view in SAP HANA studio, choose Security and open the Auditing tab.
b) Select the Audit Policies tab and click +. c) Enter a name for the audit Policy (for example, CONFIG CHANGES) d) Select the Audited Actions tab. e) Choose the “....” button to open the Edit Actions ... dialog. f) Choose Session Management and System Configuration → SYSTEM CONFIGURATION CHANGE for audited actions g) Choose the Deploy button. 4. Perform a select on table PRODUCTS and check the resulting entry in the audit trail. a) Right-click the SAP HANA system, which uses the ‘SYSTEM’ user for connection and select SQL Console. b) Enter the following sql command to create a schema and execute by clicking on a little white arrow in a green circle (F8 – Execute): select * from “TRAIN##”. “PRODUCTS” c) To check the resulting entry in the audit trail (database table), enter the following sql command: select TIMESTAMP, USER_NAME, AUDIT_POLICY_NAME, STATEMENT_STRING from “PUBLIC”. “AUDIT_LOG”
Lesson 5 Information Sources for Administrators Exercise 21: Maintaing Administrative Users and Authorization Exercise 22: Optional: Maintain Users and Authorization
581 585 593
Lesson 6 SAP HANA Live Authorization Assistant
602
UNIT OBJECTIVES ●
Explain how to handle user management and user provisioning
LESSON OVERVIEW In this lesson, you will learn about creating and managing users and roles. Business Example The users of the SAP HANA database require their own user with appropriate authorizations to log on. The administrator sets up a user ID in the system for each user. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain how to handle user management and user provisioning
●
Explain the user and role concept in SAP HANA
●
Explain how to maintain users' roles
●
Explain how to maintain SAP HANA privileges
User Management and Security in SAP HANA
Figure 419: User Management and Security in SAP HANA
Why is a security concept in SAP HANA required? ●
The simple reasons are as follows: -
Database administration should be restricted to skilled (and empowered) person.s
A more important reason security is that user administration plays a big role in SAP HANA, which means the following: -
-
-
●
Editing of SAP HANA data models should only be possible for “owners” of the model.
Several front-end tools offer direct access into SAP HANA. Object access as well as access to content of data model must be controlled within SAP HAN.A There is a need to have named users in SAP HANA for Information Consumers.
An exception to the security concept is when there is no user management for Information Consumers required, which is the case in the following situations: -
-
Access to data does not need to be controlled All data access occurs via BI Semantic Layer and Security implemented in BusinessObjects Enterprise
Relationships Between Entities
Figure 420: Relationships Between Entities
Privileges can be assigned to users directly or indirectly using roles. Privileges are required to model access control. Roles can be used to structure the access control scheme and model reusable business roles. It is recommended to manage authorization for users by using roles. Roles can be nested so that role hierarchies can be implemented. This makes them very flexible, allowing very fineand coarse-grained authorization management for individual users. All the privileges granted directly or indirectly to a user are combined. This means whenever a user tries to access an object, the system performs an authorization check using the user, the user's roles, and directly allocated privileges. It is not possible to explicitly deny privileges. This means that the system does not need to check all the users roles. As soon as all requested privileges have been found, the system aborts the check and grants access.
Several predefined roles exist in the database. Some of them are templates that need to be customized; others can be used as they are. User Administration Tools User management is configured using the SAP HANA studio. No replication of existing authorizations from source system.
Figure 421: User Administration Tools
By using SQL requests, for example, all the user management functions can also be executed from the command line. This is useful when using scripts for automated processing. SAP NetWeaver Identity Management provides additional support for user provisioning in the SAP HANA database. The SAP NetWeaver Identity Management 7.2 SP 3 contains a connector to the SAP HANA database (IDM connector). With The SAP NetWeaver Identity Management, you can perform the following actions in the SAP HANA database: ●
Creating and deleting user accounts
●
Assigning roles
●
Setting passwords for users
For more information about the SAP NetWeaver Identity Management and the IDM connector, see the SAP Community Network at http://www.sdn.sap.com → SAP NetWeaver Releases. The SAP HANA Web IDE contains a user editor and a catalog role editor for scenarios where only web-based tools are available.
Hint: The SAP.HANA.XS.IDE.ROLES::SECURITYADMIN role is required for the Web IDE scenario. For the SAP HANA Cockpit, in addition, the SAP.HANA.ADMIN.ROLES::MONITORING role is required. User Types It is often necessary to specify different security policies for different types of users. In the SAP HANA database, we differentiate between the following user types: ●
Database users that correspond to real people The database administrator creates a database user for every person who needs to work in the SAP HANA database. Database users that correspond to real people are dropped when the person leaves the organization. This means that database objects that they own are also automatically dropped, and privileges that they granted are automatically revoked.
●
Technical database users Technical database users do not correspond to real people. They are therefore not dropped if a person leaves the organization. This means that they should be used for administrative tasks such as creating objects and granting privileges for a particular application. Some technical users are available as standard, for example, the users SYS and _SYS_REPO. Other technical database users are application-specific. For example, an
application server may log on to the SAP HANA database using a dedicated technical database user.
Note: All user names can now contain Unicode characters.
Figure 423: User Types
Technically, these user types are the same. The only difference between them is conceptual. Database users that correspond to real people can be grouped according to different tasks. User Tasks
Figure 424: User Tasks
The user and role concept of the SAP HANA database allows for a fine granularity of access control based on the users' tasks, for example: ●
Business end users reading reports using client tools, for example, Microsoft Excel.
●
Modelers creating models and reports using the SAP HANA studio.
●
Database administrators operating and maintaining the database and users using the SAP HANA studio.
When accessing the SAP HANA database using a client interface (such as ODBC, JDBC, MDX), any access to data must be backed by corresponding privileges. Different schemes are implemented. On a higher level, this concept provides authorization for the data contained in the database when it is accessed using client interfaces. In the SAP HANA database system, the regular SQL authorization concept is implemented. For each SQL statement type (for example, SELECT, UPDATE, and CALL), a corresponding privilege exists that the executing user needs to have. Additionally, objects in the database (such as tables, views, or stored procedures) have an owner who can access the objects and grant privileges for them. No user, besides the owner of an object and users that the owner has provided with a privilege, can access this particular object. This authorization functions on the object level, whereby the smallest entities that can be privileged are, for example, a table or a view. In addition, analytic privileges are used to provide row-level authorization on certain kinds of database objects, such as analytic views.
The process flow for user management is as follows: ●
Define and create privileges
●
Define and create roles Use the SAP HANA studio or run the following SQL statement: CREATE ROLE
●
Assign privileges to roles
●
Create users -
Choose authentication methods: Define the initial password Or define the external User ID (for example, Kerberos to set up SSO)
-
Other user settings
Define default client is used as an implicit filter value when reading from SAP HANA data models. This To assign roles to users, use the SAP HANA studio or run the following SQL statement: GRANT TO To revoke roles, you can use the following SQL statement: REVOKE FROM
Standard Users Installation, Upgrade and Operation
Figure 427: Standard Users Installation, Upgrade and Operation
For installing, upgrading, and operating the SAP HANA database, the following standard users are necessary: Database Users When you install the SAP HANA database, a database user, called SYSTEM, is created by default. The database user SYSTEM has irrevocable system privileges, such as the ability to create other database users, access system tables, and so on.
Note: For security reasons, it is highly recommended that you do not use user SYSTEM for day-today activities. Use SYSTEM to create administration users with the minimum privilege set required for their duties, and use those users for day-to-day administrative activities. Several “internal database users” are also created, such as SYS and _SYS_STATISTICS. These users cannot log on to the SAP HANA database. Operating System User In addition to the SAP HANA database user SYSTEM, the installation process also creates an external operating system user adm (for example, sp1adm or xyzadm). This operating system user, referred to here as the operating system administrator, simply exists to provide an operating system context. From the operating system perspective, the operating system administrator is the user that owns all SAP HANA files and all related operating system processes. Within the SAP HANA studio, the operating system administrators credentials are required, for example, to start or stop database processes or to execute a recovery. The operating system administrator is not an SAP HANA database user. For installation and upgrade, the ROOT user is used. Do not use the Root user for day-to-day activities.
LESSON OVERVIEW In this lesson, you will learn about authorization, object privileges, SYSTEM privileges, package privileges, analytic privileges, and application privileges. Business Example The authorization concept is based on different types of privileges. To grant the users the right privileges, a sound understanding of the different types of privileges is necessary. LESSON OBJECTIVES After completing this lesson, you will be able to:
When accessing the SAP HANA database using a client interface (such as ODBC, JDBC, MDX), any access to data must be backed by corresponding privileges. Different schemes are implemented, as follows: System Privileges Authorize execution of administrative actions for the entire SAP HANA database. System Privileges are assigned to users and roles. Object Privileges Authorize access to data and operations on database objects. Used to restrict access to and modification of database objects, such as tables. Depending on the object type (for example, table, view), actions (for example, CREATE ANY, ALTER, DROP) can be authorized per object. For object privileges in the SAP HANA database, the SQL standard behavior is applied. Object privileges are assigned to users and roles. Analytic Privileges Analytic privileges grant different users access to different portions of data in the same view based on their business role. Authorize read access to analytic, attribute, and calculation views at runtime and provide row-level access control based on the dimensions of the relevant view. Only applied at the processing time of the user query.
Analytic Privileges need to be defined and activated before they can be granted to users and roles. Package Privileges Authorize access in the repository (modeling environment) at design time. Used to restrict the access to and the use of packages in the repository of the SAP HANA database. Packages contain design-time versions of various objects, such as Analytic, Attribute, and Calculation Views, as well as Analytic Privileges, and functions. To be able to work with packages, the respective Package Privileges must be granted. Application Privileges Authorize access to SAP HANA XS application functions. Privileges on Users Privileges on users are SQL privileges that users can grant on their user. A user can allow other users to debug SQLScript code (for example, a procedure) that is being executed by the user. . SQL Privilege
Figure 429: SQL Privilege
Object Privilege activities also include the following: ●
This privilege allows the creation of all kinds of objects, in particular, tables, views, sequences, synonyms, SQL script functions or database procedures in a schema. This privilege can only be granted on a schema. ●
ALL PRIVILEGES This is a collection of all DDL and data manipulation language (DML) privileges that on the one hand, the grantor currently has and is allowed to grant and on the other hand, can be granted on this particular object. This collection is dynamically evaluated for the given grantor and object. ALL PRIVILEGES is not applicable to a schema, but only a table, view, or table type.
●
DROP and ALTER These are DDL privileges and authorize the DROP and ALTER SQL commands. While the DROP privilege is valid for all kinds of objects, the ALTER privilege is not valid for sequences and synonyms as their definitions cannot be changed after creation.
●
SELECT, INSERT, UPDATE, and DELETE These are DML privileges and authorize respective SQL commands. While SELECT is valid for all kinds of objects, except for functions and procedures, INSERT, UPDATE, and DELETE are only valid for schemas, tables, table types, and table views.
●
INDEX This special DDL privilege authorizes the creation, alteration, or revocation of indexes for an object using the CREATE INDEX, ALTER INDEX, and DROP INDEX commands. This privilege can only be applied to a schema, table, and table type.
●
EXECUTE This special DML privilege authorizes the execution of an SQL script function or a database procedure using the CALLS or CALL command, respectively.
As shown in the figure, System Privilege, the system privileges available on SAP HANA Database are the following: ●
Users and Roles, which include the following: -
USER ADMIN This privilege authorizes the creation and changing of users using the CREATE USER, ALTER USER, and DROP USER SQL commands.
-
ROLE ADMIN This privilege authorizes the creation and deletion of roles using the CREATE ROLE and DROP ROLE SQL commands. It also authorizes the granting and revocation of roles using the GRANT and REVOKE SQL commands.
●
Catalog and Schema Management, which include the following: -
CREATE SCHEMA This privilege authorizes the creation of database schemas using the CREATE SCHEMA SQL command.
-
DATA ADMIN This privilege authorizes all users to have unfiltered read-only access to the full content of all system and monitoring views as well as to execute all data definition language (DDL) – and only DDL – commands in the SAP HANA database. Normally, the content of those views is filtered based on the privileges of the user.
CATALOG READ This privilege authorizes all users to have unfiltered read-only access to the full content of all system and monitoring views. Normally, the content of those views is filtered based on the privileges of the accessing user.
●
System Management These privileges authorize the various system activities that can be performed using the ALTER SYSTEM SQL commands. Because of the high level of impact on the system, these privileges are not designed for a normal database user. Caution must be taken when granting these privileges (for example, only grant them to a support user or role.)
●
Data Import and Export The following System Privileges are available for the authorization of the data import and export in the database: -
IMPORT This privilege authorizes the import activity in the database using the IMPORT or LOAD TABLE SQL commands. Note that, besides this privilege, the user needs the INSERT privilege on the target tables to be imported.
-
EXPORT This privilege authorizes the export activity in the database via the EXPORT or LOAD TABLE SQL commands. Note that, besides this privilege, the user needs the SELECT privilege on the source tables to be exported.
Appendix: Privileges for Administrative Tasks This appendix is an overview of the privileges that database users require to perform particular database operations in the Administration Editor.
Figure 431: Appendix: Privileges for Administrative Tasks I
Figure 432: Appendix: Privileges for Administrative Tasks II
Note: If a user with system privilege CATALOG READ is also the owner of the table, they can also move the table without object privilege ALTER. Client-side export or import of catalog objects and data is now possible without the system privilege EXPORT/IMPORT. To be able to export/import a database object on the client side, the relevant object privileges for that object are required: ●
●
For export, the SELECT privilege is required. For import, depending on the form of the import, INSERT/UPDATE, DROP, CREATE privileges are required.
Hint: The EXPORT/IMPORT system privileges still exist. However, they are very powerful and should only be assigned to users who need to do exports/imports that involve the file system of the server on which the SAP HANA database is running.
Packages contain design-time versions of various objects, such as Analytic, Attribute, and Calculation Views, as well as Analytic Privileges, and functions. To be able to work with packages, the respective package Privileges must be granted. The SAP HANA database repository is structured hierarchically with packages assigned to other packages as subpackages. If you grant privileges to a user for a package, the user is automatically also authorized for all corresponding subpackages.
Analytic privileges are used in the SAP HANA database to provide fine-grained control of what data particular users can see for Analytic use. They provide the ability for row-level authorization, based on the values in one or more columns. All Attribute Views, Analytic Views, and Calculation Views, which have been designed in the modeler and have been activated from the modeler of the HANA studio, are automatically supported by the Analytic Privilege mechanism. If you are already familiar with the authorization model of SAP NetWeaver Business Warehouse (SAP NetWeaver BW), you will see many similarities between the two models. The overall idea behind analytic privileges is the reuse of Analytic Views by different users. However, the different users may not be allowed to see the same data. For example, different regional sales managers, who are only allowed to see sales data for their regions, could reuse the same Analytic View. They would get the analytic privilege to see only data for their region, and their queries on the same view would return the corresponding data. This is a major difference to the SAP NetWeaver BW model. While the concept is very similar, SAP BW would forward an error message if you executed a query that would return values you are not authorized to see. With the SAP HANA database, the query would be executed and, corresponding to your authorization, only values you are entitled to see returned. Restrictions for Analytic Privileges An analytic privilege consists of several restrictions. Three of these restrictions are always present and have the following special meanings: ●
●
556
One restriction (cube restriction) determines for which column views (Attribute, Analytic, or Calculation Views) the privilege is used. This may involve a single view, a list of views or, by means of a wildcard, all applicable views. One restriction (activity restriction) determines the effected activity, for example, READ. This means that the activity READ is restricted and not available for use.
One restriction (validity restriction) determines at what times the privilege is valid.
In addition to these three restrictions, many additional dimension restrictions are used. These are applied to the actual attributes of a view. Each dimension restriction is relevant for one dimension attribute, which can contain multiple value filters. Each value filter is a tuple of an operator and its operands, which is used to represent the logical filter condition. For example, a value filter (EQUAL 2006) can be defined for a dimension attribute YEAR in a dimension restriction to filter accessible data using the condition YEAR = '2006' for potential users. Only dimension attributes, and no measures or key figures, can be employed in dimension restrictions. The conditions that control which data users see is either contained in an XML document or defined using SQL. As of SAP HANA SPS 10 SQL-based analytic privileges can also be created as design-time objects
Note: For new projects SQL-based analytic privileges are recommended. Management for Analytic Privileges Table 16: Management for Analytic Privileges Feature
SQL-Based
XML-Based
Control of read-only access to information models: attribute views, analytic views, calculation views
Yes
Yes
Control of read-only access to SQL views
Yes
No
Control of read-only access to database tables
No
No
Design-time support
Yes
Yes
Transportable
Yes
Yes
Design-time modeling in SAP Web IDE (Editor view) and SAP HANA studio (Modeler perspective)
In general, the user has access to an individual, independent view (Attribute, Analytic, or Calculation View) if the following prerequisites are met: ●
●
The user was granted the SELECT privilege on the view or the containing schema. The user was granted an analytic privilege that is applicable to the view. An analytic privilege is applicable to a view if it contains the view in the Cube restriction and contains at least one filter on one attribute of this view.
No SELECT privilege on the underlying base tables or views of this view is required. Implement row-level security with analytic privileges ●
558
Restrict access to a given data container to selected attribute values -
Select relevant views to which the analytic privilege is applicable: -
Attribute Views
-
Analytic Views
-
Calculation Views
Select applicable information models -
-
Views have two functions in privilege ■
Views you want to grant access to
■
Views from which you want to select fields for restrictions
You can add further views to the privilege later.
Analytic Privilege-Capable Views The Analytic Privilege mechanism is automatically enforced for all three kinds of views that can be defined using the information modeler, namely Attribute, Analytic, and calculation Views: ●
●
Attribute Views These views are built on joins of existing column tables and views. Attribute Views cannot be nested in other Attribute Views. Analytic Views These views are multidimensional cubes with a fact table joined with multiple dimension tables. The information modeler allows Analytic Views to be associated with Attribute Views to reuse the specified join paths. However, it is not possible to use
existing Attribute or Analytic Views as base views (join candidates) and use these as the basis for defining new Analytic Views. ●
Calculation Views These views are defined using SQL script. A Calculation View is a column view defined on the output of a SQL script function. In this function, any existing views, including Attribute, Analytic, and Calculation Views, can be used, for example, in a SELECT statement. This introduces interdependencies between the views.
As of SPS 06, dynamic analytic privileges can be created in the SAP HANA studio (Modeling perspective). Repository/catalog procedures can be added to the filter list of analytic privileges. Dynamic analytical privileges provide a flexible approach for specifying user-specific filter conditions. The filter conditions are obtained by SAP HANA at runtime from a database procedure, which can contain complex logic. This makes it possible to reuse the same analytical privilege for many users.
Application Privilege Developers of SAP HANA XS applications can create application privileges to authorize user and client access to their application. These privileges authorize user and client access to the application, for example to start the application or to perform administrative actions in the application. Application privileges are granted and revoked through the procedures GRANT_APPLICATION_PRIVILEGE and REVOKE_APPLICATION_PRIVILEGE procedure in the _SYS_REPO schema. Application privileges can be granted to users or roles in runtime in the SAP HANA studio. However, it is recommended that you grant application privileges to roles created in the repository. Application privileges can be granted or revoked in the SAP HANA studio.
Privileges on Users Privileges on users are SQL privileges that users can grant to other users. ATTACH DEBUGGER is the only privilege that can be granted on a user. For example, User A can grant User B the privilege ATTACH DEBUGGER to allow User B debug SQLScript code in User A's session. User A is only user who can grant this privilege.
Note: User B also needs the object privilege DEBUG on the relevant SQLScript procedure. It is not possible to grant the ATTACH DEBUGGER privilege on behalf of other users
LESSON OVERVIEW This module covers the following topics: Predelivered role Template role Support role Some specific roles will note be detailed in this lesson as it is more related to business specific roles.
Business Example For special tasks, standard roles are delivered. You need to know in which cases you can use these roles. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the purpose of the predelivered roles
●
Explain what a template role is
●
Explain the purpose of the support role
Overview of Roles A role is a collection of privileges that can be granted to either a user or another role in runtime. A role typically contains the privileges required for a particular function or task, for example: ●
Business end users reading reports using client tools
●
Modelers creating models and reports in the modeler of the SAP HANA studio
●
Database administrators operating and maintaining the database and the users
Privileges can be granted directly to users of the SAP HANA database. However, roles are the standard mechanism of granting privileges because they allow you to implement complex, reusable authorization concepts that can be modeled on business roles. Several standard roles are delivered with the SAP HANA database (for example, MODELING, MONITORING). You can use these as templates for creating your own roles. A role can contain any number of the following privileges: ●
562
System privileges for administrative tasks (for example, AUDIT ADMIN, BACKUP ADMIN, CATALOG READ)
Object privileges on database objects (for example, SELECT, INSERT, UPDATE)
●
Analytic privileges on SAP HANA information models
●
●
Package privileges on repository packages (for example, REPO.READ, REPO.EDIT_NATIVE_OBJECTS, REPO.ACTIVATE_NATIVE_OBJECTS) Application privileges for enabling access to SAP HANA XS applications
Types of Roles Roles in the SAP HANA database can exist as runtime objects only, or as design-time objects in the repository of the SAP HANA database that become runtime objects on activation.
Figure 437: Types of Roles
We recommended that you model roles as design-time objects for the following reasons: Firstly, unlike roles created in runtime, roles created as design-time objects can be transported between systems. This is important for application development because it means that developers can model roles as part of their application's security concept and then ship these roles or role templates with the application. Being able to transport roles is also advantageous for modelers implementing complex access control on analytic content. They can model roles in a test system and then transport them into a productive system. This avoids unnecessary duplication of effort. Secondly, roles created as design-time objects are not directly associated with a database user. They are created by the technical user _SYS_REPO and granted through the execution of stored procedures. Any user with access to these procedures can grant and revoke a role. Roles created in runtime are granted directly by the database user and can only be revoked by the same user. Additionally, if the database user is deleted, all roles that he or she granted are revoked. Because database users correspond to real people, this could impact the implementation of your authorization concept, for example, if an employee leaves the organization or is on vacation.
Hint: The design-time version of a role in the repository and its activated runtime version should always contain the same privileges. In particular, additional privileges should not be granted to the activated runtime version of a role created in the repository. Although there is no mechanism of preventing a user from doing this, the next time the role is activated in the repository, any changes made to the role in runtime will be reverted. It is therefore important that the activated runtime version of a role is not changed in runtime.
Runtime Roles Runtime roles are created in the SAP HANA system. A role administrator creates the role in the runtime of the SAP HANA system. Runtime roles are granted directly by the database user and can only be revoked by the same user.
Figure 438: Runtime Roles
Create Runtime Roles To create a runtime role open the role-editor by right-click on Security → Role in the SAP HANA Studio. Then select the roles and privileges that you want to include and save the role.
Design-Time Roles Design-time roles are created in the development system. A developer or role designer creates the role in the repository of the development system and tests it. Therefore the following prerequisites have to be fulfilled: ●
Authorization assigned: sap.hana.xs.ide.roles::EditorDeveloper role
●
A shared project must exist with a suitable package for storing roles
●
Package privileges on the required packages
The role is transported to the production system, for example, using HALM or CTS+ In the production system, a user administrator grants the role to end users.
Create Design-time Roles To create a design-time role, open the Editor of the Web IDE in your Web browser:http:// :<80instance_no>/sap/hana/xs/ide/editor Create the new role in the Content tree by right-click on the folder where you want to create the role. Then select the roles and privileges that you want to include and save the role.
Note: The role will be saved and activated in one step. If you want to only save the role, choose Settings and select Enable inactive save. An additional icon will be displayed in the toolbar: Save without Activating.
Predelivered Roles Several roles are delivered with the SAP HANA database. You can use these as templates for creating your own roles.
Figure 442: Predelivered Standard Role
PUBLIC: Contains privileges for filtered read-only access to the system views. Only objects for which the users have access rights are visible. By default, this role is assigned to each user.
Hint: Regard these roles as “templates”. Do not grant these roles, build your own roles instead. MONITORING Contains privileges for full read-only access to all metadata, the current system status in system and monitoring views, and the data of the statistics server. MODELING Contains all privileges required for using the information modeler in the SAP HANA studio. Contains the database authorization for a modeler to create all kinds of views and analytic privileges. Allows access to all data in activated views without any filter (_SYS_BI_CP_ALL Analytic Privilege). However, this is restricted by missing SQL privileges on those activated objects. Use this predefined role as a template CONTENT_ADMIN Contains the same privileges as the MODELING role, but with the extension that users allocated this role are allowed to grant these privileges to other users. In addition, it contains repository privileges for working with imported objects. Use this role as a template for what content administrators might need as privileges.
SAP_INTERNAL_HANA_SUPPORT This role contains privileges that allow access to certain low-level internal system views needed by SAP HANA development support in support situations, which otherwise would only be accessible to the SYSTEM user. All access is read only, and the role does not allow access to any customer data. The low-level internal system views are not part of the stable end-user interface and might change from revision to revision. To avoid users accidentally accessing these internal system views in applications or scripts, this role is subject to usage restrictions and should be granted only to SAP HANA development support users for their support activities. The SAP_INTERNAL_HANA_SUPPORT role can be granted to a configurable number of users.
Hint: An alert notifies administrators when a user is granted the SAP_HANA_INTERNAL_SUPPORT role (see SAP Note 1991615).
LESSON OVERVIEW In this lesson, you will learn how to create and copy users, deactivate and reactivate users, manage connection attempts, set initial passwords, and manage the password policy. Business Example The user administrations includes tasks to deactivate and reactivate users and to manage the password policy. To enhance the logon security of your SAP HANA database, password rules can be configured by using specific parameters. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Deactivate a user
●
Reactivate a user
●
Reset a locked user
●
Manage the password policy
Creating Users When Creating a user you have to specify the following information:
Hint: By default, new users created in SAP HANA can create objects within their own private schema and read public information. Restricted users initially have no privileges. Restricted users are intended for end users who access SAP HANA through applications. After creation they need to be granted the privileges or roles necessary to use the application. Restricted users initially ●
●
●
Cannot create objects in the database (they are not authorized to create objects in their own database schema) Cannot view any data in the database (as they are not granted, and cannot be granted, the standard PUBLIC role) Can only connect via HTTP but not via ODBC or JDBC (to enable restricted users to connect via ODBC or JDBC, they need to be granted the standard roles RESTRICTED_USER_ODBC_ACCESS or RESTRICTED_USER_JDBC_ACCESS)
Caution: A database user created as a restricted user cannot later be converted into a “normal” user.
Authentication method: ●
User name and password authentication by specifying a user name and password
●
Kerberos authentication (external) by specifying the user principal name (UPN)
●
SAML authentication (external) by selecting the identity provider and then entering the user ID
●
X.509 certificates by adding the user's public key certificate or certificates
●
SAP logon and assertion tickets
Validity period: You can specify a validity period for the user. For example, if you are creating a user for a new employee, you can enter their start date in the Valid From field. If you do not enter any values, the user is immediately and indefinitely valid. Session Client: When you create SAP HANA information models (attribute views, analytic views, and calculation views), it is possible to filter the data according to the client specified in table fields such as MANDT or CLIENT. You can specify the client relevant for the user here. Authorization: Authorization is given to the User by granting roles and privileges.
Copying Users If you are implementing user authorization through roles created in the SAP HANA repository, it is possible to create a new user by copying an existing user. The repository roles granted to the existing user are automatically granted to the new user. When copying users the user-specific information, that is, user name and authentication details are required. Additional roles and privileges could be granted to the new user.
Figure 446: Deactivation and Reactivation of Users
Deactivation of Users Users can be explicitly deactivated in the SAP HANA studio. For example, if an employee temporarily leaves the company or if a security violation is detected. It is possible to deactivate and reactivate users in the SAP HANA studio. The system privilege, USER ADMIN, is required to deactivate or reactivate users in the SAP HANA studio. In the SAP HANA studio, choose Security → Users. From the context menu of the user record, select Open. Reactivation of Users If the user has made too many invalid logon attempts, the administrator can use a SQL command to unlock the user account.
Additional User Parameters Additional core user parameters (timezone, e-mail address, and locale) are available, which are needed across different scenarios and applications based on SAP HANA.
To maintain these parameters, use the SAP HANA Studio or the following SQL statement: ALTER USER USER1 SET PARAMETER LOCALE = 'en_US.UTF-8', TIME ZONE = 'Europe/Berlin', EMAIL ADDRESS = '[email protected]' Prerequisites: ●
Users can change their own parameters (exception: validity period).
●
To change the parameters of other users, the system privilege USER ADMIN is required.
To view the current values, you can use the USERS and USER_PARAMETERS system views. The content of these system views will be filtered according to your privileges.
Managing Password Policy If the user's password has expired, the user has to change the password to a new value. Passwords for the user name and password authentication of database users are subject to certain rules, or password policy. You can change the default password policy in line with your organization’s security requirements. You cannot deactivate the password policy. Password Policy ● Password quality (length, complexity)
The password quality is defined by several parameters, which are described in detail in the SAP HANA Security Guide. The password blacklist is a list of words that are not allowed as passwords or parts of passwords. SAP HANA checks this blacklist whenever a password is created or changed. You can specify whether the words in the blacklist are case-sensitive and whether the check applies to whole words or parts of words. The password blacklist in SAP HANA is implemented with the table _SYS_PASSWORD_BLACKLIST (_SYS_SECURITY). This table is empty when you create a new instance. The _SYS_SECURITY schema and the _SYS_PASSWORD_BLACKLIST table are owned by the SYSTEM user. It is recommended that, during the initial system setup, the SYSTEM user grants change privileges for this table to a dedicated administrator user.
Caution: For security reasons, even the privilege to select should be handled carefully to prevent users from being able to view sensitive information such as a password. Password Policy Parameters The password blacklist can be configured in the Security editor of the SAP HANA studio. To change the parameter values in the “Password policy” section of the indexserver.ini, you have the following options: ●
●
Using the Configuration tab of the SAP HANA studio; follow these steps: -
Open the Administration editor and go to the Configuration tab.
-
Expand the indexserver.ini section.
-
In the Password policy section, change the required parameters.
Using the Security editor of the SAP HANA studio; follow these steps: -
●
Open the Security editor and go to the Password Policy tab.
Using a SQL statement -
-
Alter system alter configuration (indexserver.ini, SYSTEM) set (password policy, ) = with reconfigure
Note: The actual parameters are contained in the password_policy section of the indexserver.ini system properties file. Although it is recommended to configure the password policy using the Security editor of the SAP HANA studio, you can also do so by editing the indexserver.ini directly. If a parameter is set to a value outside the value range, either the minimum value or the maximum value of the value range, whichever is appropriate, is used instead.
Note: The User Lock Settings (parameter password_lock_time) define the duration for which a user is locked after the maximum number of failed logon attempts. Selecting the Lock indefinitely checkbox locks a user indefinitely. This corresponds to the parameter value -1. The value 0 unlocks the user immediately. Prerequisites for changing parameters: ●
●
System privilege INIFILE ADMIN (For blacklist) INSERT and DELETE privileges for either the _SYS_PASSWORD_BLACKLIST table or the _SYS_SECURITY schema
To view the contents of the INI file, use the M_INIFILE_CONTENTS view. The password policy parameters can be found in the M_PASSWORD_POLICY view. For more information about the parameter values, see the password policy parameters in the SAP HANA Security Guide.
For connectivity purpose, a technical user might be created. This technical user should never change the password. The mandatory periodic password change can now be re-enabled using SQL commands: ALTER USER DISABLE PASSWORD LIFETIME ALTER USER ENABLE PASSWORD LIFETIME
Disable Mandatory Initial Password Change for New User
Figure 452: Disable Mandatory Initial Password Change for New User
Managing SYSTEM User As the most powerful database user, SYSTEM is not intended for use in production systems. Use it to create lesser privileged users for particular purposes. Managing SYSTEM User ● Deactivating the SYSTEM User ALTER USER SYSTEM DEACTIVATE USER NOW ●
Exempt SYSTEM User from locking Parameter: password_lock_for_system_user
●
Resetting the SYSTEM User's Password see SAP HANA System Administration Guide
Note: As of SPS 11 the SYSTEM user is also locked if the wrong password is entered several times. For compatibility reasons a new password policy parameter hast been introduced: password_lock_for_system_user.
Deactivating the SYSTEM User SYSTEM is the database superuser. It has irrevocable system privileges, such as the ability to create other database users, access system tables, and so on. It is highly recommended that you do not use SYSTEM for day-to-day activities in production systems. Instead, use it to
create database users with the minimum privilege set required for their duties (for example, user administration, system administration). Then deactivate SYSTEM. Execute the following statement, for example, in the SQL console of the SAP HANA studio: ALTER USER SYSTEM DEACTIVATE USER NOW The SYSTEM user is deactivated and can no longer connect to the SAP HANA database. You can verify that this is the case in the USERS system view. For user SYSTEM, check the values in the columns USER_DEACTIVATED, DEACTIVATION_TIME, and LAST_SUCCESSFUL_CONNECT.
Note: You can still use the SYSTEM user as an emergency user even if it has been deactivated. Any user with the system privilege USER ADMIN can reactivate SYSTEM with the statement ALTER USER SYSTEM ACTIVATE USER NOW. To ensure that an administrator does not do this secretly, we recommend that you create an audit policy monitoring ALTER USER statements.
Resetting the SYSTEM User's Password If the SYSTEM user's password is lost, you can reset it using the index server in emergency mode and the credentials of the operating system user. The complete procedure is described in detail in the SAP HANA System Administration Guide. After performing this procedure the password for the SYSTEM user is reset. As you are logged on as the SYSTEM user in this console, you do not have to change this new password the next time you log on with this user regardless of your password policy configuration.
LESSON OVERVIEW This lesson covers the tables and views that support user management. Business Example After creating users and grant authorizations to them, you need to evaluate which privileges and roles are granted to the users. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
List tables and views that support the user management
●
Analyze which privileges a user has been granted
Information Sources for Administrators
Figure 453: System Tables and Monitoring Views
System tables and monitoring views query information about the system using SQL commands. The results appear as tables in SYS Schema.
The system view M_CONNECTIONS now contains additional information about the authentication method: SELECT USER_NAME, AUTHENTICATION_METHOD FROM M_CONNECTIONS. By default, users can only query information about themselves. Display Privileges Granted to a User Since privileges can both be assigned directly or be inherited via roles, it is often difficult to see at first glance which privileges a user has been granted. To provide better support, the view EFFECTIVE_PRIVILEGES was created.
Figure 454: Display Privileges Granted to a User
It should be mentioned that, when selecting from EFFECTIVE_PRIVILEGES, you always need the condition USER_NAME = 'something' in the WHERE clause, otherwise the query will return with an error. Display Roles Granted to a User The system view EFFECTIVE_ROLES displays the roles of the currently logged-on user. It shows both roles that were granted directly to the user, and roles that were inherited from other roles. This system view complements the system view EFFECTIVE_PRIVILEGES.
Dependency Viewer You can use the authorization dependency viewer as a first step in troubleshooting authorization errors and invalid object errors for stored procedures and calculation views with complex dependency structures. The authorization dependency viewer helps you to identify where there are invalid authorization dependencies in your object’s structure. This is particularly useful for objects with large and complex dependency structures. The authorization dependency viewer in the SAP HANA studio visualizes the object dependency structure of stored procedures and views together with the SQL authorization status of the object owner along the dependency paths. You can use the authorization dependency viewer as a first step in troubleshooting the following authorization errors for column views and procedures: ●
NOT AUTHORIZED (258)
●
INVALIDATED VIEW (391)
●
INVALIDATED PROCEDURE (430)
Authorization or invalid object errors occur if the object owner does not have all the required privileges on all underlying objects on which the object depends (for example, tables, views, and procedures). The object owner must have both the appropriate SQL object privilege (for example, EXECUTE, SELECT) and the authorization to grant the object privilege to others (that is, WITH GRANT OPTION is set). The authorization dependency viewer helps you to identify where there are invalid authorization dependencies in the object structure. This is particularly useful for objects with large and complex dependency structures.
Hint: Recommendation: Use the authorization dependency viewer only with procedures with security mode DEFINER. Procedures with security mode INVOKER are not validated correctly.
Maintaing Administrative Users and Authorization Create roles to perform administrative tasks. Create Roles: BASIC_ADMIN, BACKUP_ADMIN, DATA_ADMIN You need a user with authorizations for database administration. This database administrator should perform the following tasks: ●
All actions that any DB administrator will expect they are allowed to do and that are not specific to data schemas or repository packages.
●
All backup-related tasks
●
Create new database schemas and to import and export catalog objects
Create a new Package HA200_ROLE_PACKAG and the roles, which allow you to perform these administrative tasks. 1. Create new Package HA200_ROLE_PACKAGE using the SAP HANA Web-IDE. 2. Create a new role BASIC_ADMIN. This role collects all actions that any DB administrator will expect that they are allowed to do and that are not specific to data schemas or repository packages. Therefore the following privileges should be granted: Privilege
What does it do?
System privilege CATALOG READ
Read access to all metadata of the database catalog. Among other things, required to enter into the administration editor of SAP HANA studio
System privilege SERVICE ADMIN
Start and stop individual services (processes) of the database
System privilege INIFILE ADMIN
Modify the database configuration
System privilege TRACE ADMIN
Start and stop database traces, change the trace levels of the kernel trace
System privilege SESSION ADMIN
Kill sessions
System privilege VERSION ADMIN
Trigger garbage collection of the database’s version history (part of MVCC implementation)
This role allows all backup-related tasks, such as creating a database backup or managing the backup catalog or deleting backups from disk. Therefore, the following privileges should be granted: Privilege
What does it do?
System privilege CATALOG READ
Read access to all metadata of the database catalog
System privilege BACKUP ADMIN
Access to all backup functionalities except for restore (which requires OS user credentials)
4. Create a new role DATA_ADMIN. This role defines a user who can create new database schemas directly in the catalog and import and export catalog objects. Therefore, the following privileges should be granted: Privilege
What does it do?
System privilege CREATE SCHEMA
Create new schemas directly in the database catalog
System privilege EXPORT
Export catalog objects to the DB server (csv/binary) or to the client machine
System privilege IMPORT
Import catalog objects from the DB server (csv/binary) or from the client machine
Create User ADMIN## Create a user named ADMIN##, where ## is your group ID. Assign the database administration roles you have just created to this user. Then confirm that your user has been created. After you have created the user successfully, you can log on and add the user to the Navigator View of the HANA studio. Then confirm that your user’s schema has been created under Catalog. 1. Create a user named ADMIN##, where ## is your group ID. 2. Assign the roles HA200_ROLE_PACKAGE::BASIC_ADMIN, HA200_ROLE_PACKAGE::BACKUP_ADMIN, and HA200_ROLE_PACKAGE::DATA_ADMIN to this user. 3. Confirm that your user has been created. 4. Add the user to the Navigator View of the HANA studio. Check the Authorizations of the User ADMIN## Check the authorizations of the user ADMIN##. 1. Check if the user ADMIN## is authorized to export the TRAIN##.PRODUCTS table. The user ADMIN## is not authorized to export theTRAIN##.PRODUCTS table. The system privilege EXPORT is not sufficient to export the table. In addition, the object privilege SELECT for the TRAIN##.PRODUCTS table is needed. To solve your problem, add the object privilege for TRAIN##.PRODUCTS table to the HA200_ROLE_PACKAGE::DATA_ADMIN role.
Maintaing Administrative Users and Authorization Create roles to perform administrative tasks. Create Roles: BASIC_ADMIN, BACKUP_ADMIN, DATA_ADMIN You need a user with authorizations for database administration. This database administrator should perform the following tasks: ●
All actions that any DB administrator will expect they are allowed to do and that are not specific to data schemas or repository packages.
●
All backup-related tasks
●
Create new database schemas and to import and export catalog objects
Create a new Package HA200_ROLE_PACKAG and the roles, which allow you to perform these administrative tasks. 1. Create new Package HA200_ROLE_PACKAGE using the SAP HANA Web-IDE. a) Log on to the SAP HANA IDE with SYSTEM user. Open Chrome Browser and use the URL: http://.wdf.sap.corp:8020/sap/hana/xs/ide/editor b) Create a new Package: HA200_ROLE_PACKAGE. Therefore Right-click Content → New → Package. c) Type the name of the package in the Package name field and choose Create. 2. Create a new role BASIC_ADMIN. This role collects all actions that any DB administrator will expect that they are allowed to do and that are not specific to data schemas or repository packages. Therefore the following privileges should be granted:
588
Privilege
What does it do?
System privilege CATALOG READ
Read access to all metadata of the database catalog. Among other things, required to enter into the administration editor of SAP HANA studio
System privilege SERVICE ADMIN
Start and stop individual services (processes) of the database
System privilege INIFILE ADMIN
Modify the database configuration
System privilege TRACE ADMIN
Start and stop database traces, change the trace levels of the kernel trace
Trigger garbage collection of the database’s version history (part of MVCC implementation)
System privilege LICENSE ADMIN
Install or delete license key
SELECT on schema _SYS_STATISTICS
Read alerts of the statisticsserver process
a) Log on to the SAP HANA IDE with SYSTEM user. Open Chrome Browser and use the URL: http://.wdf.sap.corp:8020/sap/hana/xs/ide/editor b) Right-click HA200_ROLE_PACKAGE → New → Role. c) Give your role the following name: BASIC_ADMIN. d) Select theSystem Privileges tab and click +. e) Search for System Privilege CATALOG READ, highlight it, and click OK. f) Repeat the same steps for the System Privileges SERVICE ADMIN, INIFILE ADMIN, TRACE ADMIN, SESSION ADMIN, VERSION ADMIN, LICENSE ADMIN. g) Select theObject Privileges tab and click +. h) Choose Run-time and select object type SCHEMA. i) Search for Object Privilege _SYS_STATISTICS, highlight it, and click OK. j) Select the object that has just been added. k) Scroll to the right, and assign the privilege SELECT to object _SYS_STATISTICS. l) Save the newly created Role by clicking the Save button. m) Confirm the successful deploy on the role view. n) Confirm it is in the Role Catalog of SAP HANA Studio: Expand the content of the SAP HANA system → Security → Roles. 3. Create a new role BACKUP_ADMIN. This role allows all backup-related tasks, such as creating a database backup or managing the backup catalog or deleting backups from disk. Therefore, the following privileges should be granted: Privilege
What does it do?
System privilege CATALOG READ
Read access to all metadata of the database catalog
System privilege BACKUP ADMIN
Access to all backup functionalities except for restore (which requires OS user credentials)
a) Log on to the SAP HANA IDE with SYSTEM user. Open Chrome Browser and use the URL: http://.wdf.sap.corp:8020/sap/hana/xs/ide/editor
b) Right-click HA200_ROLE_PACKAGE → New → Role. c) Give your role the following name: BACKUP_ADMIN. d) Select the System Privileges tab and click +. e) Search for System Privilege CATALOG READ, highlight it, and click OK. f) Repeat the same steps for the System Privilege BACKUP ADMIN. g) Save the newly created Role by clicking the Save button. h) Confirm the successful deploy on the role view. i) To confirm it is in the Role Catalog of SAP HANA Studio, expand the content of SAP HANA system → Security → Roles. 4. Create a new role DATA_ADMIN. This role defines a user who can create new database schemas directly in the catalog and import and export catalog objects. Therefore, the following privileges should be granted: Privilege
What does it do?
System privilege CREATE SCHEMA
Create new schemas directly in the database catalog
System privilege EXPORT
Export catalog objects to the DB server (csv/binary) or to the client machine
System privilege IMPORT
Import catalog objects from the DB server (csv/binary) or from the client machine
a) Log on to the SAP HANA IDE with SYSTEM user. Open Chrome Browser and use the URL: http://.wdf.sap.corp:8020/sap/hana/xs/ide/editor b) Right-click HA200_ROLE_PACKAGE → New → Role. c) Give your role the following name: DATA_ADMIN and Save (CRTL+S). d) Select the System Privileges tab and click +. e) Search for System Privilege CREATE SCHEMA, highlight it, and click OK. f) Repeat the same steps for the System Privileges EXPORT and IMPORT. g) Save the newly created Role by clicking the Save button. h) Confirm the successful deploy on the role view. i) To confirm it is in the Role Catalog of SAP HANA Studio, expand the content of SAP HANA system → Security → Roles. Create User ADMIN## Create a user named ADMIN##, where ## is your group ID. Assign the database administration roles you have just created to this user. Then confirm that your user has been created. After you have created the user successfully, you can log on and add the user to the Navigator View of the HANA studio. Then confirm that your user’s schema has been created under Catalog.
1. Create a user named ADMIN##, where ## is your group ID. a) In the SAP HANA Studio, expand the content of the SAP HANA system → Security → Users. b) Right-click Users → New User. c) Give the user a name, ADMIN## and internal password (for example, Abcd1234) and confirm the password. 2. Assign the roles HA200_ROLE_PACKAGE::BASIC_ADMIN, HA200_ROLE_PACKAGE::BACKUP_ADMIN, and HA200_ROLE_PACKAGE::DATA_ADMIN to this user. a) Select the Granted Roles tab and click +. b) Search for the role you have created, HA200_ROLE_PACKAGE::BASIC_ADMIN, select the role, then click OK. c) Repeat the same steps for the roles HA200_ROLE_PACKAGE::BACKUP_ADMIN and HA200_ROLE_PACKAGE::DATA_ADMIN. d) Click Deploy or F8. 3. Confirm that your user has been created. a) Confirm the Deploy on the ADMIN## tab. Note: PUBLIC role has been automatically assigned. b) Confirm your user under Users Security Catalog. Now, you can log in as the user created. 4. Add the user to the Navigator View of the HANA studio. a) To add the new user ADMIN##, open the context menu of the system node and choose Add System with Different User … b) Enter user Id and password and choose Finish. When prompted for a new password, enter, Abcd1234 5, for example. c) Confirm your new user’s schema under Catalog. Check the Authorizations of the User ADMIN## Check the authorizations of the user ADMIN##. 1. Check if the user ADMIN## is authorized to export the TRAIN##.PRODUCTS table. a) In SAP HANA Studio, right-click the table PRODUCTS table under the TRAIN## schema that you just created and select Export to export the table. The table appears in the Selected Catalog Objects b) Click Next c) Select Binary for format, select Including data and Including dependencies, use the Default Directory, which will create the export file under work directory of the HANA server, and click Finish.
, under work directory, is created and the exported files are located under this directory structure. d) To start the export, choose Finish. The user ADMIN## is not authorized to export theTRAIN##.PRODUCTS table. The system privilege EXPORT is not sufficient to export the table. In addition, the object privilege SELECT for the TRAIN##.PRODUCTS table is needed. To solve your problem, add the object privilege for TRAIN##.PRODUCTS table to the HA200_ROLE_PACKAGE::DATA_ADMIN role. 2. Check if the user ADMIN## is authorized to perform a backup. a) In the Navigator view of in SAP HANA studio, select the database (database user ADMIN##) for which you want to start a backup. b) From the context menu, choose Backup and Recovery → Back Up System. c) Specify the location (directory) and the backup file prefix to use. d) When all the settings are correct, choose Next and Finish. The backup then starts. The progress of the backup is shown for all types of services (for example, the statistics server, name server, and index servers). When all the volumes have been backed up, a confirmation message is displayed. 3. Check if the user ADMIN## is authorized to change configuration Parameters a) To open the Administration Editor with the permissions of the SYSTEM user, doubleclick the SAP HANA system entry that is using the ADMIN## user for connection. b) Choose Configuration tab. c) To search for the content_vendor parameter, type a few characters (such as Content) in the Filter field. The system searches all of the parameters according to what you are typing. d) Double-click the content_vendor parameter. The parameter is located in the indexserver.ini file in the repository section. You are not authorized to perform this action.
Create a role containing analytical privileges and check the authorization. Create Role ROLE_ANALYTIC_## Create a design-time role ROLE_ANALYTIC_## using the SAP HANA Web-IDE, where ## is your group ID and assign the following roles and privileges to your new role. Add the Object Privileges _SYS_BI and _SYS_BIC with privilege SELECT to your role. Add the Object Privilege REPOSITORY_REST with privilege EXECUTE. Add a Package Privilege to give access to the sap.hana.democontent.epm.models repository package and assign authorization REPO.READ. Then deploy the role and confirm that the role has been created. Perform this task with SYSTEM user. 1. Create a role ROLE_ANALYTIC_##, where ## is your group ID. 2. Add the Object Privileges _SYS_BI and _SYS_BIC with privilege SELECT to your role. 3. Add the Object privilege REPOSITORY_REST with privilege EXECUTE to your role. 4. Add a Package Privilege to give access to repository package sap.hana.democontent.epm.models and assign authorization REPO.READ. 5. Save the role and confirm that the role has been created. Create a User USER## Create a user named USER##, where ## is your group ID. Assign the role you have just created to this user. Then confirm that your user has been created. After you have created the user successfully, you can log on and add the user to the Navigator View of the HANA studio. Then confirm that your user’s schema has been created under Catalog. 1. Create a user named USER##, where ## is your group ID. 2. Assign the role HA200_ROLE_PACKAGE::ROLE_ANALYTIC_##, where ## is your group ID to this user. 3. Confirm that your user has been created. 4. Add the user to the Navigator View of the HANA studio. Check Authorization of the User Check if the user USER## is authorized to access the Calculation View PURCHASE_OVERVIEW. 1. Check if the user USER## is authorized to access the Calculation View PURCHASE_OVERVIEW.
Create an Analytic Privilege Create a new analytic privilege, AP_PURCHASE_OVERVIEW_DE, in the package sap.hana.democontent.epm.models using the user SYSTEM. This analytic privilege should give access to the Calculation View sap.hana.democontent.epm.models. PURCHASE_OVERVIEW with restriction to the attribute SUPPLIER_COUNTRY = DE. 1. Use the Web IDE to create a new analytic privilege AP_PURCHASE_OVERVIEW_DE, in the Package sap.hana.democontent.epm.models. 2. Add the secured models (calculation view PURCHASE_OVERVIEW and calculation view PROD). The calculation view PURCHASE_OVERVIEW uses as source the calculation view PROD. Therefore, it is necessary to add the calculation view PROD in the section secured models. 3. Restrict the access to the Calculation View PURCHASE_OVERVIEW to the attribute SUPPLIER_COUNTRY = DE. Add the New Analytic Privilege to your Role and Check Authorization of the User Add the new analytic privilege to your role HA200_ROLE_PACKAGE::ROLE_ANALYTIC_## using the user SYSTEM. Then test the authorizations of user USER## by selecting the Calculation View PURCHASE_OVERVIEW. 1. Use the Web IDE to add the new analytic privileges to your role HA200_ROLE_PACKAGE::ROLE_ANALYTIC_##. 2. As USER##, select the Calculation View PURCHASE_OVERVIEW to test the authorizations.
Create a role containing analytical privileges and check the authorization. Create Role ROLE_ANALYTIC_## Create a design-time role ROLE_ANALYTIC_## using the SAP HANA Web-IDE, where ## is your group ID and assign the following roles and privileges to your new role. Add the Object Privileges _SYS_BI and _SYS_BIC with privilege SELECT to your role. Add the Object Privilege REPOSITORY_REST with privilege EXECUTE. Add a Package Privilege to give access to the sap.hana.democontent.epm.models repository package and assign authorization REPO.READ. Then deploy the role and confirm that the role has been created. Perform this task with SYSTEM user. 1. Create a role ROLE_ANALYTIC_##, where ## is your group ID. a) Right-click HA200_ROLE_PACKAGE → New → Role. b) Give your role the following name: ROLE_ANALYTIC_## and choose Create. 2. Add the Object Privileges _SYS_BI and _SYS_BIC with privilege SELECT to your role. a) Select the Object Privileges tab and click +. b) Choose Run-time and select object type SCHEMA. c) Search for Object Privilege _SYS_BI, highlight it, and click OK. d) Select the object that has just been added. e) Scroll to the right, and assign the privilege SELECT to object _SYS_BI. f) Repeat the same steps for the Object Privilege _SYS_BIC. 3. Add the Object privilege REPOSITORY_REST with privilege EXECUTE to your role. a) Select the Object Privileges tab and click +. b) Choose Run-time and select object type PROCEDURE. c) Search for object REPOSITORY_REST, highlight it, and click OK. d) Select the object that has just been added. e) Scroll to the right, and assign the privilege EXECUTE to object REPOSITORY_REST. Your role should now contain 3 Object privileges. 4. Add a Package Privilege to give access to repository package sap.hana.democontent.epm.models and assign authorization REPO.READ.
a) On the Package Privileges tab, add repository package sap.hana.democontent.epm.models. b) Highlight the added package privilege and select REPO.READ on the right pane. Note: These Package Privileges allow read access to content objects in the sap.hana.democontent.epm.models Package. 5. Save the role and confirm that the role has been created. a) Save the newly created Role by clicking the Save button. b) Confirm the successful deploy on the role view, and confirm that it is in the Role Catalog. c) Log on to the SAP HANA studio with SYSTEM user. d) Choose the Administration Perspective: Window → Open Perspective → Other... → Administrative Console. e) Expand the content of the SAP HANA system → Security → Roles. f) The new role HA200_ROLE_PACKAGE::ROLE_ANALYTIC_## appears in the list. Create a User USER## Create a user named USER##, where ## is your group ID. Assign the role you have just created to this user. Then confirm that your user has been created. After you have created the user successfully, you can log on and add the user to the Navigator View of the HANA studio. Then confirm that your user’s schema has been created under Catalog. 1. Create a user named USER##, where ## is your group ID. a) Log on to the SAP HANA studio with SYSTEM user. b) Expand the content of the SAP HANA system → Security → Users. c) Right-click Users → New User. d) Give the user a name, USER## and internal password (for example, Abcd1234) and confirm the password. 2. Assign the role HA200_ROLE_PACKAGE::ROLE_ANALYTIC_##, where ## is your group ID to this user. a) Select the Granted Roles tab and click +. b) Search for the role you have created, HA200_ROLE_PACKAGE::ROLE_ANALYTIC_##. Select the role, then click OK. c) Confirm that the role has been added. d) Click Deploy or F8. 3. Confirm that your user has been created. a) Confirm the Deploy on the USER## tab.
Note: PUBLIC role has been automatically assigned. b) Confirm your user under Users Security Catalog. Now, you can log in as the user created. 4. Add the user to the Navigator View of the HANA studio. a) To add the new user USER##, open the context menu of the system node and choose Add System with Different User … b) Enter user Id and password and choose Finish. When prompted for a new password, enter Abcd12345, for example. c) Confirm your new user’s schema under Catalog. Check Authorization of the User Check if the user USER## is authorized to access the Calculation View PURCHASE_OVERVIEW. 1. Check if the user USER## is authorized to access the Calculation View PURCHASE_OVERVIEW. a) Change to the Modeler Perspective: Window → Open Perspective → Other, select Modeler, and choose OK. b) In the Navigator Pane, open the tree for user USER## to view the available packages. c) Under the tree for user USER## open Content → sap → hana → democontent → epm → models → Calculation Views. d) Right-click Calculation View PURCHASE_OVERVIEW and choose Data Preview. e) Choose the Raw Data tab. An error message indicating that the user is not authorized appears. Create an Analytic Privilege Create a new analytic privilege, AP_PURCHASE_OVERVIEW_DE, in the package sap.hana.democontent.epm.models using the user SYSTEM. This analytic privilege should give access to the Calculation View sap.hana.democontent.epm.models. PURCHASE_OVERVIEW with restriction to the attribute SUPPLIER_COUNTRY = DE. 1. Use the Web IDE to create a new analytic privilege AP_PURCHASE_OVERVIEW_DE, in the Package sap.hana.democontent.epm.models. a) In the context menu of the user SYSTEM, right-click the package sap.hana.democontent.epm.models and choose New → Analytic Privilege … b) Log on to the SAP HANA IDE with SYSTEM user. Open Chrome Browser and use the URL: http://.wdf.sap.corp:8020/sap/hana/xs/ide/editor c) Navigate to the Package Content → sap.hana.democontent.epm.models, right-click, and choose New → Analytic Privilege. d) Enter name and label AP_PURCHASE_OVERVIEW_DE.
e) Select type Classical and choose Create. 2. Add the secured models (calculation view PURCHASE_OVERVIEW and calculation view PROD). The calculation view PURCHASE_OVERVIEW uses as source the calculation view PROD. Therefore, it is necessary to add the calculation view PROD in the section secured models. a) To add calculation view PURCHASE_OVERVIEW to the secured models choose + Add in the Secured Models section. b) Select Calculation View sap.hana.democontent.epm.models.PURCHASE_OVERVIEW and choose OK. c) To add calculation view PROD to the secured models choose + Add in the Secured Models section. d) Select Calculation View sap.hana.democontent.epm.models.PROD and choose OK. 3. Restrict the access to the Calculation View PURCHASE_OVERVIEW to the attribute SUPPLIER_COUNTRY = DE. a) Choose + Add in the Associated Attributes Restrictions section. b) Choose attribute SUPPLIER_COUNTRY. c) Choose OK. d) Choose + Restriction in the Restriction Type column to assign restrictions for SUPPLIER_COUNTRY. e) Click the gray button in the Value field to open the Value Help dialog box. f) Select value DE and click OK. (Alternatively, just type DE in theValue field.) g) Deploy your analytic privilege (Save). Add the New Analytic Privilege to your Role and Check Authorization of the User Add the new analytic privilege to your role HA200_ROLE_PACKAGE::ROLE_ANALYTIC_## using the user SYSTEM. Then test the authorizations of user USER## by selecting the Calculation View PURCHASE_OVERVIEW. 1. Use the Web IDE to add the new analytic privileges to your role HA200_ROLE_PACKAGE::ROLE_ANALYTIC_##. a) Log on to the SAP HANA IDE with SYSTEM user. Open Chrome Browser and use the URL: http://.wdf.sap.corp:8020/sap/hana/xs/ide/editor b) Navigate to the role, right-click, and choose Open With → Role Editor. c) Select the Analytic Privileges tab. d) Choose + to add new analytic privileges. e) Choose Design-time, select your analytic privilege sap.hana.democontent.epm.models.AP_PURCHASE_OVERVIEW_DE, and click OK. f) Save the changes. 2. As USER##, select the Calculation View PURCHASE_OVERVIEW to test the authorizations.
a) Use the SAP HANA studio. b) Under the tree for user USER## open Content → sap → hana → democontent → epm → models → Calculation Views. c) Right-click PURCHASE_OVERVIEW (actual data) and choose Data Preview. d) In the Available Objects pane, drag the SUPPLIER_COUNTRY field to the Label Axis pane. e) In the Available Objects pane, drag the PRODUCTID field to the Values Axis pane. f) In the Output pane, select the Table tab. g) Check the result and only values for SUPPLIER_COUNTRY DE are available.
LESSON OVERVIEW This lesson gives a brief overview of the Analytic Authorization Assistant in SAP HANA Live. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the concept of the Analytic Authorization Assistant
Introduction The applications for SAP HANA Live for SAP Business Suite are a Web-based front-end HTML5 and UI development toolkit for HTML5 (SAPUI5) on top of SAP HANA Extended Application Services (SAP HANA XS). The underlying database is SAP HANA. The following diagram provides an overview of the technical system landscape for SAP HANA Live for SAP Business Suite.
Figure 457: SAP HANA Live Scenarios
SAP HANA Live for SAP Business Suite uses the user management and authentication mechanisms provided with the SAP HANA appliance software. Therefore, the security recommendations and guidelines for user administration and authentication as described in the SAP HANA Security Guide apply.
The user interfaces of SAP HANA Live for SAP Business Suite rely on the access control mechanisms of the underlying SAP HANA database. As a prerequisite, it is assumed that every business user (any user accessing SAP HANA Live content in the SAP HANA database) is created as a named SAP HANA database user. To control the business user’s access to SAP HANA Live application content and displayed data, the relevant authorization settings have to be configured within the SAP HANA database. SAP does not deliver any predefined privileges or roles for SAP HANA Live for SAP Business Suite business users. Instead, read access privileges for SAP HANA Live business users have to be configured on the customer side in conformity with the customer’s authorization requirements.
Analytic Authorization Assistant With the SAP HANA Live Authorization Assistant, you can provide users authorizations in the SAP HANA system that is required to access business data displayed by the virtual data model of SAP HANA Live. For this, SAP HANA Live Authorization Assistant takes those permissions into account that the same users already have in ABAP-based Business Suite application. SAP HANA Live Authorization Assistant is used to manage both the analytical privileges that are restricting access to specific business data, and the object privileges that are controlling the database views the user uses to report. Authorization profiles are defined and managed using transactions in ABAP-based application systems. In a scenario that is supported by SAP HANA Live Authorization Assistant, access to business data is primarily defined using PFCG on the ABAP-based system, and then using the Authorization Assistant converted to respective permissions in the HANA system. For this automatic conversion, SAP delivers metadata for all the relevant views of the virtual data model, which defines the mapping between the authorization fields of authorization objects and the respective attributes of
views. For a selected SAP NetWeaver ABAP user, SAP HANA Live Authorization Assistant generates the analytic privileges based on his/her assigned PFCG authorizations and collects them with the request SELECT object privileges in a role. Then, you can make the follow-up assignments of the role inside SAP HANA Studio. SAP HANA Live Authorization Assistant is integrated into the SAP HANA Studio but can be installed as a separate plug-in too.
Generating Analytic Privileges With the SAP HANA Live Authorization Assistant, you can convert existing ABAP PFCG authorizations for a user to respective permissions in the HANA system. In particular, the tool generates analytic privileges and roles, which combine the analytic privileges with the required SELECT object privilege for query views to control the data that users can access.
Transformation of User’s ABAP Authorizations into Analytic Privileges for SAP HANA The analytic privileges in SAP HANA are created according to view-specific mapping rules that exist between authorization objects and view attributes, based on the logic below from the users’ authorization data stored in ABAP systems: ●
●
●
●
Multiple values for the same authorization field of the same authorization object are combined with logical OR. Different authorization fields of the same authorization object are combined with logical AND. Different authorization objects are combined with logical OR. Interval values for authorizations maintained using the FROM and TO fields and the asterisk wildcard are taken into account while generating the analytic privileges for users.
Metadata to Generate Analytic Privileges The conversion of users’ ABAP PFCG authorizations into HANA permissions are based on view-specific metadata. This metadata defines the mapping between the authorization fields of authorization objects and respective attributes of views. SAP delivers the required metadata for all the relevant query views of the virtual data model. For customer created views, the metadata is defined with the view as specific properties. LESSON SUMMARY You should now be able to: ●
604
Explain the concept of the Analytic Authorization Assistant
LESSON OVERVIEW The objective of this lesson is to clarify how you can reach a high availability of SAP HANA. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the high availability scenarios for SAP HANA
Overview of High Availability for SAP HANA SAP HANA is fully designed for high availability. It supports recovery measures ranging from faults and software errors, to disasters that decommission an entire data center. High availability is the name given to a set of techniques, engineering practices, and design principles that support the goal of business continuity.
Figure 459: Continuous Availability – Overview
The following is an overview of planned and unplanned downtimes: ●
Unplanned downtime occurs in the following situations: -
Hardware failure or malfunction, including networks
-
Software malfunction, security threat, or update
-
Natural or man-made disasters
-
Failure of compliance and operation
-
Unplanned outages
High availability is achieved by eliminating single points of failure (fault tolerance), and providing the ability to resume operations rapidly after a system outage with minimal business loss (fault resilience). Fault recovery is the process of recovering and resuming operations after an outage due to a fault. Disaster recovery is the process of recovering operations after an outage due to a prolonged data center or site failure. Preparing for disasters may require backing up data across longer distances, and may thus be more complex and costly. The key to achieving high availability is redundancy, including hardware redundancy, network redundancy, and data center redundancy. SAP HANA provides several levels of defense against failure-related outages: 1. Hardware Redundancy SAP HANA appliance vendors offer multiple layers of redundant hardware, software, and network components, such as redundant power supplies and fans, enterprise grade errorcorrecting memories, fully redundant network switches and routers, and uninterrupted power supplies (UPS). Disk storage systems use batteries to guarantee writing even with a power failure, and use striping and mirroring to provide redundancy for automatic recovery from disk failures. Generally speaking, all these redundancy solutions are transparent to the operation of SAP HANA, but they form part of the defense against system outage due to single component failures. 2. Software SAP HANA is based on SUSE Linux Enterprise 11 for SAP and includes security preconfigurations (for example, minimal network services). Additionally, the SAP HANA system software also includes a watchdog function, which automatically restarts configured services (index server, name server, and so on), in case of detected stoppage (killed or crashed). 3. Persistence SAP HANA persists transaction logs, savepoints, and snapshots to support system restart and recovery from host failures, with minimal delay and without loss of data. 4. Standby and Failover
Separate, dedicated standby hosts are used for failover, in case of failure of the primary, active hosts. This improves the availability by significantly reducing the recovery time from an outage. High Availability and Disaster Recovery
Figure 460: High Availability – Overview
As an in-memory database, SAP HANA is not only concerned with maintaining the reliability of its data in the event of failures, but also with resuming operations with most of that data loaded back in memory as quickly as possible. SAP HANA supports the following recovery measures from failures: ●
Disaster recovery support: -
-
-
●
Backups: Periodic saving of database copies in safe place Storage replication: Continuous replication (mirroring) between primary storage and backup storage over a network (may be synchronous) System replication: Continuous update of secondary system by primary system, including in-memory table loading
Fault recovery support: -
-
Service auto-restart: Automatic restart of stopped services on host (watchdog) Host auto-failover: Automatic failover from crashed host to standby host in the same system
LESSON SUMMARY You should now be able to: ●
608
Explain the high availability scenarios for SAP HANA
LESSON OVERVIEW This lesson describe how you can expand your SAP HANA system. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Describe the basics of SAP HANA scale out
●
Describe the possibilities for configuration of a distributed system
Scaling SAP HANA There are two general approaches you can take to scale your SAP HANA system: ●
Scale up Scale up means increasing the size of one physical machine by increasing the amount of RAM available for processing.
●
Scale out Scale out means combining multiple independent computers into one system. The main reason for distributing a system across multiple hosts (that is, scaling out) is to overcome the hardware limitations of a single physical server. This means that an SAP HANA system can distribute the load between multiple servers. In a distributed system, each index server is usually assigned to its own host to achieve maximum performance. It is possible to assign different tables to different hosts (partitioning the database), as well as to split a single table between hosts (partitioning of tables).
One technique you can use to deal with planned data growth is to purchase more physical RAM than is initially required, to set the allocation limit according to your needs, and then to increase it over time to adapt to your data. Once you have reached the physical limits of a single server, you can scale out over multiple machines to create a distributed SAP HANA system. You can do this by distributing different schemas and tables to different servers (complete data and user separation). However, this is not always possible, for example, when a single fact table is larger than the server's RAM size. The most important strategy for scaling your data is data partitioning. Partitioning supports the creation of very large tables (billions of rows) by breaking them into smaller chunks that can be placed on different machines. Partitioning is transparent for most SQL queries and other data manipulations.
Scale Out: Database Landscape You can generally consider using an SAP HANA scale-out architecture to deal with larger amounts of data or for higher availability. If you need to use more memory or more CPU power beyond the limitation of a single physical hardware box, you can use a distributed landscape consisting of multiple hosts. A host is the server or blade on which you create an individual node of a system. An installed SAP HANA system is identified by a system ID (SID). It is perceived as one unit from the perspective of the administrator, who can install, update, start up, shut down, or back up the system as a whole. The different components of the system see the same metadata and requests from client applications, which can be transparently dispatched to different servers in the system.
A distributed SAP HANA system is a system that is installed on more than one host. Otherwise, it is a single-host system. A host is a machine (comprised of CPU, memory, storage, network, and operating system) that runs parts of the SAP HANA system. An SAP HANA instance is the set of components of a distributed system that are installed on one host. The figure above shows a distributed system that runs on three hosts. In this example, each instance has an index server, a preprocessor server, and a name server. The instance on host 1 also contains the statistics server, which exists only once per system. The index server contains all the database and processing components. Each index server is a separate operating system process and also has its own disk volumes. When processing database operations, index servers may need to forward the execution of some operations to other servers that own data involved in the operation. In each SAP HANA system, there is one master index server. It stores the metadata and contains the master transaction manager that coordinates distributed transactions involving multiple index servers. Database clients may send their requests to any index server. If the contacted index server does not own all data involved, it will delegate the execution of some operations to other index servers, collect the result, and return it to the database client. In a distributed system, a central component is required that knows the topology and how data is distributed. This component is the name server. The name server knows which tables, table replicas, or partitions of tables are located on which index server. When processing a query, the index servers ask the name server about the locations of the involved data. To prevent a negative impact on performance, the topology and distribution information is replicated and cached on each host. In each SAP HANA system, there is one master name server that owns the topology and distribution data. This data is replicated to all other name servers, called slave name servers. The slave name servers write the replicated
data to a cache in shared memory from where the index servers of the same instance can read it. The master name server has its own persistence where it stores name server data (topology, distribution data). The slave name servers have no persistence because they are only holding replicated data. Test and Simulation For testing and debugging, it is possible to copy a scale-out landscape to a single node.
Figure 463: SAP HANA Scale Out – Test and Simulation
Configuring Scale Out SAP HANA is offered in two ways – in the form of an appliance, delivered in a number of different configurations and "sizes" by certified hardware partners, or as part of a cloudbased service. This creates different system design options with respect to scale-up and scale-out variations. To maximize performance and throughput, SAP recommends that you scale up as far as possible (acquire the configuration with the highest processor and memory specification for the application workload), before scaling out (for deployments with even greater data volume requirements).
Note: The SAP HANA hardware partners have different building blocks for their scaleout implementations. Therefore, you should always consult your hardware partner when planning your scale-out strategy. As part of setting up a distributed system, you need to configure the network parameters. Make sure that you do this before you add additional hosts because one server needs to be available so that you can connect to the SAP HANA studio. You map hostnames to IP addresses by editing the section internal_hostname_resolution in the global.ini file.
Monitoring Landscape Overview from SAP HANA Studio
Figure 464: Monitoring Landscape Overview from SAP HANA Studio
File System for a Distributed Installation
Figure 465: File System for a Distributed Installation (1)
During installation, directories for data (default is /usr/sap//global/hdb/data) and log area (default is /usr/sap//global/hdb/log) are defined. The next directory level is mnt00001, mnt00002, and so on, where each worker host uses exactly one directory. Installing Master and Slave Servers of multiple storages mounted at mnt00..., because the number of directories does not change when new services are added. The next level is the actual volume hdb00001, hdb00002, with one directory per service.
Note: There is no storage volume assigned to the Standby server.
Figure 466: File System for a distributed Installation (2)
The Parameter System Default Value is the lowest free instance number available on the Instance number host /usr/sap.
Note: You can only accept this default value during the installation if you install a singlehost system. You must change this default path if you plan to create a distributed system. The Installation path is as follows: ●
●
614
The home directory /usr/sap//home. Use a number with value x+1, where x is the highest existing ID of the user ID on the current host Group ID.
●
The home of the logon is shell /bin/sh.
●
The path for storing the data volumes is //global/hdb/data.
●
The path for storing the log volumes is //global/hdb/log.
Figure 467: A Typical Configuration for a Distributed System
Note: You find the complete row store in the master. Up to 3 master name-servers can be defined. During startup one server is elected as active master. The active master assigns a volume to each starting index server or no volume in case of standby servers.
Note: For operational security a check for local time settings is performed during integration of new host or hosts in a Scale-Out cluster. Standard is to prevent an integration of new Scale-Out members with bigger time differences. Additionally, there exists an alert, which checks regularly on time differences in Scale-Out clusters Rearrangement of Scale-Out Landscapes ●
●
●
●
Hosts can be added and removed out of a living Scale-out setup. If a host is to be removed, data sitting on this host has to be redistributed to other hosts in the scale-out setup. The remaining hosts of the scale-out arrangement must be able to cope with the data amount according to the sizing rules for SAP HANA (max. 50% occupation with persistent data). After the data is redistributed, the host can be extracted.
This process can be supported within the SAP HANA studio: Landscape → Configuration (context menu of hostname).
●
Be careful to start a new Backup History after doing such a kind of topology changes.
●
For more information, refer to the SAP HANA Administration Guide.
Note: To ensure that you can recover your system to a point in time after you added the host, we recommend that you stop productive operations until you have added the host and performed a new, complete data backup. After you remove a host from your system, you must perform a data backup to ensure that you can recover the database to a point in time after you removed the host.
Data Distribution SAP HANA supports different ways of distributing data between multiple index servers in a single system: ●
●
Different tables can be assigned to different index servers, which normally run on different hosts (database partitioning). A table can be split in a way that different rows of the table are stored on different index servers (table partitioning).
When a non-partitioned table is created in a distributed system, it must be assigned to one index server. By default, new tables are distributed across available index servers using a round-robin approach. For example, if there are three available index servers A, B, and C (including the master), the first table created will be located on server A, the next one on server B, the next on server C, and so on. In addition, it is also possible to specify explicitly that a table or a partition is created on a specific index server.
With SPS5, a distribution of data like tables into a scale-out landscape was published. Distribution concepts are scenario-dependent. Scale-out requirements for BW and the Business Suite are different due to load and data structures. BW: OLAP load with few to many concurrent users ●
Read: typically rather long-running queries, reading many data.
●
Write: batch-inserts
●
Many joins or views according to star schema
Business Suite: OLTP load with many concurrent users ●
Read: many single records ...
●
Write: many single records ...
●
Few joins/views
The consequences are as follows: ●
●
Cross-node joins are critical for both the Business Suite and SAP BW, but common data structures (star schema, master data) make static optimization (without analysis of actual load) in SAP BW easier Partitioning is easier in SAP BW due to common data structures (for example, partition objects by time)
Data Distribution using SAP BW on SAP HANA ● Tables are partitioned and the partitions distributed over the different nodes ●
●
●
●
This distribution works well in a rather static environment (Fact, DataStore Object (DSO), and Persistent Staging Area (PSA) tables in SAP BW), but not within the Business Suite OLAP load benefits from parallel processing of queries Sizing of SAP HANA for SAP BW offers detailed information about the size of row and columnar store, including its expected temporal development HW setups are defined with these SAP BW requirements (SAP Note 1637145)
Data Distribution using SAP Business Suite on SAP HANA Scale-out scenarios with multiple worker nodes to scale memory are not yet released for Suite on HANA. It is recommended to scale up memory by using a hardware configuration that maximizes the available database memory. Suite on HANA plans to offer an own specific definition of data distribution. Regarding the availability of multi-node scenarios (scale out) for Suite on HANA, refer to SAP note 1825774. Redistribution of data tables is available. ●
●
●
618
Necessary if additional hosts are added to an existing scale-out cluster This process can be supported from within the SAP HANA studio: Landscape → Redistribution For more information, refer to the SAP HANA Administration Guide
Scale Out and High Availability High-availability enables the failover of a node within one distributed SAP HANA appliance. Failover uses a cold standby node and is triggered automatically.
Figure 470: Introduction to High Availability
Master name-server failure: In case of a master name-server failure, another of the remaining name-servers will become active master. Index-server failure: The master name-server detects an index-server failure and executes the failover. During the failover, the master name-server assigns the volume of the failed index-server to the standby server. Scale Out: Database Landscape
Host auto-failover is a local “N+m” (m is often 1) fault recovery solution that can be used in addition or as an alternative measure to system replication. One (or more) standby hosts are added to an SAP HANA system, and configured to work in standby mode. As long as they are in standby mode, the databases on these hosts do not contain any data and do not accept requests or queries. This means that they cannot be used for other purposes such as quality or test systems. When an active (worker) host fails, a standby host automatically takes its place. Since the standby host may take over operation from any of the primary hosts, it needs shared access to all the database volumes. This can be accomplished by a shared, networked storage server, by using a distributed file system, or with vendor-specific solutions that use an SAP HANA programmatic interface to dynamically detach and attach (mount) networked storage upon failover. Scale Out: High Availability Implementation
Figure 472: Scale Out: High Availability Implementation
In support of host auto-failover, database clients can be configured with the connection information of multiple hosts, optionally including the standby host. SAP HANA clients that were configured to reach the original host need to be sent to the standby host after host auto-failover. One approach is a network-based (IP or DNS) approach. Alternatively, SQL/MDX database clients can be configured with the connection information of multiple hosts, optionally including the standby host (a multi-host list is provided in the connection string). The client connection code (ODBC, JDBC, and so on) will try to connect to one of these (using a “roundrobin” approach), and upon successful connection receives the updated connection configurations. This ensures that clients can continue to reach the SAP HANA database, even after failover.
High availability scenarios in a multi-node cluster with a standby-node are released for the SAP Business Suite on HANA, but are restricted to the simplest case of two servers (one worker, one standby) only, since scale-out in general is not yet supported for Suite on HANA.
Note: Some use cases (for example, SAP BW powered by HANA) might have different requirements or recommendations for minimal setups (for example, BW has a defined setup for SAP HANA Scale-Out – SAP Note 1637145).
Note: In case of any problems during installation. for example, when you have to cancel the installation, see SAP note HANA upgrade fails with 'ERR: Cannot open install registry'
Business Example The results from the hardware sizing project, conducted with the SAP Quicksizer Tool and the knowledge of the SAP Hardware Partner, show that the SAP HANA production system should be a Scale Out system. It’s your task to install the SAP HANA Scale Out system.
Caution: The SAP HANA Scale Out system will be installed on the wdflbmt7194 and wdflbmt7195. This means that you have to work together with your colleague administrator on the other server. The system landscape for the Scale Out installation is shown in the figure.
Figure 474: SAP HANA Scale Out landscape
Log on to the SAP HANA Host using PuTTY Use PuTTY to verify that the nfs connection between hosts wdflbmt7194 and wdflbmt7195 is setup. Use the following username and password to log on: Username : ha200root Password : ha200_KPS$ 1. Check that the directory hanaDist is shared between the servers WDFLBMT7194 and WDFLBMT7195. Create and Mount the Directory If the check of task 1 was negative, continue with this task, if nor, proceed to the task Log On to the SAP HANA Server using Remote Desktop (RDP). A shared directory is needed, which is mounted on both hosts. 1. Create the directory /hanaDist/shared. 2. Mount the directory /hanaDist.
Log on to the SAP HANA Server using Remote Desktop (RDP) The SAP HANA Scale Out installation will be performed using the installation tool hdblcmgui. To be able to use the graphical installer, you need to logon to the SUSE Enterprise desktop on your SAP HANA host. 1. Use the Microsoft Remote Desktop (RDP) tool to connect once to the SUSE Enterprise desktop on the host wdflbmt7194 with the username and password provided in the previous task. 2. On host wdflbmt7194, use the following username and password: Username : ha200root Password : ha200_KPS$ Use hdblcmgui to Install the SAP HANA Scale Out System Start the SAP HANA Scale Out System installation by using the graphical installation tool hdblcmgui. 1. Install the SAP HANA Scale Out System using the properties specified below: Parameter
Value
SAP HANA System ID
MHS
Instance number
10
System Type
Multi-Host System
host wdflbmt7194
Master
host wdflbmt7195
Standby
Check the SAP HANA Scale Out file System After Installation After the installation, check whether everything was installed in the correct locations. 1. Use PuTTY or Remote Desktop to check the following directories: Directory
Note some of the content you see
/hanaDist /usr/sap /hanaDist/data /hanaDist/shared Check the SAP HANA Services Check that all of the SAP HANA service are running on the SAP HANA host. 1. Using PuTTY and the mhsadm user on the command line to check the SAP HANA services.
Business Example The results from the hardware sizing project, conducted with the SAP Quicksizer Tool and the knowledge of the SAP Hardware Partner, show that the SAP HANA production system should be a Scale Out system. It’s your task to install the SAP HANA Scale Out system.
Caution: The SAP HANA Scale Out system will be installed on the wdflbmt7194 and wdflbmt7195. This means that you have to work together with your colleague administrator on the other server. The system landscape for the Scale Out installation is shown in the figure.
Figure 474: SAP HANA Scale Out landscape
Log on to the SAP HANA Host using PuTTY Use PuTTY to verify that the nfs connection between hosts wdflbmt7194 and wdflbmt7195 is setup. Use the following username and password to log on: Username : ha200root Password : ha200_KPS$ 1. Check that the directory hanaDist is shared between the servers WDFLBMT7194 and WDFLBMT7195. a) Use PuTTY to logon on the host wdflbmt7195 and execute the command: DF -H | GREP /HANADIST. The result is shown in the following figure:
If not, continue with TASK 2 otherwise with TASK 3. Create and Mount the Directory If the check of task 1 was negative, continue with this task, if nor, proceed to the task Log On to the SAP HANA Server using Remote Desktop (RDP). A shared directory is needed, which is mounted on both hosts. 1. Create the directory /hanaDist/shared. a) Enter the following command: MKDIR /HANADIST/SHARED 2. Mount the directory /hanaDist. a) Enter the following command: MOUNT -A b) Check that /hanaDist is now mounted correctly by executing the following command: DF -H or more sophisticated Alternatively, you can use the command: DF -H | GREP /HANADIST As result, you should see more detailed information about this directory, as see in the figure, Check nfs setup. Log on to the SAP HANA Server using Remote Desktop (RDP) The SAP HANA Scale Out installation will be performed using the installation tool hdblcmgui. To be able to use the graphical installer, you need to logon to the SUSE Enterprise desktop on your SAP HANA host. 1. Use the Microsoft Remote Desktop (RDP) tool to connect once to the SUSE Enterprise desktop on the host wdflbmt7194 with the username and password provided in the previous task. a) Start Remote Desktop Connection using the Windows Start Menu → Search for: Remote Desktop Connection.
2. On host wdflbmt7194, use the following username and password: Username : ha200root Password : ha200_KPS$ a) When presented the Login to xrdp screen, enter the username and password provided above. Use hdblcmgui to Install the SAP HANA Scale Out System Start the SAP HANA Scale Out System installation by using the graphical installation tool hdblcmgui. 1. Install the SAP HANA Scale Out System using the properties specified below: Parameter
Value
SAP HANA System ID
MHS
Instance number
10
System Type
Multi-Host System
host wdflbmt7194
Master
host wdflbmt7195
Standby
a) To install the SAP HANA Multi-Host System MHS, follow the instructions in the following figures:
Figure 481: Enter Password, Check Summary and Installation Logs
Check the SAP HANA Scale Out file System After Installation After the installation, check whether everything was installed in the correct locations. 1. Use PuTTY or Remote Desktop to check the following directories: Directory
Note some of the content you see
/hanaDist /usr/sap /hanaDist/data /hanaDist/shared a) Change to the directories in the table below with the command: CD and display the content with the command: LS -L. When listing the directories you should see at least the following content: Directory
Note some of the content you see
/hanaDist
The directories data, log, and shared
/usr/sap
The directories MHS, hostctrl, and trans
/hanaDist/data
The directory MHS
/hanaDist/shared
The directory MHS
Check the SAP HANA Services Check that all of the SAP HANA service are running on the SAP HANA host. 1. Using PuTTY and the mhsadm user on the command line to check the SAP HANA services.
a) Use the already opened PuTTY session and change to the mhsadm user with the command: SU - MHSADM . b) To see if all the SAP HANA service are running, execute the command: HDB INFO. The following figure shows the output of the HDB info command.
LESSON OVERVIEW This lesson describes the techniques available for disaster recovery support. Business Example Hardware errors may be the course of data loss. To prevent your system from such a data loss, you plan to realize a scenario for disaster recovery support. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Describe the scenarios for disaster recovery support
Overview SAP HANA offers three levels of disaster recovery: support backups, storage replication, and system replication. Backups SAP HANA uses in-memory technology, but of course it fully persists any transaction that changes the data, such as row insertions, deletions, and updates, so it can resume from a power outage without loss of data. SAP HANA persists two types of data to storage: transaction redo logs and data changes in the form of savepoints. A transaction redo log is used to record a change. To make a transaction durable, it is not required to persist the complete data when the transaction is committed. Instead, it is sufficient to persist the redo log. Upon an outage, the most recent consistent state of the database can be restored by replaying the changes recorded in the log, redoing completed transactions and rolling back incomplete ones. A savepoint is a periodic point in time, when all the changed data is written to storage, in the form of pages. One goal of performing savepoints is to speed up the restart: When starting up the system, logs need not be processed from the beginning, but only from the last savepoint position. Savepoints are coordinated across all processes (called SAP HANA services) and instances of the database to ensure transaction consistency. By default, savepoints are performed every five minutes, but this can be configured. Savepoints normally overwrite older savepoints, but it is possible to freeze a savepoint for future use; this is called a snapshot. Snapshots can be replicated in the form of full data backups, which can be used to restore a database to a specific point in time. This can be useful in the event of data corruption, for instance. In addition to data backups, smaller periodic log backups ensure the ability to recover from fatal storage faults with minimal loss of data. Savepoints can be saved to local storage, and the additional backups can be additionally saved to backup storage. Local recovery from the crash uses the latest savepoint, and then replays the last logs, to recover the database without any data loss. If the local storage was
corrupted by the crash, it is still possible to recover the database from the data and log backups, possibly with loss of some data. Regular shipping backups to a remote location over a network or via couriers can be a simple and relatively inexpensive way to prepare for a disaster. Depending on the frequency and shipping method, this approach may have a recovery time ranging from hours to days. Storage Replication One drawback of backups is the potential loss of data between the time of the last backup and the time of the failure. Therefore, a preferred solution is to provide continuous replication of all persisted data. Several SAP HANA hardware partners offer a storage-level replication solution, which delivers a backup of the volumes or file system to a remote, networked storage system. In some of these vendor-specific solutions, which are certified by SAP, the SAP HANA transaction only completes when the locally persisted transaction log has been replicated remotely. This is called synchronous storage replication. Synchronous storage replication can be used only where the distance between the primary and backup site is relatively short (typically 100 kilometers or less), allowing for submillisecond round-trip latencies. Due to its continuous nature, storage replication (sometimes also called remote storage mirroring) can be a more attractive option than backups, as it reduces the amount of time between the last backup and a failure. Another advantage of storage replication is that it also enables a much shorter recovery time. This solution requires a reliable, high bandwidth and low latency connection between the primary site and the secondary site. See SAP Note 1755396 Released DT solutions for SAP HANA with disk System Replication. System Replication System replication employs an “N+N” approach, with a secondary standby system that is configured as an exact copy of the active, primary system. Each service instance of the primary SAP HANA system communicates with a counterpart in the secondary system. The secondary system can be located near the primary system to serve as a rapid failover solution for planned downtime, or to handle storage corruption or other local faults, or, it can be installed in a remote site to be used in a disaster recovery scenario. Like storage replication, this disaster recovery option requires a reliable link between the primary and secondary sites. The instances in the secondary system operate in recovery mode. In this mode, all secondary system services constantly communicate with their primary counterparts, replicate and persist data and logs, and load data to memory. The main difference is that the secondary system does not accept requests or queries.
Storage Replication The mirroring is offered on the storage system level. It will be offered together with the appliance as a special offering by our partners. The hardware partner will define how this concept is finally realized with his operation possibilities. Performance impact is to be expected on data changing operations as soon as the synchronous mirroring is activated. The impact depends strongly on various external factors like distance, connection between data centers, and so on. The synchronous writing of the log with the concluding COMMITs is the crucial part here. In case of an emergency, the primary data center is not available anymore and a process for the take-over must be initiated. So far, many customers have requested a manual process here, but an automated process can also be implemented. This take-over process then would end the mirroring officially, will mount the disks to the already installed SAP HANA software and instances, and start up the secondary database side of the cluster. If the hostnames and instance names on both sides of the cluster are identical, no further steps with HDBRENAME are necessary.
Storage Replication with QA and DEV System on Second Site It would be possible to run a development or QA instance of the three-tier installation on this secondary cluster hardware, simply to utilize it until the take-over is executed. The take-over then would stop these Dev. or QA instances and mount the production disks to the hosts. It would require an additional set of disks for the Dev. and QA instance. Several hardware partners are planning to offer this additional option of active-active operation. The same applies to asynchronous mirroring solutions for distant data centers (>100km). Some hardware partners have concepts available to offer this asynchronous Storage Replication, see SAP note 1755396.
Figure 485: Storage Replication with QA and Dev. System on Second Site
System Replication Usually system replication is set up so that a secondary standby system is configured as an exact copy of the active primary system, with the same number of active hosts in each system. The number of standby hosts need not be identical. With multitier system replication you have one primary system and can have multiple secondary systems. Each service instance of the primary SAP HANA system communicates with a counterpart in the secondary system.
The secondary system can be located near the primary system to serve as a rapid failover solution for planned downtime, or to handle storage corruption or other local faults, or, it can be installed in a remote site to be used in a disaster recovery scenario. Also both approaches can be chained together with multitier system replication. Like storage replication, this disaster recovery option requires a reliable connection channel between the primary and secondary sites. The instances in the secondary system operate in recovery mode. In this mode, all secondary system services constantly communicate with their primary counterparts, replicate and persist data and logs, and load data to memory. The main difference to primary systems is that the secondary systems do not accept requests or queries. A cluster across data centers with DB controlled transfer is realized by System Replication. Replication Modes When the secondary system is started in recovery mode, each service component establishes a connection with its counterpart, and requests a snapshot of the data in the primary system. From then on, all logged changes in the primary system are replicated. Whenever logs are persisted in the primary system, they are also sent to the secondary system. A transaction in the primary system is not committed until the logs are replicated. What this means in detail, can be configured by choosing one of the log replication modes:
System Replication: Advantages and Disadvantages The advantages of system replication include the following: ●
●
●
●
Memory is continuously loaded on a secondary site as a preparation for the possible takeover and occupies resources. Switch over faster than with storage replication/mirroring (2-5 min.). During the take-over to the secondary site, only a roll.forward since the latest synchronization point is necessary. Very short performance ramp (only minutes not hours without preparation).
The disadvantages of system replication include the following: ●
The hardware (Memory & CPU) is actively used on the secondary site for the standby/ shadow processes.
Shadow Database Solution SAP HANA System Replication is SAP’s shadow database solution with SAP HANA. The technology is similar to other shadow technologies on the database market. SAP has extended this solution with new features (async, near zero downtime maintenance, secondary backups, multiple Secondaries (1:n), and so on.) and optimized the transfer process. Today SAP HANA System Replication features offer a stable and easy to implement shadow database solution. The SAP HANA database also supports log shipping by recovering log backup files on a secondary system. This log shipping technology is based on the same technique as the shadow database solution.
There are also plans to offer the secondary site for active operation for applications like readonly reporting. This would offer a real active/active setup (from the application perspective) with the option to withdraw reporting load away from the primary SAP HANA system to the shadow SAP HANA system. System Replication with QA and DEV System on 2nd Site
Figure 489: System Replication with QA and Dev. System on 2nd Site
The shadow SAP HANA instance on Secondary needs about 50 to 100 GB of main memory to receive the log and data packages and transfer this to the local persistence. Take care to keep this memory free by limiting the resource requirements on the other QA or DEV systems. Define the max. memory usage of the other SAP HANA instance with the database parameter global_allocation_limit so that the sum of all instances fit and keep about 100 GB free for the shadow instance. Use secondary servers for non-productive systems under the following conditions: ●
Turn off column preload (preload_column_tables=false) in primary and secondary.
●
Non-productive systems must have their own disk infrastructure.
●
Non-Productive systems have to be turned off with takeover of the productive system.
●
Keep some memory free for shadow database instances on the secondary hardware.
●
With running QA/DEV and using the resources of the secondary HW, the secondary shadow SAP HANA instance cannot be prepared for the take-over (preload of table structures), and the performance ramp will be considerably longer.
System Replication with QA and DEV System on Second Site: Advantages and Disadvantages The advantages of system replication with a QA and DEV system on second Site include the following: ●
QA/DEV. operated on secondary site (mixed cost calculation)
Synchronous and asynchronous solution available Impact of synchronous solution on Primary is at about 10% (in contrast to about 25% with storage replication) Transfer process from Primary to Secondary is optimized and lesser transfer amount necessary compared to Storage Replication. During the take-over to the secondary site, only a roll forward since the latest data synchronization point is necessary.
The disadvantages of system replication with a QA and DEV system on second Site include the following: ●
●
Table and column data cannot continuously be loaded into memory on the secondary site. Hardware (memory and CPU) is actively used for QA/DEV. and partly for the standby/ shadow processes.
●
Take-over similar to storage mirroring (20 to 30 min. at best).
●
Performance Ramp is similar to storage mirroring (1-3 hours).
●
QA and Dev. need their own disk infrastructure carefully separated to not face influencing effects on each other.
Minimal Setup for System Replication The minimal setup for System Replication in one data center for fast takeovers is shown in the following figure.
Figure 490: Minimal Setup for System Replication
Operation Modes There are two different operation modes for the configuration of system replication.
Note: Comparison between delta_datashipping and logreplay with regard to network traffic shows significantly reduced network traffic. Delta data shipping shows peaks roughly every 10 minutes when delta data shipping is triggered whereas logreplay shows continuously shipped log buffers. System Replication with Operation Mode Delta Datashipping
Figure 492: System Replication with Operation Mode Delta Datashipping
The following are the events for the start of transport: 1. The primary system creates an internal data package similar to a full data backup and transfers this initially to the secondary site. The transport happens asynchronously. 2. Log information is started to be transferred in parallel to the initial data transfer. The log is transported asynchronously until the commit of the finished transaction occurs. With the commit, also all other not yet transferred or written log information and the final commit
have to be written synchronously before the primary productively used database is allowed to continue transactional work. 3. All load and unload operations of main indexes and table columns are monitored and offered with the incremental data transfer to the secondary system. These main indexes and table columns are then loaded or unloaded equivalently to memory to be prepared for the takeover. The following are the events during incremental transport: 1. Small incremental backups with the help of the shadow memory concept operation of SAP HANA are started to transfer delta data package regularly every 10 minutes (default parameter setting is 600 seconds) to the secondary site. 2. With this delta data information, also information of the loaded main indexes into SAP HANA on the primary site are transferred to the secondary site to prepare the main memory there with these main indexes on the secondary site too. System Replication with Operation Mode Log Replay
Figure 493: System Replication with Operation Mode Log Replay
Since the first version of system replication, the operation mode delta_datashipping has been the default replication method. With the operation mode logreplay no delta data shippings are necessary anymore and the takeover time have been reduced and more components are already initialized at replication time. In case of operation modelogreplay system Replication uses an initial data shipping to initialize the secondary site. After that only log shipping is done and log buffers received by the secondary are replayed there. Savepoints are executed individually for each service and column table merges are executed on the secondary site. With the operation mode logreplay, log segments can be marked as retained so that they can sync a secondary system after a disconnect. With continuous log replay, delta data shipping cannot be used to sync a secondary site anymore. This is because although the primary and secondary persistence is logically compatible they are no longer physically compatible. This means the data, that is contained in
the persistence is the same, but the layout of the data on pages can be different on the secondary site. Therefore a secondary site can sync via delta log shipping only. This is relevant for the following use cases: ●
●
The secondary site has been disconnected for some time (for example, because of a network problem or temporary shutdown of secondary site) A former primary site has been registered for failback
The secondary site only uses log of the online log area of the primary SAP HANA system for syncing. The log must be retained for a longer time period than before to be able to sync the secondary site. If syncing via delta log shipping does not work, for example because the log has been reused, a full data shipping becomes necessary. To avoid this, if possible, the concept of Log Retention has been introduced.
Setup of System Replication The configuration tasks on the primary and secondary systems to set up system replication using the SAP HANA studio are shown in the following figures. With this configuration, you have the possibility to recover from a data center outage by switching to a secondary site.
Figure 494: Setup of System Replication
The following are the configuration steps for the setup of System Replication: 1. The primary system is informed to enable System Replication. 2. The secondary database has to be stopped. Content will be wiped out during initial load with full data backup later during initial start of replication. 3. The secondary system is advised to connect to the primary system and informs about the attempt to start the System Replication standby process.
This process is secured with certificates, and so on.
●
Only one command is needed: HDBNSUTIL.
●
●
●
Both sides have to have the same number of active and standby hosts with the same sizing (memory, CPU). SAP HANA itself handles the relationships of, for example, scale-out setups on both sides (primary to secondary) and how communication is established with which counterpart. Communication takes place internally between sites on TREXnet.
Enable the Primary System The steps to configure the Primary System using SAP HANA studio are outlined in the figure, Enable the Primary System.
Figure 495: Enable the Primary System
Enable Register and Start Secondary System with HANA Studio The steps to enable register and the Secondary System using SAP HANA studio are outlined in the figure, Enable Register and Start Secondary with HANA Studio.
Figure 496: Enable Register and Start Secondary System with HANA Studio
Check and Monitor System Replication After setting up the secondary system for system replication, you can monitor the status of the replication in SAP HANA studio. The Administration Editor of the primary system shows the general status and detailed information of the system replication.
Performing a Takeover If a disaster occurs where the primary data center is no longer available, a failover to the secondary data center takes place. In case of a takeover, the secondary site can find the latest savepoint in place on the data disk area. This is the starting point like in case of the usual database restart, but a lot of huge data packages (main indexes) are already preloaded in memory like on primary before takeover. This supports the restart dramatically. Based on this initial savepoint on secondary, the log replay can start and roll the database forward to the latest point in time. ●
●
648
In a synchronous state, no committed transaction is lost. The open transaction will have to be restarted and clients will reconnect for this to SAP HANA. Synchronous setups are meant for distances up to 50-100 km. In case of an asynchronous setup, there probably will be some loss. This depends on the time period where the secondary site was not reachable or the line was too weak to cope with the data transfer fast enough. These setups are usually used for longer distances between data centers of 100 km and more, but are also possible if the impact of the standby process is not allowed to feedback into daily operation (change performance).
This script called landscapeHostConfiguration.py is provided so that SAP HANA itself can communicate its status: ●
SAP HANA is OK.
●
SAP HANA will be OK after a host auto-failover, for example.
●
Or not enough instances are started and a takeover would be useful.
A takeover is only recommended when the return code from the script is 1 (error).
Zero Downtime Maintenance SAP HANA offers Zero Downtime Maintenance together with SAP HANA System Replication. System Replication can be used to upgrade your SAP HANA systems because the secondary system can run with a higher software version than the primary system. As a prerequisite, System Replication is configured and active between two identical SAP HANA systems. If System Replication is active, you can first upgrade the secondary system to a new revision and have it take over the role of the primary system. The takeover takes few minutes only and committed transactions or data are not lost. You can then do an upgrade on the primary system, which is now in the role of secondary.
Figure 500: Zero Downtime Maintenance
The secondary system can be initially installed with the new software version or upgraded to the new software version when replication has already been configured. After the secondary has been upgraded, all data has to be replicated to the secondary system (having already the new software version). When the secondary system is ACTIVE (all services have synced), a takeover has to be executed on the secondary system. This step makes the secondary system productive with the new software version.
Featured by SAP NetWeaver ABAP stack Based on connectivity suspend feature of the SAP NetWeaver ABAP stack (SAP note 1913302)
●
-
-
●
●
DBSL of the database interface decouples transaction management between ABAP and HANA database This keeps transaction on ABAP layer alive and allows to change components (software versions) on the layers below on secondary (shadow) HANA instance
Further information also in Step-by-Step Implementation Guide for SAP HANA System Replication: https://scn.sap.com/docs/DOC-47702 Hardware mix (SAP note 1984882- Using HANA System Replication for Hardware Exchange with minimum Downtime)
LESSON SUMMARY You should now be able to: ●
Describe the scenarios for disaster recovery support
Lesson 2 Administration of Multitenant Database Containers
665
Lesson 3 Backup and Recovery of Multitenant Database Containers
676
UNIT OBJECTIVES ●
●
Explain the architecture of multitenant database containers. Distinguish between global administration tasks and administration tasks for a tenant database
●
Manage and control the memory and CPU usage of a tenant database
●
Describe security aspects when using multitenant database containers
●
Explain the backup concept for multitenant database containers.
LESSON OVERVIEW This lesson gives a brief overview of the architecture of multitenant database containers. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the architecture of multitenant database containers.
Overview of Architecture and Technology In a multiple-container system, only the system database runs the name server. The name server contains landscape information about the system as a whole, including which tenant databases exist. It also provides indexserver functionality for the system database. Unlike the name server in a single-container system, the name server of the system database in a multiple-container system does not own 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. Tenant databases require only an own index server. Servers that do not persist data, such as the compile server and the preprocessor server, run on the system database and serve all databases. The XS server runs embedded in the (master) index server of the tenant database by default, although it can be added as a separate service if necessary. The SAP Web Dispatcher, which runs as a separate database service on the system database, is used to route incoming HTTP requests from clients to the correct XS server based on virtual host names. This is part of network configuration. A SAP HANA multitenant database containers system has one SID and one HANA software version: ●
Shared installation of database system software
●
Tenant databases are identified by name or port
●
Additive sizing for all tenant database
Strong isolation features, each tenant database has its own: ●
●
Database admin and end users, database catalog, repository, persistence, backups, traces, and logs Tenants memory sizing and CPU consumption can be configured independently
Integration with SAP HANA data center operation procedures, housekeeping, backups, and so on.
The system database is created during installation of a multiple-container system. It contains information about the system as a whole and all tenant databases. It is used for central system administration. A multiple-container system has exactly one system database. It is created during system installation or migration from a single-container system. It contains the data and users for system administration. System administration tools, such as the SAP HANA studio, 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 does not 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). Installation of the System Database The System database of an SAP HANA multitenant database container system can be installed using the SAP HANA database lifecycle manager. Installing the System database is a prerequisite step for configuring SAP HANA multitenant database containers from the SAP HANA cockpit or the SAP HANA studio. During installation you have to select the multiple_containers value for the Database Mode property to configure the system to support multitenant database containers. The Database Mode specifies whether the system is installed in single-container mode (default) or multiplecontainer mode. The system database is created during the installation process. A system administrator must create the required tenant databases after installation.
Figure 503: MDC: Installation of the System Database
By default, all database processes in an MDC system run under the same default operating system user adm. Tenant databases are self-contained/isolated in terms of users, database catalog, repository, logs, etc. MDC: Database Isolation The Database Isolation specifies the isolation of the tenant databases on operating system level for multitenant database container SAP HANA systems. By default, all database processes in a multiple-container system run under the default OS user adm. If it is important to mitigate against cross-database attacks through OS mechanisms, you can configure the system for high isolation. In this way, the processes of individual tenant databases must run under dedicated OS users belonging to dedicated OS groups. Databasespecific data on the file system is subsequently protected using standard OS file and directory permissions.
The properties of a system with high isolation level are as follows: ●
●
●
Processes of individual tenant databases run under the dedicated OS users belonging to dedicated OS groups. Database-specific data on the file system is protected using OS file and directory permissions. Note: adm does not have OS access to tenant data volumes, log volumes, or backups, but can access tenant-specific trace and configuration files. Operations that require OS access are restricted to users with the correct permissions. This adds another layer of protection between tenants: tenant administrators with access to the OS cannot access other tenants or the system database using OS commands.
MDC HANA Studio For monitoring and administration of multitenant database container systems you can use SAP HANA cockpit and SAP HANA studio. SAP HANA studio has been adapted to be able to:
658
●
Connect to the system database and any tenant database
●
Display the database type in the system view
●
Monitor the system database and any tenant database using the administration editor
MDC HANA Cockpit SAP HANA cockpit can be used to monitor the system database and any tenant database. Therefore a new catalog SAP HANA System Administration is available in the SAP HANA cockpit, which allows you to monitor and manage all tenant databases. The following tiles are available: Manage Databases Indicates overall system health and provides access to the Manage Databases app where you can monitor the status and resource usage of individual databases, as well as perform other administration tasks System Alerts Indicates the number of high and medium alerts currently raised in tenant databases and provides access to the Alerts app where you can view and analyze alert details
Tiles of the SAP HANA Database Administration catalog are used to administer an individual database – either a single-container system, a tenant database, or the system database of a multiple-container system. Installation of a Tenant Database During the installation of a multiple-container system, only the system database is initially created. You create and configure tenant databases afterward from the system database using the Manage Databases app of the SAP HANA cockpit or the SQL command CREATE DATABASE. The new tenant database is created and possibly started, and appears in the Manage Databases app.
Monitoring of Multitenant Database Container Systems Monitoring using the Manage Databases app: ●
●
●
Monitor the overall availability, resource usage, and performance of tenant databases and the system database itself from the system database To examine a particular database in more detail, you can drill-down further by clicking the aspect you are interested in (for example, database name, alerts, or used memory) Further operations on a tenant database (stop, start, and delete) are available in the footer toolbar
Figure 508: MDC: Monitoring using the Manage Databases App
Port Assignment in Tenant Databases Every tenant database in a multiple-container system has dedicated ports for SQL- and HTTP-based client communication, as well as for internal communication. However, there are no standard port number assignments. Port numbers are assigned automatically from the available port number range according to availability at the time the database is created or a service is added. Administrators can also explicitly specify which port numbers to use when they create a tenant database or add a service. The only exception to this is the tenant database that is automatically created when you convert a single-container system to a multiple-container system. This database retains the port numbers of the original singlecontainer system. The default port number range for tenant databases is 340—399. This means that the maximum number of tenant databases that can be created per instance is 20. However, you can increase this by reserving the port numbers of further instances. You do this by configuring the property [multidb] reserved_instance_numbers in the global.ini file. The default value of this property is 0. If you change the value to 1, the port numbers of one further instance are available (for example, 30040—30199 if the first instance is 00). If you change it to 2, the port numbers of two further instances are available (for example, 30040— 30299 if the first instance is 00). And so on.
HTTP(S) Client Access The XS server allows Web-based applications to access SAP HANA via HTTP(s). The internal Web Dispatcher of the SAP HANA system manages these incoming HTTP(s) requests. To allow applications to send requests to specific databases in a multiple-container system, every tenant database needs an alias hostname. Requests to the alias hostname can then be forwarded to the XS server of the corresponding tenant database. Requests with the physical hostname in the HTTP host header are forwarded to the XS server running on the system database. The default HTTP ports are used in all cases, that is, 80 (HTTP) and 43 (HTTPs). Alias hostnames are mapped to internal HTTP(s) ports so that incoming requests can be routed to the correct database. You configure the internal SAP Web Dispatcher by specifying the URLs by which tenant databases are publicly accessible in the xsengine.ini file of each individual tenant database. It is not necessary to specify the URL of the system database, this is done automatically.
Scale-Out-Scenario A system with multitenant database containers can be distributed across several hosts. To ensure availability, an instance of the system database runs on all hosts (worker and standby) in a single master and multiple workers configuration. Tenant databases can be created on worker hosts and existing databases can be scaled out through the addition of services. If a host fails, the standby instance will fail over all active databases and their services. The following figure shows a scale-out-scenario for a multiple-container system with 3 tenant databases distributed across 4 hosts (3 worker and 1 standby). If host 2 goes down, the standby host becomes active. The tenant DBs normally running on host 2 will become active on the standby host.
Migration of a Single Database to a Multitenant Database System SAP HANA single database system can be migrated to a multitenant database system. This step is irrevocable. ●
System database will be generated
●
Single DB will be converted into a tenant DB automatically
●
No changes to application or customer data
●
Migration does not occur automatically with SPS09 upgrade -
Must be explicitly triggered
-
Single DB is SPS09 default, MDC is optional
LESSON SUMMARY You should now be able to: ●
664
Explain the architecture of multitenant database containers.
LESSON OVERVIEW This lesson gives you an overview on the administration tasks when using multitenant database containers. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Distinguish between global administration tasks and administration tasks for a tenant database
●
Manage and control the memory and CPU usage of a tenant database
●
Describe security aspects when using multitenant database containers
Administration Tasks Overview In SAP HANA systems that support multitenant database containers, there is a distinction between administration tasks performed at system level and those performed at database level. Unlike a single-container system in which system and database are perceived as a single unit and are, therefore, administered as one, multiple-container systems have two levels of administration. Some administration tasks are performed in the system database and apply globally to the system and all its databases. Global Administration Tasks ● Starting and stopping the whole system ●
Monitoring the system
●
Configuring parameters in configuration (*ini) files at system level
●
Setting up and configuring tenant databases, for example:
●
-
Creating and dropping tenant databases
-
Disabling features on tenant databases
-
Configuring system- and database-specific parameters in configuration (*ini) files
-
Scaling out tenant databases by adding services
-
Backing up individual databases
Backing up the whole system, including all tenant databases
Recovering the whole system, including all tenant databases
Some administration tasks are performed in the database and apply only to that database. They include, for example: ●
Monitoring the database
●
Provisioning database users
●
Creating and deleting schemas, tables, and indexes in the database
●
Backing up the database
●
Configuring database-specific parameters in configuration (*ini) files
Start and Stop As a system administrator, you can start or stop tenant databases either individually, or all at once by starting the whole system. Starting and Stopping of an SAP HANA system containing multitenant database containers affects the system database and all tenant databases.
Note: If you stop a tenant database individually, you can subsequently only start it again individually. It will not be started with a full system (re)start. A tenant database could be stopped and started individually, as follows: ●
●
666
From the system database, using the SQL statement ALTER SYSTEM START | STOP DATABASE From the Manage Databases app in SAP HANA cockpit, by selecting the tenant database and choosing Stop Tenant Database or Start Tenant Database in the footer toolbar
Lesson: Administration of Multitenant Database Containers
Figure 511: MDC Start Stopp
Note: If you stopped the database, it is a hard stop. The database is stopped immediately even if users are connected. Open transactions are aborted and rolled back; no savepoint operation is forced. It is not possible to back up a stopped database.
Setting Parameters and Managing Resources The configuration (*.ini ) files of the SAP HANA system contain properties for configuring the system as a whole and individual tenant databases, hosts, and services. In multiple-container systems, system configuration files have an additional layer database to facilitate the configuration of properties for individual databases. Database-specific properties can be configured at both the system and database level. Those configured at the system level apply to all databases, while those configured at the database level apply to a specific database. It is possible to configure database-specific properties at the system level only from the system database. Database-specific properties can be configured at both the database level from the system database or from the relevant database. For properties that can be configured at the system, host, and database level, the value configured at database level takes precedence. If properties are configured at database level, a database-specific configuration file is stored at the following location on the server: /hana/shared/$SID/global/hdb/custom/config/DB_
Disable Features on a Tenant Database Some features of the SAP HANA database are not required or desirable in certain environments, in particular features that provide direct access to the file system, the network, or other resources. To maximize your control over the security of your system, you can disable these features in tenant databases, for example import and export operations or the ability to back up the database. The system view M_CUSTOMIZABLE_FUNCTIONALITIES provides information about those features that can be disabled and their status. This view exists in both the SYS schema of every database, where it contains database-specific information, and in the SYS_DATABASES schema of the system database, where it contains information about the enablement of features in all databases. Features in tenant databases are disabled in the customizable_functionalities section of the global.ini file. Tenant database administrators can see which features are enabled in their database using the view M_CUSTOMIZABLE_FUNCTIONALITIES (SYS).
Figure 512: MDC: Disable Features in tenant databases
Note: Not all features are required or desirable in all environments, for example, features that provide direct access to the file system, the network, or other critical resources, or features that are only required in specific deployment scenarios such as Dynamic Tiering. All restricted features are enabled in the system database and cannot be disabled there.
Lesson: Administration of Multitenant Database Containers
Configuration change blacklist To ensure the stability and performance of the overall system or for security reasons, it may be necessary to prevent certain system properties from being changed by tenant database administrators, for example, properties related to resource management. A configuration change blacklist (multidb.ini) is available for this purpose. This blacklist contains several critical properties by default. You can customize the default configuration as well as add further properties by editing the file in the SAP HANA studio.
Figure 513: Configuration Change Blacklist
Note: Properties in the blacklist can still be configured at all levels in the system database. Tenant database administrators cannot change the properties in the configuration change blacklist. If they try, they see the error message: Change not allowed for tenant database.
Resource Management of Multitenant Database Containers It is possible to manage and control the memory and CPU usage of your multiple-container system by configuring limits for individual tenant databases. Several system properties allow you to influence the allocation of memory and CPU resources in SAP HANA systems. System properties (INI) files have a database layer to facilitate the configuration of properties for individual tenant databases. The following properties are particularly useful for influencing the resource consumption of tenant databases: ●
Limits the maximum amount of memory that can be allocated to all processes of a given tenant DB. ●
CPU Limits the number of concurrently running threads used by the SAP HANA job executor.
The parameter memorymanager.allocationlimit – in file indexserver.ini of each tenant DB limits the maximum amount of memory that can be allocated to all processes of a given tenant DB. The current allocation limit can be viewed by selecting ALLOCATION_LIMIT from M_SERVICE_MEMORY Example (From within the SYSTEMDB): ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'DATABASE', 'MYDB') SET ('memorymanager', 'allocationlimit') = '8192' WITH RECONFIGURE
Note: Stop and start is not required if ‘WITH RECONFIGURE’ is included. The parameter execution.max_concurrency - in file indexserver.ini of each tenant DB directly influences the maximum number of CPU cores that can be utilized per tenant DB. This parameter limits the number of concurrently running threads used by the SAP HANA job executer the current runtime value can be viewed by select ' MAX_CONCURRENCY' from the 'M_JOBEXECUTORS' view Example (From within the SYSTEMDB): ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'DATABASE', 'MYDB') SET ('execution', 'max_concurrency') = '4' WITH RECONFIGURE
Note: Stop and start is not required if ‘WITH RECONFIGURE’ is included.
System Views and Diagnosis Files in Multiple-Container Systems The SYS schema containing SAP HANA system views is available in the system database and all tenant databases. Several views contain specific information for monitoring multitenant database containers. System views are located in the SYS schema. In a system with multitenant database containers, every database has an SYS schema with system views that contain information about that database only. In addition, the system database has a further schema, SYS_DATABASES, which contains views for monitoring the system as a whole. The views in the SYS_DATABASES schema provide aggregated information from a sub-set of the views available in the SYS schema of all tenant databases in the system. These union views have the additional column DATABASE_NAME to allow you to identify to which database the information refers. To be able to view information in these views, you need the system privilege DATABASE ADMIN. In a system with multitenant database containers, the trace files of the system database are stored at the default location: /usr/sap//HDB//trace. Trace files of tenant databases are stored in a sub-directory named DB_.
Lesson: Administration of Multitenant Database Containers
Security Administration Unlike a single database system in which system and database are a single unit and administered as one, additional security aspects have to be considered in a MDC system. Security Aspects of Multitenant Database Containers ● Clients connect via dedicated ports to individual databases ●
Security-relevant features are configurable per database
●
Only controlled access between databases
●
Tenant databases are created and managed from the system database
Note: No direct access to tenant database table content from the system database
Security Functions Overview
Figure 514: Security Functions Overview
Further Security Functions Security Aspects of Multitenant Database Containers Separate user administration for the system database and all tenant databases.
●
●
Individual auditing for every database.
●
Individual data volume encryption for tenant databases.
Separate encryption for the external and internal communication channels of individual tenant databases.
Users and Authorizations In a system with multitenant database containers each tenant database has its own database admin and end users. The system database and all tenant databases each have their own SYSTEM user. The SYSTEM user of the system database has additional privileges for managing tenant databases, for example, creating and dropping databases, changing configuration (*.ini) files of databases, and performing database-specific data backups. In a multiple-container system, system privileges granted to users in a particular multitenant database container authorize operations in that database only. The only exception is the system privilege DATABASE ADMIN. This system privilege can only be granted to users of the system database. It authorizes the execution of operations on individual tenant databases. For example, a user with DATABASE ADMIN can create and drop tenant databases, change the database-specific properties in configuration (*.ini) files, and perform database-specific backups.
Figure 515: Overview: User Administration
In a multiple-container system, privileges granted to users in a particular database authorize access to and modification of database objects in that database only. That is, unless crossdatabase access has been enabled for the user. This is made possible through the association of the requesting user with a remote identity on the remote database. Cross-Tenant Database Access There are use cases where queries should run across tenant databases. In multiple-container systems, read-only queries across database containers are supported but not enabled by default.
Lesson: Administration of Multitenant Database Containers
Read-only queries between multitenant database containers are possible through the association of the requesting user with a remote identity on the remote database or databases. Cross-database queries (federation) are supported in SQL engine and Calculation engine. Every tenant database in a multiple-container system is self-contained with its own isolated set of database users and isolated database catalog. However, to support in particular crossapplication reporting, cross-database SELECT queries are possible. This means that database objects such as tables and views can be local to one database but be read by users from other databases in the same system. A user in one database can run a query that references objects in another database if the user is associated with a sufficiently privileged user in the remote database. This associated user is called a remote identity. This is the user who executes the query (or part of the query) in the remote database and therefore the user whose authorization is checked. Cross-database access is not enabled by default and must be configured before such user mappings can be set up.
Figure 516: Cross Database Queries between Multitenant Database Containers
By default cross database access between tenants is inactive. To be able to run queries spanning multiple tenant databases the global cross database access switch has to be turned on. A whitelist of databases that are allowed to communicate with each other also has to be set up. Activation of Cross-Tenant Database Access ● Turn on cross-tenant database communication (run this from SYSTEM database only). ●
●
Whitelisting a cross-tenant database communication channel (from SYSTEM database only). Add a remote identity to the requesting user on the remote database.
Hint: Communication channels are uni-directional by default (that is, a “one way street”). They can be made bi-directional by explicitly defining the configuration in reverse. If enabled, a user from one tenant database can execute queries in another tenant database if this user is mapped to a user with “remote identity” there, as follows: ●
A user in the target database can only be associated with one user in the source database.
●
The association is unidirectional.
●
Only the SELECT privileges of the user in the target database are considered during a cross-database query, all other privileges of the remote user are ignored.
Auditing Auditing can be enabled individually for every database in a multiple-container system. For tenant databases, the relevant system property ([auditing configuration] global_auditing_state) is set in the global.ini file of the database . For the system database, it is set in the nameserver.ini file. Tenant database administrators cannot configure audit trail targets independently for their database. The default target for all audit trails in tenant databases is internal database table. The system administrator may change the default audit trail targets for tenant databases by changing the relevant property ([auditing configuration] *_audit_trail_type) in the global.ini file.
Encryption in Multitenant Database Containers Data volume encryption can be enabled individually for tenant databases in a multiplecontainer system. Ideally, you enable encryption immediately after installation or upgrade of SAP HANA. This also applies to systems installed in multiple-container mode. Any subsequently created tenant databases will then automatically have encryption enabled. If a particular tenant database does not require encryption, the tenant database administrator can switch it off independently of the system in the Security editor of the SAP HANA studio. If encryption is not enabled after system installation, you can enable it retroactively in the Security editor either for all tenant databases together by making the setting in the system database, or for individual tenant databases by making the setting in the relevant tenant database.
Caution: Enabling data volume encryption after a tenant database has been created and is already in operation does not provide complete protection. Due to the shadow memory nature of SAP HANA persistence, outdated versions of pages may still remain unencrypted on disk. To attain complete protection, you need to perform a data backup, drop the tenant database, clean the disk space, create the tenant database again, enable encryption, and then perform a data recovery.
Lesson: Administration of Multitenant Database Containers
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) can be configured separately for the external and internal communication channels of individual tenant DBs. Therefore separate key store and trust stores must be available and configured for each tenant DB. In MDC systems, certificates are stored and configured per tenant database. Storing certificates in the database simplifies the configuration and makes certificate management available to tenant administrators. This is especially relevant for hosting scenarios where tenant administrators usually do not have access to the file system.
Note: If you decide to store certificates in the file system for an MDC system, you need to set additional .ini file parameters. If certificates are stored in the database, the related ini file parameters should be disabled in tenant databases. Refer to the SAP HANA Security Guide for details.
LESSON SUMMARY You should now be able to: ●
Distinguish between global administration tasks and administration tasks for a tenant database
●
Manage and control the memory and CPU usage of a tenant database
●
Describe security aspects when using multitenant database containers
Backup and Recovery of Multitenant Database Containers
LESSON OVERVIEW This lesson explain the backup concept for multitenant database containers. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Explain the backup concept for multitenant database containers.
●
Perform a backup of the system database
●
Perform a backup a tenant database
Backup of Multitenant Database Containers Multitenant database containers follow the usual SAP HANA backup and recovery principles, as follows: ●
●
●
●
Log backups are carried out automatically if the log mode is set to NORMAL (recommended for production) Backup information is stored in the backup catalog Different backup destinations are supported: backups to the file system, backups to 3rd party backup tools
●
Database copies using backup and recovery are supported for individual databases
●
Recovery options: point-in-time recovery, recovery to a specific data backup
●
676
Data backups are initiated manually or scheduled via scripts or tools such as DBA Cockpit
Tool support: SAP HANA Studio, SAP HANA Cockpit, DBA Cockpit, command line (SQL statements)
Lesson: Backup and Recovery of Multitenant Database Containers
Figure 517: Overview: Backup of Multitenant Database Containers
The following are specific properties of multitenant database container backup and recovery: ●
●
The system database plays a central role. It can initiate both backups of the system database itself and of individual tenant databases. Recoveries are always initiated by the system database. Tenant databases can carry out their own backups unless this has been prohibited in the system configuration.
●
System database and tenant databases have their own backup catalogs.
●
Snapshots are currently not supported.
Multitenant Database Containers: Backing up the System Database Data backups of the system database are needed on a regularly basis. The system database contains information about the system as a whole and all tenant databases and is used for central system administration.
Figure 518: Multitenant database containers: Backing up the system database
A data backup of the system database could be performed using SAP HANA studio. Therefore right-click on the system database in the Systems view and choose Backup and Recovery → Backup Up System Database .... Then specify your backup settings and start the backup.
Multitenant Database Containers: Backing up a Tenant Database Since data backups of the system database only contain information about the system as a whole, also data backups of the tenant databases are needed on a regularly basis. The tenant databases contain the business data. They have their own index servers.
Lesson: Backup and Recovery of Multitenant Database Containers
Figure 519: Multitenant database containers: Backing Up a Tenant Database
A data backup of a tenant database could be performed using SAP HANA studio. Therefore, right-click the system database in the Systems view and choose Backup and Recovery → Backup Up Tenant Database .... Then select the tenant database to be backed up and specify your backup settings and start the backup.
Note: Depending on the system configuration, it may also be possible to initiate a data backup directly from a tenant database.
Viewing Backup Information Backup information is contained in the backup catalog. With SAP HANA multi-tenant database containers, the system database and each tenant database have their own backup catalog. It is possible to display the backup information for all databases or for a specific tenant database. For housekeeping purposes it is possible to delete old backups from the backup catalog only, or also from the file system or third-party backup tool.
Recovery of Multitenant Database Containers For SAP HANA multi-tenant database containers, you can recover the system database. You can also recover a tenant database via the relevant system database. System database and tenant database or databases can be recovered one by one in the same system (recovery) or in a different system (system copy) of the type SAP HANA multi-tenant database containers. For a recovery, source database and target database must have identical configurations. A recovery of the system database may be needed, for example, if there are physical errors in the system database’s volumes.
Recovering the System Database The whole system will be shut down, including all tenant databases.
●
●
Specify your recovery type and further recovery settings and start the recovery.
●
The system database will be recovered and restarted.
●
Restart the tenant databases.
●
The content of the tenant databases is not affected by the system database recovery.
A recovery of a tenant database may be required, for example, if a logical error occurred in the tenant database Recovering a Tenant Database ● Recovery of tenant databases can only be initiated from the system database. ●
The system database and other tenant databases are not affected.
●
Select the tenant database to be recovered.
●
Specify your recovery type and further recovery settings and start the recovery.
Configure Target Host for Tenant Recovery
Figure 520: Configure Target Host for Tenant Recovery
As of SPS 11 it is possible to influence the distribution of the tenant database across target hosts. Before you start the recovery, create a new tenant database on one of the hosts (this will be the host that the master index server runs on). Using Add Service, specify the target hosts for further services of your tenant database (for example, additional index servers). Services contained in the backup for which you have not specified a target host will be distributed automatically by SAP HANA to suitable target hosts.
LESSON OVERVIEW The last three lessons about SAP Solution Manager are theory only. There are no system demonstrations to show, because there is no Solution Manager setup in our system landscape. To make the lessons a bit more insightful, I have created some videos that show how the SAP Solution Manager and SAP HANA work together. You can show them during the lessons.Video 1: SAP Solution Manager 7.1 sp12 setup steps for SAP HANA. Link: https:// www.youtube.com/watch?v=GckIssoHHtEVideo 2: SAP Solution Manager 7.1 sp12 monitoring SAP HANA. Link: https://www.youtube.com/watch?v=T-g8XA1K3tUVideo 3: SAP Solution Manager 7.1 sp12 using DBACOCKPIT for SAP HANA. Link: https:// www.youtube.com/watch?v=9qo2fq0-q3UVideo 4: SAP Solution Manager 7.1 sp12 using MOPZ to request an SPS for SAP HANA. Link: https://www.youtube.com/watch? v=OFxBbBWwsyY You can also search on youtube.com with the search keys“hay bouten solution manager” to find all the video's on my channel.
LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Describe how SAP HANA is integrated in SAP Solution Manager
Architecture: Logical Landscape View
Figure 521: Architecture: Logical Landscape View – Monitoring with SAP Solution Manager
Besides the landscape data that is normally sent from the technical systems to the SLD (Solution Landscape Directory) → LMDB, also Diagnostics agents are installed on each host. For now, the rule is that for each virtual host name one Diagnostics Agent needs to be installed. These agents are also used to fetch some landscape data but they send monitoring data, logs, and traces to SAP Solution Manager too. Solution Manager 7.1 for SAP HANA
Figure 522: Solution Manager 7.1 for SAP HANA – Monitoring with SAP Solution Manager
The goal is to monitor availability of services in the SAP HANA Database. An SAP Solution Manager landscape overview is shown in the following figure.
Figure 523: Technical Monitoring: System Monitoring – Monitoring with SAP Solution Manager
SOLMAN_WORKCENTER is a central SAP GUI transaction for configuration, setup, administration, and monitoring with the SAP Solution Manager. The SAP Solution Manager Administration work center is embedded in the SAP Solution Manager work center framework. The work center overview can be opened in different ways: ●
●
●
●
686
By calling transaction SOLMAN_WORKCENTER in the SAP GUI By opening transaction SM_WORKCENTER or the following URL in the SAP Solution Manager http://:/sap/bc/webdynpro/sap/ags_workcenter In the SAP Netweaver Business Client Separately in a browser by calling the URL http://:/sap/bc/ webdynpro/sap/ags_workcenter?WORKCENTER=AGS_WORK_SM_ADMIN
With SAP Solution Manager 7.1 SP04, no SLT monitoring is available and no complete metrics for alerts via the DBAcockpit. With SAP Solution Manager 7.1 SP02/SP03, there is no DBAcockpit integration and no SLT monitoring. SAP HANA Integration with SAP Solution Manager
Figure 528: SAP HANA integration with SAP Solution Manager – Monitoring with SAP Solution Manager
The following is a high-level overview about the required steps to integrate SAP HANA to the SAP Solution Manager. Detailed step-by-step documentation, minimum required patch levels, and important SAP Notes are available in SAP Note 1747682. One of the first steps is to correctly install the SAP HANA DB clients in the SAP Solution Manager. The PDF attachments to this SAP Note contain further documentation and the required steps for integration of SAP HANA in the SAP Solution Manager, including the Early Watch Alert setup. Furthermore, the corresponding master Notes for the SAP Solution Manager need to be applied, for example, SAP Note 1652693. These SAP Notes can also be applied by choosing SAP Solution Manager → Workcenter (SOLMAN_WORKCENTER transaction) → SAP Solution Manager: Configuration → System Preparation → Implement SAP Note. A dedicated exercise for this training will give you the chance to perform a relevant part of this integration procedure (SAP HANA monitoring setup in the SAP Solution Manager) by yourself. For this exercise, we will focus on the steps to be performed on the SAP Solution Manager side. However, for live situations, the following components and products need to be installed and configured in addition to SAP HANA: ●
Figure 529: Setup for Host Agent and Diagnostics Agent – Monitoring with SAP Solution Manager
Check the SAP host agent version and confirm that it complies with the minimum requirements outlined before (7.20 SP 84 or higher). Execute the following command with root user credentials on the SAP HANA server: /USR/SAP/HOSTCTRL/EXE/SAPHOSTEXEC -VERSION The required SAP HANA User with the Monitoring role mentioned above can be created with the SAP HANA Studio, as follows: ●
Click your SAP HANA system from the Navigator panel on the left. Choose Catalog → Authorizations, right-click Users and choose New User. Follow the steps required by the tool.
Alternatively, you can use the SQL Editor in the SAP HANA studio to create this user using SQL syntax. The monitoring user will be used by the SAP Solution Manager for connecting to SAP HANA. You need to successfully connect to SAP HANA with this user at least once. Depending on the settings, the SAP HANA studio asks users to change their initial password after their first login. Therefore, in order to enable a first successful connection with this user to SAP HANA, you may be required to change the initial password.
Register SAP HANA in System Landscape Directory (SLD)
Figure 530: Register SAP HANA in System Landscape Directory (SLD) – Monitoring with SAP Solution Manager
You need to ensure that the Lifecycle Management package is installed on the SAP HANA server: Check if the directory lm_structure (SLD data supplier) is available in /usr/sap/ . The SAP unified installer installs this package with standard SAP HANA installations. Configure SAP HANA as Managed System: Create System
Figure 531: Configure SAP HANA as Managed System: Create System – Monitoring with SAP Solution Manager
The detailed steps for system creation and further configuration steps for SAP HANA integration in the SAP Solution Manager, as explained in the following, are mostly intuitive and semi-automatic.
The SAP Solution Manager will ask you, among others, to enter your SAP HANA , Instance number, SAP HANA host name, product and software component versions, Diagnostic Agents, and so on. In many cases, you will be able to choose from different available options, which will be recognized automatically by the system. For example, since you previously registered SAP HANA in the SLD, the SAP Solution Manager will display your SAP HANA hostname (including correct IP address, and so on) on the list of hosts to choose from. In other cases, some entries will be filled in automatically by the system via Outside Discovery, such as the SAP HANA version. Otherwise, you can look at the help files for each field in order to enter the right information. If you are not sure about which information to enter, you can keep the defaults. Configure SAP HANA as Managed System: Components
Figure 532: Configure SAP HANA as Managed System: Components – Monitoring with SAP Solution Manager
The guided procedure will guide you through all steps. You can navigate back and forward through the different steps by clicking Previous or Next.
Figure 533: Configure DBACOCKPIT and Performance Warehouse – Monitoring with SAP Solution Manager
Most steps in the guided procedures for configuration will be performed semi-automatically, and traffic lights will indicate the statuses. If some of the checks or steps for configuration fail, a yellow or red flag with an error message will be shown on the log area (bottom UI area). You can click the Show link under the Details column and assess the criticality of the step. Depending on the criticality you may decide to ignore the error. In some cases solutions for errors will be suggested by the system, for example, the need to apply an SAP Note. If the SMD Agent was installed correctly, the Assign Diagnostic Agents step will automatically display the right Agent to be selected by the user. The right introscope server name, monitoring user, SAP HANA hostname, etc. will also be displayed by default for the Enter System Parameters step. You may want to change the user, for example, in case you assigned a new monitoring user.
Figure 536: Technical Monitoring Metrics up and Running – Monitoring with SAP Solution Manager
This step shows the results of the Technical Monitoring configuration for SAP HANA in the SAP Solution Manager. System, database, and operating system monitoring metrics for SAP HANA will be displayed. LESSON SUMMARY You should now be able to: ●
Describe how SAP HANA is integrated in SAP Solution Manager
LESSON OVERVIEW In this lesson, you will learn how to establish a remote service connection for SAP HANA. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Establish a remote service connection for SAP HANA
Tool Overview
Figure 537: Tool Overview: Remote Support
Note: The recommendation is to establish the remote support before an emergency happens. In addition to run the on-site configuration tool, we recommend that you establish a SAP Solution Manager connectivity and configure a remote service connection (via SAProuter) as part of the initial setup.
As of SAP Solution Manager 7.1 SP04, the SAP HANA databases can be integrated into SAP Solution Manager. -
Performance Warehouse
-
Alerting Infrastructure
-
DBA Cockpit (also available in SAP BW systems as of SAP BW 7.30 SP05)
The remote service connection can be established through the SAProuter -
A new connection type allows SAP support to access customer databases via a local SAP HANA studio installation
Safe Remote Access via SAP Solution Manager
Figure 538: Safe Remote Access via SAP Solution Manager – Remote Support
To offer secure remote access to the customer system we need (for BOE) the following remote connections: ●
R/3 Support
●
HTTP Connect – URLAccess
●
Windows Terminal Server
●
EarlyWatch
●
SAP Solution Manager
●
SolMan Diagnostics
The SAP remote supportability Web site shows a clear roadmap, starting at the top and working down, for customers to follow when working towards better supportability of their SAP Business Objects products. We encourage all of our customers to work their way through these tools in order to provide them with increasingly sophisticated support opportunities.
Establishment of a Remote Connection to SAP Solution Manager
Figure 539: Establishment of a Remote Connection to SAP Solution Manager
Set up a support connection as described in SAP Note 1634848 (SAP HANA database service connections). Remote Connection via SAP Router to SAP HANA Studio
Figure 540: Remote Connection via SAP Router to SAP HANA Studio
The remote connection to SAP Solution Manager 7.1 must established (see SAP Note 962516) . ●
●
SAP Business Objects Central Management Console (CMC) to be connected via HTTP connect – URL access (note 592085). SAP Backend system and SLT system can be connected to SAP Solution Manager 7.1 and shall also be remotely connected to SAP via SAP R/3 support (see notes 812732) and HTTP Connect.
Remote Access to OS Level
Figure 543: Remote Access to OS Level
Problem Analysis Using hdbcons hdbcons is a command line tool with which commands can be executed against running processes using a separate communication channel. It is intended for problem analyses by the SAP HANA development support.
Caution: Incorrect usage of hdbcons commands can lead to crashes, deadlocks, or data corruptions. Only the SAP HANA development support has the required technical expertise to execute these commands. The hdbcons command can be executed directly in the Administration editor on the Console tab. However, it is not visible by default. You can enable the display of the Console tab in the preferences of the Administration Console under Global Settings.
Note: To see a list of available commands and display the help for a command, enter the command HELP.
Each command is subject to an individual authorization check. Operating system user (adm) access is not required.
SAP HANA Database Data Export In some cases, the SAP development support team may ask to export data from your SAP HANA database. The data export can be done from the SQL console within HANA studio or by using the export option.
LESSON OVERVIEW This lesson shows how to use and configure the SAP Early Watch Alert. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Set up an EarlyWatch Alert for SAP HANA
SAP EarlyWatch Alert Setup for SAP HANA For the currently supported scenarios, monitoring for the SAP HANA database can be included into the EarlyWatch Alert (EWA) service for the SAP Business Suite application. Checks for SAP HANA are in the EarlyWatch Alert. A first version of SAP HANA-specific content in the EarlyWatch Alert is provided with ST-SER 701_2010_1 SP 06.
Figure 546: Data Collection
Requirements for the Data Collection How to set up this SAP system (for example, an SAP ERP or SAP System Landscape Transformation system) so that HANA checks appear in the EarlyWatch Alert for this system is described in SAP Note 1543278. If the SAP HANA database is not connected with an ABAP stack, then SAP Solution Manager itself should take on the role of the ABAP system. The SAP HANA checks then appear in the EarlyWatch Alert for SAP Solution Manager.
The download mechanism has changed and it follows the standardized data collection using ST-PI. Import ST-PI 2008_7xx Support Package 6. Read SAP Note 1665364 and implement the latest version of SAP Note 1741541. The prerequisite for the collection of data is a functioning connection to the SAP HANA database of the ABAP system. The installation of this connection is described in SAP Note 1597627. If the Solution Manager collects the SAP HANA download data, you must install the connection to the SAP HANA system for it. If you have generated the EarlyWatch Alert (EWA) using the old solution, deschedule the batch job MONITOR_BOBJ_STATUS*.
Figure 547: Requirements for the Data Collection
Setup of SAP EWA in SAP Solution Manager ●
Check the required RFC Destinations in Managed System Setup in SAP Solution Manager: READ Destination (from SAP Solution Manager to the Managed System) RFC Destination from the Managed System to SAP Solution Manager (to the Application Client)
●
Configuring and activating SDCCN: Configure Automatically‘→ Activate Services Transaction SDCCN on the Managed System: Go To → Settings → Task Specific → RFC Destinations: The SAP Solution Manager should be inserted.
●
Create logical component of the ABAP stack to which the SAP HANA DB is connected
●
Assign logical component to a solution
●
Scheduling SAP EWA download collection
●
Checking SAP EWA Reports / See SAP EWA Reports
●
With SAP Solution Manager 7.1 SP9 a central EarlyWatch Management Guided Procedure is introduced, which leads the user through the single steps of EWA setup.
Register SAP HANA System in SLD The provided functionality in HLM (HANA Lifecycle Management) knows the configuration of the connection parameters for the central System Landscape Directory (SLD) system. When an SAP HANA system is connected to SLD, it can report its status and provide details and information for the system itself. Install Solution Manager Diagnostics Agent (SMD)
Solution Manager Diagnostics is another SAP application to monitor the SAP system and it communicates with an SMD agent that is installed on the local machine to be monitored. The installation of the SMD agent should be performed using the Software Provisioning Manager (SWPM), see SAP Note 1858920 - Diagnostics Agent Installation with SWPM. EWA Setup for SAP HANA
Figure 548: EWA Setup for SAP HANA
SAP HANA Content in EWA
Figure 549: EWA for HANA: Overview
The EarlyWatch Alert covers several areas of SAP HANA, including the following:
Review the number of trace and log files (of the previous week). This indicates if SAP HANA behaves smoothly. (If several Dump files are occurring, this might be critical.)
Alert Monitoring SAP EarlyWatch Alert
Figure 554: EWA content for SAP HANA: Alert Monitoring SAP EarlyWatch Alert
LESSON OVERVIEW This appendix provides you with additional information. LESSON OBJECTIVES After completing this lesson, you will be able to: ●
Provide you with additional information
Deep Diving into Memory Management and Persistence Page Attribute Access and SAP HANA smart data access This section is marked as optional. Depending on the state of knowledge and interest of the participants as well as time constraints you can select whether to present it or just refer to it.
Paged Attribute Access Starting with SAP HANA SPS 06 (Revision 60) it is possible to activate paged attributes for a column-store table. By doing so, SAP HANA can read attribute structures from disk based on pages, which reduces the overhead of keeping data in memory that is not required.
Figure 557: Paged Attribute Access – Things to be Considered
Hybrid LOBs Since it potentially consumes lots of memory, storing LOBs (BLOB, CLOB, NCLOB) inside of row and column store tables is not reasonable in many cases. Starting with SAP HANA SPS 06 LOBs can be stored in virtual files inside of HANA.
Figure 560: Hybrid LOBs – Details on the Migration
Hint: Syntax details and additional options can also be found in the SAP HANA SQL and System Views Reference. Smart Data Access SAP HANA smart data access enables remote data to be accessed as if they are local tables in SAP HANA, without copying the data into SAP HANA.
Not only does this capability provide operational and cost benefits, but most importantly it 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. Features
Figure 562: SAP HANA Smart Data Access – Features
In SAP HANA virtual tables can be created which point to remote tables in different data sources. Customers can write SQL queries in SAP HANA, which could operate on virtual tables. The SAP HANA query processor optimizes these queries, and executes the relevant part of the query in the target database, returns the results of the query to SAP HANA, and completes the operation.
The supported remote data sources are the following: ●
Teradata Database: version 13.0
●
SAP Sybase IQ: version 15.4 ESD#3 and 16.0
●
SAP Sybase Adaptive Service Enterprise: version 15.7 ESD#4
●
Intel Distribution for Apache Hadoop: version 2.3 (This includes Apache Hadoop version 1.0.3 and Apache Hive 0.9.0.)
New or Improved Smart Data Access Features in SAP HANA SPS 07
Figure 563: New or Improved Smart Data Access Features in SAP HANA SPS 07
Smart data access has first been released with SAP HANA SPS 06. With SPS 07 of SAP HANA certain features were added and enhanced: ●
Expanded Remote Source Systems Support: With SAP HANA SPS 07 smart data access supports new data sources such as Oracle 12c, Microsoft SQL Server ver11 and Hadoop Hortonworks HDP 1.3
●
Extended DML Support on Virtual Tables: Smart data access supports inserting, updating and deleting data in virtual tables. The inserted data is transferred to the remote database on-the-fly. It is also updated transactionally on-the-fly and deleted on-the-fly transactionally from the remote database. Insert/Update/Delete support is provided for the supported datasources.
Note: Limitation: There is no support of inserts, updates and deletes for BLOB/CLOB and no support of correlated queries.
●
Calc View Support for Virtual Tables: When creating a calculation view, it is possible to add virtual tables as data sources. Optimizations such as push down of filters are also supported in these scenarios.
Note: Limitations: no support of aggregate / group by / order by function push down
Generic Adapter Framework: Add support for new ODBC data sources by providing connectivity configuration files.
●
Remote Caching for Hadoop Sources: When SAP HANA dispatches a federated query to HIVE, it involves series of ‘map’ and ‘reduce’ job execution. This could take few minutes to hours to complete a query depending on the data size in Hadoop and the current cluster capacity. In most cases, the data in Hadoop cluster is not frequently updated and successive execution of map/reduce jobs might result in same tuples. As of SPS 07, HANA allows this result view to be materialized in the remote system thus avoiding the repetitive execution of the same query. This behavior can be controlled by hinting the optimizer to use remote caching.
●
Configuration Validation Utility – hdbsdautil: The utility checks drivers and dependency files of a given data source type. It can also connect to remote database with given credential information and run queries with/ without result set display.
Hint: Details on how to add remote data sources and create virtual tables can be found in the SAP HANA Administration Guide.
Dynamic Tiering The dynamic tiering option allows to move cooler, or large-volume data, out of SAP HANA tables and into extended tables.
Figure 564: Key Aspects of Dynamic Tiering
Dynamic Tiering Overview The SAP HANA dynamic tiering option is a native big data solution for SAP HANA. The dynamic tiering option adds smart, disk-based extended storage to your SAP HANA
database. Dynamic tiering enhances SAP HANA with large volume, warm data management capability. The dynamic tiering option adds the extended storage service to your SAP HANA system. You use the extended storage service to create the extended storage store and extended tables. Extended tables behave like all other HANA tables, but their data resides in the disk-based extended storage store. Your application automatically determines which tier to save data to: the SAP HANA inmemory store (the hot store), or extended storage (the warm store). When you use dynamic tiering to place hot data in SAP HANA in-memory tables, and warm data in extended tables, highest value data remains in memory, and cooler less-valuable data is saved to the extended store. This can reduce the size of your in-memory database.
Figure 565: Dynamic Tiering Overview
Transaction Management and Concurrency Control Multi Version Concurrency Control If someone is reading from a database at the same time as someone else is writing to it, it is possible that the reader will see half-written or inconsistent pieces of data. There are several ways of solving this problem, known as concurrency control methods. The simplest way is to make all readers wait until the writer is done, which is known as a lock. This can be very slow, so SAP HANA takes a different approach with Multi Version Concurrency Control (MVCC): each user connected to the database sees a snapshot of the database at a particular instant in time. Any changes made by a writer will not be seen by other users of the database until the changes have been completed (or, in database terms: until the transaction has been committed). MVCC enables long-running read transactions without blocking update transactions and a high level of parallelization using insert only data records.
SAP HANA supports transactional consistency which guarantees that the current job is either completely applied to the system or disposed.
Figure 566: Different Status of Reading and History Files
When SAP HANA needs to update an item of data, it will not overwrite the old data with new data, but instead mark the old data as obsolete and add the newer version elsewhere (see also graphic above). Thus, there are multiple versions stored, but only one is the latest. This allows readers to access the data that was there when they began reading, even if it was modified or deleted part way through by someone else. It also allows the database to avoid the overhead of filling in holes in memory or disk structures but requires (generally) the system to periodically sweep through and delete the old, obsolete data objects.
Depending on the transaction isolation level, different transaction may see different versions of data even if they read it at the same time. The graphic above shows an example. Transaction Isolation Levels MVCC can be used to implement different transaction isolation levels. SAP HANA supports both transaction level snapshot isolation and statement level snapshot isolation. With transaction level snapshot isolation, all statements of a transaction see the same snapshot of the database. This snapshot contains all changes that were committed at the time the transaction started, plus the changes made by the transaction itself. Transaction level snapshot isolation roughly corresponds to SQL isolation level “repeatable read”. With statement level snapshot isolation, different statements in a transaction may see different snapshots of the database. Each statement sees the changes that were committed when the execution of the statement started. This isolation level corresponds to SQL transaction isolation level“read committed”.
Note: If required, it is also possible to lock a table exclusively. This needs to be triggered by the application respectively database user. Transaction Level Snapshot Isolation The graphic below depicts transaction level snapshot isolation in detail. In the timeline there are five transactions and two versions of data item D: ●
The initial version V1 of the data item is created by transaction T1 and committed.
●
Version V1 is updated by transaction T3 (new version V2 created).
Following the principle of transaction level snapshot isolation, since T2 and T4 have started before T3 committed the changes, they still see version V1 even if they read after T3 is committed. Since transaction T5 starts when the change performed by T3 is already committed, T5 reads the new version V2.
Figure 568: Transaction Level Snapshot Isolation
Hint: The transaction isolation level can be changed using the command “SET TRANSACTION. Please see the SAP HANA SQL Reference for details.”
Abbreviations
720
CRM
Customer Relationship Management
CTS+
Enhanced Change and Transport System. CTS+ allows using transport mechanisms from ABAP (CTS) for Java objects as well.
DBA Cockpit
The DBA Cockpit is a platform-independent tool that you can use to monitor and administer your database.
HANA Database SQL. This is the command line tool of SAP HANA.
IMDB
In-Memory Database
JAVA
Programming Language
JDBC
Java Database Connectivity – Java Standard Edition platform
ODBC
Open Database Connectivity – is a standard
OLAP
Online Analytical Processing
PAK
Planning Application KID
PLM
Product Life-Cycle Management
RAM
Random-Access-Memory
RDBMS
Relational Database Management System
RDS
Rapid Deployment Solutions
RFC
Remote Function Call
SAP HANA
High Performance Analytic Appliance from SAP
SAP NetWeaver
SAP's integrated technology computing platform
Sapadm
SAP Host Agent Administrator contains all required elements for centrally monitoring any host.
SCM
Supply Chain Management
Solution Manager
It provides central access to tools methods and preconfigured content that you can use during the evaluation, implementation, and productive operation of your systems.
SQLDBC
SQL Database Connectivity is a runtime library that enables applications to execute SQL statements in the database.
