Sap Hana Log Backup (Hana Studio)

Last post 01-09-2019, 12:18 PM by Sunil Telagamsetti. 4 replies.
Sort Posts: Previous Next
  • Sap Hana Log Backup (Hana Studio)
    Posted: 11-15-2018, 3:23 AM

    Did anyone have this error.

    I start automatically a Hana log backup from the Hanastudio.

    It is successfully created a job in the jobcontroller and transmit data but the job never complete.

    After i kill the job, the job is marke as complete.


    Any ideas.



  • Re: Sap Hana Log Backup (Hana Studio)
    Posted: 11-15-2018, 7:08 AM

    HANA log jobs will run for 6 hours by default, we call it as persistent log backup job. We don't have to kill it, after 6 hours persistent pipeline will be closed and new persistent pipeline for log job will be created this ensures quick and very reliable logs backup. This approach is designed for HANA log backups to avoid failures during log jobs.

  • Re: Sap Hana Log Backup (Hana Studio)
    Posted: 01-09-2019, 11:21 AM



    Can you tell me what happens after 6 hours? Does it start again automatically? (does it run forever, starting again every 6 hours?)

  • Re: Sap Hana Log Backup (Hana Studio)
    Posted: 01-09-2019, 11:29 AM
    • efg is not online. Last active: 05-28-2020, 3:42 PM efg
    • Top 10 Contributor
    • Joined on 02-02-2010
    • CommVault Tinton Falls NJ
    • Master
    • Points 1,729

    Yes, as soon as another log backup request comes in from the HANA database a new 6 hour job will be started.  The reason for this is that HANA can trigger many log backups so keeping the job open for 6 hours will allow the log backups to run faster as there is less overhead managing the startup and shutdown of the data pipes.  Also from a reporting perspective, there will be less "total" jobs showing up in job history. 

    Hope this helps explain the logic/use case for this design.

    Ernst F. Graeler
    Senior Engineer III
  • Re: Sap Hana Log Backup (Hana Studio)
    Posted: 01-09-2019, 12:18 PM

    Let me try to explain about the HANA persistent jobs.

    HANA database continuously initiates log backups. They can be as quick as a job in a few seconds or can be one job in an hour. It also backs up the catalog periodically (even if there is no activity), typically once in 15 minutes (this is also backed up by persistent log backup job).

    When we receive the first log backup request from HANA, we will initiate a persistent log backup job and reserve a resource. Even if the log backup completes from HANA end, we will keep the persistent job alive and hold the resource. We keep this persistent job alive for 6 hours (configurable).

    Three cases when we complete the CV persistent log backup job:

    1. When we receive the first log backup request after the 6 hours duration, we will complete the existing persistent job, release the resource, and start a new persistent job. So, in effect, the job may run for a few minutes over 6 hours.
    2. If there is any failure within these 6 hours, we will complete the job immediately. A new job will be started for the next log backup attempt from HANA. In this case, the persistent log backup job duration may be less than 6 hours.
    3. If HANA is not sending any log backup requests for 60 minutes. After an idle time of 60 minutes, we will complete the job, release resource and will not start a new persistent log backup job until HANA requests for a new log backup.

    We map the HANA log backup jobs to CV persistent jobId based on the HANA DB service name. All the log jobs initiated by a HANA service during the 6 hours duration will be backed up by the same persistent job.

    There are multiple HANA services per instance doing the log backups, that’s why we may see multiple persistent jobs running per Commvault instance at the same time.

The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Copyright © 2020 Commvault | All Rights Reserved. | Legal | Privacy Policy