Skip to Content
0

Time Travelling in SAP HANA

Feb 27, 2017 at 08:41 PM

62

avatar image
Former Member

We came across a few white papers on Time Travelling in SAP HANA but I was hoping to understand a few things:

1. Are there any differences in behaviour on HANA when using TIme Travelling on a runtime version of HANA vs Enterprise (eg Runtime - HANA as db under Banking Services or CRM etc) or are there alternative TT tech avail in such cases or on it's way?

2. In relation to TT, Should Auto Commit ever be switched off (requirement for TT to work) on a HANA DB when it runs as a dedicated DB for an SAP Solution?

Or is AUTOMCOMMIT OFF only applicable when developing your own apps? (Eg Enterprise HANA)

I don' feel comfortable with the fact that I now have to hammer M_TRANSACTIONS for the last_committed_Id or that I have to issue explicit COMMIT commands,

...Let alone consider the additional amount of space we may require for collecting history data over time for time travel.

We're trying to use the history capability for recoverability to a point in time if ever data gets hacked/broken and we don't have the luxury of restoring a full db (eg have to restore the entire landscape to the same pit, due to dependencies)

3.Any ideas where to find TT info per SAP Solution?

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

2 Answers

avatar image
Former Member Mar 06, 2017 at 01:13 PM
0

Any Ideas on this?

L

Share
10 |10000 characters needed characters left characters exceeded
Lars Breddemann
Sep 19, 2017 at 04:52 AM
0

Hi Liezl

not sure these questions are still relevant to you. I only saw them now, so let's do a quick answer:

> 1. Are there any differences in behaviour on HANA when using TIme Travelling on a runtime version of HANA vs Enterprise ?

Nope. "runtime" and "enterprise" are types of HANA licenses and don't refer to the capabilities or to the technology. "Time travel" queries work the same in all HANA versions.

> 2. In relation to TT, Should Auto Commit ever be switched off (requirement for TT to work) on a HANA DB when it runs as a dedicated DB for an SAP Solution? Or is AUTOMCOMMIT OFF only applicable when developing your own apps? (Eg Enterprise HANA)

AUTOCOMMIT OFF or ON is a setting that applies per session. It's not something you can set per database. Since this setting defines whether or not the application running the session wants to be able to control the transaction with COMMIT and ROLLBACK, it's really up to the application to choose this setting or to give users the choice.

If you don't feel comfortable using COMMIT, then this feature is not for you.

> ...Let alone consider the additional amount of space we may require for collecting history data over time for time travel.

Sure, keeping old version of data takes space. There is no free lunch.

> We're trying to use the history capability for recoverability to a point in time if ever data gets hacked/broken and we don't have the luxury of restoring a full db (eg have to restore the entire landscape to the same pit, due to dependencies)

AAAND the alarm bells are on!

History tables are in no way a point in time recovery mechanism! Database recovery means to consistently restore a state of the database.

Rolling back just one or a few tables does two things:

1. You still have a point in time recovery with all the problematic consequences and external dependencies

2. You now don't have a consistent state in your database anymore, since one table reflects an older state.

Could it be that this older state actually is still consistent? Sure, but you cannot prove or check that without manual programming and (likely) application level checks. That means you have to reinvent the transaction consistency for each table that could be rolled back. And that's something you really like to avoid.

Another fallacy is to think that the history tables are somewhat more secure than normal tables and therefore able to "protect" against faulty data manipulation. That's not the case.

History tables are stored in the same database and thus exposed to the same risks as any other table. A key point in securing databases is to take backups and store these backups somewhere else. There is no way around that if you want to be able to recover your database.

> 3.Any ideas where to find TT info per SAP Solution?

Due to many other aspects of history tables and the ways they can/cannot be used, I am not aware of any major SAP Solution that makes use of it. SAP BW started using it for their DSO objects and reverted back to normal tables, once the inefficiencies of the approach became clear.

Happy to discuss further, but in my opinion, there are not many good use cases for history tables.

Cheers,

Lars

Share
10 |10000 characters needed characters left characters exceeded