Re: Best way of migrating from Oracle 12.1.0.2 RAC / ASM to Oracle 18 non-RAC ?

If you can take the outage for the upgrade, then Data Guard is probably your best option for the lowest downtime migration. You can automate almost all of your upgrade steps since you will have the target system in place and you can practice your upgrade as much as you want while also keeping the target DB in synch.

If the upgrade takes longer than your outage window, GoldenGate is probably your best option. This option eliminates the need to upgrade at all since you are replicating directly from your 12c source to the 18c target.

RAC and ASM have no effect on either option.

On Tue, Feb 25, 2020 at 4:30 PM Steve Wales (AddOns) < steve.wales_at_addonsinc.com> wrote:

> So, I have a 500GB-ish database (Oracle 12.1.0.2, 2-node RAC, ASM, Linux
> 7). The decision has been made to migrate to non-RAC and Oracle 18 since
> RAC is just overkill for what’s needed.
>
>
>
> Current config is 1 PDB inside a CDB. It’s also all hosted in Oracle
> Cloud Infrastructure if that makes any difference.
>
>
>
> I am wondering what my options are for this upgrade scenario with the
> smallest amount of downtime ?
>
>
>
> Export / Import is always an option but probably 5-6 hours in that by the
> time the export completes and import does its thing and indexes rebuild.
>
>
>
> If I was going from 12 to 12 on non-ASM in the past I’ve turned on backup
> mode, copied datafiles over to the new server, run a CREATE CONTROLFILE and
> then applied archive logs periodically during the day up to the point of
> shutdown of the source and had the whole thing copied over in 15 minutes or
> less.
>
>
>
> I’m not quite sure what my options are in that respect when running ASM
> (and also every time I’ve done that in the past it’s been a non-Container
> database so I’m a little unsure how a CDB/PDB adds complications to that).
>
>
>
> The business is prepared for a 5-6 hour outage one Saturday night if
> needed, but I figured I’d pick the brains of some smart people here to see
> what other options might be available.
>
>
>
> Thanks
>
> Steve
>
> *Disclaimer*
>
> The information contained in this communication from the sender is
> confidential. It is intended solely for use by the recipient and others
> authorized to receive it. If you are not the recipient, you are hereby
> notified that any disclosure, copying, distribution or taking action in
> relation of the contents of this information is strictly prohibited and
> may be unlawful.
>
> This email has been scanned for viruses and malware, and may have been
> automatically archived.
>

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