Skip to Content
Author's profile photo Nicholas Chang

SAP HANA Dynamic Tiering Doubts and Questions – Brainstorming

Q1. Since Dynamic Tiering was claimed as Disk columnar based, appreciate if someone can shed some light on why every query runs on extended table, remote Row Scan was used instead of Column Search.

Understand that “remote” was used by SAP HANA treated extended table as virtual table.

Experiment A:

Select * from Extended Storage table and based on the visualize plan, remote row scan was used.

Experiment B:

Select specific column from Extended Storage table and based on the visualize plan, remote row scan was used as well.

Experiment C and D: Replicate experiment A and B query on HANA Columnar table. From below, we can see that Column Search was used for both queries.

Q2. In RLV enabled Extended Storage, noticed that delta is constantly high in log_es as shown below.

Since RLV is improve performance to enable write concurrently and acts like a delta store in HANA, when will the delta merge happens and will the percent used shrink down if delta merge happens?

Q3. Realize that we can enable the trace “fedtrace” for indexserver to give us how indexserver operated on esstore, is there any trace we can enable on esserver to gain more insight on how exactly esserver works?

All valuable inputs and questions are welcome and perhaps we can use this space as a central knowledge base for Dynamic Tiering.

Hopefully these questions are answered before we consider Dynamic Tiering as a solution for multi data temperature.


Nichoals Chang

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Lars Breddemann
      Lars Breddemann

      Ok, concerning Q1:

      As I see it, even though the ES server uses a column store database engine, the output of any query - just like in SAP HANA - is a record set.

      Since SAP HANA technically communicates via plain SQL with the IQ engine which was the starting point for the ES server, it's not surprising to see that the results from the extended storage access are in fact rows.

      That doesn't mean that the internal processing within the ES server is row based - it simply means that there is a materialization involved in the communication between indexserver and ES server.

      And yes, I'd agree if you would now say: "well, is that necessary? Couldn't that be optimized?". I guess there are options to optimize here (deliver results in "column store" format, directly hand over query operation trees instead of SQL queries, etc... ) - but this might be future development.

      About your Q2, you may want to check

      - Lars

      Author's profile photo Nicholas Chang
      Nicholas Chang
      Blog Post Author

      Hi Lars,

      Thanks for the precious answers as always.. btw, i think i need more time to digest.

      Thanks again!

      Nicholas Chang