Hana Cleaner
Hana Cleaner
For more about the SAP HANACleaner see SAP Note 2399996
SAP Note 2400024 provides administration suggestions, e.g. recommendations about the hanacleaner
© 2023 SAP SE. All rights reserved. Customer 1
House Keeping
HANACleaner – using hdbuserstore
Host, port and DB user needs to be provided in the hdbuserstore:
Then the hanacleaner can connect using the info stored in hdbuserstore:
Depending on what housekeeping tasks the specific hanacleaner user will do, he needs specific sets of privileges,
for example:
E.g. here the user A2 is missing the system privilege TRACE ADMIN:
-be minimum number of retained backup entries in this number of entries of successful data backups will remain in the -1 (not used)
the catalog backup catalog
-bd days minimum retained days of backup entries in the the youngest successful data backup entry in the backup catalog that is -1 (not used)
catalog older than this number of days is the oldest successful data backup entry
not removed from the backup catalog
-bb true/ switch to delete backups also if set to true the backup files corresponding to the backup entries are false
false also deteleted
-bo true/ output the backup catalog if set to true the backup catalog is printed before and after cleanup false
false
-br true/ output the deleted entries if set to true the deleted backup entries are printed after the cleanup false
false
Example:
Here backup catalog entries (i.e. not the backups themselves) older than 42 days are deleted, but at least 5 backup entries a re kept, and the
deleted backup entries are printed out
Example:
Here backup catalog entries (i.e. not the backups themselves) older than 30 days are deleted, but at least 5 backup entries a re kept, and the
deleted backup entries are printed out:
Example:
Here trace file older than 42 days are removed in two different ways:
Example:
Here backup.log and backint.log files older than 1 day
are deleted, and the removed trace files are displayed:
-tcb true/false clear traces with backup the trace files that are removed with the –tc, -tb and -te flags are backed up (as .gz) with false
ALTER SYSTEM CLEAR TRACES … WITH BACKUP (not applicable for -tf, since
"WITH BACKUP" does not exist for ALTER SYSTEM REMOVE TRACES)
Note: Some small, unnecessary files, like .stat (SAP Note 2370780) might be deleted,
so number removed and archived file might seem incorrect.
-tbd directory for the trace backups full path of the directory to where the back up (see -tcb) of the trace files are moved ' ' (they stay)
-tmo seconds time out for the move the move, requested by the -tbd flag, must wait until the compression, requested by the 30 seconds
-tcb flag, is finished. This can take some seconds. If it is not finished before the time out,
specified by the -tmo flag, the move will not happen (a warning will be logged).
Example:
Here all trace files older than 3 days are backed up and moved to /tmp/tracebackup → 1 .trc file is moved and one .stat file is deleted
Example:
Here dump files older than 1 day are deleted
-hr days retention days for unfortunately there is no file rotation for *.hdbcons.trc files (see SAP Note 3051846), therefore -hr -1 (not used)
lines in the can be used to define retention days for lines in these files. WARNING: this might temporarily
hdbcons trace file require up to twice the file's memory usage! If the file is larger than 10 GB hanacleaner will print a
warning and then ignore that file.
Example: Here lines older than 200 days are removed from the .hdbcons.trc files
-gr list of retention days for files in the directory specified with -gd and with the file names including the word specified with -gw are only saved “”
days any general file for this number of days Note: -gr must be a list with the same length as -gd and -gw (not used)
-gd directories a comma separated list with full paths of directories with files to be deleted according to -gr (entries pairs with default "" (not
entries in -gw) used)
-gw filename parts a comma separated list with words that files should have in their names to be deleted according to -gr (entries default "" (not
pairs with entries in -gd) used)
Example:
Here files hana in their file names, in the folders /tmp/hanachecker_output/ & /tmp/hanasitter_output older than 10 resp. 20 days are deleted
-ar days minimum number retained days of the alerts minimum retained age of statistics server alerts -1 (not used)
-ao true/ output alerts if true, then all alerts will be displayed before and after the cleanup (if false
false number of alerts are more than 10 thousand, hanacleaner will not do this
output)
-ad true/ output deleted alerts if true, then deleted alerts will be displaye after the cleanup (if number of false
false alerts are more than 10 thousand, hanacleaner will not do this output)
Example:
Here alerts older than 5 days are removed from the statistics server alert table:
-lr maximum number of free if there are more free log segments for a service that this number then ALTER SYSTEM RECLAIM -1 (not used)
log segments per service LOG will be executed
Note: A too small value could cause overhead and contention due to RECLAIM LOG executions.
The setting -lr 250 has been found to be a good compromise.
Example:
Here the ALTER SYSTEM RECLAIM LOG command is executed since there was a hana process that had more than one free log segment:
-ur retention time [days] of the audit log table if the audit log database table has audit log older than these number -1 (not used)
days ALTER SYSTEM CLEAR AUDIT LOG UNTIL will be executed
Example:
Here the ALTER SYSTEM CLEAR AUDIT LOG UNTIL is executed and 29 entries in the audit log table were removed:
-pe retention days for pending e-mails [days] pending statistics server e-mail notifications older than these number of -1 (not used)
days are removed
(requires SELECT and DELETE on the _SYS_STATISTICS schema)
Example:
Here the DELETE FROM _SYS_STATISTICS.STATISTICS_EMAIL_PROCESSING WHERE SECONDS_BETWEEN(SNAPSHOT_ID,
CURRENT_TIMESTAMP) > 0 * 86400 is executed and 58 emails were removed:
-kr days min retained unknown object lock days min age (today not included) of retained object lock entries with -1 (not used)
OBJECT_NAME = ‘(unknown)’, see SAP Note 2147247
Example:
Here all transactional lock history entries with OBJECT_NAME = ‘(unknown)’ are removed:
-om mb object history table max size if the table _SYS_REPO.OBJECT_HISTORY is bigger than -1 (not used)
this threshold this table will be cleaned up according to SAP
Note 2479702
-oo true/ output cleaned memory from object displays how much memory was cleaned up from object history -1 (not used)
false table table
Example:
In this example there was nothing to clean up from the object history:
-fl % fragmentation limit maximum fragmentation of data volume files, of any service, before defragmentation of that service -1 (not used)
is started: ALTER SYSTEM RECLAIM DATAVOLUME '<host>:<port>’ 120 DEFRAGMENT
Note: If you use HSR see next slide
-fo true/false output fragmentation displays data volume statistics before and after defragmentation false
Example:
Here defragmentation will be done of all ports if fragmentation is more than 20% for any port:
This situation is normal if you use SAP HANA System Replication (HSR) (see SAP Note 1999880 Q19)
SAP Note 2332284 explains that to make RECLAIM DATAVOLUME work if you have HSR you have to
temporarily change some parameters
Why?
• HANACleaner is an automatic house-keeper → dangerous if it starts to automatically change SAP
HANA parameters
• Additionally, from security point of view, the technical user used to execute SAP HANACleaner should
not have INIFILE ADMIN
1. Both following two flags, -cc, and -ce, must be > 0 to control the force compression optimization on tables that never was compression re-optimized (i.e.
last_compressed_record_count = 0):
-cc Max allowed raw main records If number raw main rows are larger this could be compression optimized if compressed -1 (not used)
rows = 0 and -ce indicates it also e.g. 10000000
-ce [GB] Max allowed estimated size If estimated size is larger this could be compression optimized if compressed rows = 0 -1 (not used)
and -cc indicates it also e.g. 1
2. All following three flags, -cr, -cs, and -cd, must be > 0 to control the force compression optimization on tables with columns with compression type 'DEFAULT' (i.e. no
additional compression algorithm in main)
-cr Max allowed rows If a column has more rows and compression = ‘DEFAULT’ this table could be re- -1 (not used)
compressed if -cs and -cd indicate it also e.g. 10000000
-cs [MB] Max allowed size If a column is larger and compression = ‘DEFAULT’ this table could be re-compressed if -1 (not used)
-cr and -cd indicate it also e.g. 500
-cd [%] Min allowed distinct count If a column has smaller distinct row quota this table could be re-compressed if -cr and - -1 (not used)
cs indicate it also e.g. 1
3. Both following two flags, -cq and -cu, must be > 0 to control the force compression optimization on tables whose UDIV quota is too large, i.e. #UDIVs/(#raw main +
#raw delta)
-cq [%] Max allowed UDIV quota If a column’s UDIV quota is larger this table could be re-compressed if -cu indicates it -1 (not used)
also e.g. 150
-cu Max allowed UDIVs If a column has more UDIVs → compress if –cq indicates it also -1 (not used)
e.g. 10000000
4. Flag -cb must be > 0 to control the force compression optimization on tables with columns with SPARSE (<122.02) or PREFIXED and a BLOCK index
-cb Max allowed rows If more rows → compress if BLOCK and PREFIXED -1 (not used)
e.g. 100000
Following three flags are general; they control all three, 1., 2., 3., and 4. compression optimization possibilities above
-cp [true/false] Per partition Switch to consider above flags per partition false
-cm [true/false] Merge before Switch to perform a delta merge before compression false
-co [true/false] Output Switch to print out tables selected for compression optimization false
Example: Here (1.) tables that were never compressed with more than 10 million raw records and more than 1 GB of estimated size or (2.) tables with columns only
default compressed with more than 10 million rows, distinct row quota less than 1% and size more than 500 MB or (3.) tables with UDIV quota larger than 150% and more
than 10 million UDIVs, will be compression re-optimized:
-eh day minimum retained days for handled events handled events that are older that this number of days will be -1 (not used)
acknowledged and then deleted
-eu day minimum retained days for unhandled events unhandled events that are older that this number of days will be handled, -1 (not used)
acknowledged and then deleted
Example:
Here handled events older than 5 days and unhandled events older than 34 days were deleted.
It turned out the 113 unhandled events were deleted:
Examples (Note: Here default Table Statistics (i.e. HISTOGRAM, see SAP Note 1872652) is used! For more options see next slide .):
Here statistics optimization was created for 3 out of 4 virtual tables (the 4 th already had statistics):
Here number of columns per executions was limited to 2, so 3 executions were done to create statistics on this table:
Example:
Here statistics optimization HISTOGRAM was created for 1 out of 1 virtual tables (since number of rows were less than 40 and the DB was HANA):
Note: This only creates statistics! For statistics refresh, see next slide
-vnr number of days > 0 refresh age of VT if the VT statistics of a table is older than this number of days it will be -1
statistics refreshed (Note: -vl and -vr holds also for refresh) (no refresh)
Example:
Here statistics optimization was refreshed for 3 out of 3 data statistics (i.e. the 3 columns of the 1 existing VT):
Note: This is not the same thing as refresh of a virtual table! See -vtr below.
-dsr number of days > 0 refresh age of data if the data statistics is older than this number of days it will be refreshed -1
statistics (Note: this is the same as –vnr, except that -vl and -vr are ignored) (no refresh)
Example:
Here a table and statistics were created as per example in SAP Note 2800028 #8, so we have two statistics reasons CREATE STATISTICS:
-vtr ‘I’, ‘W’, and/or, refresh virtual a string that defines if refresh should be done on virtual tables shown as mismatch from the procedure ‘’
‘E’ or any tables CHECK_VIRTUAL_TABLES with a severity of INFO, WARNING, and/or ERROR. The string can be 1, (not used)
combination 2, or 3 characters long with the characters I (for INFO), W (for WARNING), and E (for ERROR).
-vts name of a schema with the the -vtr will only be done for tables in this schema ‘’ (all
schema virtual tables schemas)
-vta name of a VT the virtual tables the -vtr will only be done for this virtual table ‘’ (all
tables)
-vtp true/false print VT checks print VTs found by CHECK_VIRTUAL_TABLES before and after the refreshes false
Example:
Here all virtual tables in schema VT_SCHEMA will be checked if any of those needs to be refreshed, but -es false, the refreshes will not actually be
executed (only shown, since -os true):
-ir days inifile content history retention deletes older inifile content history (should be more than 1 year) -1 (not used)
Example:
Example:
-ir days inifile content history retention deletes older inifile content history (should be more than 1 year) -1 (not used)
Example:
-es true/false execute sql Execute all crucial housekeeping tasks (useful to turn off for investigations with –os=true) True
-os true/false output sql Prints all crucial housekeeping tasks (useful for debugging with –es=false) False
Example:
Note: For
multiple
configuration
files, see
some slides
below
Example:
-op output path full path of the folder (will be created if not there) where the hanacleaner logs are written (not used)
Note: if you include %SID in the output path, it will automatically be replaced with the actually SID of your system
-or days retention logs in the path specified with -op are only saved for this number of days -1 (not used)
-so true/ standard 1: write to std out, 0: do not write to std out 1
false out switch
Example:
Here a output folder is deleted and then automatically created again by hanacleaner and the daily log file written into it:
-en emails for email notification a comma separated list of email addresses that will receive emails in case of fatal (not used)
errors
-et seconds timeout time for email warning emails specified with –en gets emails if HANACleaner ran too long (not used)
-enc email client to explicitly specify the client (e.g mail, mailx, mutt,..), only useful if -en if used mailx
-ens sender's email to explicitly specify sender's email address, only useful if -en if used (configured used)
-enm mail server to explicitly specify the mail server, only useful if -en is used (configured used)
Example:
Here HANACleaner took longer than 10 seconds, so it send an email
Example:
Here two keys are stored; one for SystemDB and one for a Tenant:
Example:
Here trace files older than 42 days are deleted from the SystemDB and from a Tenant:
Example:
Here the user HANACLEANER1 with same password was created in both SystemDB and in a Tenant
(for privileges,
see earlier slides)
Then only one key, for the SystemDB, was provided in hdbuserstore
Example:
Here the key SDBKEY is used
to access the system, then it is
specified with -dbs that two
databases, SYSTEMDB and PQL,
will be cleaned up on their old
trace files
Example:
Here the HANACleaner is started on a system that is a Secondary in a HSR setup, with online check interval 10 seconds:
Then the HANACleaner that runs on the previous Secondary can now start with the cleanup tasks:
Example:
(tries to clean trace
files older than 400
days again after 1 day):
This shell script, hanacleaner.sh, provides the <sid>adm environment, with source $HOME/.bashrc and then executes the hanacleaner
command:
Then a new crontab can be created, calling this shell script, e.g. once every night at 1 o'clock:
Note: if you want to log the output to std_out set up the crontab like this:
Hint 1: 00 18 * * 0 → execute 18:00 Sundays Hint 2: 00 18 * * * 0 su - <sid>adm –c "python ..hanacleaner.py … " as root → no need to source
© 2023 SAP SE. All rights reserved. Customer 49
House Keeping
HANACleaner & CRON with Lock (e.g. for Scale-Out)
HANACleaner can be scheduled with CRON to run in background, so that the terminal can be closed
Note: hanacleaner expects the environment of <sid>adm → source /bin/bash (or equivalent)
Note: cron can try to start hanacleaner e.g. every week, but thanks to a lock, it will not start until the first process stopped
This shell script, hanacleaner.sh, provides the <sid>adm environment, with source $HOME/.bashrc and then executes hanacleaner:
(Note: Check, by manually executing ./hanacleaner.sh, that it works. If not, there might be a hidden ^M originating from using VI in dos mode. This can be solved by
:set ff=unix in VI as described in this forum.)
Then a new crontab can be created, calling this shell script regularly ( in this example 0 0 * * 0 = once a week), but only if the previous lock is gone:
It is possible with ps to find that hanacleaner is running in background (but maybe not as easy as with hanasitter):
System DB System DB Replica System DB Replica System DB Replica System DB Replica System DB
Master Nameserver Worker Nameserver Worker Nameserver Worker Nameserver Worker Nameserver Master Nameserver
Host 1
Crashes
Host 1
Tenant DB HSI.2 Restarted Tenant DB HSI.2
Tenant DB HSI.1 Tenant DB HSI.1
Worker Indexserver (as Stand-By)
Master Indexserver Worker Indexserver Master Indexserver
atgvmls7071 > atgvmls7072 > atgvmls7073 > atgvmls7071 > atgvmls7072 > atgvmls7073 >
hanacleaner.py hanacleaner.py hanacleaner.py hanacleaner.py hanacleaner.py hanacleaner.py
Online check, Primary Online Check, Primary Online Check Online Check Online Check, Primary Online check, Primary
Check, Master Check, & Check, Master Check → sleeps → sleeps Check, Master Check Check, Master Check,
Clean Up Activities → sleeps → sleeps & Clean Up Activities
On both SYSTEMDB & HSI On SYSTEMDB On SYSTEMDB On SYSTEMDB On SYSTEMDB On both SYSTEMDB & HSI
*
* Storing SYSTEM in hdbuserstore is ofcourse unacceptable
from security point of view! Instead I should have created a
HANACLEANERUSER, with proper privileges, in SystemDB
and used that user in SDBKEY instead.
*
* Storing SYSTEM in hdbuserstore is ofcourse unacceptable
from security point of view! Instead I should have created a
HANACLEANERUSER, with proper privileges, in SystemDB
Note: This could of course been executed via a CRON job instead (see last slide) and used that user in SDBKEY instead.
*
* Storing SYSTEM in hdbuserstore is ofcourse unacceptable
from security point of view! Instead I should have created a
HANACLEANERUSER, with proper privileges, in SystemDB
Note: This could of course been executed via a CRON job instead (see last slide) and used that user in SDBKEY instead.
Now we can kill the current running HANACleaner by first checking the PIDs: