Large and mid-market companies continue to adopt SAP to run their firms. The powerful SAP platform runs every aspect of a large enterprise from mission-critical lines of business all the way to administrative and supports services. For these firms, high availability is paramount; a system outage or performance degradation can cost millions of dollars. In this blog, we will discuss in detail about S4 HANA Monitoring.
System monitoring is a daily routine activity and this document provides a systematic step by step procedure for Server Monitoring. It gives an overview of technical aspects and concepts for proactive system monitoring.
To Perform SAP HANA Database Administration and monitoring features, SAP HANA Administration Console Perspective can be used.
Administrator Editor can be accessed in several ways −
1. From System View Toolbar − Choose Open Administration default button
2. In System View − Double Click on HANA System or Open Perspective
In Administration View: HANA studio provides multiple tabs to check configuration and health of the HANA system. Overview Tab tells General Information like, Operational Status, system usage, start time of first and last started service, system replication status, version, build date and time, Platform, hardware manufacturer, etc.
It also gives an overview of Used Memory, Peak Memory, and its Allocation Limit.
From the overview screen we also get information about used resident memory, total memory, and physical memory.
Log volume size along with total disk usage and total disk size is also reflected in this screen.
None of the above-used space should reach the threshold.
To perform daily monitoring we need to perform below checks:
1. Check all services are running
2. Performance –> Threads
3. Performance –> Sessions
4. Performance –> Expensive Statement Trace
5. Performance –> Load
We need to check the load of below 4 parameters:
1. CPU utilized
2. DB Resident Memory
3. Disk Used
4. Memory Used
Below is load of CPU at given range of time. We need to make sure it doesn’t cross the threshold.
There are two type of volume present in HANA
The data volume contains the data from the last completed savepoint.
The log volume contains all changes on the data volume since the last completed savepoint.
Each log volume contains the file logsegment_<partition_ID>_directory.dat and one or more log segment files (logsegment_<partition_ID>_<segment_number>.dat).
Currently, only one log partition is supported for each service, so the default file names are:
logsegment_000_directory.dat and logsegment_000_00000000.dat, logsegment_000_00000001.dat, logsegment_000_00000002.dat and so on.
Log segment files are overwritten depending on the log mode. The log mode determines how logs are backed up. Log volumes only grow if there are no more segment files available for overwriting.
Storage location of data file and log file are at:
7. Configuration –> global.ini
1. Global.ini contains information like:
- Crash dump
Few other .ini files are listed below. We can check them if faced
8. Trace Configuration
We can configure trace as per our landscape requirement.
c. End to End trace
d. Performance trace
e. User-specific trace
f. Expensive statement trace.
In below table we have explained each trace, it’s default status and purpose of the trace.
|Database Trace||Active||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.
|SQL Trace||Inactive||The SQL trace collects information about all executed SQL statements and saves
it in a trace file for further analysis. It is inactive by default.
Information collected includes the overall execution time of each statement, the number
of records affected, potential errors (for example, unique constraint violations) that
where reported, the database connection being used, and so on.
|User-Specific Trace||Inactive||The user-specific trace is used to trace activity through the available components
(I.e. IndexServer, NameServer) for a specific application or database user.
|Performance Trace||Inactive||The performance trace is a performance tracking tool built into the SAP HANA database.
It records performance indicators for individual query processing steps in the database
kernel. It is inactive by default.
Information collected includes the processing time required in a particular step, the data
size read and write, network communication, and information specific to the operator
or processing-step-specific (for example, number of records used as input and output).
|End-To-End Traces||Inactive||The predefined end-to-end traces are used by applications to trace activity through all
the available trace components. I.e. IndexServer, NameServer
|Expensive Statements Trace||Inactive||Expensive statements are individual SQL statements whose execution time exceeded
a configured threshold.
|Kernel Profiler||Inactive||The kernel profiler is a sampling profiler built into the SAP HANA database. It can be used
to analyze performance issues with systems on which third-party software cannot be
installed, or parts of the database that are not accessible by the performance trace.
Caution To be able to use the kernel profile, you must have the
SAP_INTERNAL_HANA_SUPPORT role. This role is intended only for SAP HANA development support.
Locating the Trace/Diagnostic Files
Diagnosis files include log and trace files, as well as a mixture of another 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 access diagnosis files on the Diagnosis Files tab of the Administration editor as shown in below screenshot.
SAP HANA offers different kinds of high availability mechanisms, supporting a broad range of recovery scenarios from various faults. One of the features is System Replication.
System Replication: SAP HANA replicates all data to a secondary SAP HANA system (standard SAP HANA feature). Data is constantly pre-loaded on the secondary system to minimize the recovery time objective (RTO)
In our case, our production system is in High Availability. So we need to make sure replication is always active.
If we go inside Landscape, then go inside System Replication. There we can see a list of host and its secondary hostname.
We must assure replication status is active every time.