Manual OPatch Apply for Oracle RAC (Primary & Standby) – 19.27 Release Update
As a seasoned Oracle Database Administrator, I’ve navigated the intricate landscape of Oracle Real Application Clusters (RAC) and Data Guard configurations. Over the years, I’ve encountered numerous challenges, particularly when it comes to patching these complex environments. One of the most intricate tasks is applying patches manually using OPatch, especially in a RAC setup with a primary and standby configuration.
Recently, I came across an article detailing the step-by-step process of manually applying the 19.27 Release Update using OPatch in an Oracle RAC environment. While the article provides a comprehensive walkthrough, I felt compelled to share my own insights and experiences, adding a personal touch to the process. My aim is to not only guide you through the technical steps but also to offer practical advice, real-world scenarios, and best practices that I’ve gathered over the years.
Patching is not just a routine maintenance task; it’s a critical operation that ensures the stability, security, and performance of your database systems. A misstep can lead to significant downtime, data loss, or security vulnerabilities. Therefore, understanding the nuances of manual patching in a RAC environment is essential for any DBA.
In this guide, I’ll walk you through the entire process of manually applying the 19.27 Release Update using OPatch in an Oracle RAC setup with a primary and standby configuration. Along the way, I’ll share personal anecdotes, highlight common pitfalls, and provide tips to make the process smoother and more reliable.
Step-by-Step Guide
1. Check Environment Details
Before initiating the patching process, it’s crucial to have a clear understanding of your current environment. This includes:
- Oracle Database Version: Ensure you’re running Oracle 19c, as the 19.27 Release Update is specific to this version.
- Operating System: Verify the OS version and architecture (e.g., Oracle Linux 7.9, x86_64).
- Cluster Configuration: Identify the number of nodes in your RAC setup and confirm the primary and standby roles.
- OPatch Version: The OPatch utility must be updated to version 12.2.0.1.45 or later to apply this patch.
Personal Tip: Documenting your environment details not only aids in the patching process but also serves as a valuable reference for future maintenance tasks.
2. Prerequisites
Before applying the patch, ensure the following prerequisites are met:
- Read the README Files: Each patch comes with a README file detailing specific instructions, prerequisites, and post-patching steps. It’s imperative to read and understand these instructions thoroughly.
Oracle® Database Patch 37641958 – GI Release Update 19.27.0.0.250415
You must use the OPatch utility version 12.2.0.1.45 or later to apply this patch
- Backup: Always take a full backup of your database and configuration files. This includes the Oracle Home, Grid Infrastructure Home, and any custom scripts or configurations.
- Check for Invalid Objects: Run the following SQL queries to identify any invalid objects:
Real-World Scenario: In a previous patching operation, I neglected to check for invalid objects beforehand. Post-patching, several application modules failed due to invalid PL/SQL packages. A simple pre-check could have prevented hours of troubleshooting.
3. Download Patches
Obtain the necessary patches from Oracle Support:
Note: Ensure you have the appropriate access rights to download patches from Oracle Support.
4. Check New Patch Numbers & Descriptions
After downloading, verify the patch numbers and descriptions to ensure they match your intended updates. This can be done by reviewing the patch metadata or using the opatch utility:
opatch lsinventory
Advice: Keeping a record of patch numbers and descriptions helps in tracking applied patches and is beneficial during audits or troubleshooting.
5. Check Current OPatch Version & Installed Patches
Before proceeding, confirm the current OPatch version and list of installed patches:
# For Database Home
. oraenv
opatch version
opatch lspatches
# For Grid Infrastructure Home
. oraenv
opatch version
opatch lspatches
Personal Experience: During one patching session, I discovered that the OPatch utility was outdated, leading to patch application failures. Regularly updating OPatch ensures compatibility with the latest patches.
6. Copy Patches to All Servers
Transfer the downloaded patches to a consistent directory on all nodes, such as /u01/software/. Ensure proper ownership and permissions:
mkdir -p /u01/software/
cp /path/to/patches/* /u01/software/
chown -R oracle:oinstall /u01/software/
Tip: Using a shared file system or automation tools like Ansible can streamline this process in larger environments.
7. Update OPatch Utility Both Oracle Homes and Grid Homes
Update the OPatch utility in both the Oracle Home and Grid Infrastructure Home:
# For Grid Infrastructure Home
cd $GRID_HOME
mv OPatch OPatch_backup
unzip /u01/software/p6880880_190000_Linux-x86-64.zip
# For Database Home
cd $ORACLE_HOME
mv OPatch OPatch_backup
unzip /u01/software/p6880880_190000_Linux-x86-64.zip
Reminder: Always backup the existing OPatch directory before updating.
8. Unzip the Patch on All Servers
Extract the patch files on each node:
cd /u01/software/
unzip p37641958_190000_Linux-x86-64.zip
Note: Replace p37641958_190000_Linux-x86-64.zip with the actual patch file name.
9. Run OPatch Conflict Checks Both Grid and Oracle Homes
Before applying the patch, perform conflict checks to identify any potential issues:
# For Grid Infrastructure Home
cd $GRID_HOME
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /u01/software/37641958/37642901
# For Database Home
cd $ORACLE_HOME
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /u01/software/37641958/37642901
Advice: Resolving conflicts beforehand prevents patch application failures and ensures a smoother process.
10. Run OPatch System Space Checks Both Grid and Oracle Homes
Ensure sufficient disk space is available for the patching process:
# For Grid Infrastructure Home
cd $GRID_HOME
opatch prereq CheckSystemSpace -phBaseDir /u01/software/37641958/37642901
# For Database Home
cd $ORACLE_HOME
opatch prereq CheckSystemSpace -phBaseDir
Standby-First Approach: Why It’s Crucial & How to Execute It
One of the best practices in Oracle patching – especially in Data Guard setups – is the standby-first approach. The idea is simple: apply the patch first on the standby database before touching the primary. Why?
Why is this approach important?
- Risk Mitigation: If the patch causes issues, your primary remains unaffected, and you can roll back changes from standby.
- Zero Downtime Option: If you have Active Data Guard, users can continue read operations while the patch is being tested on the standby.
- Testing Ground: It becomes a rehearsal for the real thing, allowing you to validate the patch impact.
How to apply it:
- Apply patch on standby nodes: Follow the same patching steps (conflict check, space check, apply).
- Restart standby services and validate logs and health.
- Perform a switchover (optional) to test the patched standby in primary role (if allowed by downtime window).
- Once confirmed, patch the actual primary.
Hypothetical Case: Imagine you’re working for a bank. The primary serves real-time transactions. You patch standby first during non-peak hours, and once it passes validation, you safely patch the primary node after switching roles—zero risk to end-user banking operations.
Rollback Plan: What If Something Goes Wrong?
Every seasoned DBA knows: hope for the best, prepare for the worst. Oracle patching isn’t foolproof, and having a rollback plan is your safety net.
Your rollback toolkit should include:
- Pre-patch backup: Using RMAN or snapshot-based backups of Oracle Home/Grid Home.
- OPatch rollback commands: Keep the exact patch numbers handy. For example:
- Restore OPatch directory: If OPatch was upgraded, have a backup (OPatch_backup) ready.
- Listener and Cluster Services status: Know how to bring services back online manually.
Real Scenario: One of our clients in the manufacturing industry applied the patch without checking kernel compatibility. The node crashed during Grid Home patching. Thanks to our rollback and OCR backups, we were back up in 45 minutes.
Key advice:
- Keep a patch rollback test script.
- Never skip validating the rollback ID from the README.
- Keep cluster logs and alert logs ready for immediate troubleshooting.
Final Validation Steps After Patching
Once patching is complete on all nodes (standby and primary), validation is your final checkpoint before business resumes.
What to validate:
- DB and GI Services:
- Listener & Cluster Health:
- Patch Verification:
- Database Health Check:
- Application Testing: Engage your app teams for smoke testing—check login modules, batch jobs, or ETL loads.
Example: In a telecom setup we worked with, post-patching validation discovered a job scheduler failed due to a missed environment variable reset. That 5-minute check saved a potential escalation from the L2 support team.
Summary: What You’ve Learned
Let’s recap the key points this guide covered:
- Environment checks and prerequisites
- Backing up and validating objects
- Patch download, unzip, conflict checks, and system space analysis
- Manual OPatch apply process for both Grid and DB Homes
- Standby-first strategy to reduce risk
- Rollback planning for safety
- Final validation steps to close the loop confidently
This is not just theory-it’s a playbook from the field, based on real patching stories from banking, telecom, and e-commerce companies.
Conclusion: Patching with Confidence
Patching an Oracle RAC environment with a Data Guard setup manually using OPatch is not just a checklist of steps – it’s a process that demands planning, precision, and a deep understanding of your environment.
Through this article, I’ve not only shown you how to apply the 19.27 Release Update but also walked you through the why behind each step – something I believe makes all the difference between a good DBA and a great one.
Whether you’re working in a mid-sized company or handling mission-critical systems for an enterprise, patching isn’t just maintenance – it’s a form of preventive care. Think of it like updating the brakes on a high-speed train: it’s not glamorous, but it’s essential to keep things safe and smooth.
Takeaways to Remember:
- Always back up before you patch.
- Read the README. Twice.
- Validate both before and after.
- Don’t underestimate post-patching checks.Takeaways to Remember:
- Automate wherever possible, but understand the manual process first.
If you’re doing this for the first time, take your time. If you’re experienced, revisit your strategy to see what you can optimize. And always document everything — because six months later, your future self will thank you.
At Learnomate Technologies Pvt Ltd, we truly believe that strong real-world knowledge makes all the difference – especially in critical areas like Oracle RAC patching. That’s why we provide some of the best industry-oriented training, where you learn from practical examples, not just theory.
If you’re serious about building your skills, do check out our YouTube channel for better insights and real-world tutorials: www.youtube.com/@learnomate.
Also, feel free to explore more about our training programs on our official website: www.learnomate.org.
If you’d like to stay connected and keep learning together, follow me on LinkedIn too: Ankush Thavali – LinkedIn. I keep sharing useful tips, guides, and a lot more over there!
And hey — if you love reading and want to dive deeper into different technologies, you can always check out our blog section here: Learnomate Blogs.
Let’s keep learning and growing together!
Happy Reading!
Ankush😎