Moving from a Test to Production Environment

A Moving from a Test to Production Environment

This appendix describes the scripts that we provide for you to migrate your test system to the production environment and includes the following sections:

A.1 Moving Installations from a Source Environment to a Target Environment

Oracle Fusion Middleware provides various scripts that you use to move your environment.

To move Oracle Home that contains all binary files of your Veridata installation, use the copyBinary and pasteBinary scripts. After moving the Oracle Home, use the copyConfig and pasteConfig scripts to move a copy of the Veridata domain configuration including the Administration Server, Managed Server, and other components in the domain to the target environment.

Note:

Test to production migration is not supported for a compact domain or for repository databases other than Oracle and SQL Server.

A.2 Additional Steps for Moving Oracle GoldenGate Veridata Repository

In addition to the common procedures described in the guide , follow the instructions below for moving the Oracle GoldenGate Veridata repository to a target environment:

A.2.1 Moving Veridata Configuration Data from Test to Production

To export and import Veridata repository configuration data, use the scripts available in the DOMAIN_HOME/veridata/bin directory use the following steps:

To export the repository from the test environment, run the export script as follows:

DOMAIN_HOME/veridata/bin/veridata_export.sh  -export /tmp/export.xml -all -wluser cmd_user -exportPassword

Table A-1 describes the arguments you specify while running the export and import scripts.

Table A-1 Arguments for the Veridata Test to Production Scripts

Argument	Description
`export`	Indicates that the script is exporting Veridata data from the test environment.
`import`	Indicates that the script is importing Veridata data to the production environment.
`wluser` `cmd_user`	Specifies the administrative WebLogic Server user.
`exportPassword`	Indicates that the script is exporting the `cmd_user` password.

Verify that any Veridata Agent host, port, and user password specifiers for the production host are updated in the just created /tmp/export.xml file.
If the Veridata Agent host or port has changed, then you must manually update the generated export.xml file with the new host and port informations for the Connections.
The export operation exports all of the data in the repository to XML file without validation. If your environment has some compare pairs for which the Validation Status is not successful, then the import operation will fail with the XML file generated by the export operation. To prevent failure of the import operation, you have the option to disable the compare pair validation. You can do this by updating the generated XML with these steps:
1. Open the generated XML file.
2. Search for the configuration tag. This tag has the validation attribute, which is set to required, by default.
3. Set the validation attribute to one of the following values:
  
  omit-failures — Indicates that all successfully validated compare pairs will be added to the repository and other specified compare pairs will be ignored.
  
  none — Indicates that no compare pair validation is done before adding the compare pairs to the repository. You and then use the Veridata GUI to review and fix the validation problems. For example:
  
  Old tag: <configuration operation="update" validation="required">
  
  Updated tag: <configuration operation="update" validation="omit-failures">

To import the repository to the production environment, run the import script as follows:

DOMAIN_HOME/veridata/bin/veridata_import.sh -update  /tmp/export.xml -wluser  cmd_user

A.2.2 Applying Configuration Changes while Moving from Test to Production

While moving from a test to production environment, if there are any configuration changes for the Veridata Agent such as host and port changes or if there is any schema or catalog name changes in the compare pairs, you must first execute the following statements:

Task 1 For all databases

Update DEV_VERIDATA.TABLE_INFO set  SRC_SCHEMA_NAME = production_source_schema Where    SRC_SCHEMA_NAME  = test_source_schema
 Update TABLE_INFO set  TARG_SCHEMA_NAME = production_target_schema Where    TARG_SCHEMA_NAME  = test_target_schema

Where DEV_VERIDATA is the name of the production repository schema.

Where production_source_schema is the name of the production source schema and production_target_schema is the name of the production target schema.

Where test_source_schema is the name of the test source schema and test_target_schema is the name of the test target schema.

Task 2 Appropriate to your database

Task 1 For SQL Server and Sybase databases:

Update TABLE_INFO set  SRC_CATALOG_NAME = production_source_catalog Where    SRC_CATALOG_NAME  = test_source_catalog

Update TABLE_INFO set  TARG_CATALOG_NAME = production_target_catalog Where    TARG_CATALOG_NAME  = test_target_catalog

Where production_source_catalog is the name of the production source catalog and production_target_catalog is the name of the production target catalog.

Where test_source_catalog is the name of the test source catalog and test_target _catalog is the name of the test target catalog.

Task 2 For NSK:

Update the table names in the COMPARE_PAIR table to replace the test node names and disk volume names with the production names using one of the following appropriate for your database:

For Oracle:

Update COMPARE_PAIRS SET  SRC_TABLE_NAME = '\SPROD.$PDATA' ||    SUBSTR(SRC_TABLE_NAME, 12) Where SRC_TABLE_NAME like '\STEST.TDATA%'
Update COMPARE_PAIRS SET  TARG_TABLE_NAME = '\TPROD.$PDATA' ||
    SUBSTR(TARG_TABLE_NAME, 12) Where TARG_TABLE_NAME like '\TTEST.TDATA%'

For SQL Server:

Update COMPARE_PAIRS SET  SRC_TABLE_NAME = '\SPROD.$PDATA' +    SUBSTRING(SRC_TABLE_NAME, 12, LEN(SRC_TABLE_NAME) -  12) Where SRC_TABLE_
    NAME like '\STEST.TDATA%'
Update COMPARE_PAIRS SET  TARG_TABLE_NAME = '\TPROD.$PDATA' +    SUBSTRING(TARG_TABLE_NAME, 12, LEN(TARG_TABLE_NAME) -12) Where TARG_TABLE_
    NAME like '\TTEST.TDATA%'

A.2.3 Modifying the Agent details in the Production Environment

Update the Veridata Agent details in the CONNECTIONS table of the production environment host as described below:

If only the Agent host name needs to be changed, update the database as follows:
```
Update CONNECTIONS set MGR_NAME = 'prod host' where MGR_NAME 'test host'
```

If there are more changes to the Veridata Agent, such as changes to the port number, User ID, password, and Repair User ID, then you should start the Veridata application and update the environment using the UI or command-line tool.

For example, create an /tmp/con.xml XML file as follows:

#Create xml as below by filling placeholders between @ and connections can be more than one.
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE configuration SYSTEM
    "http://@VeridataServerHost@:@veridataServerPort@/veridata/configuration.dtd">
    <configuration validation="required">
    <connection name="@conneciotnName@" host="@sqlManagerHostSrc@" 
        port="@sqlManagerPortSrc@" user="@sqlConn0User@"
        password="@sqlConn0Password@" repairUser="@repairUsername@"
        repairPassword="@repairPassword@" agent-timeout="4000" 
        truncate-spaces="false" fetch-size="3" use-ssl="false">
           <description>
            <![CDATA[
                SQL Scripting Source Connection
            ]]>
            </description>
   </connection>
   </configuration>

Update the Veridata Agent with your XML file using:

DOMAIN_HOME/veridata/bin/veridata_import.sh -update /tmp/con.xml -wlUser cmd_user

Start the Veridata Agent after making these changes.