Re: Theory Question/Discussion regarding Replication Tools

Ultimately, we have one system that they're wanting to feed into disparate database backends and have them _all_ in sync at the same time (or near the same time) due to acquisitions and software that behaves differently from the acquiring company.

Which means we now have a requirement that Oracle DatabaseA and Postgres databaseA are showing the same transactions and they're wanting to key off Oracle as the System of Record.

In my mind the SoR should be prior to the end points in this scenario through some type of Hub that sends the transactions to all end points (databases) of interest.

On Mon, Apr 3, 2023 at 2:53 PM Tim Gorman <tim.evdbt_at_gmail.com> wrote:

> Chris,
>
> I've worked with organizations who modified their downstream analytic
> environments as the intermediate or temporary solution to unify different
> information, while they worked on the far larger project to move everything
> upstream to common systems.
>
> This recognizes that the immediate critical requirement is for global
> strategic information for decision-making, because day-to-day activities
> can usually be managed for a few years using the systems acquired along
> with the acquired company, until everyone can be consolidated onto the same
> operation applications in the long-term. Building data maps for the
> ETL/ELT processes from the disparate operational environments to the
> downstream analytic environments helps inform the organization on what each
> acquired component org might be missing, which also provides input for the
> eventual consolidation.
>
> As the eventual consolidated operational system(s) are deployed gradually,
> and the ETL/ELT feeds to the downstream analytics evolve accordingly, then
> the downstream analytics can also temporarily include reporting to compare
> and verify correctness and identify anomalies from the migrations.
>
> I do believe that replication for the reasons you describe might develop
> into a crutch, providing temporary accommodation for differences which does
> not lead to a permanent solution. The approach above leads to a solution,
> but continual bandaiding by adding more replication does not lead to a
> viable permanent solution.
>
> If the replication is just a stop-gap leading to the long-term solution,
> then all is good. But if the replication is viewed as the long-term
> solution, or if the long-term solution is fuzzy or non-existent, then I'd
> be worried.
>
> Hope this helps...
>
> -Tim
>
>
>
> On 4/3/2023 11:29 AM, Chris Taylor wrote:
>
> Find myself in an interesting position where multiple databases need to be
> kept in sync with transactions. Primarily caused by corporate acquisitions.
>
> Having dealt with replication in the past with both Goldengate and IBM's
> QRep, is it just me, or is replication a "band-aid/bandage" for a bad
> design when multiple end points need to be kept in sync?
>
> Seems to me replication is what you slap-on to feed a data mart, or a
> postgres or a Snowflake when you don't have some kind of central hub that
> is responsible for sending those transactions to their appropriate end
> points.
>
> I'm curious what solutions what you guys have seen and if any of your
> platforms are using a central type hub to send transactions out to
> different end points when those end points are databases such as Oracle,
> Postgres, Snowflake?
>
> Am I crazy, or is everyone else? :D
>
> Thanks,
> Chris
>
>
>

--
http://www.freelists.org/webpage/oracle-l