How to safely activate the currently active config file without causing disaster by way of lost activation (4301401)

At times it is required to activate the same config file. The reasons are numerous. One common reason is to update the object cache on source and consequently on target. Though the preferred approach is to make copy of the currently active config file and activate the copy, there are reasons customers may want to take a shorter approach and want to activate the currently active config file. One reason is, having to activate the config file to push changes to the object cache across very frequently. Another reason is, they do not want to have to deal with frequent change in the name of the config file with multiple activations. Yet another reason is, the list of the config file keeps growing and it is very difficult to view the output of “list config”. This article attempts to find a workaround that may work and in those situations it does not work, it will not result in lost activation, something that requires a database downtime. 

If it is absolutely required to activate the currently active config file, always use the “nolock” option. This ensures that in the event of the activation process not able to lock a source table (in situations where the locking of the source table is needed), the activation will still complete and any table that is required to be locked but could not be locked will only have missed some DML. But it will never result in a situation where no config file is active anymore. Here is the syntax:

sp_ctrl>activate config <active_config_file> nolock