(SP35) Point-In-Time Recovery

The Point-In-Time Recovery (PIT) recovery feature allows you to make the state of an archive consistent with a primary database. In the case the primary database or the archive (e.g. Hadoop) has been restored to a certain moment and is now in an inconsistent state, this functionality analyzes the situation and synchronizes the archive with the primary database.

There are two supported use cases:

  1. Archive is restored to a point in time when it doesn't correspond with the primary database - the necessary data for recovery are stored in the changelog in the primary database
  2. Primary database is restored to a point in time when it doesn't correspond with the archive - the changelog is stored in the archive

These use cases can be used either separately or combined.

The PIT recovery feature recovers only changes performed by the OutBoard Data Tiering with NLS. These changes are:

  • Archiving
  • Reloading
  • Writer operations
  • Change of the structure

Other limitations are mentioned in the table below:

FunctionalityLimitations
InfoProvider type
  • DataStore objects, Write Optimized DataStore objects and InfoCubes are supported
Aging profile
  • Aging profile with only one target storage is supported
Target storage type
  • Hadoop as target storage is supported

Point-in-time Recovery Setup

The first use case requires binary storage to store the changelog. Go to the transaction /DVD/SM_SETUP and click on New Storage. In a pop-up window fill in these parameters:

  • Storage ID
  • Storage Type: BLOB
  • Blob Size: Recommended value is 32 000, the maximum size depends on the type of the primary database
  • Data Class: Area of the database where the tables are stored (default value is APPL1)
  • Database Prefix: Custom prefix of the changelog table name


Go to Settings > Expert settings and choose DEFAULT InfoProvider and set its parameter PIT_BIN_STORAGE to Storage ID of your binary storage.

To be able to recover from the first use case, set parameter USE_PIT_HANA to X. To be able to recover from the second use case, set parameter USE_PIT_ARCHIVE to X.

If you set one or both of these parameters for DEFAULT InfoProvider to X, it enables the PIT recovery and creates a PIT changelog for all newly created DAPs of the InfoProviders. If some DAPs already exist, you should run the report /DVD/NLS_PIT_ENABLE (first use case) and/or /DVD/NLS_ARCH_PIT_ENABLE (second use case) for these InfoProviders. We recommend you run these reports in the background, as it may take a while.

If you want to enable PIT recovery just for some InfoProviders, set one or both of these parameters for specific InfoProviders to and save it. This creates the PIT changelog right away.

It is possible to recover only changes performed after the PIT changelog creation.

Housekeeping

To delete the PIT changelog data older than a retention period, use the report:

  • /DVD/SM_HANA_CHL_DELETE for the changelog in the primary database
  • /DVD/SM_CHL_DELETE for the changelog in the archive

To delete the PIT changelog data for all InfoProviders, just leave the select option for InfoProviders empty. We recommend you schedule the execution of this job periodically to avoid the growth of the database.

Make sure that the retention period is big enough because it's possible to recover the changes only if the database was restored to a point within this period. If you are using both supported use cases, the retention period must be the same for both changelogs.