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 issueSEND REPLICAT
with theTHREADS
option instead of includingthreadID
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. -
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 theHANDLECOLLISIONS
orNOHANDLECOLLISIONS
parameter in the Replicat parameter file. SeeHANDLECOLLISIONS | NOHANDLECOLLISIONS
in Reference for Oracle GoldenGate. This command can be sent directly to an individual thread by means ofSEND REPLICAT
group_name[threadID]
or you can use theTHREADS
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 disableHANDLECOLLISIONS
, either by issuingSEND REPLICAT
with theNOHANDLECOLLISIONS
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
withHANDLECOLLISIONS
, when issued for a specific Replicat thread, shows that the command setHANDLECOLLISIONS
for allMAP
statements, not only the one handled by the specified thread. This is a known issue. The command actually affects only theMAP
statement that includes the specified thread. -
NOHANDLECOLLISIONS
-
Turns off the
HANDLECOLLISIONS
parameter but does not remove it from the parameter file. To avoid enablingHANDLECOLLISIONS
the next time Replicat starts, remove it from the parameter file. -
table_spec
-
table_spec
restrictsHANDLECOLLISIONS
orNOHANDLECOLLISIONS
to 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.
-
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 theRESETREPORTSTATS
|NORESETREPORTSTATS
option. SeeSTATOPTIONS
. -
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 theDEFERAPPLYINTERVAL
parameter. -
Processing data
– processing data -
Skipping current transaction
–START REPLICAT
withSKIPTRANSACTION
was used. -
Searching for START ATCSN
csn
–START REPLICAT
withATCSN
was used. -
Searching for START AFTERCSN
csn
–START REPLICAT
withAFTERCSN
was used. -
Performing transaction timeout recovery
– Canceling current incomplete transaction and repositioning to start new one (see theTRANSACTIONTIMEOUT
parameter). -
Waiting for data at logical EOF after transaction timeout recovery
– Waiting to receive remainder of incomplete source transaction after aTRANSACTIONTIMEOUT
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 theMAP
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 aSEND REPLICAT
command with aSUSPEND
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
withthreadID
. 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 ofthreadIDlow-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
andTRACE2
.If the Replicat is in coordinated mode and
TRACE
is used with aTHREADS
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 whenSEND REPLICAT
is issued bygroupname
withthreadID
(as inSEND REPLICAT fin003
TRACE
...) or when only one thread is specified withTHREADS
.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 toDDL
.
-
-
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 withfile_name
. For example:SEND REPLICAT
group_name
TRACE file_name DDLINCLUDEIf 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 multipleEVENTACTIONS
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 istrace.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
, andtrace003
.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 namedtrace
(without a thread ID suffix).SEND REPLICAT repe TRACE FILE ./dirrpt/trace.trc
Parent topic: Admin Client Command Line Interface Commands