Administer > Stage server > Staging server utilities


stagingcopy utility

Overview

The stagingcopy utility copies data from the production database to the production-ready data on a staging or authoring server.

Run stagingcopy before running stagingprop.

Run stagingcopy from a system that can connect to both the staging or authoring server database and the production server database.

Do not use stagingcopy if RFQs are on the production system.

The stagingcopy utility cannot handle large CLOB objects.

WC_INSTALL/bin/stagingcopy.sh parameters...


Parameter values

-dbtype

  • Specify DB2.

    This is the default database type and you can omit the dbtype parameter from the command.

  • Specify one of the following values:

    DB2/OS400

    Specify DB2/OS400 when using the native i5/OS JDBC driver.

    DB2/OS400ToolBox

    Specify DB2/OS400ToolBox when using the IBM toolbox for Java JDBC driver.

  • Specify Oracle.

-scope

Required: The level of scope for the copy to the staging or authoring server. Specify one of the following levels:

_all_

Copies both records related to the site and to all merchants. Records are copied in the following order:

  1. Site records are copied from STGSITETAB

  2. Site records are copied from STGMRSTTAB

  3. Merchant records are copied from STGMERTAB

  4. Merchant records are copied from STGMRSTTAB

_site_

Copies only site-related records. This is data that is common to all merchants. For example, the language and country or region code used by the system. This data comes from the STGSITETAB table.

_merchant_

Copies only records related to individual merchants. For example, store information is customized for individual merchants, and rows from the store tables could be specific for each merchant. You must copy all data for all merchants, not just data for one individual merchant. This data comes from the STGMERTAB table.

If you do not set the scope to _all_:

  • Copy site data before merchant data, since the site data is used by all merchants. Otherwise, the copy will fail due to a mismatch between the foreign and primary keys.

  • When you use the parameter cleanup_stage_db to clean the site data, merchant data can be deleted because of the cascade delete. You should clean the merchant data followed by the site data then copy the site data followed by the merchant data.

-dbtable

The name of any specific table to be copied. All records in this table are copied, provided the records are within the scope specified by the scope parameter; otherwise, no records are copied.

-sourcedb

Required: The name of the database on the production server.

Review the following information:

  • If -dbtype is DB2/OS400, specify the name of the database on the production server, as displayed in the relational database directory.

  • If -dbtype is DB2/OS400ToolBox, specify the host name of the server on which the production database resides.

For DB2 UDB databases, the Type 4 database name is recommended, where the Type 4 database name is prefixed with the database server and port. For example, db_server:db_port/db_name.

If -script_file is used however, the Type 2 database name must be used, because the generated script file needs the type 2 database name to connect to the database.

See the DB2 Information Center for more information:

-sourcedb_user

Required: The logon ID of the database administrator who has created the source database schema. If not specified, the ID of the user currently invoking the utility is used.

The user profile associated with the commerce instance. This is the same as the source database schema.

-sourcedb_passwd

Required: The password of the logon ID that is specified by sourcedb_user.

-destdb

Required: The name of the database on the staging or authoring server.

Review the following information:

  • If -dbtype is DB2/OS400, specify the name of the database on the staging or authoring server, as displayed in the relational database directory.

  • If -dbtype is DB2/OS400ToolBox, specify the host name of the server on which the staging or authoring database resides.

For DB2 UDB databases, the Type 4 database name is recommended, where the Type 4 database name is prefixed with the database server and port. For example, db_server:db_port/db_name.

If -script_file is used however, the Type 2 database name must be used, because the generated script file needs the type 2 database name to connect to the database.

See the DB2 Information Center for more information:

-destdb_user

Required: The logon ID of the database administrator who has created the staging or authoring database schema. If not specified, the ID of the user invoking the utility is used. This parameter is mandatory when using a remote database.

The user profile associated with the commerce instance. This is the same as the staging or authoring database schema.

-destdb_passwd

Required: The password of the logon ID that is specified by destdb_user.

If not specified, the system prompts you to enter the password. This parameter is mandatory when using a remote database.

-cleanup_stage_db

Specify if the staging tables should be cleaned before copying data or not. If you do not specify this parameter, staging tables are automatically cleaned before copying data. Specify one of the following values:

yes

Cleans the staging tables before copying data. Merchant data can be deleted because of the cascade delete.

no

Do not clean the staging tables before copying data. Nothing is deleted from the staging tables. Your copy might fail if the copy data generates conflict or duplicate key on primary key or unique indexes.

only

Cleans the staging tables but no data is copied from the production database.

If you specify -scope, you should clean and copy the merchant data after you clean and copy the site data.

-script_file

  • The name of the SQL script file generated by the stagingcopy utility when using export and import to copy the production database to the production-ready data on the specified scope. The script file also generates the delete statements to clean the production-ready data if you use the default value or specify -cleanup_stage_db _yes_.

    Before you run the script, verify that you have enough disk space to hold the exported tables. The script file is located in the stagingcopy utility directory where you invoke the stagingcopy utility.

    Also, before running the script, you need to set the correct code page for the DB2 command line session. Otherwise, you might lose data during the character conversion. Since the WebSphere Commerce database uses Unicode character, the DB2 client session also needs to be set with a Unicode code page. This can be done by setting the operating system environment variable "db2codepage".

    You must recycle the DB2 command line session in order to pick up the new environment variable. For example: 

    export db2codepage=1208
db2 terminate 


    set db2codepage=1208
db2 terminate

    Issue the following command to run the script file:

    • db2 -vtd# -f script_file_name

-batchsize

Optional: Turns SQL batch updates on or off and specifies the number of consolidated change log records to include in one SQL batch.

If you do not specify this parameter, the -batchsize parameter is set to a value of 100.

Set the -batchsize parameter to a value of 0 (zero) turns SQL batch update off.

Turn SQL batch off if you are publishing any of the following changes from the production-ready data to the production server:

When SQL batch update is turned on, change log records are sorted by change type (insert, update, or delete). Each batch will only contain changes of one type. For example, if you have 102 insert changes and the -batchsize parameter is set to 100, two SQL batches will be created: one batch will have 100 insert operations and the other will have two insert operations.

Use SQL batch updates improves the speed with which the stagingcopy utility updates the production database.

-log

The path and name of the file in which the stagingcopy utility records its activities and errors. The timestamp is appended to the file name, for example, myLog_yyyy.mm.dd_hh.mm.ss.zzz.log.

If this parameter is not specified, a log file called stagingcopy_yyyy.mm.dd_hh.mm.ss.zzz.log is created in...


See also

  1. The stagingcopy utility and the production database
  2. Examples of copying data to the production-ready database


    +

    Search Tips   |   Advanced Search