How to Patch Oracle Net Listener

When running Oracle Database on a server, the Oracle Net Listener is a vital component.

Let’s discuss how you can patch it.

The Basics

Normally, on a server, you have:

One listener
One or many database instances

That one listener handles new connections to all database instances. You patch the listener simply by starting it in the new Oracle home.

You can have multiple listeners and use remote listeners, but if you do that, you’re smart and probably won’t need the advice in this blog post.

How to Patch the Listener

Copy listener.ora from the old Oracle home to the new Oracle home.
```
export OLD_ORACLE_HOME=/u01/app/oracle/product/19.26.0/dbhome_1
export NEW_ORACLE_HOME=/u01/app/oracle/product/19.27.0/dbhome_1
cp $OLD_ORACLE_HOME/network/admin/listener.ora $NEW_ORACLE_HOME/network/admin
```
- You can avoid this step by redirecting the location of your network files using the TNS_ADMIN environment variable.
- If you have a completely default installation with no listener configuration, you don’t have a listener.ora file and can skip this step.
- In an advanced configuration you might have references to the listener Oracle home. Those you must update. But don’t confuse the listener Oracle home, with the Oracle homes of the databases with static registration. Those you update, when you patch the matching database.
Restart the listener in the new Oracle home:
```
export ORACLE_HOME=$OLD_ORACLE_HOME
$OLD_ORACLE_HOME/bin/lsnrctl stop
export ORACLE_HOME=$NEW_ORACLE_HOME
$NEW_ORACLE_HOME/bin/lsnrctl start 
```
- If you use Oracle Grid Infrastructure or Oracle Restart, they manage the listener. You automatically restart, and thus patch, the listener when you patch those components.
If you use the dbstart script to start the listener, update it with the new Oracle home.
- On Windows, you must delete the matching Windows service when you stop the listener. The lsnrctl start command should create a new listener. Be sure to set it to start automatically.

The Outage

When you restart the listener, there’s a short period where there’s no listener. It takes a second or so for the new listener to start. In that period, any new connection attempt fails:
```
ORA-12541: TNS:no listener
```
This affects new connections only. Existing connections continue to work unaffected.
As soon as the listener starts, it’ll read listener.ora and go through the static listener registrations defined by the SID_LIST. Connections to those databases are ready immediately.
For optimal flexibility, however, it’s better to use dynamic listener registration, where the database instance automatically registers with the listener. When you restart the listener, it doesn’t know of all the dynamic registrations and will have to wait until the database registers (up to 60 seconds).
- You can force a database to register with the listener:
```
SQL> alter system register;
```
- It’s a good idea to run through all of your databases after the listener restart and force a listener registration with the above command.
- Until the dynamic registration completes, any new connection to the database will fail:
```
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
```
You can hide the short outage from the client by using RETRY_COUNT and RETRY_DELAY in your connect strings. Allow the client to retry for a short period before throwing the above errors.
You can avoid the outage completely by using multiple listeners and patching them separately. Your connect strings should have an ADDRESS_LIST containing both listeners.

Do I Need to Patch the Listener and Database At the Same Time?

No, that’s up to you. If you want just one interruption, then do it all at once. Otherwise, you can do it in separate maintenance windows.

What About AutoUpgrade?

At the moment, AutoUpgrade doesn’t patch the listener. But it’s on the backlog.

Happy patching!

How to Patch Oracle Database on Exadata Cloud@Customer using Out-Of-Place

At our recent workshop in London, I was advocating for using out-of-place patching and the many benefits it brings. One of the questions was:

How do I do that on Exadata Cloud@Customer?

When you use the patching functionality in the cloud tooling, it will patch an entire Oracle home, including all databases, using in-place patching. This is a convenient option, but it extends the maintenance window on your database.

Let’s find out how to do it using out-of-place patching!

Benefits of Out-Of-Place Patching

You can patch the database with less downtime. You just shut down the database in the old Oracle home and immediately restart it in the new Oracle home.
- With in-place patching, you need more downtime. While the database is down, you need time to roll off patches and apply the new ones. Depending on the number of patches you have, this can take 5, 10, or 20 minutes.
You prepare the new Oracle home in advance.
- With in-place patching, all changes to the Oracle home occur during the maintenance window when the database is down.
There are fewer tasks in your downtime window, so less risk and less stress.
You can use a fresh, brand-new Oracle home to avoid issues with rolling off patches. Plus, a brand-new Oracle home means you don’t carry any old luggage in your Oracle home.
- With in-place patching, your Oracle home will grow over time. You’ll see that disk space keeps increasing.
In the unlikely event that you need to roll back or fall back, that’s a lot easier. You just restart the database in the old Oracle home.
- With in-place patching, you have to reverse the entire process. So, all that was cumbersome when you patched will be cumbersome when you roll back.

AutoUpgrade

In the workshop, I showed some cool demos of using AutoUpgrade for out-of-place patching. You can’t do that on Exadata Cloud@Customer. You must use the cloud tooling when you patch an entire CDB.

Alternatively, you can patch an individual PDB using AutoUpgrade and refreshable clone PDBs. I’ll have to write a blog post about that.

How to Patch Out-Of-Place on Exadata Cloud@Customer

Create a software image at the desired Release Update with any additional one-off patches. You can skip this if you want to use the Oracle-provided images.
Create a database home using the software image you just created, or use an Oracle-provided one.
I recommend that you update the cloud tooling.
Your maintenance window starts.
Move the database to the new Oracle home. The cloud tooling does that in a rolling manner, so there’s no database outage.
- It also executes Datapatch and other post-patching steps.

That’s it; your database has been patched!

After a while, you can remove the old Oracle home.
If you want to script the process, you can also use the REST APIs or dbaascli.
This also works for Exadata Database Service.
There’s no way to use out-of-place patching on Grid Infrastructure.

Happy patching!

Appendix

Other Methods

You are free to use Exadata Fleet Update for your Exadata Cloud@Customer system. It can greatly reduce your workload and automate your patching operations. Check out these resources:

AutoUpgrade New Features: Better Automation To Patch Oracle Database on Windows

Running Oracle Database on Microsoft Windows is slightly different from running it on other platforms. So, of course, patching Oracle Database is also slightly different.

The Oracle Database runs as a Windows service. AutoUpgrade must re-create the service when you perform out-of-place patching so the service starts oracle.exe from the new Oracle home.

To recreate the service, you must specify the credentials of the user who runs the service. Windows allows you to store the credentials in a special file; AutoUpgrade can use that when it recreates the service.

For security purposes, AutoUpgrades deletes the credential file when it is no longer needed. For automation, however, that’s impractical because you would need to recreate the credential file every time you patch or upgrade.

AutoUpgrade now allows you to keep the file and reuse it. To do so, use the config file parameter delete_credential_file.

How To Patch Oracle Database on Windows

Get the latest version of AutoUpgrade:

wget https://download.oracle.com/otn-pub/otn_software/autoupgrade.jar

Create an AutoUpgrade config file:

global.keystore=c:\oracle\autoupgrade\keystore
patch1.source_home=c:\oracle\product\dbhome_19_26_0
patch1.target_home=c:\oracle\product\dbhome_19_27_0
patch1.sid=DB19
patch1.folder=c:\oracle\patches
patch1.patch=RECOMMENDED
patch1.wincredential=c:\oracle\autoupgrade\credential
patch1.delete_credential_file=false

wincredential is the location where AutoUpgrade stores the credential file.
Set delete_credential_file to false to keep the credential file so you can re-use it.

Load the credentials for the user running the service into a credential file:

java -jar autoupgrade.jar 
     -config ...
     –patch 
     -load_win_credential "DB19"

Start AutoUpgrade in deploy mode:
```
java -jar autoupgrade.jar 
     -config ...
     –patch 
     -mode deploy
```
- AutoUpgrade finds and downloads the right patches for Windows.
- Creates a new Oracle home with the new patches.
- Completes the entire patching process.

That’s it! You’ve patched your Oracle Database on Windows.

Here’s a little demo from our YouTube channel. Be sure to subscribe so you don’t miss out.

Happy patching!

The Easiest Way to Download 19.27 Release Update

Oracle just released new Release Updates, so it’s time to patch your Oracle Database again. As much as I love patching, the part about finding and downloading patches is not that much fun.

Luckily, I can use AutoUpgrade to download the Release Update and other patches with just a few commands.

How to Download Release Updates

I can do the following on any computer. I just need Java 8 or 11 to run AutoUpgrade.

I download the latest version of AutoUpgrade:

wget https://download.oracle.com/otn-pub/otn_software/autoupgrade.jar

I create an AutoUpgrade config file called get-patches:

global.global_log_dir=/home/oracle/autoupgrade/logs
global.keystore=/home/oracle/autoupgrade/keystore
global.folder=/home/oracle/autoupgrade/patches

patch1.platform=LINUX.X64
patch1.patch=RU:19.27,OPATCH,OJVM

I want to download 19.27 Release Update and supporting patches for Linux and I specify that using the platform parameter.

I’ve already used AutoUpgrade to download patches, so my My Oracle Support credentials are already stored in the AutoUpgrade keystore. If you’ve never used AutoUpgrade to download patches, follow the instructions below (see Creating an AutoUpgrade Keystore).

I download the patches by starting AutoUpgrade in download mode:

java -jar autoupgrade.jar -config get-patches -patch -mode download

That’s it! I’ve download all the new Release Updates – plus OPatch and the matching OJVM bundle patch.
- DATABASE RELEASE UPDATE 19.27.0.0.0 – p37642901_190000_Linux-x86-64.zip
- OJVM RELEASE UPDATE 19.27.0.0.0 – p37499406_190000_Linux-x86-64.zip
- OPatch 12.2.0.1.46 for DB 19.0.0.0.0 (Apr 2025) – p6880880_190000_Linux-x86-64.zip

Is it really that easy? Yes, it is…

Happy patching!

What About the Other Platforms

At the time of writing, Oracle has only released the Linux patches. Once the other platforms are available, you can easily download them as well. Check the Patch Availability Document for details. Add the following to your config file:

patch2.platform=ARM.x64
patch2.patch=RU:19.27,OPATCH,OJVM

patch3.platform=AIX.x64
patch3.patch=RU:19.27,OPATCH,OJVM

patch4.platform=SPARC.x64
patch4.patch=RU:19.27,OPATCH,OJVM

patch5.platform=SOLARIS.x64
patch5.patch=RU:19.27,OPATCH,OJVM

patch6.platform=WINDOWS.X64
patch6.patch=RU:19.27,OPATCH,OJVM

Creating an AutoUpgrade Keystore

The first time I use AutoUpgrade to download patches, I must store my MOS credentials in the AutoUpgrade keystore.

I create my config file. It must include global.keystore to specify the location of the AutoUpgrade keystore.

I start the password console:

java -jar autoupgrade.jar -config get-patches -patch -load_password

AutoUpgrade prompts for a password to protect its keystore. AutoUpgrade uses the password to encrypt the keystore, which stores my My Oracle Support credentials.
- This is not the database keystore password that you use for TDE Tablespace Encryption.
```
Processing config file ...

Starting AutoUpgrade Patching Password Loader - Type help for available options
Creating new AutoUpgrade Patching keystore - Password required
Enter password:
Enter password again:
```

I specify my MOS username. AutoUpgrade then prompts me for the MOS password:

MOS> add -user <mos-username-or-email>
Enter your secret/Password:
Re-enter your secret/Password:

I save the changes, and I choose to create an auto-login keystore so I don’t have to enter the AutoUpgrade keystore password every time AutoUpgrade starts:
```
MOS> save
Convert the AutoUpgrade Patching keystore to auto-login [YES|NO] ? YES
```

I exit, and that’s it:

MOS> exit

AutoUpgrade Patching Password Loader finished - Exiting AutoUpgrade Patching

Here’s a video explaining the use of the AutoUpgrade keystore:

Pro Tips

After downloading the patches, I still need to patch my databases. I can do that using AutoUpgrade as well.
Once MRPs (888.1) or critical fixes (555.1) become available for the Release Update, I can get those as well. Or, if I need specific one-off patches:
```
patch1.patch=RU:19.27,OPATCH,OJVM,MRP,12345678,23456789,34567890
```
If the Data Pump bundle patch is also available, I can also get that:
```
patch1.patch=RU:19.27,OPATCH,OJVM,DPBP,MRP,12345678,23456789,34567890
```
- Notice the DPBP keyword, that toggles the download of the Data Pump bundle patch.

What About Grid Infrastructure

Although AutoUpgrade can’t patch Grid Infrastructure, it can still get the GI bundle patch:
```
patch1.patch=RU:19.27,OCW
```

Be sure to patch Grid Infrastructure out-of-place and I’d recommend using the SwitchGridHome method.

Introduction to Patching Oracle Data Guard

Here’s a blog post series about patching Oracle Data Guard in single instance configuration. For simplicity, I am patching with Oracle AutoUpgrade to automate the process as much as possible.

First, a few ground rules:

Always use out-of-place patching
You must have the same set of patches on primary and standby

The Methods

There are three ways of patching Data Guard:

All At Once

You patch all databases at the same time.
You need an outage until you’ve patched all databases.
You need to do more work during the outage.
You turn off redo transport while you patch.

Standby-first with restart

All the patches you apply must be standby-first installable (see appendix).
You need an outage to stop the primary database and restart it in the target Oracle home.
During the outage, you have to do less work to do compared to all at once and less work overall compared to standby-first with switchover.
The primary database remains the same. It is useful if you have an async configuration with a much more powerful primary database or just prefer to have a primary database at one specific location.

Standby-first with switchover

All the patches you apply must be standby-first installable (see appendix).
You need an outage to perform a switchover. If your application is well-configured, users will just experience it as a brownout (hanging for a short period while the switchover happens).
During the outage, you have little to do, but overall, there are more steps.
After the outage, if you switch over to an Active Data Guard, the workload from the read-only workload has pre-warmed the buffer cache and shared pool.

Summary

All at one	Standby-first with restart	Standby-first with switchover
Works for all patches	Works for most patches	Works for most patches
Bigger interruption	Bigger interruption	Smaller interruption
Downtime is a database restart	Downtime is a database restart	Downtime/brownout is a switchover
Slightly more effort	Least effort	Slightly more effort
Cold database	Cold database	Pre-warmed database if ADG

Here’s a decision tree you can use to find the method that suits you.

What If

RAC

These blog posts focus on single instance configuration.

Conceptually, patching Data Guard with RAC databases is the same; you can’t use the step-by-step guides in this blog post series. Further, AutoUpgrade doesn’t support all methods of patching RAC databases (yet).

I suggest that you take a look at these blog posts instead:

Or even better, use Oracle Fleet Patching and Provisioning.

Oracle Restart

You can use these blog posts if you’re using Oracle Restart. You can even combine patching Oracle Restart and Oracle Database into one operation using standby-first with restart.

We’re Really Sensitive To Downtime?

In these blog posts, I choose the easy way – and that’s using AutoUpgrade. It automates many of the steps for me and has built-in safeguards to ensure things don’t go south.

But this convenience comes at a price: sligthly longer outage. Partly, because AutoUpgrade doesn’t finish a job before all post-upgrade tasks are done (like Datapatch and gathering dictionary stats).

If you’re really concerned about downtime, you might be better off with your own automation, where you can open the database for business as quickly as possible while you run Datapatch and other post-patching activities in the background.

Datapatch

Just a few words about patching Data Guard and Datapatch.

You always run Datapatch on the primary.
You run Datapatch just once, and the changes to the data dictionary propagates to the standby via redo.
You run Datapatch when all databases are running out of the new Oracle home or when redo transport is turned off. The important part is that the standby that applies the Datapatch redo must be on the same patch level as the primary.

Happy patching

Appendix

Standby-First Installable

You can only perform standby-first patch apply if all the patches are marked as standby-first installable.

Standby-first patch apply is when you patch the standby database first, and you don’t disable redo transport/apply.

You can only use standby-first patch apply if all the patches are classified as standby-first installable. For each of the patches, you must:

Examine the patch readme file.
One of the first lines will tell if this specific patch is standby-first installable. It typically reads: > This patch is Data Guard Standby-First Installable

Release Updates are always standby-first installable, and so are most of the patches for Oracle Database.

In rare cases, you find a non-standby-first installable patch, so you must patch Data Guard using all at once.

How To Patch Oracle Data Guard Using AutoUpgrade And Standby-First Patch Apply With Switchover

Let me show you how I patch my Oracle Data Guard configuration. I make it as easy as possible using Oracle AutoUpgrade. I reduce the interruption by doing standby-first patch apply with a switchover.

My Data Guard configuration consists of two databases:
- SID: SALES
- Databases: SALES_COPENHAGEN and SALES_AARHUS
- Hosts: copenhagen and aarhus
- Primary database: SALES_COPENHAGEN running on copenhagen

Preparations

You should do these preparations in advance of your maintenance window. They don’t interupt operations on your databases.

I download the patches using AutoUpgrade.
- I can download the patches from any computer. It doesn’t have to be one of the database hosts, which typically don’t have internet access.
I verify all patches are standby-first installable and my configuration meets the requirements for standby-first patch apply.

I create a new Oracle home on all hosts.

Create a config file called sales.cfg:

global.global_log_dir=/home/oracle/autoupgrade-patching/sales
patch1.source_home=/u01/app/oracle/product/19.3.0.0/dbhome_1
patch1.target_home=/u01/app/oracle/product/19/dbhome_19_26_0
patch1.sid=SALES
patch1.folder=/home/oracle/autoupgrade-patching/patch
patch1.patch=RECOMMENDED,MRP
patch1.download=no

Start AutoUpgrade in create_home mode:

java -jar autoupgrade.jar -config sales.cfg -patch -mode create_home

AutoUpgrade also runs root.sh if oracle user has sudo privileges. Else, I must manually execute root.sh.

Optionally, but recommended, I run an analysis on the primary database:
```
[oracle@copenhagen] java -jar autoupgrade.jar -config sales.cfg -patch -mode analyze
```
- Check the findings in the summary report.

Patching

Proceed with the following when your maintenance window starts.

Update listener.ora on the standby host (see appendix). I change the ORACLE_HOME parameter in the static listener entry (suffixed _DGMGRL) so it matches my target Oracle home.
I reload the listener:
```
[oracle@aarhus] lsnrctl reload
```

Patch the standby database:

[oracle@aarhus] java -jar autoupgrade.jar -config sales.cfg -mode deploy

I don’t disable redo transport/apply.

Optionally, test the application of patches using a snapshot standby database.
interruption starts!
Switch over to SALES_AARHUS:
```
DGMGRL> switchover to sales_aarhus;
```
- Perform draining in advance according to your practices.
- Depending on how your application is configured, the users will experience this interruption as a brown-out or downtime.
Update listener.ora on the new standby host (copenhagen). I change the ORACLE_HOME parameter in the static listener entry (suffixed _DGMGRL) so it matches my target Oracle home.
I reload the listener:
```
[oracle@copenhagen] lsnrctl reload
```

Patch the new standby database (see appendix):

[oracle@copenhagen] java -jar autoupgrade.jar -config sales.cfg -mode deploy

Verify the Data Guard configuration and ensure the standby database is receiving and applying redo:

DGMGRL> show database SALES_COPENHAGEN;
DGMGRL> show database SALES_AARHUS;
DGMGRL> validate database SALES_COPENHAGEN;
DGMGRL> validate database SALES_AARHUS;

Post-Patching

Connect to the new primary database and execute Datapatch. You do that by calling AutoUpgrade in upgrade mode:
```
[oracle@aarhus] java -jar autoupgrade.jar -config sales.cfg -mode upgrade -clear_recovery_data
```
- Since I’m reusing the same config file, I must add the -clear_recovery_data flag. Otherwise, AutoUpgrade gets a little confused.

Happy Patching!

Appendix

Static Listener Entry

In this blog post, I update the static listener entries required by Data Guard broker (suffixed DGMGRL). My demo environment doesn’t use Oracle Restart or Oracle Grid Infrastructure, so this entry is mandatory.

If you use Oracle Restart or Oracle Grid Infrastructure, such entry is no longer needed.

Avoid Problems on the Primary Database by Testing on a Snapshot Standby

One of the advantages of standby-first patch apply, is that I can test the patches in a production-like environment (the standby) before applying them to the primary. Should I find any issues with the patches, I can stop the process and avoid impacting the primary database.

Here’s an overview of the process.

For demo purposes, my Data Guard configuration consists of two databases:

SID: SALES
Databases: SALES_COPENHAGEN and SALES_AARHUS
Hosts: copenhagen and aarhus
Primary database: SALES_COPENHAGEN running on copenhagen

How To

This procedure starts right after I’ve patched the standby (SALES_AARHUS). It runs out of the target Oracle home, whereas the primary database (SALES_COPENHAGEN) still runs on the source Oracle home.

Convert the patched standby to a snapshot standby:
```
DGMGRL> convert database SALES_AARHUS to snapshot standby;
```
- The database sets a guaranteed restore point before opening the standby in READ WRITE mode.
Test the patch apply by running Datapatch on the standby:
```
[oracle@aarhus] $ORACLE_HOME/OPatch/datapatch
```
- One always runs Datapatch on the primary database and the changes made by the patches goes into redo to the standby.
- But, since I converted to a snapshot standby, it is now opened like a normal database and I can run Datapatch on it.
- If Datapatch completes without problems on the standby, I can be pretty sure it will do so on the primary as well. The standby is after all an exact copy of the primary database.
Optionally, perform additional testing on the standby.
- I can connect any application and perform additional tests.
- I can use SQL Performance Analyzer to check for regressing SQL statements.
- I can make changes to any data in the standby. It is protected by a restore point.
When done, convert the snapshot standby back to a physical standby:
```
DGMGRL> convert database SALES_AARHUS to physical standby;
```
- This implicitly shuts down the standby, flashes back to the restore point and re-opens the database as a physical standby.
- All changes made when it was a snapshot standby, including the Datapatch run, are undone.

Continue the patching procedure on the primary database as described elsewhere.

Is It Safe?

Sometimes, when I suggest using the standby for testing, people are like: Huh! Seriously?

What Happens If I Need to Switch Over or Fail Over?

I can still perform a switchover or a failover. However, they will take a little bit longer.

When I convert to snapshot standby:

Redo transport is still active.
Redo apply is turned off.

So, the standby receives all redo from the primary but doesn’t apply it. Since you normally test for 10-20 minutes, this would be the maximum apply lag. On a well-oiled standby, it shouldn’t take more than a minute or two to catch up.

When performing a switchover or failover on a snapshot standby, you should expect an increase with the time it takes to:

Shut down
Flashback
Apply redo

I’d be surprised if that would be more than 5 minutes. If your RTO doesn’t allow for a longer period:

Get a second standby.
Consider the reduction in risk you get when you test on the standby. Perhaps a short increase in RTO could be allowed after all.

What Happens If Datapatch Fails

If Datapatch fails on my snapshot standby, I should be proud of myself. I just prevented the same problem from hitting production.

I grab all the diagnostic information I need, so I can work with Oracle Support on the issue.
Convert back to physical standby, which will undo the failed Datapatch run.
If I expect to solve the issue quickly, leave the standby running in the target Oracle home. Otherwise, put it back into the source Oracle home.

So, yes, it’s safe to use!

Happy testing

Appendix

How To Patch Oracle Data Guard Using AutoUpgrade For Non-Standby-First Installable Patches

Let me show you how I patch my Oracle Data Guard configuration. I make it easy using Oracle AutoUpgrade. I patch all at once – all databases at the same time – which means a short downtime. I can use this approach for all patches – even those that are not standby-first installable.

I recommend this approach only when you have patches that are not standby-first installable.

My Data Guard configuration consists of two databases:
- SID: SALES
- Databases: SALES_COPENHAGEN and SALES_AARHUS
- Hosts: copenhagen and aarhus
- Primary database: SALES_COPENHAGEN running on copenhagen

Preparations

You should do these preparations in advance of your maintenance window. They don’t interupt operations on your databases.

I download the patches using AutoUpgrade.
- I can download the patches from any computer. It doesn’t have to be one of the database hosts, which typically don’t have internet access.

I create a new Oracle home on all hosts.

Create a config file called sales.cfg:

global.global_log_dir=/home/oracle/autoupgrade-patching/sales
patch1.source_home=/u01/app/oracle/product/19.3.0.0/dbhome_1
patch1.target_home=/u01/app/oracle/product/19/dbhome_19_26_0
patch1.sid=SALES
patch1.folder=/home/oracle/autoupgrade-patching/patch
patch1.patch=RECOMMENDED,MRP
patch1.download=no

Start AutoUpgrade in create_home mode:

java -jar autoupgrade.jar -config sales.cfg -patch -mode create_home

AutoUpgrade also runs root.sh if oracle user has sudo privileges. Else, I must manually execute root.sh.

Optionally, but recommended, I run an analysis on the primary database:
```
[oracle@copenhagen] java -jar autoupgrade.jar -config sales.cfg -patch -mode analyze
```
- Check the findings in the summary report.

Patching

Proceed with the following when your maintenance window starts.

I connect to the primary database using Data Guard broker and disable redo transport from the primary database:
```
DGMGRL> edit database sales_copenhagen set state='TRANSPORT-OFF';
```
I update listener.ora on both hosts (see appendix). I change the ORACLE_HOME parameter in the static listener entry (suffixed _DGMGRL) so it matches my target Oracle home.
I reload the listener on both hosts:
```
lsnrctl reload
```
Downtime starts!
- Perform draining in advance according to your practices.
- Shut down your application.

Patch the primary database:

[oracle@copenhagen] java -jar autoupgrade.jar -config sales.cfg -patch -mode deploy

Simultaneously, I patch the standby database:

[oracle@aarhus] java -jar autoupgrade.jar -config sales.cfg -mode deploy

I update my profile and scripts so they point to the target Oracle home.

When patching completes in both hosts, I re-enable redo transport:

DGMGRL> edit database sales_copenhagen set state='TRANSPORT-ON';

Verify the Data Guard configuration and ensure the standby database is receiving and applying redo:

DGMGRL> show database SALES_COPENHAGEN;
DGMGRL> show database SALES_AARHUS;
DGMGRL> validate database SALES_COPENHAGEN;
DGMGRL> validate database SALES_AARHUS;

That’s it.

Happy Patching!

Appendix

Static Listener Entry

If you use Oracle Restart or Oracle Grid Infrastructure, such entry is no longer needed.

How To Patch Oracle Data Guard Using AutoUpgrade And Standby-First Patch Apply With Restart

Let me show you how I patch my Oracle Data Guard configuration. I make it as easy as possible using Oracle AutoUpgrade. I reduce the interuption by doing standby-first patch apply with a primary database restart.

My Data Guard configuration consists of two databases:
- SID: SALES
- Databases: SALES_COPENHAGEN and SALES_AARHUS
- Hosts: copenhagen and aarhus
- Primary database: SALES_COPENHAGEN running on copenhagen

Preparations

You should do these preparations in advance of your maintenance window. They don’t interupt operations on your databases.

I download the patches using AutoUpgrade.
- I can download the patches from any computer. It doesn’t have to be one of the database hosts, which typically don’t have internet access.
I verify all patches are standby-first installable and my configuration meets the requirements for standby-first patch apply.

I create a new Oracle home on all hosts.

Create a config file called sales.cfg:

global.global_log_dir=/home/oracle/autoupgrade-patching/sales
patch1.source_home=/u01/app/oracle/product/19.3.0.0/dbhome_1
patch1.target_home=/u01/app/oracle/product/19/dbhome_19_26_0
patch1.sid=SALES
patch1.folder=/home/oracle/autoupgrade-patching/patch
patch1.patch=RECOMMENDED,MRP
patch1.download=no

Start AutoUpgrade in create_home mode:

java -jar autoupgrade.jar -config sales.cfg -patch -mode create_home

AutoUpgrade also runs root.sh if oracle user has sudo privileges. Else, I must manually execute root.sh.

Optionally, but recommended, I run an analysis on the primary database:
```
[oracle@copenhagen] java -jar autoupgrade.jar -config sales.cfg -patch -mode analyze
```
- Check the findings in the summary report.

Patching

Proceed with the following when your maintenance window starts.

Update listener.ora on the standby host (see appendix). I change the ORACLE_HOME parameter in the static listener entry (suffixed _DGMGRL) so it matches my target Oracle home.
I reload the listener:
```
[oracle@aarhus] lsnrctl reload
```

Patch the standby database:

[oracle@aarhus] java -jar autoupgrade.jar -config sales.cfg -mode deploy

I don’t disable redo transport/apply.

Optionally, test the application of patches using a snapshot standby database.
Downtime starts!
- Perform draining in advance according to your practices.
- Shut down your application.
Update listener.ora on the primary host (see appendix). I change the ORACLE_HOME parameter in the static listener entry (suffixed _DGMGRL) so it matches my target Oracle home.
I reload the listener:
```
[oracle@copenhagen] lsnrctl reload
```
Patch the primary database (see appendix):
```
[oracle@copenhagen] java -jar autoupgrade.jar -config sales.cfg -patch -mode deploy
```
- I use the sales.cfg config file.
- AutoUpgrade detects it’s running against the primary database, and executes Datapatch and all the post-upgrade tasks.

Verify the Data Guard configuration and ensure the standby database is receiving and applying redo:

DGMGRL> show database SALES_COPENHAGEN;
DGMGRL> show database SALES_AARHUS;
DGMGRL> validate database SALES_COPENHAGEN;
DGMGRL> validate database SALES_AARHUS;

That’s it.

Happy Patching!

Appendix

Static Listener Entry

If you use Oracle Restart or Oracle Grid Infrastructure, such entry is no longer needed.

AutoUpgrade New Features: Extended Platform Support

From the inception of Oracle AutoUpgrade, our clear ambition has been to support all platforms where you can run Oracle Database.

We still work with this ambition in mind, and the latest version of AutoUpgrade lifts additional platform restrictions. Now, you can enjoy AutoUpgrade’s true awesomeness on even more platforms.

Photo by Museums Victoria on Unsplash

Patching

You can now use one-button patching on the following platforms:

Linux x86-64
LINUX ARM
Microsoft Windows x64
Oracle Solaris on SPARC
Oracle Solaris on x86-64
IBM AIX on POWER Systems

How to Patch a Database

Ensure that you have the latest version of AutoUpgrade:

wget https://download.oracle.com/otn-pub/otn_software/autoupgrade.jar

Patch your database using the instructions from my previous blog post or our webinar.

How to Download Patches for Other Platforms

You can also use AutoUpgrade to just download patches from My Oracle Support and you can download for multiple platforms.

Ensure that you have the latest version of AutoUpgrade:

wget https://download.oracle.com/otn-pub/otn_software/autoupgrade.jar

Create a config file. Note there are two prefixes – one for Linux and one for Windows.

global.global_log_dir=/home/oracle/autoupgrade-patching/log
global.keystore=/home/oracle/autoupgrade-patching/keystore

patch1.folder=/home/oracle/autoupgrade-patching/patch
patch1.patch=RECOMMENDED
patch1.target_version=19
patch1.platform=LINUX.X64

patch2.folder=/home/oracle/autoupgrade-patching/patch
patch2.patch=RECOMMENDED
patch2.target_version=19
patch2.platform=WINDOWS.X64

Download the latest Release Update and other recommended patches for Linux and Windows:
```
java -jar autoupgrade.jar -config download.cfg -patch -mode download
```

You can tweak it even further:

Download for additional platforms by adding more prefixes. Check the documentation for supported platform names.
Download one-off patches or other patches by adding them to the patch parameter.

Some useful information:

If you omit platform it defaults to your current platform. If AutoUpgrade doesn’t support your current platform (like when you run AutoUpgrade on a Mac), it defaults to LINUX.X64.
Rodrigo Jorge from my team has a good blog post showing how to use download mode.

Windows

AutoUpgrade has supported upgrading on Windows right since the beginning – with the exception of Oracle RAC. But now, this restriction is lifted, so you can upgrade your Oracle RAC as well.

For patching, AutoUpgrade also supports Oracle RAC on Windows. But for now, it doesn’t perform rolling patching (nor does it do so on any platform). You still need opatchauto for that.

Instead, AutoUpgrade performs an all-node patching. It brings down all nodes at once, which means database downtime.

Linux 9

The latest release also includes a few bugs related to Oracle Linux 9. You should be able to use AutoUpgrade on this platform without problems.

Happy patching

The Basics

How to Patch the Listener

The Outage

Do I Need to Patch the Listener and Database At the Same Time?

What About AutoUpgrade?

Benefits of Out-Of-Place Patching

AutoUpgrade

How to Patch Out-Of-Place on Exadata Cloud@Customer

Appendix

Other Methods

Further Reading

How To Patch Oracle Database on Windows

How to Download Release Updates

What About the Other Platforms

Creating an AutoUpgrade Keystore

Pro Tips

What About Grid Infrastructure

Further Reading

The Methods

All At Once

Standby-first with restart

Standby-first with switchover

Summary

What If

RAC

Oracle Restart

We’re Really Sensitive To Downtime?

Datapatch

Appendix

Standby-First Installable

Other Blog Posts in the Series

Preparations

Patching

Post-Patching

Appendix

Static Listener Entry

Further Reading

Other Blog Posts in the Series

How To

Is It Safe?

What Happens If I Need to Switch Over or Fail Over?

What Happens If Datapatch Fails

Appendix

Other Blog Posts in the Series

Preparations

Patching

Appendix

Static Listener Entry

Further Reading

Other Blog Posts in the Series

Preparations

Patching

Appendix

Static Listener Entry

Further Reading

Other Blog Posts in the Series

Patching

How to Patch a Database

How to Download Patches for Other Platforms

Windows

Linux 9