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: 
antonio_nunes1
Participant
Before Hana (1) 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.

   Reference doc (Very good one): https://archive.sap.com/documents/docs/DOC-47702

   Note: After installing SPS12 the parameter [inifile_checker]/enable = true

 



 

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*



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



After setting up  these the parameter [inifile_checker]/replicate=true in the primary system we algo get it in the global.ini file of secundary because it is replicares as we could see “cating” the global.ini file:



 

I suggest to change the parameter parallel_data_backup_backint_channels from the default 1 to the value 2 and look that it also 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:



 

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.

 

Open question to the community: Could you please propose other parameters to enter in the exception list? Others than the default? Other than global_allocation_limit ?

 

Hope you enjoy this blog and waiting for your contributions

Thanks

A.Nunes
Labels in this area