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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.