Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

For me, HANA is simply put a database from and for SAP. A database with special features, sure. Being a database administrator makes me think about it in a biased way. What do DBAs do with HANA? Actually this is a pretty simple list:


1. Patching, patching, patching
2. Make sure to have valid backups
3. Restore+Recovery in case of need

All other HANA specific tasks could almost be neglected. Most modern databases are made for low TCO, but SAP has taken this to some extreme level, leaving the administrator almost nothing else to do except my three tasks listed above. You can change HANA parameters for example, but it doesn't make sense unless that is recommended by SAP.

So here I could stop my blog. But wait! Christmas time is approaching quickly, so I deem this is the perfect time to compile my personal HANA wish list. As usual there is no guarantee to be heard, but not even asking would be the worst approach.


Although HANA provides quite a lot of these monitoring views with the prefix "M", the actual insight into the database operation is quite coarse. I really like the expensive statement tracing (in file indexserver.ini section [expensive_statement] enable=true), and I am positively surprised that the corresponding monitoring view M_EXPENSIVE_STATEMENTS even contains a column STATEMENT_ID. However, this STATEMENT_ID is not a hash value of the actual SQL statement, but some arbitrary number which makes it somewhat useless. Even worse, this STATEMENT_ID seems to be referenced only in monitoring views M_PREPARED_STATEMENTS and M_EXPENSIVE_STATEMENTS and nowhere else.

1. Wish: Why not using a hash value for the STATEMENT_ID? And please make this STATEMENT_ID available in more views, e.g. M_SQL_PLAN_CACHE.


With SAP pricing the HANA solution via memory consumption, this makes memory consumption a hot topic. The database should provide more detailed information about how much memory is used for which aspects. The most detailed breakdown I have found so far is in view M_MEMORY_OBJECTS, but this is not sufficient to get a feeling for what is normal memory consumption. After all, the numbers from M_MEMORY_OBJECTS correlate very well with other tools like e.g. top, raising my confidence in that view. Often I see numbers from HANA which contribute more to confusion about memory consumption than anything else.

2. Wish: Please provide more detailed information what the memory is actually used for.


SAP can be very proud to have a very consistent documentation. Unfortunately, in almost every aspect I am involved the documentation is also very rudimentary, simply describing the obvious. Or, not much better: It is inventing new technical slang in a very solipsistic way. If my description was not clear, then just have a look at anything Oracle Corp. has ever published on their database software. It is no wonder that for a brand new product like HANA the documentation is also "work in progress". However, with my experience so far with technical SAP documentation I fear the current status for HANA documentation might not change significantly.

3. Wish: Please provide more concepts and background information on how the HANA database works internally with direct references to the respective monitoring views. Additionally, some more words on what the various HANA monitoring views actually show is highly appreciated.


Doubt is a serious problem for database administrators. Even more important than availability and performance is data security. Therefore HANA also needs a tool to verify the integrity of the database. I heard rumors that such features are in the pipeline, so let's wait for HANA 1.0 SPS05.

4. Wish: SAP, please don't forget to pack the consistency check tool into this year's parcel!


Coming to think of it, if I combine a consistency check and documentation, what could I get? A consistency check for the various ini files! The life of the DBA could be simplified if there were such a tool, together with a more detailed explanation on the HANA parameters. Of course, we only change parameters due to SAP's recommendations and HANA typically works well with default parameter settings. But anyway, I believe such a tool makes sense because currently HANA accepts every nonsense. (E.g. the unit is not always clear for HANA parameters. Bits? KBytes? Blocks?)

5. Wish: Please evaluate the possibility of a parameter check tool.


SAP has already announced this, but being a DBA I simply need to have a backup integration! I know that SAP provides a reference backup script in SAP note 1651055, but HANA doesn't feel like a real database as long as it doesn't provide a real backup integration.

6. Wish: SAP, take your required time, but please release HANA 1.0 SPS05 with the backup integration soon!


Maybe this is least important on my wish list, but I'll state it nevertheless. Lightweight HANA to HANA replication would be a really cool feature. I do not mean disaster recovery scenarios with heavy replication, but for system migrations via sending logs over WAN connections. A "near zero downtime" migration from one datacenter to another is the ultimate goal for any migration consultant. Only very few HANA instances are productive yet, so this is more like an outlook of the future.

7. Wish: I wished that migrations could be done almost without interruption.


So now I kept the best for the end. In my opinion HANA has not only one but two size metrics. The classical metric is "how much data is stored inside the database" and can be expressed in the number of used bytes in the datafiles. Then there is the SAP license metric with the amount of used memory, which contains not only data but also temporary and auxiliary data structures. It is easy to query the database for these metrics, so one might wonder why these numbers are not also shown in transaction DB50, but anyway this is not my point. I really wonder why the database doesn't keep a history of these metrics. One of the first things HANA customers might do is create scripting solutions to gather and keep such information. I deem is so important that I believe it is only a matter of time until the HANA database will provide it.

8. Wish: Please provide HANA database size and memory usage metric histories inside the database.


That's all for this year. I am hoping for a wide adoption of SAP HANA in the SAP universe. So next year I might return with even more wishes!

8 Comments
Labels in this area