Two Oracle GoldenGate components facilitate day-to-day data management: the Manager and the Collector. This chapter introduces procedures and techniques for running both components.
This chapter includes the following sections:
Manager runs as a NonStop process, ensuring that Oracle GoldenGate for NonStop components run and restart if a CPU failure or operator error occurs. Manager spawns a copy of itself so that tasks that take longer, such as duplicating a TMF audit trail, do not interfere with real-time tasks. Tasks are divided between the Manager and its child process accordingly. Manager tasks on NonStop include:
Starting Logger, Extract, Replicat and Syncfile
Monitoring and reporting status of Oracle GoldenGate processing
Starting the dynamic Collector process on the target
Automatically restarting critical processes
Threshold reporting, such as when Extract falls behind the TMF-audit trail
Managing resources for the TMF audit trail, such as maintaining copies of audit trails on backup volumes
Purging trails when Extract and Replicat has finished with them
Pre-allocating log trail space for Logger processing
Now that you have your GGSCI prompt, you are ready to configure and start Manager. To configure Manager, create an appropriate parameter file. To control an Oracle GoldenGate Manager process, use the following commands.
Command | Description |
---|---|
START MANAGER |
Starts Manager. |
STOP MANAGER |
Stops Manager. You can stop Manager gracefully, or forcefully with the |
Enter Manager parameters in the MGRPARM
file. If no MGRPARM
file exists, default management parameters are taken. To add parameters, edit this file using the EDIT PARAMS MGRPARM
command.
Manager retrieves parameters as established by GGSCI ATCONFIG
commands. These parameters affect audit trail resource management.
See Reference for Oracle GoldenGate on HP NonStop Guardian for more information about Manager parameters.
A Manager parameter file would be similar to this sample.
Example 6-1 Sample Manager Parameter File
TCPIPPROCESSNAME $ZTC2 PORT 7844 DYNAMICPORTLIST 7850 - 7880, 7895 CHECKMINUTES 30 PURGEOLDEXTRACTS $DATA1.GGSDAT.*, USECHECKPOINTS, MINKEEPDAYS 2 THRESHOLD 30 LAGREPORTMINUTES 60 LAGINFOMINUTES 10 LAGCRITICALMINUTES 10 LOGFILESBEHIND 2 LOGFILESBEHINDINFO 10 DOWNCRITICAL DOWNREPORTHOURS 1
In this sample Manager parameter file
TCPIPPROCESSNAME
specifies the TCP/IP process. The default process is $ZTC0. Use the TCPIPPROCESSNAME
parameter to specify a process other than the default.
Specify the PORT
parameter so Manager can create a dynamic Collector process.
DYNAMICPORTLIST
specifies up to 256 entries for ports to be dynamically assigned to processes started by Manager. If no dynamic ports are specified, Manager will start with 7840 and increment until it finds an available port.
CHECKMINUTES 30
directs Manager to perform maintenance activities every 30 minutes. The default is 10 minutes.
Use the PURGEOLDEXTRACTS
parameter when multiple Replicat processes are reading a set of trails. For this sample, PURGEOLDEXTRACTS
directs manager to purge old files from the trail $DATA1.GGSDAT.*
. The options:
USECHECKPOINTS
specifies that Replicat checkpoints are to be used to determine when Replicat has finished processing.
MINKEEPDAYS 2
purges files only after they have been closed for 2 days.
THRESHOLD 30
directs Manager to generate an event message when the number of audit files remaining to be processed falls below 30%.
LAGREPORTMINUTES 60
specifies that Manager check lag every 60 minutes.
LAGINFOMINUTES 10
specifies that Manager report lag information to the event log every 10 minutes.
LAGCRITICALMINUTES 10
specifies that Manager write a critical message to the event log when there is 10 minute lag.
LOGFILESBEHIND 2
sends a critical message whenever a process lags a specified number of files behind the current log trail file.
LOGFILESBEHINDINFO 10
sends an informational message whenever the process falls the specified number of files behind.
DOWNCRITICAL
sends a critical message whenever Extract or Replicat abends.
DOWNREPORTHOURS
sends reports of Extract and Replicat abending.
You must start Manager before you can configure and run other Oracle GoldenGate components. The following example starts Manager in CPU 3
. Manager selects a CPU in which to run a backup process for fault-tolerance.
GGSCI> START Manager, CPU 3, PRI 170
If Manager encounters a TCP/IP error, for example if it attempts to bind to a port that is in use, it retries the error every 60 seconds and does not abend after a set number of attempts. Unlike other Oracle GoldenGate processes, it does not use the TCPERRS
file to set the delay and the number of retries.
Manager runs indefinitely, or until you enter the GGSCI STOP MANAGER
command. You might stop Manager if you need to stop the Extract and Replicat groups it manages or if you to want to activate a change to a Manager parameter.
See Reference for Oracle GoldenGate on HP NonStop Guardian for more information about GGSCI commands for Manager.
The Collector collects data from Extract and writes data to files on the target system. Extract requests Manager to start a collector process when it sees data must transmit over TCP/IP to a remote trail. Once started, the Collector waits for and performs requests to write, open, and close files in the Oracle GoldenGate trail during Extract processing.
Note:
You do not need to run collector if data transmits over an Expand connection.
To configure a Collector, you must know the port the Collector will use, the host name or IP address where the remote trail resides, and edit your Manager and Extract parameter files. You may also specify a variety of operating options, described in the "Configuration Examples".
To configure and start Collector:
In the Manager parameter file, specify the port parameter, such as: PORT
7809
.
In the Extract parameter file, specify the RMTHOST
parameter as follows:
RMTHOST host, [MGRPORT port_number] [, option] [, . . .]
Argument | Description |
---|---|
host
|
Either a remote system name or an IP address, such as: |
MGRPORT port_number
|
Specify the port that is defined in the Manager parameter file. |
options
|
You can specify a variety of options, including Collector parameters. See "Creating and Configuring the Manager Parameter File" for information on these options. See Reference for Oracle GoldenGate on HP NonStop Guardian for information about other |
The remote system must be the same system on which Collector was started, and the port number must match the port number in the Collector startup command. See "Configuration Examples" for more information.
If you specify a remote system name in the RMTHOST
parameter, you must also enter the remote system name in the TCP/IP hosts file on the target system, or on the names server for your network. For example, if you specify: RMTHOST eastnode
, you must make an entry similar to: 192.0.2.20 eastnode
in the HOSTS
file.
If you specify the remote system IP address in the RMTHOST
parameter, there is no need to make a corresponding HOSTS
file entry.
Following are the examples for configuration:
To configure Collector for port 5432
on remote system named eastnode
:
In the Manager parameter file, specify: PORT
5432
In the Extract parameter file, specify: RMTHOST eastnode, MGRPORT 5432,
and options if desired.
In the TCP/IP HOSTS
file, enter: 192.0.2.20 eastnode
To configure Collector for the default port on remote system address 192.0.2.20
:
In the Manager parameter file, specify: PORT 7809
In the Extract parameter file, specify: RMTHOST 192.0.2.20,
and options if desired.
No TCP/IP hosts file entry is required.
There are two ways to use Collector and your TCP/IP port: dynamically and explicitly. The dynamic method lets Extract request Manager to start Collector as needed. However, a user can explicitly start the Collector and let it run in the background, ready to transmit data as needed. This method is called the explicit method.
Dynamic method is the default way to use Collector. The examples above illustrate how this is configured: a port is specified in the Manager parameter file, a remote trail is specified in the Extract parameter file, and, if required, the IP address is added to your hosts file.
When capturing data over TCP/IP to remote systems that do not support dynamic Collectors, you must explicitly start a Collector on the target system before starting Extract. Each Extract must explicitly name the port to which it is writing, using the RMTHOST
parameter.
To explicitly configure your Collector, start GGSCI and enter the following:
TACL > ASSIGN STDERR, event_message_collector TACL > RUN SERVER /NOWAIT/ [-P port_number]
Note:
Your event_message_collector may be the standard system log, $0, or a virtual process, such as $VHS.
TACL > ASSIGN STDERR, $0 TACL > RUN SERVER /NOWAIT, NAME $COLL/ -P 12345
In the above example, the Collector listens on port 12345.
When you start the Collector, it references a default TCP/IP process ($ZTC0)
. You can change this to the process of your choice by running a DEFINE
statement before you start your collector.
TACL > ASSIGN STDERR, $0 TACL> DEFINE =TCPIP^PROCESS^NAME, FILE $ZTC8 TACL > RUN SERVER /NOWAIT, NAME $COLL/ -P 12345
See Reference for Oracle GoldenGate on HP NonStop Guardian for details about the Collector parameters.
Collector event messages are output to the ggserr.log
file. You can view this file using the GGSCI VIEW GGSEVT
command.
Event messages created by the Collector and Replicat on Windows and UNIX systems can be extracted and sent back to EMS on NonStop systems. This feature enables centralized viewing of Oracle GoldenGate messages across platforms.
To collect events from other systems:
Run Collector on NonStop to collect and distribute EMS messages. For each EMSCLNT process, run one Collector process.
The following example runs Collector and outputs its messages to $0.
TACL> ASSIGN STDERR, $0 TACL> RUN SERVER /NOWAIT/ –p 7880
Run the EMSCLNT utility on the remote target. EMSCLNT reads a designated error log and runs indefinitely, waiting for more messages to send. When EMSCLNT receives a message, it sends the message to a collector process on NonStop.
See the examples for running EMSCLNT on open systems for syntax information.
This UNIX example reads the file ggslog.err
for error messages. Error messages are sent to the collector to the NonStop at IP address 192.0.2.2
listening on port 7850
. The Collector on NonStop writes formatted messages to EMS Collector $0.
The Windows example below (from the DOS prompt) reads the file d:\ggserrs\log.txt
for error messages. Error messages are sent to the collector on host ggs2
listening on port 9876
. The Collector on NonStop writes formatted messages to EMS Collector $P0.
> emsclnt –h ggs2 –p 9876 –f d:\ggserrs\log.txt –c $P0
Argument | Description |
---|---|
–h ggs2 |
The node on which the collector is being run. Can be a name or IP address. This is a required parameter. |
–p 9876 |
The port where the collector is listening for messages. This is a required parameter. |
–f d:\ggserrs\log.txt |
The error file where EMSCLNT retrieves error messages. This is a required parameter. |
–c $P0 |
The collector where EMS messages should be written on the NonStop (default is $0). |