you can check whether a capture process is enabled, disabled, or aborted by querying the DBA_CAPTURE data dictionary view:
select capture_name, status from dba_capture;
if the capture process is disabled, then try restarting it.
if the capture process is aborted, then you might need to correct an error before you can restart it successfully. The following query shows when the capture process aborted and the error that caused it to abort:
select capture_name, status_change_time, error_message from dba_capture where status = 'ABORTED';
Common capture issues:
ORA-04031: unable to allocate x bytes of shared memory ("streams pool","unknown object","streams pool","kwqbsinfy:lcr") or ORA-23603 STREAMS enqueue aborted due to low SGA
Oracle is running low on memory allotted for Streams.
Check that propagation jobs and apply processes are enabled (and consuming messages).
Troubleshooting propagation or apply problems, enabling any propagation or apply which might be disabled.
Alternative: increase the memory dedicated to Streams (streams_pool_size initialization parameter) if possible.
Re-start the capture process. If the problem persists, bounce the database can help.
Capture process loops on startup
select capture_name, state from gv$streams_capture; shows state : 'initalizing' or 'dictionary initialization'.
there may be a missing logfile which cannot be opened.
check metalink Note:313279.1
ORA-01291: missing logfile
required log files were removed before they are scanned by the capture process.
determine the missing SCN range (v$logmnr_logs view) and restore the relevant log files.
ORA-00600: [kwqbcpagent: subid] and ORA-00600 [4450] reported by the qmon processes after node restart
workaround: stop and restart the capture process.
ORA-01280: Fatal Logminer Error
Also ORA-04030: Out of process memory when ...
Check memory consumption
Re-start the capture process
WARNING: no base object information defined in logminer dictionary!!! or MISSING Streams multi-version data dictionary!!!
use the values associated with the objn field to determine the objects causing this problem.
populate the data dictionary for a particular object running exec dbms_capture_adm.prepare_table_instantiation(' %object_name% '); or exec dbms_capture_adm.prepare_schema_instantiation(' %schema_name% ');
these errors can be safely ignored
Capture process (running in Real Time mode) is in "WAITING FOR REDO" state during more than 1 hour (Please note that, if the capture process is running in archive log mode, this is the normal state for the capture process)
select capture_name, parameter, value from dba_capture_parameters where parameter='DOWNSTREAM_REAL_TIME_MINE';
In a downstream environment, the following errors are logged on the source database: ORA-00270: error creating archive log and ORA-16055: FAL request rejected.
Cause: the archive log area is running out of space.
Check using "~/work/monitor_streams/minimum_archivelog.sql" script. which is the minimum archive log necessary for the capture process.
Remove old archive logs. In a downstream environment, only the archive logs received from the source database (.../archivelog/from%SOURCE%/) are really necessary for the capture process.
Error Message: Capture latency higher than default limit of 90 mins. Please check. (mail from the Streams monitoring tool)
Capture process is in "CAPTURING CHANGES" status BUT nothing is being captured (LCRs captured and LCRs enqueued = 0/s) - only in downstream environment
One (or more) of the source node are down: last archived log files have not been sent to the downstream database
Check archived log files names missing on downstream and send and register them manually:
Create or replace source directory (destination directory already created)
@source db use dbms_file_transfer.put_file(source_directory, file, destination_directory, file, db_link_downstream);
Register file with the capture process @downstream database: alter database register or replace logfile 'logfile' for 'capture_name';
alter database register or replace logical logfile '+STRMDSC_RECODG1/LHCBDSC/ARCHIVELOG/FROMLHCBR/log_3_34712_561483088.arc' for 'STRMADMIN_CAPTURE_LFC';
Capture process is in "PAUSED BY FLOW CONTROL" or "ENQUEUING MESSAGE" status:
check the source queue, probably a big amount of LCRs are spilled over to disk.
check which site has not consumed the LCRs: select subscriber_address, cnum_msgs, message_lag from gv$buffered_subscribers; (message_lag > 0).
check if the destination site is down:
If yes, then contact the destination dba in order to fix the problem.
If no, then check the propagation and apply status.
select capture_name, status from dba_capture; - must be 'enabled'
select capture_name, state from gv$streams_capture; - it will move from 'initializing' or 'dictionary initialization' to 'enqueuing message' or 'capturing changes' or 'creating LCR'.
Note: when the capture process is restarted it might scan old archive log files. The column required_checkpoint_scn in dba_capture indicates the SCN at which the capture process restarts. Low activity period may cause checkpoint to go behind
script. which provides the minimum archive log necessary to restart the capture process: itrac37:~/work/monitor_streams/minimum_archivelog.sql
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
