There are numerous parameters in SharePlex which are set to get past a problem or error condition. Usually they are unset by users once the issue is bypassed. At times they are left inadvertently turned on. The article discusses the implications of not resetting them back to their default value.
Here are some of the common pitfall of leaving the parameters turned on long after resolving the issue:
You may run into undesirable effects when running SharePlex with such parameters turned on once their utility has run its course. For example, you may have wanted to ignore DDL errors at some point and set the parameter SP_OPO_STOP_ON_DDL_ERR to 0 to achieve that. Subsequently, if you leave it turned on, you will end up having SharePlex Post process ignore all DDL errors. This is undesirable as you would want to address the root cause that resulted in this DDL error.
If the parameter change is not required anymore and is still left turned on, unnecessary checking is done by SharePlex program periodically which can be extra work for SharePlex though not a big performance drag.
The paramdb file which contains the changed parameters and the output of “list param modified” will have a cluttered look. These two are the places where the changed parameters will show up. The cluttered looks will distract the users from concentrating on other problems and parameter settings. So to tidy up the things it is best to undo the changes once they are not required anymore. Here is an example of a parameter setting that has been left turned on long after the purpose has been served:
sp_ctrl>list param modified post
Post parameters:
Parameter Name Actual Value Units Set At
------------------------------ ------------------------------------ ------- ---------------
SP_OPO_CONT_ON_ERR 1 Live
Default Value: 0
SP_OPO_DISABLE_OBJECT_NUM 618553,617905,612873 Live
Default Value:
SP_OPO_STOP_ON_DDL_ERR 0 Live
Default Value: 1
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center