Per the Oracle technical reference for IMPLIED_SHARE the following steps must be performed any time the IMPLIED_SHARE setting is changed in essbase.cfg:
- Add IMPLIED_SHARE FALSE to essbase.cfg.
- Restart Essbase Server.
- Create a new application and database, with the IMPLIED_SHARE setting in place.
- Rebuild the outline, with the IMPLIED_SHARE setting in place.
- Reload the data.
- Run aggregation or calculation scripts.
- Restart the application.
However, the technical reference does not say what would happen if the above steps are not performed. May be the implied share would not work as expected. However, on one of my recent projects we did not do the above steps and updated essbase.cfg with the implied share setting. We encountered a data loss one on of the Essbase cubes, specifically, data part of a partition area was cleared and some of the data was literally shifted to weird combinations. This event occurred when the Essbase service was restarted. Note that the data loss did not occur every time the Essbase service was restarted.
It took a bit of time to figure out what was going on. I found a document on Oracle support for an issue having the same symptoms i.e. after adding the setting IMPLIED_SHARE TRUE/FALSE value to the Essbase.cfg file and restarting the Essbase service, data is lost or shifted in Essbase. Oracle support referred me to the same document id. The document id on Oracle Support is 1539305.1. Per this document, the cause of the issue is an unpublished Bug 14258058 – IMPLIED_SHARE setting change to Essbase.cfg requires database restructure.
This is a serious issue and would expect that Oracle would add more information to the documentation covering system behavior if the IMPLIED_SHARE settings are done without the required steps.
The Essbase version on which this issue was encountered was Essbase 11.1.2.4.012