Upgrade to/within Istanbul shows properties were skipped in the upgrade history
After upgrading a cloned instance and reviewing skipped records in the upgrade history log, there are skipped updates for properties; the file_name is like:
sys_properties_<sys_id of the property> and the target_name is the property_name.
In the localhost log, a message like this is found:
2017-03-01 15:49:45 (010) worker.2 worker.2 Skipping because of database override: update/sys_properties_a2ed6a0e0a0a0b17005d5159f443a33d.xml
Normally that happens when the property is customized. But in this case, that appears not to be the case; no record is found in sys_update_xml for the property that was skipped.
However, in the upgraded instance, the customer update (sys_customer_update) flag is set to true, even though it is set to false on the instance the upgraded instance was cloned from.
Though this can happen to many other properties, it has been seen to happen with:
When cloning (even when not excluding audit and log data), the data in sys_update_xml gets overwritten with the data on the source. So if the properties were not customized on the clone source, there is no evidence in sys_update_xml that the record was customized on the target (later upgraded) instance.
But specific profiles can also be preserved during cloning. For example, properties starting with glide.db are preserved during cloning by the default Core Instance Properties clone data preserver to ensure their value is not overwritten on the clone target.
When such a preserved property is customized, after cloning, the customer update flag is still true (as will other modifications to it) while there is no customer update record in sys_update_xml. Especially in Istanbul releases, when sys_customer_update is true, that is sufficient for the upgrade to skip the record. It is planned for later releases to combine that with the requirement to have a corresponding record in sys_update_xml (as it was in releases prior to Istanbul).
In most cases, no further action is required. On the clone source (usually production), these properties are not skipped during upgrade if they are not customized. The original value should be retained on the clone target, so no further action is required there either. If there is a requirement to not skip the properties in question during upgrade, either ensure they are reverted to base release version or mark the replace on upgrade flag (sys_replace_on_upgrade) before the upgrade.