Importing Delivery Units Failed in HANA

Symptom : During the installation or upgrade of HANA, you encounter issues in the step "Importing Delivery Units".

With revision 45 and newer the following messages appear in the log:
Importing delivery units...
ERR: Upgrade failed
ERR:   error upgrading
ERR:     Import of delivery units failed
ERR:       Cannot import delivery

Starting with revision 46 an upgrade will not fail but return the exit code 2 and print the following message:
#####################################################
# Problems occurred while importing delivery units (content).
#####################################################

Solution  : Importing the delivery units is the last step in both installation and upgrade. If this fails your system will still be up and running.

Unless you are using HANA XS features fixing the import issues is not mandatory.If you are using the system to develop or run HANA XS applications, try to solve these issues by repeating the import of the affected delivery units.

To get SAP Hana delivery units consistent it is not sufficient to start SAP Hana upgrade process (by hdbupd or hdblcm) again.

Delivery Units Detail and Location:

HDB:SIDadm:  xyz/usr/sap/SID/global/hdb/auto_content 82> ls -latr

------------------- Importing Delivery Unit Manually ------------------------

regi import  Delivery _Unit_Name  --key=WW

Example:
regi import ADMIN.tgz --key=WW

Rowstore Table Corruption

Possible Rowstore Table Corruption When Continuous Page Flush is Enabled:

Prerequisites:

1- SAP HANA database Revision 120 - 122.03
2- Continuous page flush is enabled
  (parameter global.ini -> [persistence] -> continuous_flush_interval_s> 0).
   In SAP HANA database SPS12 continuous page flush is enabled by default, even if the parameter      is not explicitly set Slow disk IO will increase the likelihood to run into this problem

Solution: 

Disable continuous page flush to prevent future corruptions by running the following SQL command:

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'system') SET ('persistence','continuous_flush_interval_s') = '0' WITH RECONFIGURE;

To revert back -

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'system') UNSET ('persistence', 'continuous_flush_interval_s') WITH RECONFIGURE; 

Note - Default Value is continuous_flush_interval_s > 0 .You have to set = 0 to disable.

log backup in hana

SAP HANA creates redo log backups automatically at regular intervals By default and in during a log backup, only the actual data of the log segments for each service with persistence is written from the log area to service-specific log backups in the file system or to a third-party backup tool.

SAP HANA automatically continues creating log backups of all the log segments that have not so far been backed up.

By default, automatic log backups are enabled in SAP HANA. You can manually disable or enable automatic log backups and for enable automatic log backups,the log mode setting must be normal.

After a system failure, you may need log backups to recover the database to the desired state.

Log Backup file format :

(log_backup) __(volume ID)_(log partition ID)_(first redo log position)_(last redo log position).(backup_ID)

Example:
A log backup name could look like this : (log_backup_1_0_1234567_1238567.1380740407446)

analyzing table Joins in HANA

In SAP HANA, if a query on joined tables takes a long time, you can analyze how the tables are joined and in what order. A join evaluation (je) trace of joined SAP HANA tables provides the details you need for such an analysis.

join eval=debug  (enable the parameter)

Context : The je trace provides a lot of information that is hard to consume if you are not an SAP HANA join engine expert; however, it does provide some useful information for performance analysis. From the information within the trace files, you can see which table is used as the first table
when processing a join and how the order of tables in the join is defined. You can use this information to determine whether query performance is negatively impacted by the table join.

To start a je trace and analyze the relevant trace information, proceed as follows:

Procedure :

- In the Administration editor, choose Trace Configuration and create a new user-specific trace.
- The Trace Configuration dialog box opens.
- Specify a context name.
- The context name appears as part of the trace file name and should be easy for you to recognize and later find.
- Specify your database user or application user.
- Select the Show All Components checkbox.
- Enter join as filter text and search for the join_eval component.
- For the join_eval component, select DEBUG as the system trace level.
- Choose Finish.
- Run the query you want to trace.
- Switch off the trace by deleting the user-specific trace configuration.
- On the Diagnosis Files tab, search for the indexserver trace file, open the file, and select Show Entire File.
- From the end of the file, search backwards for the beginning of the trace section.
- The trace section starts with i TraceContext TraceContext.cpp.
- In the trace section, analyze the following trace information:
        Estimations for the WHERE conditions
        Table size and join conditions
        Join decision

history views in hana

HANA history views is very useful for checking the past detail about the database.i am sharing some history views ,which is very useful for checking performance related issues.

When HANA database is not restarted after the performance downgrade, the "System Information" views can be checked further. If the performance issue is resolved without a database restart, then it indicates that the database was not in a hang situation, but the database performance was temporarily decreased.

If HANA database has been restarted after a hang situation, the history of database status can be found in "_SYS_STATISTICS" schema:

- HOST_LONG_RUNNING_STATEMENTS
- HOST_LONG_SERIALIZABLE_TRANSACTION
- HOST_LONG_IDLE_CURSOR

- HOST_UNCOMMITTED_WRITE_TRANSACTION
- HOST_MEMORY_STATISTICS
- HOST_RESOURCE_UTILIZATION_STATISTICS

- HOST_SAVEPOINTS
- HOST_MVCC_OVERVIEW
- HOST_VOLUME_IO_PERFORMANCE_STATISTICS

hdbbackupdiag in HANA

hdbbackupdiag Tool:

The output of hdbbackupdiag contains the names of all the files required to recover the SAP HANA database.
If you specify the --check option, the results of the metadata checks are also displayed.

Example : hdbbackupdiag --check --logDirs xyz/hana/backup/SID/log --dataDir xyz/hana/backup/SID/data/

Display all the backups required to recover the database until May 11, 2015, 01:05:00 p.m. The metadata of the backups is not checked.

Example: hdbbackupdiag -f -d xyz/hana/backup/SID/log -u "2016-06-21 05:05:00"

Note :  The time specified is UTC time, not local time.

hdbbackupcheck in HANA

hdbbackupcheck Tool :

You can use the hdbbackupcheck tool to manually check the integrity of individual data backups and log backups in SAP HANA .
If no errors were detected, hdbbackupcheck returns 0.
If an error was detected, hdbbackupcheck returns 1.

Example :
hdbbackupcheck   backup/data/BackupTestMaster_databackup_1_1
hdbbackupcheck  -v  backup/data/BackupTestMaster_databackup_1_1

Note : hdbbackupcheck notifies you if any errors were detected in the checked part of the backup.