Learning notes from the learning journey: Installing and Administering SAP HANA to take the Certification "SAP Certified Associate - Database Administrator - SAP HANA".
- Locating Database in SAP HANA Cockpit:
DATABASE DIRECTORY: display an aggregated view of all the registered databases that are in a group to which the user has granted access.
To access this, use the SAP HANA Cockpit.
DATABASE MANAGEMENT: Display information about all databases in the database system, besides monitoring and admin the tenant databases.
To perform operations on a tenant database :: system privilege DATABASE ADMIN.
Blocklisted Parameters - allow control system config. changed by individual tenant db. (stored: multidb.ini) :: system privilege INIFILE ADMIN
To access this, use the SYSTEMDB.
DATABASE INFORMATION CARD :: system privilege CATALOG READ
- Checking the SAP HANA Services:
SAP architecture is based on a shared architecture between the System Database and Tenant Database. To check the CPU and Memory usage, it's possible to check the Manage Services app in SAP Cockpit.
The CPU Usage presents the percentage used, high usage alerts, and start and end time of 12 hours time range.
Note, if something is not running it's possible to navigate in the crash dump file (file created when a service is stopped) -> database trace directory: /usr/sap//HDB//trace/
- Checking the Memory Usage
MEMORY USAGE: A memory pool is used for storing in-memory tables, thread stacks, temporary computations, intermediate results, and other data structures.
Since SAP uses LINUX, it requests a reserved memory for their use, which is the virtual memory. This is the memory footprint of a program. And SAP calls it used memory.
RESIDENT MEMORY: Part of the virtual memory in physical memory. If a computation demands more memory, it borrows part of the physical memory to compute and then drops the memory again.
Physical memory >>> Resident Memory
MEMORY USAGE CARD: Cockpit -> Monitor Performance -> Analysis
- Checking the SAP persistence storage:
PERSISTENCE: The layer is responsible for keeping the changes and restoring a database as efficiently as possible after a restart.
Its storage is split into Data Volume (Row and Column storage) and Log Volume (Buffer).
The persistence layer is responsible for the durability and atomicity of transactions.
COLUMN STORE PERSISTENCE (4k - 16M): keep the data in memory arrays, in the Persistence Layer, it is handled with pages. The operations on column tables are executed on the in-memory column data structures.
ROW STORE PERSISTENCE (16k): kept in 16k pages in segments of 64MB. Concurrency control is handled by the row store and the rest, the persistence layer.
DISK STORAGE: Data changes (INSERT, DELETE, UPDATED) are saved in logs. Meanwhile, every 5 minutes, a new savepoint is created.
MEMORY DISK VOLUMES: Are stored in /usr/sap//SYS/global/hdb/data and /usr/sap//SYS/global/hdb/log.
Cockpit -> Disk Usage -> Monitor Disk Volume and Analyze Workloads.
SAVEPOINTS: they can be triggered manually by "ALTER SYSTEM SAVEPOINT".
- Checking for the SAP Alerts:
SAP Cockpit -> Alerts Application
The data collected by the data collectors of the statistics service is deleted after a default number of days (42 days but can be changed).
Monitoring and alert information are stored in database tables in _SYS_STATISTICS.
The maximum number of alerts cannot exceed 1000000.
If an alert fails, the alert remains disabled until calculates the INTERVALLENGHT x SKIP_INTERVAL_ON_DISABLE and starts again.
- Check SQL Stataments
Cockpit -> SQL Statements
Alerts :: The statistics service is implemented by a set of tables and SQLScripts procedures in the master index server and by the statistics scheduler thread that runs in the master name server.
Cockpit -> Threads :: monitor the number of currently active and blocked threads (system load).
Cockpit -> Session :: monitor all sessions in your landscape (can be saved in txt, csv or HTML.
Top comments (0)