3 Configuring Manager and Network Communications

This chapter describes how to configure the Manager process and specify ports for local and remote network communications.

This chapter includes the following sections:

3.1 Overview of the Manager Process

To configure and run Oracle GoldenGate, a Manager process must be running on all Oracle GoldenGate source and target systems, and any intermediary systems if used in your configuration. Manager is the controller process that instantiates the Oracle GoldenGate processes, allocates port numbers, and performs file maintenance. Together, the Manager process and its child processes, and their related programs and files comprise an Oracle GoldenGate instance. The Manager process performs the following functions:

  • Start Oracle GoldenGate processes

  • Start dynamic processes

  • Start the Collector process

  • Manage the port numbers for processes. (All Oracle GoldenGate ports are configurable.)

  • Perform trail management

  • Create event, error, and threshold reports

There is one Manager per Oracle GoldenGate installation. One Manager can support multiple Oracle GoldenGate extraction and replication processes.

3.2 Assigning Manager a Port for Local Communication

The Manager process in each Oracle GoldenGate installation requires a dedicated port for communication between itself and other local Oracle GoldenGate processes. To specify this port, use the PORT parameter in the Manager parameter file. Follow these guidelines:

  • The default port number for Manager is 7809. You must specify either the default port number (recommended, if available) or a different one of your choice.

  • The port must be unreserved and unrestricted.

  • Each Manager instance on a system must use a different port number.

See Reference for Oracle GoldenGate for Windows and UNIX for more information about PORT.

3.3 Maintaining Ports for Remote Connections through Firewalls

If a firewall is being used at an Oracle GoldenGate target location, additional ports are required on the target system to receive dynamic TCP/IP communications from remote Oracle GoldenGate processes. These ports are:

  • One port for each Collector process that is started by the local Manager to receive propagated transaction data from remote online Extract processes. When an Extract process sends data to a target, the Manager on the target starts a dedicated Collector process.

  • One port for each Replicat process that is started by the local Manager as part of a remote task. A remote task is used for initial loads and is specified with the RMTTASK parameter. This port is used to receive incoming requests from the remote Extract process. See Reference for Oracle GoldenGate for Windows and UNIX for more information about RMTTASK.

  • Some extra ports in case they are needed for expansion of the local Oracle GoldenGate configuration.

  • Ports for the other Oracle GoldenGate products if they interact with the local Oracle GoldenGate instance, as stated in the documentation of those products.

To specify these ports, use the DYNAMICPORTLIST parameter in the Manager parameter file. Follow these guidelines:

  • You can specify up to 5000 ports in any combination of the following formats:

    7830, 7833, 7835
    7830-7835
    7830-7835, 7839
    
  • The ports must be unreserved and unrestricted.

  • Each Manager instance on a system must use a different port list.

Although not a required parameter, DYNAMICPORTLIST is strongly recommended for best performance. The Collector process is responsible for finding and binding to an available port, and having a known list of qualified ports speeds this process. In the absence of DYNAMICPORTLIST (or if not enough ports are specified with it), Collector tries to use port 7840 for remote requests. If 7840 is not available, Collector increments by one until it finds an available port. This can delay the acceptance of the remote request. If Collector runs out of ports in the DYNAMICPORTLIST list, the following occurs:

  • Manager reports an error in its process report and in the Oracle GoldenGate ggserr log.

  • Collector retries based on the rules in the Oracle GoldenGate tcperrs file. For more information about the tcperrs file, see Section 15.5, "Handling TCP/IP Errors".

See Reference for Oracle GoldenGate for Windows and UNIX for more information about DYNAMICPORTLIST.

3.4 Choosing an Internet Protocol

By default, Oracle GoldenGate selects a socket in the following order of priority to ensure the best chance of connection success:

  • IPv6 dual-stack

  • IPv4 if IPv6 dual-stack is not available

  • IPv6

If your network has IPv6 network devices that do not support dual-stack mode, you can use the USEIPV6 parameter to force Oracle GoldenGate to use IPv6 for all connections. This is a GLOBALS parameter that applies to all processes of an Oracle GoldenGate instance. When USEIPV6 is used, the entire network must be IPv6 compatible to avoid connection failures. See Reference for Oracle GoldenGate for Windows and UNIX for more information.

3.5 Recommended Manager Parameters

The following parameters are optional, but recommended, for the Manager process.

  • AUTOSTART: Starts Extract and Replicat processes when Manager starts. This parameter is required in a cluster configuration, and is useful when Oracle GoldenGate activities must begin immediately at system startup. (Requires Manager to be part of the startup routine.) You can use multiple AUTOSTART statements in the same parameter file. See Reference for Oracle GoldenGate for Windows and UNIX for more information.

  • AUTORESTART: Starts Extract and Replicat processes again after abnormal termination. This parameter is required in a cluster configuration, but is also useful in any configuration to ensure continued processing. See Reference for Oracle GoldenGate for Windows and UNIX for more information.

  • PURGEOLDEXTRACTS: Purges trail files when Oracle GoldenGate is finished processing them. Without PURGEOLDEXTRACTS, no purging is performed and trail files can consume significant disk space. For best results, use PURGEOLDEXTRACTS as a Manager parameter, not as an Extract or Replicat parameter. See Reference for Oracle GoldenGate for Windows and UNIX for more information.

  • STARTUPVALIDATIONDELAY | STARTUPVALIDATIONDELAYCSECS: Sets a delay time after which Manager validates the run status of a process. Startup validation makes Oracle GoldenGate users aware of processes that fail before they can generate an error message or process report. See Reference for Oracle GoldenGate for Windows and UNIX for more information.

3.6 Creating the Manager Parameter File

To configure Manager with required port information and optional parameters, create a parameter file by following these steps. See "Getting Started with the Oracle GoldenGate Process Interfaces" for more information about Oracle GoldenGate parameter files.

Note:

If Oracle GoldenGate resides in a cluster, configure the Manager process within the cluster application as directed by the vendor's documentation, so that Oracle GoldenGate fails over properly with other applications.For more information about installing Oracle GoldenGate in a cluster, see the Oracle GoldenGate documentation for your database.
  1. From the Oracle GoldenGate directory, run the GGSCI program to open the Oracle GoldenGate Software Command Interface (GGSCI).

  2. In GGSCI, issue the following command to edit the Manager parameter file.

    EDIT PARAMS MGR
    
  3. Add the parameters that you want to use for the Manager process, each on one line.

  4. Save, then close the file.

The following is a sample Manager parameter file on a UNIX system using required and recommended parameters.

Example 3-1 Sample manager file on a UNIX system

PORT 7809
DYNAMICPORTLIST 7810-7820, 7830
AUTOSTART ER t*
AUTORESTART ER t*, RETRIES 4, WAITMINUTES 4
STARTUPVALIDATIONDELAY 5
USERIDALIAS mgr1
PURGEOLDEXTRACTS /ogg/dirdat/tt*, USECHECKPOINTS, MINKEEPHOURS 2

3.7 Starting Manager

Manager must be running before you start other Oracle GoldenGate processes. You can start Manager from:

  • The command line of the operating system. See "Starting Manager from the Command Shell of the Operating System" for instructions.

  • The GGSCI command interface. See "Starting Manager from GGSCI" for instructions.

  • The Services applet on a Windows system if Manager is installed as a service. See the Windows documentation or your system administrator.

  • The Cluster Administrator tool if the system is part of a Windows cluster. This is the recommended way to bring the Manager resource online. See the cluster documentation or your system administrator.

  • The cluster software of a UNIX or Linux cluster. Refer to the documentation provided by the cluster vendor to determine whether to start Manager from the cluster or by using GGSCI or the command line of the operating system.

3.7.1 Starting Manager from the Command Shell of the Operating System

To start Manager from the command shell of the operating system, issue the following command.

mgr paramfile parameter_file [reportfile report_file]

The reportfile argument is optional and can be used to store the Manager process report in a location other than the default of the dirrpt directory in the Oracle GoldenGate installation location.

3.7.2 Starting Manager from GGSCI

To start Manager from GGSCI, run GGSCI from the Oracle GoldenGate directory, and then issue the following command.

START MANAGER

Note:

When starting Manager from the command line or GGSCI on Windows Server 2008 with User Account Control enabled, you will receive a UAC prompt requesting you to allow or deny the program to run.

3.8 Stopping Manager

Manager runs indefinitely or until stopped by a user. In general, Manager should remain running when there are synchronization activities being performed. Manager performs important monitoring and maintenance functions, and processes cannot be started unless Manager is running.

3.8.1 Stopping Manager on UNIX and Linux

On UNIX and Linux (including USS on z/OS), Manager must be stopped by using the STOP MANAGER command in GGSCI.

STOP MANAGER [!]

Where:

! stops Manager without user confirmation.

In a UNIX or Linux cluster, refer to the documentation provided by the cluster vendor to determine whether Manager should be stopped from the cluster or by using GGSCI.

3.8.2 Stopping Manager on Windows

On Windows, you can stop Manager from the Services applet (if Manager is installed as a service). See the Windows documentation or your system administrator.

If Manager is not installed as a service, you can stop it with the STOP MANAGER command in GGSCI.

STOP MANAGER [!]

In a Windows cluster, you must take the Manager resource offline from the Cluster Administrator. If you attempt to stop Manager from the GGSCI interface, the cluster monitor interprets it as a resource failure and attempts to bring the resource online again. Multiple start requests through GGSCI eventually will exceed the start threshold of the Manager cluster resource, and the cluster monitor will mark the Manager resource as failed.