you are using SOURCEISTABLE. Are you planning to initial load
for initial load there are other alternatives which are sometimes recommended instead of using GG (like expdp and impdp)
if you trying to do IL and you can have those alternatives, go ahead with those. Probably you will by pass your configuration and error all together.
if you like this reply, approach mark it helpful, correct. This will help others too
hi . thanks for reply
The solution is already in place and unfortunately can't change anything at this moment.
Also, to add, have observed one thing in extract report.
first it says:
2020-01-27 16:43:07 WARNING OGG-01223 TCP/IP error 32 (Broken pipe), endpoint: 100.78.249.108:50002.
2020-01-27 16:43:12 INFO OGG-06569 Remote Collector/Server version 12.3 receiving data is a different version than this Extract 12.2 sending data.
later, 2020-01-27 16:43:17 INFO OGG-01230 Recovered from TCP error, host 100.78.249.108, port 50002.
here, i see few tables processed and trail size increased at target, but after some moment it says: it failed on same port with below error;
Can you pls let me know any clue from above.
1 person found this helpful
did you try using , format release 12.2 in your extract parameter file
and also do you have ALLOWDUPDIRS in GLOBALS ?
Please don't forget to mark this helpful, correct appropriately. This will help others too
Thanks vikas for reply..
it was working fine earlier without mentioning format release 12.2, but will try again with that in problematic process now.
ALLOWDUPDIRS in globals is pointing to <GG_HOME>/dirdat
yeah that is correct place for allowdupdirs to point to
please keep marking the responses helpful or like them.
few qq on above behavior,
1. Does dynamic collector keep assign different ports for each extract process(parameters with RMTHOST)? How will be the behavior of collector process and port allocation, as we observed in MGR.rpt of replicat, where we see different ports for collector.
2. I am thinking the tcp/ip errors because target unable to communicate back to Source extract when all data transferred from source to target through TCP/IP. Can you please let me know on how extract process (when using rmtfile) comes to know all bytes are transferred to target in trail. I think this is the communication extract is missing and failining with reasons.
thanks in advance.
I have to dig deeper but collector is internal to GG its managed by GG automatically.
will wait for others, who have more info on this to comment on this.
1 person found this helpful
Collector process uses different ports. It picks the port dynamically / randomly. To avoid such behavior, we will be using the parameter DYNAMICPORTLIST and give some range of ports in the manager process parameter file.
Once this is given, the collector process will use the ports within the range listed. This enhances the security of the environment. So that only the range of ports which are given can be opened at the network level.
There are two types of Server Collector processes. 1. Dynamic and 2. Static.
If you need to know more about collect process, check the below link,
Thanks Veera for your reply..
Its clear now on collector process behavior with the above description.
I have already gone through the link you've mentioned and try that as well to make it static port, still we face same issue.
Can you pls also clarify 2nd one on tcp/ip. Does collector at target has any mechanism to communicate back to extract such that extract processes knows it and move its checkpoint to process other tables? What i am thinking is: that communication is not going back to extract. Because i tried the load with just one table, the trail updates the incoming data,( as its size increases at target sub-directories) and extract fails exactly after 5 mins(300 secs default timeout) since the last message in view report.
the last message is: processing mentioned table at particular timestamp.
Thanks in advance.