Knowing the restart properties of SAP HANA parameters, change and monitor results from server level

Problem Statement & Use Case : Let’s divide the arose problems in two levels :

1. With the rise of hyperscaler managed services , if you are onboarded for a customer project only for some short term critical maintenance services like upgrades, migrations , often you are going to find several access issues for administrators specially on SAP HANA client level . And for say if you only have 2 weeks to accomplish your entire activity and raising a bug in DevOps to allow SAP HANA cockpit from your VDI and to have proper access to that and following up and eventually get that done in a completely new customer environment is quintessentially mess. It may end up with changing the firewall rules or a certain amount of unnecessary delay if you take my personal experience.

2. Now again you are in confusion because you don’t know if you change the parameter whether SAP HANA will require a restart or not to get that activated. You may check from help guides but eventually you feel more convenient to see what your system suggests. Why to search for guides when you have access to your system and I can tell you SAP HANA will answer to your queries when asked properly

So what would you do if you are Technology Consultant, middle of an upgrade activity and for some issues you have to see the restart properties some SAP HANA params and tweak them urgently but you’re not entitled to neither SAP HANA Cockpit nor SAP HANA Studio (most preferable client tools for SAP HANA administrations) but have access to server.

Let’s use two saviors in this regard i.e. hdbsql views and a python script : setParameters.py.

The later one is released with SAP HANA 2.0 SPS05. And I will not go into the details of the script uses because that’s already explained by another colleague in a blog post(will find that in reference section later).

Example scenario : Let us assume there’s a situation in the middle of a maintenance activity that needs you to change the parameter ‘tcp_keepalive_count’ to 10 from default value 5. You have display-only sql credentials but not having access to client tools.

Now in this situation you may use ALTER SYSTEM ALTER CONFIGURATION ddls too if you get sql credentials with proper authorization. I had only lookup sql access to SAP HANA, so only option left was to use setParameters.py .

Solution : To allow users to log on to the SAP HANA Scale out database from a client using Kerberos authenticated SSO, the following configuration steps are necessary:

1. Check if the parameter needs restart

2. Change the parameter with setParameters.py

3. Check the views to observe the dynamic behavior of restart properties

4. Reboot SAP HANA

5. Check the views again to observe the dynamic behavior of restart properties

Now let’s go through little bit details of each one stated above :

1. Check if the parameter needs restart: We shall use three SAP HANA views to get the entire picture of this exercise i.e. :

CONFIGURATION_PARAMETER_PROPERTIES : Displays metadata and properties of the public configuration parameters for SAP HANA. It has a column RESTART_REQUIRED that specifies whether or not a restart is required. The values are: TRUE, FALSE, and CUSTOM. CUSTOM indicates a custom function or callback to decide whether a restart is required or not depending on the new value to be set. This one defines the default behavior of system and the value of RESTART_REQUIRED does not get changed if you modify the parameter.

M_CONFIGURATION_PARAMETER_VALUES : Displays landscape service parameter values. It also has a column RESTART_REQUIRED that displays if the parameter value has been changed and requires a restart to become effective: TRUE/FALSE. By querying this view you will come to know   the current system need, it’s dynamic.

M_INIFILE_CONTENT_HISTORY : Provides change history information for configuration (ini) files.

Now in our example scenario:

Log into SAP HANA by using the display only user and hdbsql

Now let’s see if that parameter needs restart on change querying CONFIGURATION_PARAMETER_PROPERTIES

So the above result suggests we need to take a reboot of SAP HANA if the parameter gets changed.

Now if we see the results in M_CONFIGURATION_PARAMETER_VALUES, its suggests that restart is not required. That depicts the parameter has not got changed from its default value yet.

Now let’s check the parameter change history to justify the above deduction.

So, yes it does not have any value, means not changed.

2. Change the parameter with setParameters.py :  Now let’s get into the python directory of the server and execute the script setParameter.py with sidadm.

And bingo , the parameter tcp_keepalive_count has been changed to custom value 10 now.

3. Check the views to observe the dynamic behavior of restart properties : Now let’s query into those views to see what the SAP HANA is suggesting to do.

M_INIFILE_CONTENT_HISTORY:

So, M_INIFILE_CONTENT_HISTORY has a row now that suggests we changed the parameter successfully . Don’t forget to take a look into the column values to verify the timestamp, application etc. in case of multiple entries.

CONFIGURATION_PARAMETER_PROPERTIES:

The view CONFIGURATION_PARAMETER_PROPERTIES dint get changed as expected as it holds the configuration behavior of a parameter.

M_CONFIGURATION_PARAMETER_VALUES:

As you see the value of the RESTART_REQUIRED column is now changed to TRUE , that means SAP HANA is suggesting “Hey, you were good at changing the parameter value now but don’t forget to restart me to get the change activated.” 

4. Reboot SAP HANA:  No mumbo-jumbo now and straight go ahead a take a reboot.

I did not have a scale-out system ,so HDB stop/start did not disappoint me at all.

5. Check the views again to observe the dynamic behavior of restart properties:  So changes were done, SAP HANA has been rebooted and let’s see the behaviors of the same views again:

M_CONFIGURATION_PARAMETER_VALUES:

Now RESTART_REQUIRED column got its previous value i.e. FALSE, meaning SAP HANA is happy now with your changes and not asking for any favor . The parameter tcp_keepalive_count has been changed and activated successfully.

CONFIGURATION_PARAMETER_PROPERTIES:

As this view contains public configuration, the value of RESTART_REQUIRED did not get hindered.

M_INIFILE_CONTENT_HISTORY:

Since no changes in parameter value happened again M_INIFILE_CONTENT_HISTORY did not get a new entry.

Still not satisfied and want to validate the settings another way? I can give some hope too:

Here you can see the parameter is updated with the changed value and nothing much, Bos’s your uncle.