alter system alter configuration ('global.ini', 'SYSTEM') set ('persistence', 'log_mode') = 'normal' with reconfigure;

1. Execute the dsshanasaparch.sql script under the same schema that contains the SAP dictionaries. This script is available in the DSS_HOME/dbms/hana directory. It creates tables that DSS uses to identify the records automatically archived by SAP HANA.

2. Execute the statement INSERT INTO "/DSS/IU_ARCHBLK" VALUES (:<em>user_name</em>) to register an SAP application user that will perform archive deletion in SAP HANA. All deletions made by this user will be marked as archived.

The internal table /DSS/IC_ARCHBLK tracks archive deletions by creating a single record for each process. It serves only as a transactional marker and has no other purpose. To prevent data accumulation, this table requires periodic cleanup. You can use the built-in functionalities of your database system to automate the cleanup of this table. Alternatively, you can manually delete old entries from the table.

3. Grant CREATE ANY TRIGGER privilege to the DSS database user:

   GRANT CREATE ANY TRIGGER TO <em>user_name</em>;
   

• Create the SAP HANA location and define the required actions in DSS:

  1. Select the Recognize SAP Archiving Process option (or define the equivalent location property SAP_Archiving) while creating a location or by editing the existing location's source and target properties.

  2. Define the following three actions on the target location:

     Location	Action	Parameter(s)
     Target	ColumnProperties	Name={col_name_for_arch_deletes} ArchiveDelete Extra
     Target	Restrict	CompareCondition=“{col_name_for_arch_deletes}=0” Context=!compare_deleted
     Target	Restrict	Context=refresh_keep_deletes RefreshCondition=“{col_name_for_arch_deletes}=0"

     These action definitions are required to create an extra column col_name_for_arch_deletes in the target location. The value populated in this column indicates the type of record deletion:

     • If a row is automatically archived by SAP, the value in this column will be set to 2.
     • If parameter SoftDelete is also defined, value 1 indicates the record was manually deleted by a user (who is not registered as an SAP application user for archive deletion).
     • Value 0 indicates the record is not deleted.

If you use ArchiveDelete and SoftDelete for the target location simultaneously, the columns created for ArchiveDelete and SoftDelete must use the same column names. Otherwise, errors will occur.

 Defining [**ColumnProperties**](/docs/dss6-action-reference-columnproperties) action with **ArchiveDelete** parameter is similar to defining [**SoftDelete**](/docs/dss6-action-reference-columnproperties#softdelete) for identifying the archived deletes.

Capturing from Backint

<b>Since</b> v6.1.0/24

DSS supports capturing changes from backups created using Backint for SAP HANA.

DSS uses the HANA system views (backup catalogs) to get the list of existing log files.

DSS does not directly access the third-party backup storage system. Instead, it interacts with the SAP HANA Backint client, which is installed on the SAP HANA database node. The Backint client handles all communication with the third-party backup storage system.

The configuration and authorization of the Backint client depend on the specific Backint software provider. For most Backint implementations, configuration is managed through a YAML configuration file. This file typically governs defining user permissions for access to the storage system, configuring log file locations, setting up repository-specific access, such as restricting the client to read-only permissions for specific repositories.

However, some Backint software providers may use different formats or methods for configuration and authorization. For example, Microsoft Backint uses a configuration mechanism that does not rely on a YAML file.

Both capture methods (Direct DBMS Log Reading and Archive Only) are supported when the DSS and HANA database are located on the same node. However, if they are on separate nodes, only the Archive Only capture method is available.

Configuration for Capturing from Backint

To enable DSS to capture data from backups created using Backint for SAP HANA, perform the following steps:

1. If you are upgrading from DSS v6.1.0/23 or an earlier version, run the script dsshanaviews.sql located in the DSS_HOME/dbms/hana directory. The script creates a set of views that DSS uses to read from system dictionaries in SAP HANA.

2. Configure location properties:

   • If DSS and the SAP HANA database are on the same node: The values for the location properties BACKINT EXECUTABLE PATH (Hana_Backint_Executable_Path) and BACKINT CONFIGURATION FILE PATH (Hana_Backint_Configuration_Path) are retrieved automatically from the SAP HANA database.

   • If DSS and the Backint client are on different nodes: DSS supports running Backint on a different node only if the Backint software allows and supports this configuration. For example, AWS Backint has been tested and is known to work in this scenario. However, this may not be possible for all Backint providers, as it depends on their implementation. In such cases, you must manually define the location properties BACKINT EXECUTABLE PATH (Hana_Backint_Executable_Path) and BACKINT CONFIGURATION FILE PATH (Hana_Backint_Configuration_Path) in DSS.

The configuration and setup of Backint on a different node are entirely your responsibility. Ensure that the Backint executables and any dependencies are properly installed and accessible on the remote node.

3. Add Backint as a trusted external application: By default, DSS does not trust external applications. To enable trust, do the following:

   • Copy the file dssosaccess_example.conf from DSS_HOME/etc to DSS_CONFIG/etc, and rename it to dssosaccess.conf.

   • Edit the dssosaccess.conf file to add the full path of the Backint application under Allowed_Plugin_Paths. Typically, the default path is /usr/sap/HDB/SYS/global/hdb/opt. For example:

     {
       ## This section safelists two directories for command execution.
       ## By default, DSS will only run binaries and scripts inside
       ## '$DSS_CONFIG/plugin/agent' and '$DSS_CONFIG/plugin/transform'   
       #
       Allowed_Plugin_Paths: [
       /usr/sap/HDB/SYS/global/hdb/opt
       ]
     }
     

Rubrik Configuration

To capture SAP HANA backups with Rubrik, you need to additionally configure two environment variables for the DSS OS user account that runs the DSS agent:

• $DBNAME - represents the SAP HANA database name
• $SAPSYSTEMNAME - indicates the SAP system identifier known as SID (System ID)

To set these variables:

1. Log in as the user who runs the Backint interface (typically the SIDadm user).
2. Confirm the values for $DBNAME and $SAPSYSTEMNAME with the SAP Basis team, who can retrieve them by running the env command on the SAP system.
3. Set these values as environment variables for the DSS OS user or add these environment variables into the channel configuration on the capture side.

AWS Backint Configuration

For AWS Backint, perform the following additional steps:

1. Create a custom AWS Backint configuration file on the HANA node. For example:

   cp /hana/shared/aws-backint-agent/aws-backint-agent-config.yaml  \ 
   /hana/shared/aws-backint-agent/aws-backint-agent-config-dss.yaml
   

2. Modify the LogFile parameter in the newly created configuration file:

   LogFile: "/hana/shared/aws-backint-agent/aws-backint-agent-catalog-dss.log"
   

3. Specify the file path of the new configuration file (for example, aws-backint-agent-config-dss.yaml) in the location property BACKINT CONFIGURATION FILE PATH (Hana_Backint_Configuration_Path).

<div class="callout callout-important">

Backint log files generally have permissions such as 622 (read-write for the owner, read-only for group and others). Since the DSS user typically belongs to the same group as the SAP HANA owner (for example, hdbadm), adjusting the umask policy could work but is generally considered insecure.

As a result of these configurations, two Backint log files are generated:

• Standard backup log: Contains information on all standard backup operations
• DSS-specific log: Contains information related specifically to DSS operations

Shared Key Authentication for AWS S3

If your Backint storage is hosted on Amazon S3 and uses shared key authentication, you may need to create an AWS configuration folder named $(HOME)/.aws and place a 'credentials' file inside it. The 'credentials' file should include a section specifying the aws_access_key_id and aws_secret_access_key required for authentication.

Disabling Backint Functionality

To disable Backint in DSS, set the environment variable ZIZ_HANA_USE_BACKUP_CATALOG to 0.

SAP HANA Primary/Secondary Configuration for Online Log Replication

This section provides instructions for setting up DSS to replicate online logs in a high availability (HA) environment using SAP HANA with an Active/Passive (Primary/Secondary) setup.

Components Involved in the Setup

• SAP HANA Instances:

  • HANA01 (Primary/Active): Handles all transactions and data processing, writing transaction logs to a local disk and backup logs to a shared disk, typically EFS (Elastic File System) or NFS (Network File System).
  • HANA02 (Secondary/Passive/Read-Only): Standby instance, does not process transactions until a switchover occurs.

• DSS Hub Server: Orchestrates the replication process. It is located on a separate server connected to both SAP HANA instances (HANA01 and HANA02) via a Virtual IP, which always points to the active node. The DSS Hub Server communicates with the active node's DSS Agent, switching to the passive node in case of failover.

• DSS Agents: Installed on both HANA01 and HANA02, capturing transaction logs and replicating them through the DSS Hub Server. The DSS Agents read the transaction logs from the local disk and backup logs from the shared disk (EFS or NFS).

• Virtual IP Linking: Ensures continuous DSS Hub Server communication with the active SAP HANA instance, eliminating manual configuration during failover.

Prerequisites

Before proceeding, verify the following:

• DSS Hub Server is installed and configured on a separate server.
• DSS Agent is installed on both HANA01 and HANA02 instances.
• DSS Agent is configured on the primary/active node (HANA01).
• The Virtual IP address points to the DSS Agent on the SAP HANA active node (HANA01).
• Replication mode: Set the SYNC_MODE parameter to either SYNC or SYNCMEM mode while registering the secondary system. Only these modes are supported by DSS for replication.
• System replication operation mode: Set the OPERATION_MODE parameter to either logreplay or logreplay_readaccess while registering the secondary system. Only these modes are compatible with DSS.

Synchronize DSS Agent Configuration

Perform the following steps to ensure that the DSS Agent configurations are identical across both primary and secondary instances of SAP HANA (HANA01 and HANA02):

1. Navigate to the directory where the DSS Agent configuration files are stored on HANA01 - $DSS_CONFIG/etc.
2. Copy the dssagent.conf and dssagent.user files to the corresponding directory on HANA02 - $DSS_CONFIG/etc.
3. On HANA02, re-start the DSS Agent to apply the new configuration. The steps to restart the agent will vary based on how it is configured on your operating system. For more information, see System Configuration for DSS Agent on Linux.

SAP Configuration

By default, SAP changes the permissions on transaction log files from 640 to 600, restricting access to the SAP user only. This configuration prevents the sapsys group from reading these files.

To enable sapsys to function correctly, modify the permissions so that the sapsys group has read-only access to the transaction log files on the passive node HANA02:

1. Log in to the HANA02 system using an account with sufficient privileges to change file permissions.

2. Navigate to the directory where the transaction log files are stored. The path may vary depending on your SAP setup.

3. Use the chmod command to change the permissions of the transaction log files to 640. This setting allows the SAP user to read and write, and the sapsys group to read. Replace path_to_transaction_logs with the actual path to your transaction log files.

   chmod 640 <em>path_to_transaction_logs</em>
   

4. Use the chgrp command to set the group ownership of the files to sapsys:

   chgrp sapsys <em>path_to_transaction_logs</em>
   

If SAP automatically reverts these permissions back to 600, consider setting up a script or a cron job that periodically checks and resets the permissions to 640.

5. Verify that the permissions are correctly set by listing the files:

   ls -l <em>path_to_transaction_logs</em>
   

   The permissions should display as -rw-r----- for each log file, indicating that the SAP user has read and write access, and the sapsys group has read access.

Capture Limitations

This section describes the limitations for capturing changes from HANA using DSS.

• DSS does not support Capture from the following table types - pool, cluster, and STXL (long text).

• When using SAP HANA as a source location, DSS does not support file-based location types (such as Amazon S3, Apache HDFS, Apache Kafka, Azure Blob Storage, Azure Data Lake Storage, Files, Google Cloud Storage) as target location.

• Until version 6.1.0/25, DSS does not support Capture from HANA encrypted logs.

HANA allows encryption of transaction logs and transaction log backups separately. So if only the transaction logs are encrypted and not the transaction log backups, then DSS can capture changes using Archive Only method.

• Since HANA does not support supplemental logging, DSS will not be able to process certain actions/parameters that require the value of a column, and that column is not present in the HANA logs. The actions/parameters affected by this limitation are listed below.

  • The following action/parameter definitions will not function due to this limitation:

    • Action CollisionDetect
    • Parameter TimeKey in action ColumnProperties
    • Parameter DbProc in action Integrate
    • Parameter Resilient in action Integrate (will not function only if a row is missing on the target)
    • Parameter BeforeUpdateColumns in action FileFormat
    • Parameter BeforeUpdateColumnsWhenChanged in action FileFormat

  • The following action/parameter definitions will not function if it requires the value of a column and that column is not present in the HANA logs:

    • Parameter CaptureExpression in action ColumnProperties (however, CaptureExpressionType=SQL_WHERE_ROW will function normally)
    • Parameter IntegrateExpression in action ColumnProperties
    • Parameter RenameExpression in action Integrate
    • Parameter CaptureCondition in action Restrict
    • Parameter IntegrateCondition in action Restrict
    • Parameter HorizColumn in action Restrict
    • Parameter AddressTo in action Restrict

The above mentioned Restrict parameters for compare and refresh will function normally.

• Online compare with mode Combine Initial Differences with Changes Captured while Compare is Running in UI (equivalent to dsscompare -o diff_cap in CLI) is not supported for HANA source.

Compare and Refresh from HANA

DSS allows you to perform only Compare and Refresh from HANA database (without using Capture). This section describes the configuration requirements for performing only Compare and Refresh from HANA database.

Grants for Compare and Refresh from HANA

This section lists the grants required for performing only Compare and Refresh from HANA database.

• The DSS database User must be granted the following privilege to read from the HANA database:

  grant select on <em>tbl </em>to <em>username</em>;