Re: Upgrading Oracle 12.1 to Oracle 19 on Win-x64

From: Rich J <>
Date: Wed, 9 Sep 2020 19:02:00 -0500
Message-ID: <>

Hey Steve,

Have you thought about trying a manual upgrade? Just today I upgraded a 12.1 database to 19 (on Linux) without the 12.1 software installed. I followed Manually Upgrading Non-CDB Architecture Oracle Databases <> after DBUA complained that it didn't know the database version. Manual upgrades in 19 are very easy, at least compared to what they used to be.

Of course, a proper backout plan for your environment is always a necessity prior to starting any upgrade.

Just a thought...


On Wed, Sep 9, 2020 at 6:31 PM k.hadd <> wrote:

> For what it's worth,
> I had installed oracle software 19c using a domain user and patched it to
> 19.7 on a windows uat environment and didn't have any issue .
> My account was part of the usual ora_* groups through a domain group (when
> I run: whoami /groups).
> Client wanted to move few refreshed DBs from to the new 19c
> CDB. I used Autoupgrade last week as moving 600GB of data and 50K objects
> was just not the fun I was ready for.
> I don't know why you had the error but I just realized that the new home
> is owned by my domain account while the old homes were ownd by the local
> admin and it still worked.
> Cheers
> Kosseila
> On Wed, Sep 9, 2020 at 4:46 PM Steve Wales (AddOns) <
>> wrote:
>> Greetings to all,
>> I have been given a server that has about 18 databases on it, a
>> combination of Production and Test and Dev, all on the same server.
>> I didn’t build it and have inherited it and now have to upgrade it.
>> The Oracle 12.1 install and all the Oracle services on the server are
>> owned by a Windows Domain account called MYDOMAIN\ora.service.
>> I went and unzipped the Oracle 19 install and went to run the setup.
>> First thing it told me was that the ora.service account has administrator
>> privileges and can’t be used to install the Oracle software.
>> So then I was going to just perform the install in a different
>> ORACLE_BASE using one of the recommended account options when it hit me.
>> When I go to run DBUA to upgrade the databases, if the services are owned
>> by different accounts, it probably won’t work. The database upgrade
>> documentation confirm this. Database upgrade is supported when the same
>> Windows user account is used as the Oracle Home user in both the source and
>> the destination Oracle Homes.
>> I have an SR open with Oracle Support but they are not being super
>> responsive at the moment. This has been dragging on for over a week and I
>> need to get the initial dev/test upgraded done to meet project deadlines.
>> The advice I’ve received so far is “Install in a different home with a
>> different user, then export and import or restore and upgrade”.
>> Neither of those are particularly appealing to me, let along running into
>> the problems of having to create new database names since I’d be building
>> new databases on the existing server and having to reconfigure all the
>> application connect strings.
>> Is there a way to get around this? What happens if I have the system
>> administrator remove the Administrative privileges from the ora.service
>> domain account ? Will this affect the running Oracle 12.1 production
>> databases in any way? Nearly all the databases I regularly look after are
>> on Linux so I don’t run into these Windows security setting problems and
>> I’m just not familiar enough with the intricacies of Windows and Oracle to
>> make an informed decision and I don’t want to go play with things blindly
>> since there are production instances at stake here.
>> Once the service is started as Admin does it do things to the database
>> binaries and data files where removal of Admin would break things ?
>> Appreciate any information or anecdotes around this situation.
>> 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.

Received on Thu Sep 10 2020 - 02:02:00 CEST

Original text of this message