SEND REPLICAT

Use SEND REPLICAT to communicate with a starting or running Replicat process. The request is processed as soon as Replicat is ready to accept commands from users.

Syntax

SEND REPLICAT group_name[threadID],
{
CACHEMGR {CACHESTATS | CACHEQUEUES | CACHEVMUSAGE} |
FORCESTOP |
GETLAG |
GETPARAMINFO [parameter_name] [FILE output_file] |
HANDLECOLLISIONS | NOHANDLECOLLISIONS [table_spec] |
INTEGRATEDPARAMS(parameter_specification) |
LOGEND |
REPORT [HANDLECOLLISIONS [table_spec]] |
RESUME |
STATUS |
STOP |
TRACE[2] [DDLINCLUDE | DDL[ONLY]] file_name |
TRACE[2] OFF |
TRACE OFF file_name |
TRACEINIT |
THREADS (threadID[, threadID][, ...][, thread_range[, thread_range][, ...])
}
group_name[threadID]

The name of the Replicat group or the name of a specific thread of a coordinated Replicat, for example fin003. If the command is issued for a specific thread, then an option that is used applies only to that thread. As an alternative, you can issue SEND REPLICAT with the THREADS option instead of including threadID with the group name. If Replicat is not running, an error is returned.

CACHEMGR {CACHESTATS | CACHEQUEUES | CACHEVMUSAGE}

Returns statistics about the Oracle GoldenGate memory cache manager. CACHEMGR should only be used as explicitly directed by Oracle Support.

CACHESTATS

Returns statistics for file caching.

CACHEQUEUES

Returns statistics for the free queues only.

CACHEVMUSAGE

Returns statistics for the virtual memory usage.

FORCESTOP

Forces Replicat to stop, bypassing any notifications. This command will roll back any active transaction and stop the process immediately. This command applies to Replicat as a whole and cannot be used for a specific Replicat thread.

GETLAG

Shows a true lag time between Replicat and the trail. Lag time is the difference, in seconds, between the time that the last record was processed by Replicat and the timestamp of the record in the trail. The results are the same as LAG REPLICAT.

GETPARAMINFO [parameter_name] [FILE output_file]

Use GETPARAMINFO to query runtime parameter values of a running instance, including Extract, Replicat, and Manager. You can query for a single parameter or all parameters and send the output to the console or a text file

parameter_name

The default behavior is to display all parameters in use, meaning those parameters that have ever been queried by the application, parameters, and their current values. If you specify a particular parameter, then the output is filtered by that name.

FILE output_file

The name of the text file that your output is redirected to.

HANDLECOLLISIONS | NOHANDLECOLLISIONS [table_spec]

Control HANDLECOLLISIONS behavior. Instead of using this option, you can specify the HANDLECOLLISIONS or NOHANDLECOLLISIONS parameter in the Replicat parameter file. See HANDLECOLLISIONS | NOHANDLECOLLISIONS in Reference for Oracle GoldenGate. This command can be sent directly to an individual thread by means of SEND REPLICAT group_name[threadID] or you can use the THREADS option to send the command through the coordinator thread to affect multiple threads.

HANDLECOLLISIONS

Use HANDLECOLLISIONS to enable automatic error handling when performing initial data loads while the source database is active. Make certain to disable HANDLECOLLISIONS, either by issuing SEND REPLICAT with the NOHANDLECOLLISIONS option or by removing the parameter from the parameter file, after the initial load is complete and online data changes have been applied to the target tables.

Note:

The message returned by SEND REPLICAT with HANDLECOLLISIONS, when issued for a specific Replicat thread, shows that the command set HANDLECOLLISIONS for all MAP statements, not only the one handled by the specified thread. This is a known issue. The command actually affects only the MAP statement that includes the specified thread.

NOHANDLECOLLISIONS

Turns off the HANDLECOLLISIONS parameter but does not remove it from the parameter file. To avoid enabling HANDLECOLLISIONS the next time Replicat starts, remove it from the parameter file.

table_spec

table_spec restricts HANDLECOLLISIONS or NOHANDLECOLLISIONSto a specific target table or a group of target tables specified with a standard wildcard (*).

INTEGRATEDPARAMS(parameter_specification)

(Oracle) Supports an integrated Replicat. Sends a parameter specification to the database inbound server while Replicat is running in integrated mode. Only one parameter specification can be sent at a time with this command. To send multiple parameter changes, issue multiple SEND REPLICAT commands as in the following example. 

SEND REPLICAT repe INTEGRATEDPARAMS (parallelism 4)
SEND REPLICAT repe INTEGRATEDPARAMS (max_sga_size 250)

To preserve the continuity of processing, the parameter change is made at a transaction boundary.

LOGEND

Confirms whether or not Replicat has processed all of the records in the data source.

REPORT [HANDLECOLLISIONS [table_spec]]

Generates an interim statistical report to the Extract report file. The statistics that are displayed depend upon the configuration of the STATOPTIONS parameter when used with the RESETREPORTSTATS | NORESETREPORTSTATS option. See STATOPTIONS.

HANDLECOLLISIONS

Shows tables for which HANDLECOLLISIONS has been enabled.

table spec

Restricts the output to a specific target table or a group of target tables specified with a standard wildcard (*).

RESUME

Resumes (makes active) a process that was suspended by an EVENTACTIONS SUSPEND event. The process resumes normal processing from the point at which it was suspended.

STATUS

Returns the current location within the trail and information regarding the current transaction. Fields output are:

  • Processing status (per thread, if Replicat is coordinated)

  • Position in the trail file (per thread, if Replicat is coordinated)

  • Trail sequence number (per thread, if Replicat is coordinated)

  • RBA in trail

  • Trail name

Possible processing status messages are:

  • Delaying – waiting for more data

  • Suspended – waiting to be resumed

  • Waiting on deferred apply – delaying processing based on the DEFERAPPLYINTERVAL parameter.

  • Processing data – processing data

  • Skipping current transaction – START REPLICAT with SKIPTRANSACTION was used.

  • Searching for START ATCSN csn – START REPLICAT with ATCSN was used.

  • Searching for START AFTERCSN csn – START REPLICAT with AFTERCSN was used.

  • Performing transaction timeout recovery – Canceling current incomplete transaction and repositioning to start new one (see the TRANSACTIONTIMEOUT parameter).

  • Waiting for data at logical EOF after transaction timeout recovery – Waiting to receive remainder of incomplete source transaction after a TRANSACTIONTIMEOUT termination.

  • At EOF (end of file) – no more records to process

Possible thread status messages when THREADS is used or the command is issued for a specific thread are:

  • Waiting for consensus stop point: This indicates that the threads are attempting to synchronize for a barrier transaction.

  • Waiting for Watermark: Indicates that all threads are attempting to stop at the same transaction boundary in the trail, known as the global watermark.

  • Waiting on all threads to start up: Indicates that the thread is waiting for all of the threads to start after a successful barrier transaction or a Replicat startup.

Possible coordinator thread status messages are:

  • Waiting for all threads to register: Indicates that the MAP statements are all being parsed to determine the thread IDs that are specified in them.

  • Processing data: Indicates that data is being processed normally.

  • Suspended, waiting to be resumed: Indicates that a SEND REPLICAT command with a SUSPEND request was sent to Replicat.

  • At EOF: Indicates that there is no more data in the trail to process.

  • Waiting to register MAP statistics: Indicates that Replicat is collecting processing statistics to send to the report file.

STOP

Stops Replicat gracefully. This command applies to Replicat as a whole and cannot be used for a specific Replicat thread.

THREADS (threadID[, threadID][, ...][, thread_range[, thread_range][, ...])

Issues the command only for the specified thread or threads of a coordinated Replicat. You can use this option or you can use groupname with threadID. Without either of those options, the command applies to all active threads.

threadID[, threadID][, ...]

Specifies a thread ID or a comma-delimited list of threads in the format of threadID, threadID, threadID.

thread_range[, thread_range][, ...]

Specifies a range of threads in the form of threadIDlow-threadIDhigh or a comma-delimted list of ranges in the format of threadIDlow-threadIDhigh, threadIDlow-threadIDhigh.

A combination of these formats is permitted, such as threadID, threadID, threadIDlow-threadIDhigh.

TRACE[2] [DDLINCLUDE | DDL[ONLY]] file_name

Turns tracing on and off. Tracing captures information to the specified file to reveal processing bottlenecks. Tracing also can be enabled by means of the Replicat parameters TRACE and TRACE2.

If the Replicat is in coordinated mode and TRACE is used with a THREADS list or range, a trace file is created for each currently active thread. Each file name is appended with its associated thread ID. This method of identifying trace files by thread ID does not apply when SEND REPLICAT is issued by groupname with threadID (as in SEND REPLICAT fin003 TRACE...) or when only one thread is specified with THREADS.

Contact Oracle Support for assistance if the trace reveals significant processing bottlenecks.

TRACE

Captures step-by-step processing information.

TRACE2

Identifies code segments rather than specific steps.

DDLINCLUDE | DDLONLY

(Replicat only) Enables DDL tracing and specifies how DDL tracing is included in the trace report.

  • DDLINCLUDE includes DDL tracing in addition to regular tracing of transactional data processing.

  • DDL[ONLY] excludes the tracing of transactional data processing and only traces DDL. This option can be abbreviated to DDL.

file_name

file_name specifies the relative or fully qualified name of a file to which Oracle GoldenGate logs the trace information. If a trace is already in progress, the existing trace file is closed and the trace resumes to the file specified with file_name. For example: 

SEND REPLICAT group_name TRACE file_name DDLINCLUDE

If no other options will follow the file name, the FILE keyword can be omitted, for example: 

SEND REPLICAT group_name TRACE DDLINCLUDE file_name
TRACE[2] OFF

Turns off tracing.

TRACE OFF file_name

Turns tracing off only for the specified trace file. This option supports the EVENTACTIONS feature, where there can be multiple trace files due to multiple EVENTACTIONS statements.

TRACEINIT

Resets tracing statistics back to 0 and then starts accumulating statistics again. Use this option to track the current behavior of processing, as opposed to historical.

Examples

SEND REPLICAT repe, HANDLECOLLISIONS
SEND REPLICAT repe, REPORT HANDLECOLLISIONS rep_*
SEND REPLICAT repe, GETLAG
SEND REPLICAT repe, INTEGRATEDPARAMS(parallelism 10)

The following gets lag for thread 3 of a coordinated Replicat.

SEND REPLICAT repe, GETLAG

The following enables tracing for only thread 1 of a coordinated Replicat. In this case, because only one thread is being traced, the trace file will not have a threadID extension. The file name is trace.trc. 

SEND REPLICAT repe, TRACE THREADS(1) FILE ./dirrpt/trace.trc

The following enables tracing for threads 1,2, and 3 of a coordinated Replicat. Assuming all threads are active, the tracing produces files trace001, trace002, and trace003. 

SEND REPLICAT repe TRACE THREADS(1-3) FILE ./dirrpt/trace.trc

The following enables tracing only for thread 1 of a coordinated Replicat. Because the command was issued directly for thread 1 without the use of a THREAD clause, the trace file is named trace (without a thread ID suffix). 

SEND REPLICAT repe TRACE FILE ./dirrpt/trace.trc