In earlier versions of Shareplex (5.3 or lower), the norm that has been followed is to use the same product directory (proddir) for various instances of Shareplex (where the instances are synonymous with variable directory or vardir). This was so long as the Shareplex version was same for all the instances. If the versions were different across various Shareplex instances, then this did not apply and separate proddir was to be used for different versions which could still have one to many relationship with the vardirs in question. Though the norms followed in pre 6.0 versions would still work, a better way to do it in Shareplex 6.0 or up is to use a separate proddir for every vardir, in a one to one relationship. This solution delves on the reasons for this recommendation.
General information.
Starting with Shareplex 6.0 and up, there is a material change in the structure of product directory (proddir) and variable directory (vardir). Some of the changes have to do with the fact that the Shareplex installation process now has the flexibility to be installed as root or non-root. Another design change is the encapsulation that is now the norm in Shareplex. During installation and subsequent startup of Shareplex, the environment variables are set at a minimum for SP_SYS_VARDIR, SP_COP_TPORT, SP_COP_UPORT, ORACLE_HOME and ORACLE_SID, among others. If the environment variables for SP_SYS_VARDIR, ORACLE_HOME and ORACLE_SID are not set then Shareplex will refer to the file defaults.yaml during startup and inherit the values for these variables from that file. This file is first created when Shareplex is installed or upgraded and it resides in the <proddir>/data directory.
With this in mind, it is highly recommended that one proddir be used only with one vardir and together they constitute a Shareplex instance. The following points further elaborate advantages of this approach:
1. The upgrade of Shareplex version can be better tuned to affect the desired Shareplex instance. Otherwise it will affect all the Shareplex instances if there was a one to many relationship between proddir and vardir.
2. With the advent of the file defaults.yaml, even if the environment variables are not set for vardir, ORACLE_HOME and ORACLE_SID, then still the correct vardir will be picked by the sp_cop so long as the proddir and vardir combination is unique. Otherwise there can be problems where Shareplex processes may associate with the wrong vardir if the environment was not set and the same proddir catered to multiple vardir.
The disadvantages of this approach are:
1. During first time installation and subsequent upgrade, multiple proddir need to be taken care of, even if all such proddir are at the same version and are going to be upgraded to the same higher version.
2. Since the number of proddir to be installed will go up when using this approach, it can result in more resource requirement in terms of disk space.
At the end of the day it can be said that the advantages far outweigh the disadvantages when configuring a unique proddir and vardir combination.
