Oracle® GoldenGate Veridata Administrator's Guide 11g Release 2 (11.2.1.0.0) Part Number E29092-01 |
|
|
PDF · Mobi · ePub |
This chapter describes how to upgrade to a new release of the Oracle GoldenGate Veridata Server and Web User Interface components.
This chapter includes the following sections:
You must upgrade all components of Oracle GoldenGate Veridata. The use of different releases of the server and agent components is not supported.
The upgrade procedure varies depending on your current version:
Upgrades from version 1 to later versions: There is no upgrade path from version 1 to version 2 and later versions. You must recreate your configuration objects in the new release. You can install the new release, and then run the old and new releases side-by-side, so that you can refer to the existing configurations as you recreate them in the new installation.
Upgrades from version 2 and later versions using a new repository: To change the database repository (to move from one instance of Oracle to another, for example, or to move from MySQL to SQL Server), follow the instructions in this manual to install the server and web components as a new installation. Oracle GoldenGate Veridata objects will be installed into the database that you specify during the installation, including the same tables for the user data that exist in the original repository. After the installation, you can use any migration tool to move the existing data from the old repository into the one.
Upgrades from version 2 and later versions using the existing repository: Use the following procedure, Section 12.1.2, "Server and Web Upgrade Instructions for All Platforms". When installing a new version of Oracle GoldenGate Veridata Server and Oracle GoldenGate Veridata Web into an existing directory, the Oracle GoldenGate Veridata installer detects the existing installation and prompts you to upgrade or quit. The upgrade path retains the current Oracle GoldenGate Veridata database repository, without an option to drop any objects. Users can log on after the upgrade and continue to work with their existing environment.
Note:
An attempt to upgrade to 11.2.1 fails if your version 3 Oracle GoldenGate Veridata was not upgraded to release 3.0.0.11 and your Tomcat version is earlier than 5.5.35. The error explains that the Catalina release (one of those earlier than 5.5.35) cannot be upgraded, so you must install to a new location.
Start the Oracle GoldenGate Veridata repository database.
Stop all running comparisons or wait until they are finished.
Close all Oracle GoldenGate Veridata Web client sessions.
Shut down Oracle GoldenGate Veridata Server and Oracle GoldenGate Veridata Web User Interface. (For more information, see Section 9.2, "Starting and Stopping the Java-Based Components".)
Run the Oracle GoldenGate Veridata installer:
UNIX and Linux: Run the GoldenGate_Veridata_
platformrelease
.sh
file from X-windows or an X-windows emulation program.
Windows: Run the GoldenGate_Veridata_
platformrelease
.exe
file.
The following steps are the same on Windows, UNIX, and Linux. These instructions show the Windows version. Some prompts appear only in the Windows version.
Welcome: Click Next to start the installation.
Select Destination Directory: Select the Oracle GoldenGate Veridata installation that you want to upgrade.
Click Upgrade to upgrade the existing installation (and preserve the repository). If you do not want to upgrade this installation or preserve the repository, click Quit.
Veridata Repository: The installer displays the encrypted version of the last known password for the repository owner. Either accept the default or type the correct one.
(Windows only) Windows Services User: If LocalSystem
is the user that starts the existing Oracle GoldenGate Veridata, this window will be enabled. It gives you the option to identify a new login to start the service or continue as LocalSystem
. If you specify a different user, that user must be granted LogonAsService
privilege or the service will not start.
Start after Install: Specify whether or not to start the software after the installation is finished. By default, it is installed to start manually. If you are installing it as a service, a system administrator can change the properties so that it starts automatically when the system starts.
Information: Review your selections and either click Cancel to start over or Next to start the upgrade.
To view the Oracle GoldenGate Veridata help system after the installation, accept the default and click Finish.
In making a decision to use a Java agent versus a C-agent be aware that:
As of Oracle GoldenGate Veridata release 3.0, you can use a Java agent for Oracle, SQL Server, DB2 LUW or z/OS, and Teradata. As of release 11.2.1, you can use a Java agent for Sybase ASE.
An 11.2.1 release of the C-agent. is available for NonStop SQL/MP.
The release 3.0 C-agent can be used for the Oracle database for Oracle GoldenGate Veridata release 11.2.1.
The instructions provided are for upgrading a C-agent from Veridata 2.x or later or a Java agent from 3.x or later to a newer release. They assume that:
You are upgrading the same agent on the same machine.
You are keeping the existing file path names of the installation.
If upgrading on a Windows system, you are keeping the existing Manager service name, if one exists.
The instructions for upgrading a Java agent depend on whether you are using a Windows or a UNIX/Linux platform.
Note:
New versions of the Java agent use different JDBC drivers, so you will need to follow the Window's step 6 or UNIX step 3 to verify the JDBC driver versions before starting the new agent.
Upgrading a Java Agent on a Windows Platform
To upgrade a Java agent on a Windows platform, double-click the GoldenGate_Veridata_
platformrelease
program and then follow the steps explained in this section.
Welcome: Click Next to start the upgrade.
Select Destination Directory: Select the Oracle GoldenGate Veridata installation that you want to upgrade.
Click Upgrade to upgrade the existing installation (and preserve the repository). If you do not want to upgrade this installation or preserve the repository, click Quit. If you click Upgrade and there is an existing agent running, you will be asked whether the agent should be stopped. Click OK to stop the agent.
Start after install: You need to confirm that the driver is correct before the agent is started, so you should not automatically start the agent after the installation is finished.
After the installation, click Finish.
Make certain that the value of the server.jdbcDriver
property in the agent.properties
file matches the agent.properties.sample
file suggested value for the new agent. For example, connections to Oracle databases now require odbc6.jar
instead of ojdbc5.jar
, so the property in the agent.properties
file should be server.jdbcDriver=ojdbc6.jar.
Start the new Java agent as explained in Section 9.2, "Starting and Stopping the Java-Based Components."
Upgrading a Java Agent on a UNIX or Linux Platform
Follow these steps to upgrade a Java agent on a UNIX or Linux Platform:
Stop the existing Java agent.
shell> agent.sh stop
Extract the Oracle GoldenGate Veridata media pack upgrade zip file to the installation directory. This will put the agent in place.
Make certain that the value of the server.jdbcDriver
property in the agent.properties
file matches the agent.properties.sample
file suggested value for the new agent. For example, connections to Oracle databases now require odbc6.jar
instead of ojdbc5.jar
, so the property in the agent.properties
file should be server.jdbcDriver=ojdbc6.jar.
Start the new Java agent as explained in Section 9.2, "Starting and Stopping the Java-Based Components."
There is no direct upgrade path from the C-agent to the Java-based agent. To use a Java agent:
Follow the instructions in Chapter 3, "Installing Oracle GoldenGate Veridata Java Agent."
You can specify the same port that was used by the existing agent Manager. If you use a different port number, make certain to notify the users of Oracle GoldenGate Veridata Web, so that they can update their connection configurations. If you use the same port, Oracle GoldenGate Veridata must be restarted so that there is no cached information from the C-agent.
To upgrade a C-agent on Windows, UNIX and Linux
Wait for all jobs that use this agent to finish running.
From the agent installation location, run GGSCI. The default location is GoldenGate_Veridata/agent
.
In GGSCI, issue the following command to stop the Manager process.
STOP MANAGER
Shutting down the Manager process prevents new agent processes from being started by the server component, if it is still running.
Extract the new Oracle GoldenGate Veridata Agent files to the same directory where the current agent is installed. The default relative path that is extracted is veridata/agent
. You might need to change the extraction path if your naming conventions are different. Overwrite the existing files in the agent
directory with the extracted files.
Run GGSCI from the agent directory.
In GGSCI, issue the following command to start the Manager process.
START MANAGER
In GGSCI, issue the following command to verify that the installation succeeded. The command should return "Manager is running."
INFO MANAGER
(Windows) In the Services control panel, verify that the correct service for this agent started.
To upgrade a C-agent on NonStop
Wait for all user jobs that use this agent to finish running.
From the agent installation location, run GGSCI. The default location is GoldenGate_Veridata/agent
.
In GGSCI, issue the following command to stop the Manager process.
STOP MANAGER
Shutting down the Manager process prevents new agent processes from being started by the server component, if it is still running.
Transfer the new Oracle GoldenGate Veridata Agent files in binary mode to the volume and subvolume on the NonStop Server where you want to upgrade the agent.
Alter the VERUNPAK
macro to be an edit file by issuing the following TACL command.
FUP ALTER VERUNPAK, CODE 101
Run the VERUNPAK
macro by issuing the following TACL command.
RUN VERUNPAK
At the prompt, verify the location of the agent that you want to upgrade. Type Y
to confirm the location shown or N
to select another location.
Installing GoldenGate at $DATA.GoldenGate Veridata Is this correct? (Y/N) y UNPAK - File decompression program - T1255G06 - (2002-05-06) Archive version: 1 File Mode RESTORE Program - T9074G07 (15JAN2002) Copyright Tandem Computers Incorporated 1981-2002 Summary Information Files restored = 7 Files not restored = 0 GoldenGate Veridata for Nonstop Installation Installs the GoldenGate Veridata Product Enter X at any prompt to quit.
You are prompted for a SQL catalog for the agent to use. Type the catalog name or type X
for no catalog.
SQL Catalog for Compilation (X for no catalog)? $data.cpscat SQL compiling VERIAGT GoldenGate Veridata Installation Complete.
Run GGSCI from the agent directory.
In GGSCI, issue the following command to start the Manager process.
START MANAGER
In GGSCI, issue the following command to verify that the installation succeeded. The command should return "Manager is running."
INFO MANAGER
If tables have remote partitions, copy VSNSERV
to the remote nodes.
If your tables have partitions on remote nodes, you will need to place a copy of the VSNSERV
module on each of those nodes.
If all of the remote nodes are the same hardware type, you can use a copy of the VSNSERV
that is in the Oracle GoldenGate Veridata agent subvolume. Otherwise, you might need to download the correct agent build for that hardware type. It will include the correct VSNSERV
.
To place the VSNSERV
on each node, you can do either of the following:
Install the entire Oracle GoldenGate Veridata Agent package on each of the remote nodes, even though the agent itself will not be running on them.
Copy the VSNSERV
object to each of the remote nodes. To use this option, take the following steps.
To copy VSNSERV to remote nodes
Copy the appropriate VSNSERV
program to each of the remote nodes.
Log onto each remote node as a super user.
Issue the following commands on each remote node:
FUP GIVE vsnserv, SUPER.SUPER FUP SECURE vsnserv, "NNNN", PROGID
The first command sets the VSNSERV
owner as SUPER.SUPER
.
The second command sets security and PROGID
to run as SUPER.SUPER
.
This upgrade procedure assumes that the location of VSNSERV
on each remote node did not change from the original installation. If the location did change, you must change the HOST
parameter(s) in the GLOBALS
file. See Section 4.4.3, "Creating a GLOBALS File".