We've been using Fathom Replication Plus for last 10+ years, it works efficiently but finds very difficult to maintain during server outages. Rebuilding the Replication is really a painful task and effects our business hugely.
I was exploring the options to migrate to Openedge PRO2. I'm fairly new to PRO2, after few research it sounds that it delivers all the features that is built in Replication plus and additionally it allows data to be exported to other platform.
It'll be grateful if anyone could share your experiences with PRO2 and reasons why shouldn't be migrating to PRO2 from Replication Plus.
Also, I couldn't find a document/wiki on comparison of features, benefits between PRO2 and Replication Plus.
Any inputs will really help me to make right decision.
Thank You,
Pro2 and OpenEdge Replication are very different in how they work. here is a very rudimentary summary of differences.
Pro2 relies on 4GL triggers on all those tables that are being replicated. Could be all or only one. These triggers record entries in a "change log". When SQL is used for database updates, a second set of triggers is required. A background 4GL program then reads the change log and performs the equivalent operations on the target database(s). schema changes are not replicated. target database does not have to be identical to source. index rebuilds do not break replication. works best when every table being replicated has a unique index but that is not required. every database change in source causes a record to be created in the change log. that record also has to be deleted. transaction sizes increase significantly.
oe replication is /all/ database changes to an identical oe database (i.e. an exact copy of source). schema changes are replicated. replication is done by shipping transaction log records (ai records) from source to target and performing the exact same operations on the target. no triggers are used. many maintenance operations like an index rebuild will break replication which then has to be started over. disabling ai, which is sometimes necessary, breaks replication.
gus
> On Dec 1, 2015, at 12:30 PM, eswarm wrote:
>
> Update from Progress Community [https://community.progress.com/]
>
> eswarm [https://community.progress.com/members/eswarm]
>
> We've been using Fathom Replication Plus for last 10+ years, it works efficiently but finds very difficult to maintain during server outages. Rebuilding the Replication is really a painful task and effects our business hugely.
>
> I was exploring the options to migrate to Openedge PRO2. I'm fairly new to PRO2, after few research it sounds that it delivers all the features that is built in Replication plus and additionally it allows data to be exported to other platform.
>
> It'll be grateful if anyone could share your experiences with PRO2 and reasons why shouldn't be migrating to PRO2 from Replication Plus.
>
> Also, I couldn't find a document/wiki on comparison of features, benefits between PRO2 and Replication Plus.
>
> Any inputs will really help me to make right decision.
>
> Thank You,
>
> View online [https://community.progress.com/community_groups/openedge_rdbms/f/18/t/21716]
>
> You received this notification because you subscribed to the forum. To stop receiving updates from only this thread, go here [https://community.progress.com/community_groups/openedge_rdbms/f/18/t/21716/mute].
>
> Flag [https://community.progress.com/community_groups/openedge_rdbms/f/18/t/21716?AbuseContentId=60aa8ed4-843e-47e4-8249-cca4c55d1050&AbuseContentTypeId=46448885-d0e6-4133-bbfb-f0cd7b0fd6f7&AbuseFlag=true] this post as spam/abuse.
Hi James, we don't use it for DRP. The volume of deliveries our application generate and sends to customers are quiet high (close to 200,000 xml files per week). To balance the load we replicate the source database to 2 targets. on those target machine, the deliveries are running continuously through out the day by connecting dbs in read only mode. Our DBs size is more than 2.5TB, so rebuilding replication takes handful lots hours and causing deliveries to queued that in turn results in outage to our customers.
Thanks
Thanks gus for your reply.
Yes, we can manage the schema updates separately. the application code are exact copy between source and target server, so not worried about triggers. I'm looking to build exact copy of OE database with few overhead (like applying schema manually on target dbs) in near real time.
If you're not using it for DR then I'd say that Pro2 is definitely worth considering as a solution. One of the really nice advantages of Pro2 is that your schema on the target can be different. So you can have production oriented indexes on production, and reporting indexes on the target. So you can really tune up each database for the application it is designed for. You can't do that with OE Repl.
what is your definition of "real time" ? both forms of replication can be delayed by minutes or even hours.
> On Dec 2, 2015, at 5:31 AM, eswarm wrote:
>
> Update from Progress Community [https://community.progress.com/]
>
> eswarm [https://community.progress.com/members/eswarm]
>
> Thanks gus for your reply.
>
> Yes, we can manage the schema updates separately. the application code are exact copy between source and target server, so not worried about triggers. I'm looking to build exact copy of OE database with few exceptions (like schema) in near real time.
>
> View online [https://community.progress.com/community_groups/openedge_rdbms/f/18/p/21716/76248#76248]
>
> You received this notification because you subscribed to the forum. To unsubscribe from only this thread, go here [https://community.progress.com/community_groups/openedge_rdbms/f/18/t/21716/mute].
>
> Flag [https://community.progress.com/community_groups/openedge_rdbms/f/18/p/21716/76248?AbuseContentId=d9b3da94-e623-4894-adcb-7cddaaf5f759&AbuseContentTypeId=f586769b-0822-468a-b7f3-a94d480ed9b0&AbuseFlag=true] this post as spam/abuse.
Currently with Replication Plus, the latency is around less than 10-20 secs (data grows at a rate of around 100MB of data per minute) mainly because the severs are hosted on the same network switch....we would like to retain those numbers with PRO2 hopefully.
Hi Eswarm,
Pro2 is in near real-time and easily within the 10-20 secs latency you mention above. Pro2 is extremely low-impact, scalable architecture meaning replication speeds of anywhere between 10,000 and 50,000 rows are replicated per minute of a typical LAN environment
How it works:
• Data changes are captured with replication triggers
• A minimal amount of information is written to the queue to identify the updated record
• The multi-threaded replication process retrieves the updated record
• The data queued in the replication database is moved via the MS or Oracle Data Server to SQL Server to the target database
Cheers
John.
One last note... Pro2 isn't a disaster recovery product, please continue DR with Replication.
As per John's post (and he should know!!) the latency will be well within your requirements. Just be aware it only writes the data once the transaction is complete. But then you want this to ensure integrity, and OE Replication does this also.
oe replication does NOT wait for the transaction to be complete. the target can be updated before transaction commit. or after, depending on network conditions and load.
> On Dec 2, 2015, at 11:26 AM, James Palmer wrote:
>
> Update from Progress Community [https://community.progress.com/]
>
> James Palmer [https://community.progress.com/members/jdpjamesp]
>
> As per John's post (and he should know!!) the latency will be well within your requirements. Just be aware it only writes the data once the transaction is complete. But then you want this to ensure integrity, and OE Replication does this also.
>
> View online [https://community.progress.com/community_groups/openedge_rdbms/f/18/p/21716/76288#76288]
>
> You received this notification because you subscribed to the forum. To unsubscribe from only this thread, go here [https://community.progress.com/community_groups/openedge_rdbms/f/18/t/21716/mute].
>
> Flag [https://community.progress.com/community_groups/openedge_rdbms/f/18/p/21716/76288?AbuseContentId=9e9dbae5-f761-4a77-a21a-3d6027352f36&AbuseContentTypeId=f586769b-0822-468a-b7f3-a94d480ed9b0&AbuseFlag=true] this post as spam/abuse.
thanks James - beer in the post :)
Thanks gus, that make sense. Again, any incomplete transaction data are of no use :-).
true.
the incomplete transactions, if any, will either be completed as more transaction log records arrive at the secondary, or they will be backed out if the database is started as primary.
> On Dec 2, 2015, at 12:24 PM, eswarm wrote:
>
> Update from Progress Community [https://community.progress.com/]
>
> eswarm [https://community.progress.com/members/eswarm]
>
> Thanks gus, that make sense. Again, any incomplete transaction data are of no use :-).
>
> View online [https://community.progress.com/community_groups/openedge_rdbms/f/18/p/21716/76296#76296]
>
> You received this notification because you subscribed to the forum. To unsubscribe from only this thread, go here [https://community.progress.com/community_groups/openedge_rdbms/f/18/t/21716/mute].
>
> Flag [https://community.progress.com/community_groups/openedge_rdbms/f/18/p/21716/76296?AbuseContentId=b5be0cf1-12d9-4f39-a778-609d08e3d942&AbuseContentTypeId=f586769b-0822-468a-b7f3-a94d480ed9b0&AbuseFlag=true] this post as spam/abuse.
>> Pro2
>> transaction sizes increase significantly.
How significantly ? Is that just the time needed to write to the log. There is no additional I/O on a primary database, right? I assume "change log" is recommended be in a separate database.
Second question:
We all know that OE replication need to be rebuilt from time to time. Do you know any cases or could think of any cases when working Pro2 replication need to be rebuilt ( target re-synced with a source) ?
I believe "change log" can go in a separate DB or just additional structures in the primary.
As for your second question, and John Goodland will no doubt be able to confirm, but the only reason I can think of for rebuilding would be when you perform any action that would change ROWIDs on the primary database. Is that right, John?
The only reason you would completely rebuild the target is if a dump and load is performed on the source db.
Thanks for confirming, [mention:3ad22569ffda49dc9060a3a9f905af6f:e9ed411860ed4f2ba0265705b8793d05].
What about if you were to implement table partitioning? Doesn't that change the rowid's? Maybe it doesn't, I've never done it, but doesn't the target db store the rowids of the source records?
if you use table partitioning, once rows are placed into their partitions, the rowids do not change unless you change the partition key value to cause a row to be moved from one partition to another.
if you have an unpartitoned table and replicate it with pro2, and you then partition it and run the split utility, all the rowids will change, probably breaking replication.
regards,
gus (gus@progress.com)
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
> On Dec 4, 2015, at 4:57 AM, James Palmer wrote:
>
> Update from Progress Community [https://community.progress.com/]
>
> James Palmer [https://community.progress.com/members/jdpjamesp]
>
> Thanks for confirming, John Goodland [https://community.progress.com/members/jgoodlan].
>
> What about if you were to implement table partitioning? Doesn't that change the rowid's? Maybe it doesn't, I've never done it, but doesn't the target db store the rowids of the source records?
>
> View online [https://community.progress.com/community_groups/openedge_rdbms/f/18/p/21716/76465#76465]
>
> You received this notification because you subscribed to the forum. To unsubscribe from only this thread, go here [https://community.progress.com/community_groups/openedge_rdbms/f/18/t/21716/mute].
>
> Flag [https://community.progress.com/community_groups/openedge_rdbms/f/18/p/21716/76465?AbuseContentId=0c1604a0-ec58-42f6-a680-9f9bfac9a9e6&AbuseContentTypeId=f586769b-0822-468a-b7f3-a94d480ed9b0&AbuseFlag=true] this post as spam/abuse.