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

From: Ls Cheng <>
Date: Thu, 10 Sep 2020 15:30:20 +0200
Message-ID: <>


You can also try the autoupgrade tool which works so far pretty ok with some minor issues


On Thu, Sep 10, 2020 at 2:03 AM Rich J <> wrote:

> 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...
> Rich
> 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 - 15:30:20 CEST

Original text of this message