Why does the GoldenGate replicat process display running without applying any records?

Why does the GoldenGate replicat process display running without applying any records? Sometimes, we will find that the status of the replicat process shows running, but the report shows that no records are updated. There are four main reasons for this phenomenon: 1. The replicat process is reading the wrong trail record. 2. The replicat process is reading the wrong trail file. 3. The specified table name format is incorrect. 4. The replicat or extract process hang has occurred. 4. in this case, the Process status is displayed as running, but no records are copied when you view the report. In the first case, run info extract, detail, or run info replicat to view the rmttrail parameter in the extract parameter file, detail or view the name, host, and path of the trail file being read by the replicat reportreplicat process must be the same as that specified in the extract process parameters. If the second case is true, execute info replicat, detail or view the replicat report. Execute ls-l to view the target trail file and check whether the trail file is being read, the end of the trail file being read by the replicat process is not linked to the next available file solution: Execute alter replicat rep_name, extseqno nnnnnn, and switch the extrba 0 division replicat to the next slap file, restart the replicat process. This phenomenon is usually caused by the source side performing the etrolover operation. We usually need to modify the extseqno and extrba of the extract, pump, and replicat processes in the entire synchronization process to solve the problem. If the format of the specified table name is incorrect, run logdump on the trail file to check whether the table name in the trail file matches the schema specified in the replicat process parameters. if the table_name is consistent with the hang process, the extract process, the replicat process, and the mgr process may both start with hang. You can run the ps-ef | grep proecess_name process to check whether multiple processes are running, or execute the stop operation in ggsci to check whether the process can be stopped normally. If not, in many cases, we can directly kill process_name (which can be in ggsci or OS) to restart the process to solve the problem. Source http://blog.csdn.net/xiangsir/article/details/8728747