Re: Datapatch while users/applications are connected?

Right - what I prefer doing is cloning the Oracle Home to a new copy of the existing version. Patch that new home (in the case of 19.14 to 19.17). Shutdown and restart the database in the new home (differs depending on RAC/grid vs single-instance/no-grid of course).

I've just never considered running datapatch against a database that was available to users. Seems like you're just *begging *for Applications to get interrupted which is bad for everyone when people start yelling at you about database errors in their application! :) (Or you've told them that it's back up , but _now_ you have to take it down again - 'my bad' - also not good.)

Chris

On Thu, Dec 15, 2022 at 12:18 AM Ilmar Kerm <ilmar.kerm_at_gmail.com> wrote:

> Question was about datapatch, not opatch.
>
> First, I strongly recommend to adopt out-of-place patching, both on RAC
> and single instance.
> 1) First you install and patch a new Oracle home. While database instance
> is still running from old oracle home.
> 2) During patching window, you shut down instance from old home and start
> it from new home. Depends on your database traffic, it could be quite a
> quick operation. On RAC you do it one instance at a time, while database is
> still running on other instances (RAC rolling). With single instance+FSFO
> data guard I bounce the FSFO target first, wait it to be in SYNC and then
> perform a failover (or switchover if you do not have any other far-away
> standby instances) - so for applications the downtime can be in tens of
> seconds (potentially less than RAC brownouts actually...).
> 3) After (RAC - all) instances are running from new home - you run
> datapatch. On RAC - only on one instance (where all PDB are open) - online
> operation (but keep an eye on it).
>
>
> On Thu, Dec 15, 2022 at 12:52 AM Mladen Gogala <gogala.mladen_at_gmail.com>
> wrote:
>
>> On 12/14/22 13:52, Ilmar Kerm wrote:
>>
>> RAC is patched in rolling fashion, so nothing should be down for users in
>> any point in time. This includes datapatch.
>> Even with single instance - if no/minimal downtime is desired, there
>> really is no other option.
>> Monitor datapatch execution like any other database session - it has
>> happened for me a few times that for example long running DBMS_SCHEDULER
>> jobs lock the package while datapatch wants to replace the package - so
>> datapatch will start waiting for a lock.
>>
>> How will you run "opatch" on the running instance? If my memory serves me
>> right, it is necessary to run "opatch" before "datapatch". On a single
>> instance, it is necessary to bring the instance down. There is no rolling
>> upgrade of a single instance DB.
>>
>> --
>> Mladen Gogala
>> Database Consultant
>> Tel: (347) 321-1217https://dbwhisperer.wordpress.com
>>
>>
>
> --
> Ilmar Kerm
>

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