How staging server works | DBClean
Performance consideration and practice
The staging utility provides the ability to propagate all changes for the staged data to the production data in one session. But in some cases, customers might have several stores in their production server, if they only want to propagate the changes in a certain store within one propagation session. In a normal scenario of a staging server, it is not working, which results in wasting time and losing concentration. In some extreme situation, if it is necessary to propagate updated staging data to the production server, more staging data always means more performance impact to the production server.
The staging utility in WebSphere Commerce V6.0 introduced a feature called filtering, which provides the infrastructure to achieve the filtered propagation according to business needs. Basically, it does not provide specific logic to filter according to specific business goals, like filter by store, by contract, or by promotion. However, it provides the infrastructure on top of which those goals can be implemented.
In this filtering solution for staging server, performance impact can be reduced by introducing a marking for each change. The marking can be any natural number stored in a new column called STGFILTER in the STAGLOG table. All of the changes related to the same business goal can be assigned the same marking to be recognized by the staging utilities. For example, since the latest propagation process, all of the changes related with store 501 have the same marking in the column STGFILTER.
You can use the following command to propagate all changes with a new parameter named -filter:
stagingprop ... -filter 501 ...The new parameter -filter can tell the stagingprop utility that only the changes with a marking 501 will be propagated in this time.