From: | Alicja Kucharczyk <zaledwie10minut(at)gmail(dot)com> |
---|---|
To: | Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)com> |
Cc: | pgsql-admin(at)lists(dot)postgresql(dot)org |
Subject: | Re: New Oracle system in our house, migration chances |
Date: | 2022-01-13 15:02:36 |
Message-ID: | CAM=sWa5mX-PWWNpXN4NyLoHUug29O=v7NmGerfMZdV0gGiYM=g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
czw., 13 sty 2022 o 15:54 Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)com>
napisał(a):
> On 13/1/22 4:51 μ.μ., Thomas Kellerer wrote:
> > Julien Rouhaud schrieb am 13.01.2022 um 15:13:
> >> I would go with option A if possible. If you want to get an idea of how
> >> complicated a migration would be, ora2pg does have a migration cost
> assessment
> >> report [1]. It can even check the queries if you have the audit trail
> enabled
> >> on your oracle database (if that existed in that version).
> >>
> > I second this. Option A) is much cleaner. In my experience compatibility
> layers
> > that promise that "System A" behaves exactly like "System B" also
> introduce
> > a lot of additional problems. And if something goes wrong, you can never
> be sure
> > which part causes the problem.
> Thanks, of course I agree with the last sentence.
> >
> >
> >
>
>
> --
> Achilleas Mantzios
> DBA, Analyst, IT Lead
> IT DEPT
> Dynacom Tankers Mgmt
>
>
>
just to be clear is it an ISV or in-house built system? Because I see two
different answers ...
From | Date | Subject | |
---|---|---|---|
Next Message | Ron | 2022-01-13 15:06:47 | Re: New Oracle system in our house, migration chances |
Previous Message | Achilleas Mantzios | 2022-01-13 14:54:05 | Re: New Oracle system in our house, migration chances |