Wednesday 24 May 2017

Hana DR – Replication of INI parameters

Before Hana SPS12 we always have to manually setup the INI parameters on the secondary site after a change in the primary. It is not a tough thing to do nevertheless SPS12 introduced a feature to get a synchronization between the systems in a DR scenario also for INI parameter changes. One more step in the Hana synchronization and in my opinion it’s welcome.

I’ll not go into the replication configuration steps just describe my findings on the INI replication subject. Hope you get it useful.
Note: After installing SPS12 the parameter [inifile_checker]/enable = true

SAP HANA DR, SAP HANA Replication and Parameters

The parameters starting by fixed_exclusion are not documented in the SAP Note 2036111 and respective attach. They correspond to values we get after installing the system as SAP default and as such we cannot change them. If we try to change such a parameter we get the following message which I think is very clear on the usage of these parameters and the [inifile_checker]/exclusion*

SAP HANA DR, SAP HANA Replication and Parameters

Just for reference follows a screen shot of DR configuration I’ve setup to show this INI replication features:

SAP HANA DR, SAP HANA Replication and Parameters

After doing these configuration we get the parameter [inifile_checker]/replicate=true also in the global.ini file of secondary system as we could see “cating” the global.ini file:

SAP HANA DR, SAP HANA Replication and Parameters

I suggest to change the parameter parallel_data_backup_backint_channels from the default 1 to the value 2 and look that it immediately replicates to the secondary. Print screen of secondary above.

And what’s about the exceptions list? By default the ini parameters related to server names and others that are site specific belong to an exception enumeration we wouldn’t replicate.

Just to illustrate I suggest to change e.g. operation_mode:

SAP HANA DR, SAP HANA Replication and Parameters

Because this is in the exception enumeration it doesn’t replicate in the secondary system. In this case it makes sense to not replicate automatically because to have a such a change we have to follow a specific procedure with different steps to run on primary and others on secondary server before getting this parameter completely activated in the DR configuration.

No comments:

Post a Comment