There are issues to be aware of using Ogg's "Loading data from file to Replicat" approach: The Replicat process is the foreground process
Therefore, it is best to call the Replicat process in vncserver or run it in the background nohup way. The following is run in the background using the Nohup method.
[[email protected] ~]$ ll rep_backgroud.sh-rwxr-xr-x 1 Oracle oinstall 98 June 2 03:02 Rep_backgroud.sh[[email Protect Ed] ~]$ cat rep_backgroud.sh Cd/u02/ggs---> Note this line, not omitted,/u02/ggs is Ogg's installation directory Replicat paramfile/u02/ggs/dirprm/ REPFTOR.PRM Reportfile/u02/ggs/dirrpt/repftor.rpt[[email protected] ~]$ [[email protected] ~]$ nohup sh/home/oracle/ rep_backgroud.sh &
===================== Disconnect SecureCRT, then reconnect securecrt================================
[Email protected] ~]# Ps-ef | grep reporacle 22585 1 0 03:03? 00:00:00 sh/home/oracle/rep_backgroud.shoracle 22586 22585 5 03:03? 00:00:02 replicat paramfile/u02/ggs/dirprm/repftor.prm reportfile/u02/ggs/dirrpt/repftor.rptroot 22628 22603 0 03:04 PTS/1
Note the point:
1. If the REPLICAT process was executed in the manner of the previous process, the SECURECRT was disconnected midway, and then in the destination table (defined in/U02/GGS/DIRPRM/REPFTOR.PRM) there is a partial record. The destination table needs to be truncate before the REPLICAT process is re-launched.
2. The core of the OGG "Loading data from File to Replicat" method is:
The extract process--->trail file (which defines the location in the parameter file of the extraction process)--the destination table (the rep process applies the trail file to the destination table)
3. The extract process at this time should also be the foreground process, but I did not disconnect securecrt during the test, not tested.
An issue that should be noted with the Ogg "Loading data from File to Replicat" method: The Replicat process is the foreground process