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
pasteBinary scripts. After moving the Oracle Home, use the
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.
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
Indicates that the script is exporting Veridata data from the test environment.
Indicates that the script is importing Veridata data to the production environment.
Specifies the administrative WebLogic Server user.
Indicates that the script is exporting the
Verify that any Veridata Agent host, port, and user password specifiers for the production host are updated in the just created
If the Veridata Agent host or port has changed, then you must manually update the generated
export.xmlfile 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:
Open the generated XML file.
Search for the
configurationtag. This tag has the
validationattribute, which is set to
required, by default.
validationattribute 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:
<configuration operation="update" validation="required">
<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
DEV_VERIDATAis the name of the production repository schema.
production_source_schemais the name of the production source schema and
production_target_schemais the name of the production target schema.
test_source_schemais the name of the test source schema and
test_target_schemais 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
production_source_catalogis the name of the production source catalog and
production_target_catalogis the name of the production target catalog.
test_source_catalogis the name of the test source catalog and
test_target _catalogis the name of the test target catalog.
- Task 2 For NSK:
Update the table names in the
COMPARE_PAIRtable to replace the test node names and disk volume names with the production names using one of the following appropriate for your database:
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.xmlXML 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.