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:
-
Open the generated XML file.
-
Search for the
configuration
tag. This tag has thevalidation
attribute, which is set torequired
, by default. -
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 andproduction_target_schema
is the name of the production target schema.Where
test_source_schema
is the name of the test source schema andtest_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 andproduction_target_catalog
is the name of the production target catalog.Where
test_source_catalog
is the name of the test source catalog andtest_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.