Data moving utility commands

The staging server uses the following three utility commands. Each command is described in detail below :

  1. stagingprop
  2. stagingcopy
  3. stagingcheck

The stagingprop command propagates the delta database data from the staging server to the production server. It processes each record in the STAGLOG table. The stagingprop command is the most frequently used staging command. For example, you may use the stagingprop command nightly to propagate the delta from the staging to the production.

The stagingcopy command differs from the stagingprop command in two ways. First, staging prop moves data from the staging server to the production server, while stagingcopy copies from the production server to the staging server. Second, the stagingprop command moves only the data that has changed since the last time stagingprop was run while stagingcopy copies all the data in the database. Stagingcopy is a powerful command that should be used cautiously. There are two cases in which you should use stagingcopy. The first case is when the staging server is setup after the production server database contains data. In this case the stagingcopy command is used to prepare the staging server database with the same data as the production server database. The second case is when the database on the staging server is damaged and must be recreated.

The stagingcheck command checks for unique index conflicts between the tables in the staging database and the production database. A unique index conflict can occur when content data is changed on the production server instead of the staging server. For example, if you create a product on the staging server, then create a different product on the production server, and the two different products have the same product ID. Based on the stagingcheck report, you can fix you data in the staging server manually and then propagate the delta to the production server. This command can be run before stagingprop to find any unique index conflicts, but it will degrade performance. To avoid unique index conflicts, update content data on the staging server only and propagate it to the production server.

Feedback